trabajo fin de estudios - biblioteca.unirioja.es · el objetivo del proyecto es la creación de una...

TRABAJO FIN DE ESTUDIOS

Aplicación web para la escuela de fútbol de Mareo enLogroño

Abel Sierra Gómez

PROYECTO FIN DE CARRERA

Tutor: Juan José Olarte Larrea

Curso 2011-2012

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

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

Aplicación web para la escuela de fútbol de Mareo en Logroño, trabajo fin deestudios

de Abel Sierra Gómez, dirigido por Juan José Olarte Larrea (publicado por la Universidadde 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.

UNIVERSIDAD DE LA RIOJA

Facultad de Ciencias, Estudios Agroalimentarios e Informática

PROYECTO FIN DE CARRERA

Ingeniería Técnica en Informática de Gestión

Aplicación Web para la Escuela de Fútbol de

Mareo en Logroño

Alumno: Abel Sierra Gómez

Director: Juan José Olarte Larrea

Logroño, junio de 2012

1

Resumen

Este proyecto pretende desarrollar un sitio Web para la Escuela de Fútbol de Mareo en

Logroño que ayude a alojar toda la información referente a dicha escuela. Para ello, se creará

una aplicación Web que sirva como carta de presentación de la propia escuela y añada además

unas funcionalidades para los empleados que estén relacionados con la misma.

El servicio principal que debe ofrecer la aplicación es la gestión de estadísticas durante

la temporada para que puedan ser visibles y almacenadas en cualquier momento por los

empleados.

El empleado podrá mostrar, almacenar y modificar los datos de los empleados,

entrenadores, jugadores, padres y equipos que conforman la Escuela, las estadísticas de todos

y cada uno de los partidos jugados por cada equipo y jugador, y las faltas de asistencia al

entrenamiento.

Por último, al añadir una falta de asistencia al entrenamiento, la aplicación deberá

enviar un mensaje de correo y un mensaje de texto a móvil al padre del jugador para informar

de dicha falta.

2

Índice

Resumen ................................................................................................................................................ 1

Índice ..................................................................................................................................................... 2

Índice de Figuras .................................................................................................................................... 5

Índice de Tablas ..................................................................................................................................... 6

Introducción .......................................................................................................................................... 7

Tema abordado.................................................................................................................................... 7

Motivo de la elección ........................................................................................................................... 7

Límites .................................................................................................................................................. 7

Documento de Objetivos del Proyecto ................................................................................................... 8

Objetivo .................................................................................................................................................... 8

Participantes en el proyecto .................................................................................................................... 8

Comunicaciones ....................................................................................................................................... 8

Alcance del proyecto ................................................................................................................................ 9

Requisitos mínimos alcanzables .......................................................................................................... 9

Posibles ampliaciones de la plataforma .............................................................................................. 9

Metodología ............................................................................................................................................. 9

Tecnologías a utilizar .............................................................................................................................. 10

Identificación de riesgos y planes de acción .......................................................................................... 12

Riesgos posibles ................................................................................................................................. 12

Actuaciones previstas ante los riesgos .............................................................................................. 12

Entregables ............................................................................................................................................ 12

Descomposición de tareas ..................................................................................................................... 13

Calendario de trabajo semanal .......................................................................................................... 15

Diagrama de Gantt ............................................................................................................................ 15

Gestión del proyecto............................................................................................................................ 18

Introducción ........................................................................................................................................... 18

Factores del retraso ............................................................................................................................... 18

Comparación de estimaciones y resultados........................................................................................... 18

Comparación de fechas ...................................................................................................................... 18

Comparación de horas ....................................................................................................................... 18

Análisis de resultados............................................................................................................................. 19

Análisis ................................................................................................................................................ 20

Introducción ........................................................................................................................................... 20

Objetivo.............................................................................................................................................. 20

Ámbito ............................................................................................................................................... 20

Visión general ......................................................................................................................................... 20

Sistema .............................................................................................................................................. 20

Como posibles ampliaciones de la aplicación Web cabe destacar .................................................... 21

Usuarios de la aplicación ................................................................................................................... 21

Visión general del sistema ................................................................................................................. 22

Requisitos funcionales ....................................................................................................................... 22

Requisitos no funcionales .................................................................................................................. 23

3

Ciclo 1: Aplicación Web (Administrar y visualizar información) ............................................................ 25

Análisis ................................................................................................................................................ 25

Introducción ........................................................................................................................................... 25

Casos de Uso .......................................................................................................................................... 25

Administrar información de la aplicación Web .................................................................................. 25

Visualizar información de la aplicación Web ..................................................................................... 30


Diseño ................................................................................................................................................. 34

Introducción ........................................................................................................................................... 34

Descripción de los elementos básicos de Joomla! ................................................................................. 36

Prototipos de interfaz ............................................................................................................................ 37

Construcción ........................................................................................................................................ 40

Interfaces definitivas .............................................................................................................................. 40

Interfaces de administración ............................................................................................................. 40

Interfaces de visualización ................................................................................................................. 44

Ciclo 2: Gestionar estadísticas .............................................................................................................. 46

Análisis ................................................................................................................................................ 46

Introducción ........................................................................................................................................... 46

Casos de Uso .......................................................................................................................................... 46

Gestionar estadísticas ........................................................................................................................ 46


Requisitos no funcionales .................................................................................................................. 56

Prototipos de interfaz ............................................................................................................................ 57

Clases de análisis .................................................................................................................................... 60

Clases ................................................................................................................................................. 60

Diseño ................................................................................................................................................. 61

Diseño arquitectónico ............................................................................................................................ 61

Diseño de la base de datos .................................................................................................................... 62

Entidad relación ................................................................................................................................. 62

Modelo conceptual ............................................................................................................................ 64

Diagrama de base de datos ............................................................................................................... 65

Normalización .................................................................................................................................... 66

Clases de diseño ..................................................................................................................................... 67

Clases de negocio ............................................................................................................................... 67

Especificación de pruebas unitarias ....................................................................................................... 68

Clases de equivalencia ....................................................................................................................... 68

Identificación casos de prueba........................................................................................................... 69

Construcción ........................................................................................................................................ 71

Tecnología utilizada ............................................................................................................................... 71

Código relevante .................................................................................................................................... 71

Encriptar contraseña.......................................................................................................................... 71

Envío y recepción de datos del formulario ......................................................................................... 72

Evitar inyección SQL ........................................................................................................................... 72

Sesiones ............................................................................................................................................. 73

4

Capa de persistencia .......................................................................................................................... 75

Capa lógica de negocio ...................................................................................................................... 76

Codificar y decodificar una cadena a UTF-8....................................................................................... 78

Añadir Empleado ............................................................................................................................... 79

Interfaces definitivas .............................................................................................................................. 83

Resultados de las pruebas unitarias ....................................................................................................... 85

Ciclo 3: Control de las faltas de asistencia a los entrenamientos .......................................................... 88

Análisis ................................................................................................................................................ 88

Introducción ........................................................................................................................................... 88

Casos de Uso .......................................................................................................................................... 88

Gestionar control de faltas de asistencia a los entrenamientos ........................................................ 88


Clases de análisis .................................................................................................................................... 92

Clases ................................................................................................................................................. 92

Diseño ................................................................................................................................................. 93

Diseño de la base de datos .................................................................................................................... 93

Entidad relación ampliado ................................................................................................................. 93

Modelo conceptual ampliado ............................................................................................................ 94

Diagrama de base de datos ampliado ............................................................................................... 95

Clases de diseño ..................................................................................................................................... 96

Clases de negocio añadidas ............................................................................................................... 97

Especificación de pruebas unitarias ....................................................................................................... 97

Clases de equivalencia ....................................................................................................................... 97

Identificación casos de prueba........................................................................................................... 98

Construcción ...................................................................................................................................... 100

Tecnología utilizada ............................................................................................................................. 100

Código relevante .................................................................................................................................. 100

Enviar email ..................................................................................................................................... 100

Enviar SMS ....................................................................................................................................... 102

Añadir Falta Entrenamiento ............................................................................................................ 103

Interfaces definitivas ............................................................................................................................ 103

Resultados de las pruebas unitarias ..................................................................................................... 106

Pruebas de aceptación ......................................................................................................................... 107

Bibliografía ........................................................................................................................................ 108

Anexo A: Manual usuario Administración Joomla! (Back-end) .......................................................... 110

Anexo B: Actas de Reuniones ............................................................................................................. 119

Anexo C: Contenido del CD adjunto ................................................................................................... 121

5

Índice de Figuras

Figura 1: Diagrama de Gantt. Vista general. ............................................................................................... 15

Figura 2: Diagrama de Gantt. Seguimiento del proyecto. .......................................................................... 15

Figura 3: Diagrama de Gantt. Tareas de gestión del proyecto. .................................................................. 16

Figura 4: Diagrama de Gantt. Tareas del análisis del proyecto. ................................................................. 16

Figura 5: Diagrama de Gantt. Tareas del Ciclo 1: Administrar y visualizar aplicación Web. ...................... 16

Figura 6: Diagrama de Gantt. Tareas del Ciclo 2: Gestión estadísticas....................................................... 17

Figura 7: Diagrama de Gantt. Tareas del Ciclo 3: Control faltas de asistencia. .......................................... 17

Figura 8: Diagrama de Gantt. Defensa del proyecto. ................................................................................. 17

Figura 9: Visión general del sistema. .......................................................................................................... 22

Figura 10: Diagrama de casos de uso administrar componentes ............................................................... 25

Figura 11: Diagrama de casos de uso administrar contenidos de la aplicación Web ................................. 27

Figura 12: Diagrama de casos de uso administrar usuarios de la aplicación Web ..................................... 28

Figura 13: Diagrama de casos de uso administrar multimedia de la aplicación Web ................................ 29

Figura 14: Diagrama de casos de uso administrar inscripciones de la aplicación Web .............................. 29

Figura 15: Diagrama de casos de uso visualizar información aplicación Web ........................................... 30

Figura 16: Tablas BD Joomla!. Menu .......................................................................................................... 34

Figura 17: Tablas BD Joomla!. Banners ...................................................................................................... 35

Figura 18: Tablas BD Joomla!. Usuarios ...................................................................................................... 35

Figura 19: Prototipo de interfaz acceso administrador. Login ................................................................... 37

Figura 20: Prototipo de interfaz panel de control del administrador......................................................... 37

Figura 21: Prototipo de interfaz gestor categorías. .................................................................................... 38

Figura 22: Prototipo de interfaz aplicación Web ........................................................................................ 38

Figura 23: Prototipo de interfaz inscripción ............................................................................................... 39

Figura 24: Interfaz acceso administrador. Login ........................................................................................ 40

Figura 25: Interfaz panel de control del administrador. ............................................................................. 40

Figura 26: Interfaz gestor categorías. ......................................................................................................... 41

Figura 27: Interfaz gestor artículos. ............................................................................................................ 42

Figura 28: Interfaz nuevo artículo. ............................................................................................................. 42

Figura 29: Interfaz gestor multimedia. ....................................................................................................... 43

Figura 30: Interfaz gestor menús. ............................................................................................................... 43

Figura 31: Interfaz gestor usuarios. ............................................................................................................ 43

Figura 32: Interfaz gestor extensiones. ...................................................................................................... 44

Figura 33: Interfaz página principal visualización de la aplicación Web. .................................................... 44

Figura 34: Interfaz inscripción a la Escuela de Fútbol de Mareo en Logroño. ............................................ 45

Figura 35: Diagrama de casos de uso para la gestión de un empleado. .................................................... 46

Figura 36: Diagrama de casos de uso para la gestión de un entrenador. .................................................. 47

Figura 37: Diagrama de casos de uso para la gestión de un administrador. .............................................. 48

Figura 38: Diagrama de casos de uso para la gestión de un equipo. ......................................................... 49

Figura 39: Diagrama de casos de uso para la gestión de un jugador. ........................................................ 50

Figura 40: Diagrama de casos de uso para la gestión de un partido. ......................................................... 51

Figura 41: Diagrama de casos de uso para la gestión de estadísticas. ....................................................... 52

Figura 42: Diagrama de casos de uso para la gestión de un padre. ........................................................... 53

Figura 43: Prototipo de interfaz login ......................................................................................................... 57

Figura 44: Prototipo de interfaz visualizar información. ............................................................................ 58

Figura 45: Prototipo de interfaz añadir información .................................................................................. 58

Figura 46: Prototipo de interfaz modificar información ............................................................................. 59

Figura 47: Prototipo de interfaz eliminar información ............................................................................... 59

6

Figura 48: UML. Clases de análisis. ............................................................................................................. 60

Figura 49: Arquitectura tres capas ............................................................................................................. 61

Figura 50: Entidad relación ......................................................................................................................... 62

Figura 51: Modelo conceptual .................................................................................................................... 64

Figura 52: Diagrama de base de datos ....................................................................................................... 65

Figura 53: Clases de diseño ........................................................................................................................ 67

Figura 54: Interfaz login .............................................................................................................................. 83

Figura 55: Interfaz login incorrecto ............................................................................................................ 84

Figura 56: Interfaz index administrador ..................................................................................................... 84

Figura 57: Interfaz index empleado ............................................................................................................ 85

Figura 58: Diagrama de casos de uso para la gestión de una falta de entrenamiento. ............................. 88

Figura 59: Diagrama de casos de uso para añadir una falta de asistencia a un entrenamiento. ............... 89

Figura 60: Diagrama de casos de uso para recibir falta de asistencia a un entrenamiento. ...................... 90

Figura 61: UML. Clases de análisis ampliado. ............................................................................................. 92

Figura 62: Entidad relación ampliado ......................................................................................................... 93

Figura 63: Modelo conceptual ampliado .................................................................................................... 94

Figura 64: Diagrama de base de datos ampliado ....................................................................................... 95

Figura 65: Clases de diseño ampliado ........................................................................................................ 96

Figura 66: Interfaz visualizar falta entrenamiento ................................................................................... 103

Figura 67: Interfaz añadir falta entrenamiento (Administrador) ............................................................. 104

Figura 68: Interfaz falta entrenamiento añadida correctamente (Administrador) .................................. 104

Figura 69: Interfaz modificar falta entrenamiento (Administrador) ........................................................ 105

Figura 70: Interfaz eliminar falta entrenamiento (Administrador) .......................................................... 105

Índice de Tablas

Tabla 1: Descomposición de tareas ............................................................................................................ 14

Tabla 2: Comparativa por fechas ................................................................................................................ 18

Tabla 3: Comparativa por horas ................................................................................................................. 18

7

Introducción

Tema abordado

Este proyecto pretende desarrollar una aplicación Web para la Escuela de Fútbol de

Mareo en Logroño donde pueda alojar toda la información referente a dicha escuela. También

incluirá un apartado con acceso restringido para los empleados, en donde se podrá obtener y

actualizar las características y resultados relacionados con los equipos y jugadores de la

escuela. Además, en dichas estadísticas se llevará un control de las faltas de asistencia al

entrenamiento con el objetivo de avisar al tutor/a o padre/madre del jugador mediante

mensaje de texto a móvil y correo electrónico.

Motivo de la elección

Actualmente, entreno a dos equipos de fútbol base de dicha escuela, además de estar

altamente involucrado en todo lo relacionado con ella.

Desde hace unos años, la escuela ya dispone de un sitio Web, lo que le ha servido para

crecer, tanto deportivamente como popularmente año tras año.

Por eso, he pensado basarme en esta idea para realizar este proyecto con el objetivo

de que el producto final sea lo suficientemente abierto, completo y sencillo de manejar como

para que la Escuela de Fútbol de Mareo en Logroño pueda hacer uso total de ella en un futuro,

y ayude a gestionar la actividad diaria de la escuela (noticias, resultados, plantillas, etc.) y a

almacenar los datos de equipos, jugadores, padres, partidos, estadísticas y faltas de asistencia.

Límites

El proyecto está asignado a una escuela de fútbol real donde el cliente de la aplicación

es la propia escuela de fútbol, en la figura de su director. Además, soy partícipe activo y futuro

usuario de la aplicación por lo que tengo acceso directo a diversos empleados de la escuela a

los que podré consultar requisitos, mostrar incrementos para pedir su opinión, mejoras, etc.

Además, se establecerán una serie de requisitos mínimos, que explicaré más adelante

en el Documento de Objetivos del Proyecto, que deberán satisfacer la aplicación, así como

varias posibles mejoras que se irán llevando a cabo en función del tiempo disponible una vez

alcanzados los objetivos mínimos.

8

Documento de Objetivos del Proyecto

En este apartado se especifican las características del proyecto que se quiere realizar,

su alcance, sus riesgos y otros aspectos similares.

Además, se detallarán los principales entregables así como la descomposición de

tareas y el plan de trabajo.

Debido a que este documento se basa en estimaciones, será una de las partes más

susceptibles a sufrir cambios y modificaciones.

Objetivo

El objetivo del proyecto es la creación de una aplicación Web para alojar toda la

información referente a la Escuela de Fútbol de Mareo en Logroño.

Además, los empleados de la escuela podrán almacenar, modificar y mostrar datos y

estadísticas relacionadas tanto de los equipos como de los jugadores.

También, se llevará un control de las faltas de asistencia a los entrenamientos con el

objetivo de notificar de la falta al tutor/a o padre/madre del jugador mediante mensaje de

texto a móvil y correo electrónico.

El objetivo final es que la Escuela de Fútbol de Mareo en Logroño pueda hacer uso

total de dicha aplicación.

Participantes en el proyecto

- Director:

o Juan José Olarte Larrea, profesor del departamento de Matemáticas y

Computación de la Universidad de La Rioja.

- Alumno: o Abel Sierra Gómez

Comunicaciones

El director del proyecto y el alumno han llegado de mutuo acuerdo a que las

comunicaciones entre ambos será mediante:

- Correo electrónico: será la forma más habitual de comunicación para tratar pequeñas

dudas e informar del estado del proyecto al director. También se utilizará para

concretar reuniones en persona entre el director y el alumno.

- Reuniones en persona: serán para tratar temas más importantes. Además, se levantará

acta de cada reunión realizada.

9

Alcance del proyecto

El alcance de un proyecto define y detalla los límites y objetivos del proyecto que se

deberán haber alcanzado al término de su desarrollo.

Para ello, se ha incluido una lista con los requisitos mínimos a cumplir en el proyecto y

una lista de posibles ampliaciones que podrán permitir al alumno llevarlas a cabo. En todo

caso, tanto las ampliaciones que se puedan incluir en el proyecto, como las que no, se

documentarán a continuación.

Requisitos mínimos alcanzables

Creación de una aplicación Web sobre la Escuela de Fútbol de Mareo en Logroño que

contendrá:

- Toda la información referente a la Escuela de Fútbol de Mareo en Logroño.

- Acceso restringido mediante usuario y contraseña de empleados para poder actualizar

y obtener características relacionadas tanto de los equipos como de los jugadores de la

Escuela de Fútbol de Mareo en Logroño.

- Control de las faltas de asistencia de los jugadores a los entrenamientos, con el

objetivo de notificar la falta al tutor/a o padre/madre del jugador mediante mensaje

de texto a móvil o correo electrónico.

Posibles ampliaciones de la plataforma

- Creación de una Tienda Online, donde se podrá comprar productos relacionados con la


- Creación de un foro para todos los miembros de la Escuela de Fútbol de Mareo en

Logroño.

- Creación de un Chat para la comunicación en tiempo real de todos los miembros de la


Metodología

El proyecto lo desarrollaré basándome en la metodología del Proceso Unificado del

Desarrollo de Software, propuesto por Ivar Jacobson, Grady Booch y James Rumbaugh

([JAC00]), la cual se caracteriza por estar dirigida por casos de uso, centrada en la arquitectura

y por seguir un ciclo de vida iterativo e incremental.

He escogido esta metodología por ser muy conocida, y porque se adapta

perfectamente al objetivo anteriormente explicado de ir añadiendo nuevas funcionalidades al

sistema en cada iteración. Estas iteraciones ofrecen como resultado un incremento de la

aplicación desarrollada que añade o mejora las funcionalidades del sistema en desarrollo.

Esta metodología me va a permitir poder evaluar cada entregable, y de esta forma

minimizar el riesgo de que el cliente esté insatisfecho, ya que sólo se desarrolla y entrega una

parte de la aplicación. Además me permitirá recoger información del cliente útil para

posteriores incrementos.

http://es.wikipedia.org/wiki/Grady_Booch

http://es.wikipedia.org/wiki/James_Rumbaugh

10

Tecnologías a utilizar

Durante el desarrollo utilizaré diferentes tecnologías. Con el fin de elegir las más

apropiadas para el proyecto, se ha realizado y hecho pruebas con diferentes tecnologías que

ha derivado en la selección de las más adecuadas para la aplicación:

La aplicación Web denominada “Administrar y visualizar información” he decidido,

desde un principio, desarrollarla mediante un Sistema Gestor de Contenidos, por lo que he

seleccionado las siguientes alternativas para su estudio:

a) Drupal: es un sistema gestor de contenidos muy configurable que permite publicar

artículos, imágenes, u otros archivos y servicios añadidos como foros, encuestas,

votaciones, blogs y administración de usuarios y permisos. Además, es un sistema

dinámico. Es un programa libre, con licencia GNU/GPL, escrito en PHP, desarrollado y

mantenido por una activa comunidad de usuarios. Destaca por la calidad de su código

y de las páginas generadas, el respeto de los estándares de la Web, y un énfasis

especial en la usabilidad y consistencia de todo el sistema. Después de estudiarla, se

desechó porque se comprobó que esta tecnología se utilizaba para entornos más

profesionales y de alto rendimiento. Por tanto, como los usuarios que van hacer uso

de la aplicación no tienen por qué disponer de un alto nivel de conocimientos

informáticos, utilizaré una tecnología más sencilla y de fácil manejo.

b) Joomla!: es un gestor de contenidos bastante maduro, ofrece innumerables

funcionalidades y la posibilidad de instalar herramientas adicionales, puede adaptarse

fácilmente a diversos proyectos Web o incluso a intranets, pueden montarse desde

blogs hasta tiendas virtuales, gestores de descargas, sitios con foros o catálogos

especializados, y un largo etc. En contraposición a Drupal, este gestor requiere menos

control, tiene más aspectos a tener en cuenta, una curva de aprendizaje más corta,

una mayor comunidad de usuarios y facilidades para la implementación de

extensiones. Además su facilidad de uso y de administración, como su infinidad de

plantillas hacen que para la aplicación a desarrollar sea la alternativa perfecta. Por

último, su API completamente documentada y su gran popularidad, así como el interés

en aprender esta nueva tecnología hace que sea la alternativa más válida y completa.

Después de analizar estas dos alternativas he optado por Joomla!, ya que permite la

creación de sitios Web y de completas aplicaciones online. Muchos de sus aspectos,

incluyendo su facilidad de uso y su extensibilidad, lo han hecho muy popular entre

desarrolladores y usuarios, habiendo sido galardonado en los años 2006 y 2007 con el CMS

Award que premia a la mejor aplicación de estas características de código abierto.

Su código es abierto y está escrito en PHP, usa base de datos MySQL y es un software

libre, que se basa en herramientas similares, que no generan costos de licencias.

Por todo esto y porque era una tecnología que quería conocer y aprender a utilizar, he

decidido escogerla, además de porque creo que es la mejor alternativa ahora mismo para mi

proyecto.

11

Tras seleccionar Joomla! como gestor de contenidos, el Sistema de Almacenamiento

de información (SGBD) para toda la aplicación será:

- MySQL: es un sistema de gestión de bases de datos relacional, multihilo y

multiusuario. Sus principales características:

o Posee un amplio subconjunto del lenguaje SQL.

o Disponibilidad en gran cantidad de plataformas y sistemas.

o Diferentes opciones de almacenamiento según si se desea velocidad en las

operaciones o mayor número de operaciones disponibles.

o Transacciones y claves foráneas.

o Conectividad segura.

Para la elección del lenguaje de programación para la aplicación “Gestión de

estadísticas” y “Control de faltas de asistencia al entrenamiento”, se han seleccionado los

siguientes para su estudio:

a) ASP: es una tecnología de Microsoft del tipo "lado del servidor" para páginas Web

generadas dinámicamente, que ha sido comercializada como un anexo a Internet

Information Services (IIS). Intenta ser solución para un modelo de programación rápida

ya que "programar en ASP es como programar en Visual Basic y C#", por supuesto con

muchas limitaciones y algunas ventajas específicas en entornos Web.

Estudié esta alternativa pero la deseché, ya que creo que es un lenguaje de

programación algo limitado a solo funcionar con IIS.

b) JSP: es un lenguaje multiplataforma para la creación de sitios Web dinámicos. Está

orientado a desarrollar páginas Web en Java.

Estudié esta alternativa para ampliar mis conocimientos obtenidos a lo largo de la

carrera, en concreto, en la asignatura Programación de Bases de datos, pero decidí

desecharla, ya que creo que para una mejor formación es mejor conocer diferentes

lenguajes de programación.

c) PHP: es un lenguaje multiplataforma para la creación de sitios Web dinámicos. Es

usado principalmente en la interpretación del lado del servidor y no necesita ser

compilado para ejecutarse. La mayor parte de su sintaxis ha sido tomada de C, Java y

Perl con algunas características específicas. Es libre, por lo que se presenta como una

alternativa de fácil acceso para todos. Capacidad de conexión con la mayoría de los

motores de base de datos que se utilizan en la actualidad, destaca su conectividad con

MySQL y PostgreSQL.

Tras estudiar las diferentes alternativas, he decidido que el lenguaje más apropiado

para realizar la aplicación es PHP. Las principales razones por dicha elección son: el interés que

tengo por aprender este lenguaje que es muy utilizado en aplicaciones Web y porque

considero que conocerlo me va a facilitar mucho el trabajo con Joomla!, ya que como he

comentado anteriormente, está escrito en PHP.

12

Identificación de riesgos y planes de acción

En este apartado se intentará identificar todas las fuentes de riesgo para el proyecto y

definir un modo de actuación para cada caso.

Riesgos posibles

1. Desconocimiento de alguna herramienta necesaria por parte del alumno, como por

ejemplo Joomla! o PHP.

2. Problemas personales del alumno: enfermedades, accidentes, etc.

3. Problemas hardware o software en el equipo de desarrollo.

4. Errores en la estimación de fechas, debidos a la falta de un horario estricto y fijo para

el proyecto.

5. El producto final no satisface al cliente o al director.

Actuaciones previstas ante los riesgos

1. Desconocimiento de alguna herramienta: ya se sabe que algunas herramientas

requerirán un estudio previo, por lo dedicaré un tiempo a ello en la planificación de

fechas.

2. Problemas personales del alumno: la planificación de fechas y horas dedicadas al

proyecto, puede verse afectada por este problema debido a que la realización de dicho

proyecto lo realiza una única persona. En este caso, se puede plantear un calendario

con horas extras, para que el calendario vuelva a cuadrar.

3. Problemas hardware o software en el equipo de desarrollo: el proyecto se realizará en

los dos ordenadores que el alumno dispone en casa, guardando en ellos copias de

seguridad, además de en un disco duro externo para evitar pérdidas de información.

4. Errores en la estimación de fechas, debidos a la falta de un horario estricto y fijo para

el proyecto: se documentará los fallos en la estimación y si hace falta se replantearán

las tareas. De todas formas, se intentará comparar mis estimaciones con las de otros

proyectos parecidos, además de ser realista con las estimaciones, si bien es mejor

excederse en el tiempo estimado.

5. El producto final no satisface al cliente o al director: ambos estarán informados

periódicamente por parte del alumno de los avances y cambios realizados. Además,

como tienen acceso a cada incremento, el riesgo se minimiza.

Entregables

- Cada incremento: producto y documentación (porción de la memoria) asociada.

- Manual de administrador de Joomla!

- Aplicación final: sitio Web completo.

13

Descomposición de tareas

Se han introducido las tareas en una tabla, asignándoles a cada una de ellas las horas

estimadas para la realización de cada una de ellas. Todos estos datos son aproximados.

Id Nombre de tarea Duración estimada en horas

1 Seguimiento proyecto 15

2 Revisiones 8

3 Reuniones 7

4 Gestión proyecto 109

5 Generación DOP 17

6 Estudio previo 5

7 Descomposición de tareas 3

8 Asignar tiempo a tareas 2

9 Diagrama de Gantt 2

10 Documentación 4

11 Revisión 1

12 Generación memoria 92

13 Estudio previo 12

14 Creación memoria 65

15 Revisión documento 15

16 Análisis 17

17 Estudio previo 12

18 Establecer los límites del sistema a desarrollar 6

19 Establecer viabilidad del sistema 6

20 Especificación de requisitos 5

21 Documento de especificación de requisitos 5

22 Ciclo 1: Aplicación Web (Visualizar y administrar información) 101

23 Análisis 15

24 Casos de Uso 7

25 Identificar actores 1

26 Crear casos de uso 4

27 Diagramas actividades 1

28 Documentación 1

29 Clases en análisis 5

30 Identificar clases 3

31 Diagrama de clases 1

32 Generar documentación 1

33 Documentación 2

34 Revisión análisis 1

35 Diseño 11

36 Diseño arquitectura del sistema 3

37 Diseño BD 3

38 Documentación 3

39 Diseño interfaces 3

40 Prototipos 3

41 Documentación 1

42 Revisión diseño 1

43 Construcción 75

44 Generación de código 75

45 Ciclo 2: Gestión Estadísticas 166

46 Análisis 20

47 Casos de Uso 10



50 Diagramas actividades 1

51 Documentación 2

14





56 Documentación 2


58 Diseño 29


60 Diseño BD 5

61 Diagrama UML 3

62 Documentación 2


64 Prototipos 4

65 Diseño clases 14




69 Documentación 2


71 Construcción 117


73 Plan de pruebas 7

74 Pruebas Unitarias, integración y sistema/aplicación 7

75 Ciclo 3: Control Faltas Asistencia Entrenamiento 77

76 Análisis 15

77 Casos de Uso 6



80 Documentación 2





85 Documentación 2


87 Diseño 16


89 Diseño BD 3

90 Diagrama UML 2

91 Documentación 1


93 Prototipos 2

94 Diseño clases 6




98 Documentación 2


100 Construcción 46


102 Plan de pruebas 6

103 Pruebas Unitarias, integración y sistema/aplicación 6

104 Defensa proyecto 9

105 Preparación 8

106 Defensa 1

TOTAL HORAS PROYECTO 494

Tabla 1: Descomposición de tareas

15

Calendario de trabajo semanal

A continuación se muestra el horario dedicado al desarrollo completo del proyecto:

Lunes Martes Miércoles Jueves Viernes Sábado Domingo

9:00 – 10:00

10:00 – 11:00

11:00 – 12:00

12:00 – 13:00

13:00 – 14:00

14:00 – 15:00

15:00 – 16:00

16:00 – 17:00

17:00 – 18:00

18:00 – 19:00

19:00 – 20:00

20:00 – 21:00

Horas empleadas Horas opcionales Horas dedicadas a otras

tareas

Diagrama de Gantt

Figura 1: Diagrama de Gantt. Vista general.

Figura 2: Diagrama de Gantt. Seguimiento del proyecto.

16

Figura 3: Diagrama de Gantt. Tareas de gestión del proyecto.

Figura 4: Diagrama de Gantt. Tareas del análisis del proyecto.

Figura 5: Diagrama de Gantt. Tareas del Ciclo 1: Administrar y visualizar aplicación Web.

17

Figura 6: Diagrama de Gantt. Tareas del Ciclo 2: Gestión estadísticas.

Figura 7: Diagrama de Gantt. Tareas del Ciclo 3: Control faltas de asistencia.

Figura 8: Diagrama de Gantt. Defensa del proyecto.

18

Gestión del proyecto

Introducción

Ha sido imposible seguir las fechas implantadas al inicio del proyecto debido a diversos

motivos. Por ello, la finalización del proyecto y su defensa se han retrasado tres meses y

medio.

Factores del retraso

El principal factor del retraso ha sido el no cumplimiento de las horas diarias que se

especificaban en el Documento de Objetivos del Proyecto y que se iban a emplear en la

realización del mismo. Esta circunstancia viene dada por diferentes motivos personales, lo que

ha hecho que durante varios meses no pueda dedicar dichas horas para el desarrollo del

proyecto.

Comparación de estimaciones y resultados

Comparación de fechas

A continuación, se muestra una tabla en la que se comparan para todas las tareas las

fechas de comienzo y finalización previstas con las fechas de comienzo y finalización reales.

Nombre de tarea Fecha

comienzo prevista

Fecha comienzo

real

Fecha fin prevista

Fecha fin real

Seguimiento proyecto 03/10/2011 3/10/2011 13/02/2012 01/06/2012

Gestión proyecto 03/10/2011 3/10/2011 13/02/2012 01/06/2012

Análisis 1/11/2011 22/01/2011 07/11/2011 30/01/2012

Ciclo 1: Aplicación Web (Visualizar y administrar información)

7/11/2011 30/01/2012 05/12/2011 29/02/2012

Ciclo 2: Gestión Estadísticas 5/12/2011 29/02/2012 19/01/2012 18/04/2012

Ciclo 3: Control Faltas Asistencia Entrenamiento 19/01/2012 18/04/2012 09/02/2012 10/05/2012

Defensa proyecto 10/02/2012 01/06/2012 13/02/2012 01/06/2012

Tabla 2: Comparativa por fechas

Comparación de horas

A continuación, se muestra una tabla en la que se comparan las horas estimadas y las

horas reales de duración para todas las tareas.

Nombre de tarea Horas estimadas Horas reales

Seguimiento proyecto 15 13

Gestión proyecto 109 115

Análisis 17 20

Ciclo 1: Aplicación Web (Visualizar y administrar información) 101 110

Ciclo 2: Gestión Estadísticas 166 185

Ciclo 3: Control Faltas Asistencia Entrenamiento 77 80

Defensa proyecto 9 7

TOTAL HORAS PROYECTO 494 530

Tabla 3: Comparativa por horas

19

Análisis de resultados

Analizando la comparativa de fechas, el mayor retraso se produce al comienzo del

análisis, ya que hay un salto de tiempo, de casi tres meses desde la fecha de comienzo

estimada hasta la fecha de comienzo real, en el que no pude desarrollar el proyecto por lo

comentado anteriormente. Además, debido a que la duración real es mayor que la estimada se

produce otro retraso de más o menos medio mes, provocado por los riesgos identificados en el

Documento de Objetivos del Proyecto.

Por esta última causa comentada en la comparativa de fechas, se observa en la

comparativa por horas, que exceptuando el seguimiento del proyecto y la defensa del

proyecto, todas las tareas tienen una duración real mayor que la estimada.

20

Análisis

Introducción

Objetivo

El objetivo del proyecto es desarrollar una aplicación Web para la Escuela de Fútbol de

Mareo en Logroño, donde poder alojar, mantener y actualizar toda la información referente a

dicha entidad. En este apartado, se pretende dar una visión global de lo que será la aplicación

y sirva de apoyo vital para el diseño del software.

Ámbito

La aplicación Web debe permitir el acceso a todos los usuarios a la información de la

Escuela de Fútbol de Mareo en Logroño. Además, debe permitir el acceso a los empleados a

una zona restringida (mediante usuario y contraseña) donde deben poder obtener y actualizar

las características, estadísticas y resultados. Por último, debe permitir introducir las faltas de

asistencia de cada jugador y enviar, en caso de falta de asistencia a un entrenamiento, un

correo electrónico y un mensaje de texto a móvil al padre, madre o tutor/a de dicho jugador.

Visión general

Sistema

La aplicación se dividirá en tres partes:

- La primera parte contendrá la información perteneciente a la Escuela de Fútbol de

Mareo en Logroño, por lo que debe ser accesible desde Internet para todos los

usuarios que quieran informarse sobre dicha escuela. Además contendrá todo lo

necesario para administrar la aplicación Web, es decir, para mantenerla, actualizarla y

modificarla mediante el gestor de contenidos. Este apartado será utilizado

exclusivamente por un usuario administrador y en ella primará la facilidad de manejo.

- La segunda parte estará dedicada a visualizar, almacenar, eliminar y modificar

estadísticas y datos sobre los jugadores y equipos de la Escuela de Fútbol de Mareo en

Logroño, es decir, incluirá una información detallada por equipos y jugadores para que

los empleados, se informen a través de una zona restringida mediante usuario y

contraseña. Esta aplicación será utilizada exclusivamente por todos los empleados

pertenecientes a la Escuela de Fútbol de Mareo en Logroño. Existirán tres roles con

distintos privilegios que explicaré más adelante: administrador, empleado y otro

empleado.

- Y por último, una parte para el control de faltas de asistencia a los entrenamientos de

los jugadores. Esta aplicación se encargará de enviar al padre, madre o tutor/a del

jugador un correo electrónico y un mensaje de texto a móvil avisando de la falta de

asistencia al entrenamiento del jugador.

21

Como posibles ampliaciones de la aplicación Web cabe destacar

- Una tienda online para la venta de productos relacionados con la Escuela de Fútbol de

Mareo en Logroño.

- La creación de un foro para todos los miembros de la Escuela de Fútbol de Mareo en

Logroño, para que puedan exponer información, dudas o preguntas a los demás

integrantes de dicha escuela.

- La creación de un Chat para la comunicación en tiempo real de todos los miembros de

la Escuela de Fútbol de Mareo en Logroño.

Usuarios de la aplicación

Diferentes usuarios accederán a la aplicación, y éstos estarán diferenciados entre sí

por distintos roles que les permitirán realizar diferentes tareas. Teniendo en cuenta esto, se

distinguen cuatro tipos de usuarios:

- Usuario de consulta: es el usuario que accede a la aplicación Web a través de Internet

para visualizar toda la información referente a la Escuela de Fútbol de Mareo en

Logroño. No requiere de identificación.

- Empleado: son los usuarios que pertenecen a la Escuela de Fútbol de Mareo en

Logroño, tales como monitores, entrenadores, fisioterapeutas y coordinadores. Estos

usuarios, podrán visualizar, almacenar y actualizar estadísticas y datos de jugadores y

equipos. Cada empleado dispondrá de su usuario y contraseña para el acceso a esta

zona restringida de la aplicación Web. Por último, comentar que, aunque en la escuela

un coordinador tenga más funciones que un monitor o un entrenador, la aplicación les

otorgará los mismos privilegios, por lo que los tres tendrán el mismo rol en la

aplicación.

- Administrador: es el usuario que podrá mantener, actualizar y modificar la aplicación

Web. También podrá realizar las funciones del empleado.

- Padre: usuario que recibirá, mediante correo electrónico y mensaje de texto a móvil,

las faltas de asistencia al entrenamiento.

22

Visión general del sistema

Para definir los requisitos iniciales de la aplicación voy a crear un diagrama de casos de

uso de alto nivel para entender con una visión general cual es el problema y que soluciones

voy a plantear.

El diagrama de casos de uso de alto nivel obtenido es el siguiente:

Figura 9: Visión general del sistema.

Requisitos funcionales

Del diagrama de casos de uso generado para dar una visión general de la aplicación se

pueden deducir los siguientes requisitos funcionales como RF.n, donde n será el número de

Requisito Funcional:

RF.1: privilegios de administrador

Existirá un perfil de administrador que tendrá total libertad para el acceso y control total de la

aplicación.

RF.2: privilegios de empleado

El administrador creará perfiles para los distintos empleados de la Escuela de Fútbol de Mareo

en Logroño, quienes podrán acceder a la parte restringida de la aplicación asociada a ellos.

RF.3: control faltas de asistencia.

Los empleados serán los encargados de controlar las faltas de asistencia. Se entiende por

control al hecho de añadir las faltas para su posterior envío por parte de la aplicación de un

correo electrónico y un mensaje a móvil a los padres, madres o tutores.

RF.4: faltas de asistencia

El padre, la madre o el/la tutor/a recibirá un mensaje de texto a móvil o un correo electrónico

indicando que el jugador ha faltado al entrenamiento. Se enviará automáticamente justo

después de que el empleado añada la falta a la aplicación.

23

Requisitos no funcionales

A continuación numero los requisitos no funcionales como RNF.n, donde n será el

número de Requisito no Funcional:

RNF.1: requisitos de usabilidad

El producto final deberá ser lo más sencillo posible de manejar, para una mayor compresión y

rapidez de uso para los diferentes usuarios.

RNF.2: requisitos de rendimiento

El sistema deberá ser rápido y el tiempo de respuesta el mínimo posible para que la

navegación sea lo más ágil posible.

RNF.3: requisitos de mantenimiento

La aplicación debe ser fácil de mantener una vez implementada.

RNF.4: requisitos de seguridad

La aplicación debe tener una gestión segura para impedir el acceso no autorizado y proteger

de las amenazas más usuales como:

Inyección SQL: es un método de inserción o “inyección” de código intruso que se vale de una

vulnerabilidad informática presente en una aplicación en el nivel de validación de las entradas

para realizar consultas a una base de datos. Para evitarlo en la aplicación, utilizaré el código

necesario para ello.

Ataques por contraseña: es cuando un atacante utiliza las técnicas necesarias para descubrir

las contraseñas. Para evitarlo en la aplicación, las contraseñas serán almacenadas encriptadas

y así evitar problemas al enviarlas y recibirlas con la base de datos. El algoritmo utilizado será

MD5.

Debilidad del sistema de autenticación: es cuando un usuario no autorizado accede a la

aplicación. Para evitarlo se crearán sesiones para manejar la información que cada usuario

necesita. Una vez el usuario cierre la sesión, o bien, pasen 10 minutos de inactividad, dicha

sesión se destruirá.

RNF.5: requisitos de concurrencia

Se estudiará el problema de la concurrencia para evitar que haya problemas en el acceso

concurrente de dos o más usuarios a la base de datos a la aplicación. Para ello, cuando un

usuario modifique una determinada información, esta se bloqueará para que no surjan

lecturas sucias u otros problemas.

RNF.6: requisitos de privacidad

Solo podrán acceder a la aplicación gestión de estadísticas, una vez registrados, empleados de

la Escuela de Fútbol de Mareo en Logroño. La información almacenada en la aplicación, solo

será utilizada para labores internas y cumplirá las disposiciones recogidas en la Ley Orgánica de

Protección de Datos.

24

RNF.7: flexible de ampliar.

Debe preverse la posibilidad de que en el futuro se desarrolle una tienda online para la venta

de productos relacionados con la escuela, un foro para que puedan exponer sus dudas,

preguntas, así como informar a los demás integrantes de dicha escuela, y un Chat para la

comunicación en tiempo real de todos los miembros de la Escuela de Fútbol de Mareo en

Logroño.

RNF.8: requisitos de software

La aplicación debe ser manejable en los navegadores más usados, tales como: Internet

Explorer, Firefox, Chrome y Safari.

25

Ciclo 1: Aplicación Web (Administrar y visualizar información)

Análisis

Introducción

Una vez definido el diagrama de casos de uso de alto nivel en el que se reflejan los

requisitos generales que quiero que contenga mi sistema, y enunciados los requisitos

funcionales generales del sistema que se deducen de él, voy a desglosar de una manera más

detallada y específica los casos de uso anteriores, en diagramas de casos de uso que me hagan

entender completamente la funcionalidad del sistema. Además, a partir de estos casos de uso

podré obtener los requisitos específicos de cada una de las partes del sistema.

Casos de Uso

Administrar información de la aplicación Web

En este apartado voy a refinar el caso de uso “Administrar información” generado en el

diagrama de la visión general. Los diagramas de casos de uso que definen los requisitos que

debe cumplir esta función son los siguientes:

La figura 10 muestra el diagrama de casos de uso del administrador para la gestión de

componentes de la aplicación.

Figura 10: Diagrama de casos de uso administrar componentes

Caso de uso 1: Administrar noticias

- Definición: esta operación permitirá al administrador la gestión de las noticias

mostradas en la aplicación.

- Precondición: el usuario desea administrar las noticias de la aplicación.

- Postcondición: se muestra el panel de control de noticias y las posibles operaciones a

realizar.

26

Caso de uso 2: Administrar galería

- Definición: esta operación permitirá al administrador la gestión de la galería mostrada

en la aplicación.

- Precondición: el usuario desea administrar la galería de la aplicación.

- Postcondición: se muestra el panel de control de la galería y las posibles operaciones a

realizar.

Caso de uso 3 Administrar banner

- Definición: esta operación permitirá al administrador la gestión de los banners de la

aplicación.

- Precondición: el usuario desea administrar los banners que contiene la aplicación.

- Postcondición: se muestra el panel de control de los banners y las posibles

operaciones a realizar.

Caso de uso 4: Administrar contacto

- Definición: esta operación permitirá al administrador gestionar los tipos de contacto

de la aplicación.

- Precondición: el usuario desea administrar los tipos de contacto.

- Postcondición: se muestra el panel de control y las posibles operaciones a realizar.

Caso de uso 5: Administrar plantillas

- Definición: esta operación permitirá al administrador gestionar las plantillas de los

diferentes equipos de la Escuela de Fútbol de Mareo en Logroño.

- Precondición: el usuario desea administrar las plantillas.

- Postcondición: se muestra el panel de control de las plantillas y las posibles


Caso de uso 6: Administrar temporadas

- Definición: esta operación permitirá al administrador gestionar las temporadas de los


- Precondición: el usuario desea administrar las temporadas.

- Postcondición: se muestra el panel de control de las temporadas y las posibles


Caso de uso 7: Login

- Definición: representa el mecanismo para identificar el rol que el usuario que accede a

la aplicación asume. Consiste en la introducción del nombre de usuario y contraseña

establecidos. Una vez que estos datos han sido proporcionados a la aplicación, la

misma se encargará de realizar una autentificación obteniendo los privilegios que tiene

el usuario en la aplicación y mostrando la interfaz apropiada para dicho usuario.

- Precondición: el usuario debe estar validado dentro de la base de datos. Accede a la

zona restringida mediante su nombre de usuario y su contraseña.

- Postcondición: el usuario empleado podrá realizar las operaciones asignadas para su

rol.

27


contenidos de la aplicación.

Figura 11: Diagrama de casos de uso administrar contenidos de la aplicación Web

Caso de uso 8: Agregar contenido

- Definición: esta operación permitirá al administrador agregar los contenidos

mostrados en la aplicación.

- Precondición: el administrador desea agregar contenidos o artículos a la aplicación.

- Postcondición: se muestra el panel de control de contenidos al administrador.

Caso de uso 9: Modificar contenido

- Definición: esta operación permitirá al administrador modificar los contenidos

mostrados en la aplicación.

- Precondición: el administrador desea modificar los contenidos o artículos de la

aplicación.


Caso de uso 10: Borrar contenido

- Definición: esta operación permitirá al administrador borrar los contenidos de la

aplicación.

- Precondición: el administrador desea borrar los contenidos o artículos de la aplicación.


28


usuarios de la aplicación.

Figura 12: Diagrama de casos de uso administrar usuarios de la aplicación Web

Caso de uso 11: Registrar usuario

- Definición: esta operación permitirá al administrador registrar o dar de alta a un nuevo

usuario en la aplicación.

- Precondición: el administrador desea registrar o dar de alta un nuevo usuario en la

aplicación.

- Postcondición: se muestra el panel de control de usuarios y las posibles operaciones a

realizar, con el nuevo usuario dado de alta.

Caso de uso 12: Modificar usuario

- Definición: esta operación permitirá al administrador modificar un usuario de la

aplicación.

- Precondición: el administrador desea modificar un usuario existente de la aplicación.


realizar, con el usuario modificado.

Caso de uso 13: Eliminar usuario

- Definición: esta operación permitirá al administrador eliminar un usuario de la

aplicación.

- Precondición: el administrador desea eliminar un usuario existente de la aplicación.


realizar, pero con el usuario eliminado.

29

La figura 13 muestra el diagrama de casos de uso del administrador para la gestión

multimedia de la aplicación.

Figura 13: Diagrama de casos de uso administrar multimedia de la aplicación Web

Caso de uso 14: Subir archivo

- Definición: esta operación permitirá al administrador subir archivos al servidor.

- Precondición: el administrador desea subir un archivo al servidor.

- Postcondición: se muestra el panel gestor de archivos con el nuevo archivo.

Caso de uso 15: Bajar archivo

- Definición: esta operación permitirá al administrador eliminar o bajar un archivo del

servidor.

- Precondición: el administrador desea eliminar o bajar un archivo del servidor.

- Postcondición: se muestra el panel gestor de archivos sin el archivo eliminado.


inscripciones.

Figura 14: Diagrama de casos de uso administrar inscripciones de la aplicación Web

30

Caso de uso 16: Administrar inscripción campus

- Definición: esta operación permitirá al administrador recibir en el correo electrónico la

inscripción rellenada del campus.

- Precondición: el usuario desea obtener las nuevas inscripciones para el campus. El

administrador deberá estar logueado en la cuenta del correo electrónico.

- Postcondición: se muestra la nueva inscripción para el campus.

Caso de uso 17: Administrar inscripción escuela

- Definición: esta operación permitirá al administrador recibir en el correo electrónico la

inscripción rellenada para jugar en la Escuela.

- Precondición: el usuario desea obtener las nuevas inscripciones para el acceso a la

Escuela. El administrador deberá estar logueado en la cuenta del correo electrónico.

- Postcondición: se muestra la nueva inscripción para el acceso a la Escuela.

Caso de uso 18: Login correo

- Definición: representa el mecanismo para identificar el rol que el usuario que accede al

correo electrónico asume. Consiste en la introducción del nombre de usuario y

contraseña establecidos. Una vez que estos datos han sido proporcionados a la cuenta

de correo, la misma se encargará de realizar una autentificación obteniendo los

privilegios que tiene el usuario en la cuenta y mostrando la interfaz apropiada para el

usuario.

- Precondición: el administrador debe estar validado. Accede a la zona restringida

mediante su nombre de usuario y su contraseña.

- Postcondición: el administrador podrá realizar las operaciones asignadas para su rol.

Visualizar información de la aplicación Web

En este apartado voy a refinar el caso de uso “Visualizar información” generado en el

diagrama de la visión general. El diagrama de casos de uso que define los requisitos que debe

cumplir esta función es el siguiente:

Figura 15: Diagrama de casos de uso visualizar información aplicación Web

31

Caso de uso 19: Ver información temporada

- Definición: esta operación permitirá a los usuarios que accedan a la aplicación Web,

informarse sobre los calendarios, resultados y clasificaciones de los diferentes equipos

de la Escuela de Fútbol de Mareo en Logroño.

- Precondición: el usuario desea acceder a la información de las diferentes temporadas.

- Postcondición: se muestra la página con la información sobre las temporadas de los

diferentes equipos.

Caso de uso 20: Leer noticias


informarse sobre las últimas noticias de la Escuela de Fútbol de Mareo en Logroño.

- Precondición: el usuario desea acceder a las noticias.

- Postcondición: se muestra la página de noticias.

Caso de uso 21: Ver información campus

- Definición: esta operación permitirá a los usuarios acceder a la información referente

al campus. Dependiendo de lo que considere el usuario, podrá inscribirse al campus.

- Precondición: el usuario desea acceder a la información del campus.

- Postcondición: se muestra la página con la información sobre el campus.

Caso de uso 22: Inscripción campus

- Definición: permitirá al usuario inscribirse en el campus de la Escuela de Fútbol de

Mareo en Logroño.

- Precondición: el usuario desea rellenar la inscripción para apuntarse al campus.

- Postcondición: se muestra al usuario un mensaje que la inscripción se ha realizado

correctamente.

Caso de uso 23: Ver organigrama


informarse sobre el organigrama de la Escuela de Fútbol de Mareo en Logroño, es

decir, ver las competencias de cada persona que la compone.

- Precondición: el usuario desea acceder al organigrama.

- Postcondición: se muestra la página con la información referente al organigrama de la


Caso de uso 24: Ver plantillas


informarse sobre las diferentes plantillas que hay en la Escuela de Fútbol de Mareo en

Logroño.

- Precondición: el usuario desea acceder a las plantillas.

- Postcondición: se muestra la página con la información referente a las diferentes

plantillas de la Escuela de Fútbol de Mareo en Logroño.

32

Caso de uso 25: Inscripción escuela

- Definición: esta operación permitirá apuntarse en la Escuela mediante un formulario

de inscripción.

- Precondición: el usuario desea inscribirse en la Escuela de Fútbol de Mareo en

Logroño.

- Postcondición: se envía un mensaje indicando al usuario que su inscripción se realizó correctamente.

Caso de uso 26: Contacto

- Definición: esta operación permitirá al usuario contactar con la Escuela de Fútbol de

Mareo en Logroño mediante correo electrónico. Además permitirá al usuario conocer

otras formas de contacto.

- Precondición: el usuario desea ponerse en contacto con la Escuela de Fútbol de Mareo

en Logroño.

- Postcondición: se muestra la información de las diferentes formas para contactar con

la escuela.


A continuación numero los requisitos funcionales como RF.n, donde n será el número

de Requisito Funcional:

- RF.1: gestión del contenido

Gestión total sobre la configuración de la aplicación y la inclusión de nuevos

contenidos o artículos.

Casos de uso: el requisito se deriva de los casos de uso 8.-Agregar contenido, 9.-

Modificar contenido y 10.-Borrar contenido.

- RF.2: gestión de usuarios

Gestión sobre los distintos tipos de usuarios que pueden acceder a la aplicación.

Casos de uso: el requisito se deriva de los casos de uso 11.-Registrar usuario, 12.-

Modificar usuario y 13.-Eliminar usuario.

- RF.3: gestión de archivos

Gestión sobre la subida y bajada de los distintos archivos que se quieren incluir o

eliminar de la aplicación.

Casos de uso: el requisito se deriva de los casos de uso 14.-Subir archivo y 15.-Bajar

archivo

- RF.4: gestión de inscripciones

Gestión de las inscripciones de los usuarios a la escuela y al campus.

Casos de uso: el requisito se deriva de los casos de uso 16. – Administrar inscripción

campus, 17.- Administrar inscripción escuela.

33

- RF.5: la aplicación debe mostrar información.

Debe permitir a los usuarios que acceden a la aplicación informarse sobre las noticias,

las temporadas, las plantillas, etc. es decir, sobre toda la información referente a la


Casos de uso: el requisito se deriva de los casos de uso 19.-Ver información

temporadas, 20.- Leer noticias, 21.-Ver información campus, 23.-Ver organigrama y

24.-Ver plantillas.

- RF.6: la aplicación debe permitir inscripciones.

Permitir la inscripción de los usuarios a la escuela y al campus.

Casos de uso: el requisito se deriva de los casos de uso 22.- Inscripción escuela y 25.-

Inscripción escuela.

- RF.7: contacto

Permitir a los usuarios informarse y comunicarse directamente con el director de la


Casos de uso: el requisito se deriva del caso de uso 26.-Contacto.

- RF.8: posibilitar el cambio de información mostrada en la aplicación

La aplicación debe permitir la edición del contenido. De ello se encargará el

administrador.

Casos de uso: el requisito se deriva de los casos de uso 1.- Administrar noticias, 2.-

Administrar galería, 3.- Administrar banner, 4.- Administrar contacto, 5.- Administrar

plantillas y 6.- Administrar temporadas.

- RF.9: privilegios del administrador

Existirá un perfil de administrador que tendrá control total de la aplicación. El

administrador podrá crear nuevos usuarios para administrar todo lo relacionado con la

gestión de información de la aplicación Web. Además podrá asignarles diferentes

privilegios.

- RF.10: la plataforma contará con un manual para el administrador que servirá para

crear una pequeña ayuda para la futura administración de la aplicación Web.

34

Diseño

Introducción

Este ciclo está desarrollado al completo por el gestor de contenidos Joomla!. Como he

comentado anteriormente en el Documento de Objetivos del Proyecto, no había utilizado

nunca esta tecnología, pero una vez estudiado el funcionamiento del mismo, me ha permitido

realizar de una forma sencilla y rápida el diseño de la aplicación Web.

La arquitectura Web necesaria para ejecutar Joomla! la he conseguido utilizando

Xampp, servidor que instala Apache, MySQL, PHP y PHPMyAdmin.

Una vez hecho esto, la instalación de Joomla! es muy sencilla: comprueba las versiones

de PHP y MySQL instaladas para ver que todo está correcto y pide configurar la base de datos

donde se va a instalar el contenido del sitio Web.

La base de datos contiene todos los datos necesarios para el correcto funcionamiento

de la aplicación Web, es decir, toda la información sobre usuarios, sesiones, plantillas,

módulos, componentes y contenidos. A continuación, muestro varios ejemplos donde

aparecen diferentes tablas utilizadas por Joomla!.

Figura 16: Tablas BD Joomla!. Menu

35

Figura 17: Tablas BD Joomla!. Banners

Figura 18: Tablas BD Joomla!. Usuarios

36

Descripción de los elementos básicos de Joomla!

- Plantillas: la plantilla (template) proporciona el aspecto visual para la aplicación Web.

Al instalar Joomla!, se incluyen varias plantillas, tanto para el Panel de Control del

Administrador como para el diseño del sitio Web. Por último, es preciso comentar que

existen multitud de sitios Web que ofrecen plantillas gratuitas o comerciales. En mi

caso, he utilizado la plantilla GK Sporter.

- Componentes: son pequeñas aplicaciones independientes entre sí que gestionan la

información dentro de Joomla!. Los componentes añaden distintas funcionalidades a

Joomla! y lo convierten en mucho más que una Web de artículos o noticias. La

instalación estándar de Joomla! incluye:

o Componente que gestiona los contenidos: com_content.

o Componente que administra y muestra la página principal del sitio Web:

com_frontpage.

o Componente encargado de administrar los contactos y enviar los mensajes por

email que escriben desde el formulario los usuarios: com_contact.

o Componente de administración de banner: com_banners.

o Componente de encuestas y votaciones: com_poll.

o Componente de gestión y publicación de enlaces: com_weblinks.

o Componentes de sindicación de noticias (hacia otros sitios: com_rss y desde

otros sitios: com_newsfeeds.

o Componente que genera las ventanas internas que contienen otras páginas

externas (iframes): com_wrapper.

o Componente de mensajería interna: com_messages.

o Componente del buscador interno: com_search.

o Los componentes relacionados con funciones de usuario: com_login,

com_user, y com_registration.

- Módulos: son extensiones o complementos de Joomla! que permiten añadir bloques

de información secundaria en diferentes posiciones o zonas de la plantilla. El ejemplo

más claro de módulo es el menú principal (mod_mainmenu) que facilita la navegación

por el sitio Web.

- Plugins: son extensiones que realizan dentro de Joomla! una amplia variedad de

funciones relacionadas fundamentalmente con la autentificación de usuarios, el

funcionamiento del buscador interno o con la edición de contenidos. Por ejemplo, en

la aplicación Web he instalado un plugin para la utilización del API de Google Maps.

37

Prototipos de interfaz

En este apartado muestro los bocetos de los prototipos de interfaz que voy a utilizar

en este primer ciclo sobre la aplicación Web. Estos prototipos los seguiré de guía a la hora de

diseñar las interfaces de la aplicación, pero no necesariamente será así estructurado el diseño

final de la interfaz.

Acceso administrador:

Figura 19: Prototipo de interfaz acceso administrador. Login

Panel de control del administrador:

Figura 20: Prototipo de interfaz panel de control del administrador.

38

Gestor categorías:

Figura 21: Prototipo de interfaz gestor categorías.

Página principal visualización de la aplicación Web:

Figura 22: Prototipo de interfaz aplicación Web

39

Página inscripción visualización de la aplicación Web:

Figura 23: Prototipo de interfaz inscripción

40

Construcción

Interfaces definitivas

En esta primera iteración, analizaré cuales van a ser las interfaces que presentará la

aplicación Web, tanto para administrar la información como para visualizarla.

Interfaces de administración

Interfaz acceso administrador:

Inicialmente se va a ver cuál es la interfaz de página que utilizo para administrar la

aplicación Web. Para acceder a ella, se introduce la siguiente URL:

http://localhost/j17/administrator y se mostrará el formulario de acceso:

Figura 24: Interfaz acceso administrador. Login

Una vez que me he logueado, accedo al Panel de Control del Administrador:

Figura 25: Interfaz panel de control del administrador.

Las diferentes partes en las que se divide el Panel de Control del Administrador son:

1) Menú para acceder a todas las funciones disponibles de administración. Además, en la

parte derecha del menú se encuentra: información de los usuarios no conectados al

front-end y de los conectados a la administración, los mensajes privados que ha

recibido el usuario que está conectado, el enlace para ver el sitio Web que estoy

creando y el enlace para finalizar sesión (Finalizar).

http://localhost/j17/administrator

41

2) Iconos de acceso rápido a las funciones más utilizadas del Panel de Control del

Administrador.

3) Información sobre los usuarios conectados, los artículos populares y los últimos

artículos añadidos a la aplicación Web.

El componente más importante para crear lo que los usuarios verán en la aplicación

Web, es el componente “contenido”.

A continuación voy a mostrar las interfaces para gestionar dicho contenido en Joomla!

Interfaz gestor categorías:

Todos los artículos se organizan en categorías. Cualquier categoría puede contener

artículos y otras categorías.

Figura 26: Interfaz gestor categorías.

42

Interfaz gestor artículos:

Son los textos e imágenes que se muestran en una página de la aplicación Web.

Figura 27: Interfaz gestor artículos.

Para crear un nuevo artículo se pulsa sobre el icono “nuevo”, mostrando:

Figura 28: Interfaz nuevo artículo.

43

Interfaz gestor multimedia:

Para insertar imágenes, las subo utilizando el gestor multimedia y luego tengo que

manipular las propiedades de la imagen con el botón edición Imagen en el menú editor cuando

añado o edito un artículo.

Figura 29: Interfaz gestor multimedia.

Interfaz gestor menús:

Por defecto, la instalación genera un menú principal, el cuál podré editarlo pero nunca

eliminar. Además la aplicación cuenta con un menú secundario.

Figura 30: Interfaz gestor menús.

Interfaz gestor usuarios:

En este apartado se puede añadir, editar y eliminar a los usuarios. Además podré

asignar a cada uno de ellos los privilegios que desee.

Figura 31: Interfaz gestor usuarios.

44

Interfaz gestor extensiones:

Desde este panel se puede instalar módulos, plugins, extensiones, etc. para poder

utilizarlos en la aplicación Web.

Figura 32: Interfaz gestor extensiones.

Interfaces de visualización

Interfaz página inicial:

En este apartado muestro las interfaces de visualización de la aplicación Web que voy

a utilizar para mostrar a los usuarios toda la información perteneciente a la Escuela de Fútbol

de Mareo en Logroño.

Figura 33: Interfaz página principal visualización de la aplicación Web.

45

Interfaz inscripción escuela:

Figura 34: Interfaz inscripción a la Escuela de Fútbol de Mareo en Logroño.

46

Ciclo 2: Gestionar estadísticas

Análisis

Introducción

En este segundo ciclo del sistema voy a incrementar al sitio Web con las

funcionalidades necesarias para poder visualizar, almacenar y actualizar las diferentes

estadísticas y datos sobre los jugadores y equipos de la Escuela de Fútbol de Mareo en

Logroño.

A esta nueva aplicación Web se accede a través del enlace “Zona Entrenadores” del

menú secundario de la aplicación Web del primer ciclo. Los usuarios que pueden realizar

gestiones en esta aplicación, son los usuarios con roles: empleado y administrador. Estos

usuarios deben acceder a esta zona restringida mediante nombre de usuario (nombre y primer

apellido sin espacios) y contraseña.

Casos de Uso

Gestionar estadísticas

En este apartado voy a refinar el caso de uso “Gestionar estadísticas” generado en el

diagrama de la visión general. Los diagramas de casos de uso que definen los requisitos que

debe cumplir esta función son los siguientes:

La figura 35 muestra el diagrama de casos de uso para la gestión de un empleado.

Como se puede observar, el usuario empleado solo puede visualizar los datos.

Figura 35: Diagrama de casos de uso para la gestión de un empleado.

Caso de uso 27: Visualizar empleado

- Definición: esta operación permitirá al empleado o al administrador visualizar los datos

de un empleado.

- Precondición: el empleado o el administrador desea visualizar un empleado.

- Postcondición: se muestran los datos del empleado.

47

Caso de uso 28 Añadir empleado

- Definición: esta operación permitirá al administrador añadir los datos de un nuevo

empleado.

- Precondición: el administrador desea añadir un empleado.

- Postcondición: se añaden los datos del nuevo empleado.

Caso de uso 29: Modificar empleado

- Definición: esta operación permitirá al administrador modificar los datos de un

empleado.

- Precondición: el administrador desea modificar los datos de un empleado.

- Postcondición: se modifican los datos de un empleado.

-

Caso de uso 30: Eliminar empleado

- Definición: esta operación permitirá al administrador eliminar los datos de un

empleado.

- Precondición: el administrador desea eliminar un empleado.

- Postcondición: se eliminan los datos del empleado.

Caso de uso 31: Login

- Definición: representa el mecanismo para identificar el rol que el usuario que accede a

la aplicación asume. Consiste en la introducción del nombre de usuario y contraseña

establecidos. Una vez que estos datos han sido proporcionados a la aplicación, la

misma se encargará de realizar una autentificación obteniendo los privilegios que tiene

el usuario en la aplicación y mostrando la interfaz apropiada para dicho usuario.

- Precondición: el usuario debe estar validado dentro de la base de datos. Accede a la

zona restringida mediante su nombre de usuario y su contraseña.

- Postcondición: el usuario podrá realizar las operaciones asignadas para su rol.

La figura 36 muestra el diagrama de casos de uso para la gestión de un entrenador.

Como se puede observar, el usuario empleado solo puede visualizar los datos.

Figura 36: Diagrama de casos de uso para la gestión de un entrenador.

48

Caso de uso 32: Visualizar entrenador

- Definición: esta operación permitirá al administrador o al empleado visualizar los datos

de un entrenador.

- Precondición: el empleado o el administrador desea visualizar un entrenador.

- Postcondición: se muestran los datos del entrenador.

Caso de uso 33: Añadir entrenador


entrenador.

- Precondición: el administrador desea añadir un entrenador.

- Postcondición: se añaden los datos del nuevo entrenador.

Caso de uso 34: Modificar entrenador


entrenador.

- Precondición: el administrador desea modificar los datos de un entrenador.

- Postcondición: se modifican los datos de un entrenador.

Caso de uso 35: Eliminar entrenador


entrenador.

- Precondición: el administrador desea eliminar un entrenador.

- Postcondición: se eliminan los datos del entrenador.

La figura 37 muestra el diagrama de casos de uso para la gestión de un administrador.

Como se puede observar, el usuario empleado no tiene acceso a ninguna de estas acciones.

Figura 37: Diagrama de casos de uso para la gestión de un administrador.

49

Caso de uso 36: Visualizar administrador

- Definición: esta operación permitirá al administrador visualizar los datos de un

administrador.

- Precondición: el administrador desea visualizar un administrador.

- Postcondición: se muestran los datos del administrador.

Caso de uso 37: Añadir administrador


administrador.

- Precondición: el administrador desea añadir un administrador.

- Postcondición: se añaden los datos del nuevo administrador.

Caso de uso 38: Modificar administrador


administrador.

- Precondición: el administrador desea modificar los datos de un administrador.

- Postcondición: se modifican los datos de un administrador.

Caso de uso 39: Eliminar administrador


administrador.

- Precondición: el administrador desea eliminar un administrador.

- Postcondición: se eliminan los datos del administrador.

La figura 38 muestra el diagrama de casos de uso para la gestión de un equipo.

Figura 38: Diagrama de casos de uso para la gestión de un equipo.

Caso de uso 40: Visualizar equipo


de un equipo.

- Precondición: el empleado o el administrador desea visualizar un equipo.

- Postcondición: se muestran los datos del equipo.

50

Caso de uso 41: Añadir equipo

- Definición: esta operación permitirá al empleado o al administrador añadir los datos

de un nuevo equipo.

- Precondición: el empleado o el administrador desea añadir un equipo.

- Postcondición: se añaden los datos del nuevo equipo.

Caso de uso 42: Modificar equipo

- Definición: esta operación permitirá al empleado y al administrador modificar los

datos de un equipo.

- Precondición: el empleado o el administrador desea modificar los datos de un equipo.

- Postcondición: se modifican los datos de un equipo.

Caso de uso 43: Eliminar equipo

- Definición: esta operación permitirá al empleado o al administrador eliminar los datos

de un equipo.

- Precondición: el empleado o el administrador desea eliminar un equipo.

- Postcondición: se eliminan los datos del equipo.

A partir de aquí, para que la visualización de los diagramas sea más clara, solamente

se incluye el usuario empleado en los diagramas, si bien el usuario administrador tiene los

mismos privilegios en todos estos casos.

La figura 39 muestra el diagrama de casos de uso para la gestión de un jugador.

Figura 39: Diagrama de casos de uso para la gestión de un jugador.

Caso de uso 44: Visualizar jugador


de un jugador.

- Precondición: el empleado o el administrador desea visualizar un jugador.

- Postcondición: se muestran los datos del jugador.

51

Caso de uso 45: Añadir jugador


de un nuevo jugador.

- Precondición: el empleado o el administrador desea añadir un jugador.

- Postcondición: se añaden los datos del nuevo jugador.

Caso de uso 46: Modificar jugador

- Definición: esta operación permitirá al empleado o al administrador modificar los

datos de un jugador.

- Precondición: el empleado o el administrador desea modificar los datos de un jugador.

- Postcondición: se modifican los datos de un jugador.

Caso de uso 47: Eliminar jugador


de un jugador.

- Precondición: el empleado o el administrador desea eliminar un jugador.

- Postcondición: se eliminan los datos del jugador.

La figura 40 muestra el diagrama de casos de uso para la gestión de un partido.

Figura 40: Diagrama de casos de uso para la gestión de un partido.

Caso de uso 48: Visualizar partido


de un partido.

- Precondición: el empleado o el administrador desea visualizar un partido.

- Postcondición: se muestran los datos del partido.

52

Caso de uso 49: Añadir partido


de un nuevo partido.

- Precondición: el empleado o el administrador desea añadir un partido.

- Postcondición: se añaden los datos del nuevo partido.

Caso de uso 50: Modificar partido


datos de un partido.

- Precondición: el empleado o el administrador desea modificar los datos de un partido.

- Postcondición: se modifican los datos de un partido.

Caso de uso 51: Eliminar partido


de un partido.

- Precondición: el empleado o el administrador desea eliminar un partido.

- Postcondición: se eliminan los datos del partido.

La figura 41 muestra el diagrama de casos de uso para la gestión de estadísticas.

Figura 41: Diagrama de casos de uso para la gestión de estadísticas.

Caso de uso 52: Visualizar estadísticas

- Definición: esta operación permitirá al empleado o al administrador visualizar las

estadísticas de los partidos de un jugador o de un equipo.

- Precondición: el empleado o el administrador desea visualizar las estadísticas de los

partidos de un jugador o de un equipo.

- Postcondición: se muestran las estadísticas de los partidos de un jugador o de un

equipo.

53

Caso de uso 53: Añadir estadísticas

- Definición: esta operación permitirá al empleado o al administrador añadir las

estadísticas del partido de un jugador o de un equipo.

- Precondición: el empleado o el administrador desea añadir las estadísticas del partido

de un jugador o de un equipo.

- Postcondición: se añaden las estadísticas del partido de un jugador o de un equipo.

Caso de uso 54: Modificar estadísticas

- Definición: esta operación permitirá al empleado o al administrador modificar las


- Precondición: el empleado o el administrador desea modificar las estadísticas del

partido de un jugador o de un equipo.

- Postcondición: se modifican las estadísticas del partido de un jugador o de un equipo.

Caso de uso 55: Eliminar estadísticas

- Definición: esta operación permitirá al empleado o al administrador eliminar las


- Precondición: el empleado o el administrador desea eliminar las estadísticas del

partido de un jugador o de un equipo.

- Postcondición: se eliminan las estadísticas del partido de un jugador o de un equipo.

La figura 42 muestra el diagrama de casos de uso para la gestión de un padre.

Figura 42: Diagrama de casos de uso para la gestión de un padre.

Caso de uso 56: Visualizar padre


del padre o tutor del jugador.

- Precondición: el empleado o el administrador desea visualizar los datos del padre o

tutor del jugador.

- Postcondición: se muestran los datos del padre o tutor del jugador.

54

Caso de uso 57: Añadir padre


de un nuevo padre o tutor del jugador.

- Precondición: el empleado o el administrador desea añadir un padre o tutor del

jugador.

- Postcondición: se añaden los datos del nuevo padre o tutor del jugador.

Caso de uso 58: Modificar padre


datos los datos del padre o tutor del jugador.

- Precondición: el empleado o el administrador desea modificar los datos del padre o

tutor del jugador.

- Postcondición: se modifican los datos del padre o tutor del jugador.

Caso de uso 59: Eliminar padre


del padre o tutor del jugador.

- Precondición: el empleado o el administrador desea eliminar los datos del padre o

tutor del jugador.

- Postcondición: se eliminan los datos del padre o tutor del jugador.


A continuación, se muestran los requisitos funcionales:

RF.1: gestión de un empleado

Esta aplicación será restringida y deberá permitir la recogida de datos sobre la Escuela de

Fútbol de Mareo en Logroño. Cada empleado tendrá control para visualizar los empleados y

cada administrador tendrá control para visualizar, añadir, eliminar y modificar los empleados

almacenados en la base de datos para mantenerla actualizada.

Casos de uso: el requisito se deriva de los casos de uso 27.-Visualizar empleado, 28-Añadir

empleado, 29.-Modificar empleado y 30.-Eliminar empleado.

RF.2: gestión de un entrenador


Fútbol de Mareo en Logroño. Cada empleado tendrá control para visualizar los entrenadores y

cada administrador tendrá control para visualizar, añadir, eliminar y modificar los

entrenadores almacenados en la base de datos para mantenerla actualizada.

Casos de uso: el requisito se deriva de los casos de uso 32.-Visualizar entrenador, 33.-Añadir

entrenador, 34.- Modificar entrenador y 35.- Eliminar entrenador.

RF.3: gestión de un administrador


Fútbol de Mareo en Logroño. Cada administrador tendrá control para visualizar, añadir,

55

eliminar y modificar los administradores almacenados en la base de datos para mantenerla

actualizada.

Casos de uso: el requisito se deriva de los casos de uso 36.-Visualizar administrador, 37.-Añadir

administrador, 38.- Modificar administrador y 39.- Eliminar administrador.

RF.4: gestión de un equipo


Fútbol de Mareo en Logroño. Cada empleado y cada administrador tendrá control para

visualizar, añadir, eliminar y modificar los equipos almacenados en la base de datos para

mantenerla actualizada.

Casos de uso: el requisito se deriva de los casos de uso 40.-Visualizar equipo, 41.-Añadir

equipo, 42.-Modificar equipo y 43.-Eliminar equipo.

RF.5: gestión de un jugador



visualizar, añadir, eliminar y modificar los jugadores almacenados en la base de datos para


Casos de uso: el requisito se deriva de los casos de uso 44.-Visualizar jugador, 45.-Añadir

jugador, 46.- Modificar jugador y 47.-Eliminar jugador.

RF.6: gestión de un partido


Fútbol de Mareo en Logroño. Cada empleado y administrador tendrá control para visualizar,

añadir, eliminar y modificar los partidos almacenados en la base de datos para mantenerla

actualizada.

Casos de uso: el requisito se deriva de los casos de uso 48.-Visualizar partido, 49.-Añadir

partido, 50.- Modificar partido y 51.- Eliminar partido.

RF.7: gestión de estadísticas



visualizar, añadir, eliminar y modificar las estadísticas almacenadas en la base de datos para


Casos de uso: el requisito se deriva de los casos de uso 52.-Visualizar estadísticas, 53.-Añadir

estadísticas, 54.- Modificar estadísticas y 55.- Eliminar estadísticas.

RF.8: gestión de un padre


Fútbol de Mareo en Logroño. Cada empleado y administrador tendrá control para visualizar,

añadir, eliminar y modificar los padres almacenados en la base de datos para mantenerla

actualizada.

Casos de uso: el requisito se deriva de los casos de uso 56.-Visualizar padre, 57.-Añadir padre,

58.- Modificar padre y 59.- Eliminar padre.

56

RF.9: privilegios de administrador

Existirá un perfil de administrador que tendrá total libertad para el acceso y control total de la

aplicación. El nombre de usuario y la contraseña serán asignados al administrador a la entrega

de la aplicación. Por último comentar que el administrador podrá crear más perfiles de

administrador.

RF.10: privilegios de empleado

El administrador creará perfiles para los distintos empleados de la Escuela de Fútbol de Mareo

en Logroño, quienes podrán acceder a la parte restringida de la aplicación asociada a ellos. El

nombre de usuario (nombre y primer apellido sin espacios) y la contraseña serán asignados al

empleado por el administrador. El empleado podrá cambiar la contraseña cuantas veces

desee.

Requisitos no funcionales

A continuación, se muestran los requisitos no funcionales:

RNF.1: requisitos de usabilidad

El producto final deberá ser lo más sencillo posible de manejar, para una mayor compresión y

rapidez de uso para los diferentes usuarios

RNF.2: requisitos de seguridad

La aplicación debe tener una gestión segura para impedir el acceso no autorizado y proteger

de las amenazas más usuales como:

Inyección SQL: es un método de inserción o “inyección” de código intruso que se vale de una


para realizar consultas a una base de datos. Para evitarlo en la aplicación, utilizaré el código

necesario para ello.

Ataques por contraseña: es cuando un atacante utiliza las técnicas necesarias para descubrir

las contraseñas. Para evitarlo en la aplicación, las contraseñas serán almacenadas encriptadas

y así evitar problemas al enviarlas y recibirlas con la base de datos. El algoritmo utilizado será

MD5.

Debilidad del sistema de autenticación: es cuando un usuario no autorizado accede a la

aplicación. Para evitarlo se crearán sesiones para manejar la información que cada usuario

necesita. Una vez el usuario cierre la sesión, o bien, pasen 10 minutos de inactividad, dicha

sesión se destruirá.

RNF.3: requisitos de concurrencia

Se estudiará el problema de la concurrencia para evitar que haya problemas en el acceso

concurrente de dos o más usuarios a la base de datos de la aplicación. Para ello, cuando un

usuario modifique una determinada información, esta se bloqueará para que no surjan

lecturas sucias u otros problemas.

57

RNF.4: requisitos de privacidad

Solo podrán acceder a la aplicación, una vez registrados por el administrador, empleados de la

Escuela de Fútbol de Mareo en Logroño. La información almacenada en la aplicación solo será

utilizada para labores internas y cumplirá las disposiciones recogidas en la Ley Orgánica de

Protección de Datos.

RNF.5: requisitos de mantenimiento

La aplicación debe ser fácil de mantener una vez implementada.

RNF.6: requisitos de rendimiento

El sistema deberá ser rápido y el tiempo de respuesta el mínimo posible para que la

navegación sea lo más ágil posible.

RNF.7: requisitos de software

La aplicación debe ser manejable en los navegadores más usados, tales como: Internet

Explorer, Firefox, Chrome y Safari.

Prototipos de interfaz

En este apartado se muestran los bocetos de los prototipos de interfaz que se van a

utilizar en este segundo ciclo sobre la aplicación de gestión de estadísticas. Estos prototipos se

seguirán como guía a la hora de diseñar las interfaces de la aplicación, pero no necesariamente

será así estructurado el diseño final de la interfaz.

Como he comentado anteriormente, esta aplicación es de acceso restringido para los

diferentes empleados y administradores de la Escuela de Fútbol de Mareo en Logroño, por los

que serán los encargados de interactuar con la interfaz para visualizar, añadir, eliminar y

modificar cualquier información contenida en la aplicación. A continuación, se muestra una

primera toma de cómo estará estructurada la interfaz de la aplicación:

Login:

Figura 43: Prototipo de interfaz login

58

Visualizar información:

Figura 44: Prototipo de interfaz visualizar información.

Añadir información:

Figura 45: Prototipo de interfaz añadir información

59

Modificar información:

Figura 46: Prototipo de interfaz modificar información

Prototipo de interfaz eliminar información:

Figura 47: Prototipo de interfaz eliminar información

60

Clases de análisis

A continuación, se muestra el diagrama de clases UML referente a este segundo ciclo

sobre la aplicación de gestión de estadísticas:

Figura 48: UML. Clases de análisis.

Clases

Empleado: representa a todos los empleados que forman parte de la Escuela de Fútbol de

Mareo en Logroño. De esta superclase heredan las siguientes subclases:

Administrador: subclase que identifica al empleado que es administrador de la

aplicación.

Entrenador: subclase que identifica a los empleados que son entrenadores de los


Jugador: representa a todos los jugadores pertenecientes a la Escuela de Fútbol de Mareo en

Logroño.

Equipo: representa a todos los equipos que forman la Escuela de Fútbol de Mareo en Logroño.

Padre: contiene los datos de los padres que tienen a uno o varios hijos jugando en algún

equipo de la Escuela de Fútbol de Mareo en Logroño.

Partido: contiene los datos de los partidos jugados por los diferentes equipos de la Escuela de

Fútbol de Mareo en Logroño.

61

Diseño

Diseño arquitectónico

Para el desarrollo de la aplicación voy a utilizar un diseño arquitectónico de tres capas

(presentación, lógica de negocio y persistencia), en el que objetivo primordial es la separación

de la lógica de negocio de la lógica de diseño. A continuación, se muestra la estructura de las

capas:

Figura 49: Arquitectura tres capas

- Capa de presentación: es la que ve el usuario, es decir, presenta el sistema al usuario.

En la aplicación, estaría compuesta por la interfaz de usuario que compone el sistema.

Esta interfaz será la utilizada a través de Internet por los diferentes empleados de la


- Capa de negocio: es donde residen los programas que se ejecutan, se reciben las

peticiones del usuario y se envían las respuestas tras el proceso. Aquí es donde se

establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de

presentación, para recibir las solicitudes y presentar los resultados, y con la capa de

datos, para solicitar al gestor de base de datos almacenar o recuperar datos de él. En

la aplicación, estaría compuesta por el código que permite gestionar y presentar toda

la información que contiene la aplicación.

- Capa de persistencia (datos): es donde residen los datos y es la encargada de acceder a

los mismos. Reciben solicitudes de almacenamiento o recuperación de información

desde la capa de negocio. En la aplicación, está compuesta por el código que accede a

la BD MySQL.

62

Diseño de la base de datos

Entidad relación

Para describir cuáles son las entidades y cuáles son los atributos que deberá contener

cada entidad, he construido un diagrama Entidad Relación Extendido (EER) que me ayudará a

entenderlo.

Figura 50: Entidad relación

63

A continuación, se va a describir de una forma más amplia y detallada el contenido de estas

entidades:

- Empleado: entidad que contiene todos los datos necesarios para utilizar la aplicación.

Contiene los datos personales de los empleados de la Escuela de Fútbol de Mareo en

Logroño, así como nombre de usuario (nombre y primer apellido sin espacios) y

contraseña para acceder a la aplicación. Además, incluye el dato rol, el cuál servirá a la

aplicación para asignar los privilegios dependiendo de quién acceda a ella. La clave

primaria de la entidad es DNI.

- Administrador: entidad en la que se registran los datos de los empleados que son

administradores. Los datos que contiene son la identificación del administrador y su

DNI. La clave primaria de la entidad es el DNI.

- Entrenador: entidad en la que se registran los datos de los empleados que son

entrenadores. Los datos que contiene son la identificación del entrenador, el DNI y el

cargo que representa en el equipo que entrena. La clave primaria de la entidad es el

DNI.

- Jugador: entidad que contiene todos los datos de los jugadores que pertenecen a la

Escuela de Fútbol de Mareo en Logroño. Contiene un identificador único para cada

jugador, todos los datos personales, la posición que ocupa en el campo y la pierna

hábil. La clave primaria de la entidad es el identificador del jugador.

- Equipo: entidad que contiene todos los equipos que componen la Escuela de Fútbol de

Mareo en Logroño. El único campo y clave primaria de la entidad es categoría.

- Partido: entidad que contiene todos los datos necesarios para almacenar los partidos

jugados por los equipos de la Escuela de Fútbol de Mareo en Logroño. Los datos que

contiene son el rival del partido, el campo en el que se juega, si juega de local o

visitante, la fecha en la que se juega, la jornada a la que pertenece el partido y las

características generales del partido, cómo son los goles de uno y otro equipo y las

tarjetas. La clave primaria de la entidad es el identificador partido.

- Padre: entidad que contiene los datos de los padres de los jugadores de la Escuela de

Fútbol de Mareo en Logroño. Contiene el DNI, nombre, apellidos, email y teléfono

móvil del padre. La clave primaria de la entidad es el DNI.

64

Modelo conceptual

Una vez detalladas las entidades necesarias para esta iteración, se va a proceder a

realizar la transformación al modelo conceptual.

Figura 51: Modelo conceptual

65

Diagrama de base de datos

A partir del diagrama de entidad-relación y el conceptual se ha definido la estructura

de las tablas de la base de datos.

Figura 52: Diagrama de base de datos

66

Normalización

Primera Formal Normal (1FN)

Se puede decir que la base de datos está en 1FN porque todos sus atributos son

monovaluados, es decir, sus valores son atómicos.

Segunda Forma Normal (2FN)

La base de datos que he creado se encuentra en 2FN porque puedo determinar que

está en 1FN y además cualquier atributo que no figura en la clave candidata depende de toda

la clave candidata en vez de solo una parte de ella.

Tercera Forma Normal (3FN)

Tras haber realizado un análisis de la base de datos puedo determinar que la base de

datos se encuentra en 3FN, ya que todas las tablas se encuentran en 2FN y ningún atributo no-

primario de la tabla es dependiente transitivamente de una clave candidata. Un atributo no-

primario es un atributo que no pertenece a ninguna clave candidata. Una dependencia

transitiva es una dependencia funcional X → Z en la cual Z no es inmediatamente dependiente

de X, pero sí de un tercer conjunto de atributos Y, que a su vez depende de X. Es decir, X → Z

por virtud de X → Y e Y → Z.

Forma Normal de Boyce-Codd (FNBC)

Llegados a este punto puedo decir que la base de datos también se encuentra en

FNBC, porque en cada relación X → Y, X es superclave.

Por lo tanto, puedo concluir que la base de datos se encuentra normalizada hasta la

Forma Normal de Boyce-Codd.

67

Clases de diseño

En este apartado se va a detallar el diagrama de clases mostrado en el apartado de

clases de análisis.

A continuación, se muestran las clases de diseño junto a todos sus atributos y su

constructor. Para facilitar la legibilidad solo se han incluido varias operaciones y no se han

añadido los métodos Get y Set de las clases.

Figura 53: Clases de diseño

Clases de negocio

La clase Empleado representa a todos los empleados que forman la Escuela de Fútbol

de Mareo en Logroño. Por ello, contendrá todos los empleados que podrán acceder a la

aplicación de gestión de estadísticas. El campo Rol servirá a la aplicación para asignar los

privilegios que tiene cada empleado.

De dicha clase heredan las subclases Administrador y Entrenador. Esta última posee

una relación con la clase Equipo, con la cuál puedo conocer los entrenadores que dirigen a un

equipo.

A su vez, la clase Equipo está relacionada tanto con la clase Jugador como con la clase

Partido, lo que me permite conocer los jugadores que pertenecen a un Equipo y los partidos

que juega un Equipo.

Por otro lado, en la clase EsJugadoPor existen dos relaciones, una con la clase Partido

y otra con la clase Jugador, por lo que puedo conocer los Jugadores que han jugado el Partido,

y así añadir las diferentes estadísticas de cada jugador en cada partido en EsJugadoPor.

Por último, en la clase Jugador también existe otra relación con Padre, para conocer el

tutor o padre que tiene el Jugador.

68

Especificación de pruebas unitarias

En este apartado se va a especificar las pruebas mínimas a realizar una vez acabada la

construcción del ciclo gestión de estadísticas.

A continuación, se identifican las clases de equivalencia y después se originarán los

casos de prueba correspondientes.

Para que la memoria no sea demasiada extensa, solamente se van a mostrar varias

pruebas.

Clases de equivalencia

Se separarán una por una las pantallas de la aplicación Web con el fin de facilitar su

identificación.

Cada clase de equivalencia se identificará con un número de identificación. Prefijo de

la página que pertenezca, un guion y el número de clase de equivalencia.

Acceso empleados (AE)

Esta clase de equivalencia corresponde con la página de acceso de los empleados a la

aplicación gestión de estadísticas.

Condición de entrada

Clases válidas Clases no válidas

Empleado

Existe El nombre usuario existe en la BD

AE-1 El nombre de usuario no existe en la BD

AE-2

Contraseña

Existe La contraseña existe en la BD

AE-3 La contraseña no existe en la BD

AE-4

Rol

Administrador Rol=’Administrador’ AE-5

No administrador

Rol=’Entrenador’ Rol=’Otro Empleado’

AE-6

Cambiar contraseña Empleado (CCE)

Esta clase de equivalencia corresponde con la página cambiar la contraseña de acceso

a la aplicación gestión de estadísticas (Rol no Administrador).



Contraseña 1 y Contraseña 2

Iguales Contraseña1 = Contraseña2

CCE-1 Contraseña1 != Contraseña 2

CCE-2

Contraseña 1 Nº Caracteres >= 8 caracteres

<= 15 caracteres CCE-3 < 8 caracteres

> 15 caracteres CCE-4

Formato La contraseña contiene números y letras

CCE-5 La contraseña no contiene números y letras

CCE-6

69

Identificación casos de prueba

En este apartado se crearán los casos de prueba una vez obtenidas las clases de

equivalencia. Para que la memoria no sea demasiada extensa, solamente se van a mostrar los

casos de prueba resueltos para las clases de equivalencia obtenidas en el apartado anterior.

Acceso empleados (AE):

Prueba Unitaria 1

Casos válidos

Descripción Acceso correcto de un Empleado con rol Administrador

Entradas Nombre usuario: administrador Contraseña: proyecto2012

Clases cubiertas AE-1, AE-3, AE-5

Salida Esperada Conectado correctamente: Rol Administrador

Prueba Unitaria 2

Casos válidos

Descripción Acceso correcto de un Empleado con rol Entrenador

Entradas Nombre usuario: abelsierra Contraseña: 6934bohece


Salida Esperada Conectado correctamente: Rol Entrenador u Otro Empleado

Prueba Unitaria 3

Casos no válidos

Descripción Acceso incorrecto de un Empleado. La contraseña no existe en la BD.

Entradas Nombre usuario: abelsierra Contraseña: contrasena

Clases cubiertas AE-2, AE-4

Salida Esperada Nombre usuario o contraseña incorrectos

Prueba Unitaria 4

Casos no válidos

Descripción Acceso incorrecto de un Empleado. El nombre usuario y la contraseña no existen en la BD.

Entradas Nombre usuario: “ ” Contraseña: “ “



70

Cambiar Contraseña Empleado (CCE):

Prueba Unitaria 5

Casos válidos

Descripción Modificación de la contraseña correcta de un Empleado

Entradas Contraseña1: 97t242p7 Contraseña2: 97t242p7

Clases cubiertas CCE-1, CCE-3, CCE-5

Salida Esperada La contraseña se ha modificado

Prueba Unitaria 6

Casos no válidos

Descripción Modificación de la contraseña incorrecta de un Empleado. Las contraseñas no son iguales.

Entradas Contraseña1: aaaaaa77 Contraseña2: aaaaaa78

Clases cubiertas CCE-2

Salida Esperada Las Contraseñas son diferentes. No se ha modificado la Contraseña

Prueba Unitaria 7

Casos no válidos

Descripción Modificación de la contraseña incorrecta de un Empleado. Las contraseñas no contienen números y letras.

Entradas Contraseña1: aaaaaaaa Contraseña2: aaaaaaaa


Salida Esperada Los datos introducidos no cumplen los formatos establecidos. La Contraseña no se ha modificado

Prueba Unitaria 8

Casos no válidos Descripción Modificación de la contraseña incorrecta de un Empleado. Las

contraseñas no tienen el número mínimo de caracteres (8).

Entradas Contraseña1: aa Contraseña2: aa

Clases cubiertas CCE-1, CCE-4


71

Construcción

Tecnología utilizada

No voy a entrar en detalles de la tecnología utilizada, ya que esa descripción ya se ha

realizado en el DOP (Documento de objetivos del proyecto).

La implementación de la aplicación gestión de estadísticas se ha realizado utilizando la

tecnología PHP. Para llevar a cabo el proyecto se han utilizado la herramienta Netbeans IDE

PHP, Dreamweaver y el servidor apache XAMPP.

Además para la creación de la BD MySQL se ha utilizado la herramienta PHPMyAdmin.

Por último, he utilizado el conjunto de bibliotecas de base de datos para PHP ADOdb.

Esto me permite tener la gran ventaja de poder cambiar de base de datos sin necesidad de

rescribir cada llamada a la base de datos realizada por la aplicación.

Código relevante

En este apartado se va a mostrar las partes del código que he considerado más

relevantes.

Encriptar contraseña

Para proteger la seguridad en el acceso de los empleados a la aplicación, utilizo el

algoritmo de reducción criptográfico de 128 bits Md5. Para ello, siempre que se inserte o se

modifique un empleado de la Escuela de Fútbol de Mareo en Logroño, o un empleado

modifique la contraseña de acceso a la aplicación, se almacenará la contraseña encriptada en

la base de datos. Esta contraseña será transformada a una cadena en hexadecimal (campo

varchar de 32 caracteres en la base de datos).

Un ejemplo de la utilización del algoritmo MD5 en la aplicación es en la función

“modificarContraseña”. Con esta función se modifica la contraseña de un Empleado, por lo

que para guardarla encriptada en md5, se usa la función md5() de PHP.

//Función que modifica la contraseña de un empleado function modificarContrasena($nombreUsuario,$contrasena)

{

$BD = new baseDatos();

$BD-> conectar();

$BD->comenzarTransaccion();

$consulta = "UPDATE empleado SET

contrasena=md5('".$contrasena."') WHERE

nombre_usuario='".$nombreUsuario."'";

$resultado=$BD->getConexion()->Execute($consulta);

$BD->CompletarTransaccion();

$BD->desconectar();

}

72

Envío y recepción de datos del formulario

Para evitar posibles ataques a la seguridad de los formularios HTML, todos los datos

serán enviados por el método Post. Este método envía ocultos todos los datos.

A continuación, se muestra una parte del código de la aplicación de un formulario. En

la propiedad method de la etiqueta <form> será dónde definiré como envía el formulario los

datos, en este caso, como he comentado anteriormente: post.

<form action="visualizarEmpleado1.php" method="post">

<table width="500px" cellspacing=?"0" cellpadding=?"0" border=?"0"

align="center">?

<tr>

<th class="separador" colspan="4" bgcolor="#e1b600">Visualizar

Empleado</th>

</tr>

</tr>

<tr>

<td class="celdaLabel">

<label for="nombre_usuario">Nombre usuario:</label>

</td>

<td><select name="nombre_usuario"><?php

$empleado = new empleado();

$empleado->sacaMenuDesplegableNombreUsuario(); ?>

</select>

</td>

</tr>

<tr>

<td colspan="2" class="boton"><input class="botonFormulario"

type="submit" value="Buscar"></td>

</tr>

</table>

</form>

Para la recepción del dato del Formulario, accedo a la variable en PHP de la siguiente

forma: $_POST[‘nombre_usuario’]; (Siendo nombre_usuario el nombre del campo del

formulario).

Evitar inyección SQL

La inyección SQL es un método de infiltración de código malicioso que se vale de una


para realizar consultas a una base de datos.

Para evitar este problema de seguridad, valido todas las variables de entrada con la

función de PHP mysql_real_escape_string(). Esta función me devuelve una cadena con los

caracteres especiales “escapados”, es decir, cada vez que se encuentra un carácter especial

para MySQL en la cadena del valor de la variable, le antepone una barra invertida con el fin de

anular el efecto del mismo.

Un ejemplo de la utilización de la función de PHP mysql_real_escape_string() en la

aplicación es: a la variable $nombreUsuario se le asigna el valor que devuelve

mysql_real_escape_string() del dato recogido por el método de envío post. Más adelante,

explicaré la función de PHP utf8_decode.

//Almaceno en variables los datos recogidos en el formulario, evito

inyección, y decodifico ñ y acentos

$nombre_usuario =

mysql_real_escape_string(utf8_decode($_POST['nombre_usuario']));

73

Sesiones

Una sesión se define como el tiempo que un usuario permanece conectado a un sitio

Web. De forma más técnica y relacionada con programación del lado del servidor, una sesión

es un bloque de información que almacena todo tipo de variables y valores relacionados con

los usuarios y sus visitas a un sitio Web en particular. El control de la sesión consiste en poder

realizar un seguimiento del usuario mientras se mantenga navegando por el sitio Web,

permitiendo mostrar contenido de las páginas en función de su nivel de autorización.

A continuación, voy a explicar brevemente como he implementado las sesiones en la

aplicación gestión de estadísticas. Para iniciar una sesión utilizo la función session_start(), con

la cual creo un identificador de sesión nuevo, o retomo un id de sesión creado previamente, y

para destruirla utilizo la función session_destroy().

En primer lugar, la página “login.php” se encarga de validar los datos enviados desde el

formulario de acceso (nombre usuario y contraseña). Si son correctos, creo las variables de

sesión: el nombre de usuario que inicia sesión, si está autentificado y la fecha y hora del último

acceso. Si no son correctos, se redirige al usuario hacia la página “index2.php”, donde se

mostrará el error, junto al formulario de acceso, de que no existen el nombre de usuario y la

contraseña introducidos. El código es el siguiente:

<?php

include_once("../negocio/sesion/funcionesSesion.php");

include_once("../negocio/empleado.php");

session_start();

//creo nombres de variables para los campos recogidos en el formulario

$nombre_usuario =


$contrasena =

mysql_real_escape_string(utf8_decode($_POST['contrasena']));

if(comprobarLogin($nombre_usuario, $contrasena)==true)//Si los datos

están en la BD

{

$_SESSION['usuario'] = $nombre_usuario; //Variable que almacena el

nombre del usuario que se conecta

$_SESSION['autentificado']="si"; //Variable que almacena que está autentificado $_SESSION["ultimoAcceso"]= date("Y-n-j H:i:s");//Variable que

almacena fecha y hora de la última sesión

if (isset($_SESSION['usuario'])) {

$empleado_validado = new empleado();

$rol = $empleado_validado->validarEmpleado($nombre_usuario,

$contrasena);

if ($rol == 'administrador')

{

//header('Location: index_administrador.php');

header('Location:

../administrador/indexAdministrador.php');

}

else

{

header('Location: ../entrenador/indexEntrenador.php');

//$sesion->comprobar_usuario_validado();

}

}

else

74

{

header('Location: ../index2.php');

}

}

else //Si los datos no están en la BD

{

header('Location: ../index2.php');

}

?>

Todas las páginas Web que van a utilizar sesiones, hay que inicializarlas llamando a la

función anteriormente comentada session_start(). Por ello, he creado una página llamada

“seguridad.php” que voy a insertar al inicio de todas las páginas Web de la Aplicación gestión

de estadísticas que requieren protección mediante sesiones. El código es el siguiente:

<?php

session_start();

if($_SESSION['autentificado']=="si") //Si el usuario está

autentificado

{

//Calculamos el tiempo transcurrido

$fechaGuardada = $_SESSION["ultimoAcceso"];

$ahora = date("Y-n-j H:i:s");

//strtotime: convierte una fecha de formato Unix (número de

segundos desde el 1 de Enero del 1970)

$tiempo_transcurrido = (strtotime($ahora)-

strtotime($fechaGuardada));

if($tiempo_transcurrido >= 600){

//si han pasado 10 o más minutos

session_destroy(); // destruyo la sesión

header("Location: ../../index.php"); //envio al usuario a la

página de autentificación

//sino, actualizo la fecha de la sesión

}

else {

$_SESSION["ultimoAcceso"] = $ahora;

}

}

else

{

//si el usuario no está autentificado

header("Location: ../../index.php");

}

?>

Este código comprueba si se está o no autentificado. Si lo está, actualiza la fecha y hora

de la última sesión, en caso contrario se redirige a la página inicial de acceso a la aplicación.

También, por motivo de seguridad, si la sesión está inactiva durante un periodo mayor o igual

de 10 minutos, será destruida, con el consiguiente cierre de sesión.

Por último, la sesión puede ser destruida por el propio empleado o administrador

pulsando sobre “Cerrar Sesión” en la Web. El código que se ejecuta es el siguiente:

<?php

//Cerrar sesión

session_start();

75

unset($_SESSION['usuario']); //destruye la variable de sesión

‘usuario’

session_destroy(); //destruye sesión

header('Location: ../index.php'); //redirecciona a index.php (Acceso

aplicación)

?>

Capa de persistencia

Para añadir, visualizar, modificar y eliminar los datos almacenados en la base de datos

he diseñado y creado en la capa de persistencia una clase llamada “baseDatos” que contiene

todos los métodos necesarios para conectar, desconectar y manejar transacciones.

Como he comentado anteriormente, he utilizado el conjunto de bibliotecas de base de

datos para PHP ADOdb. Esto me permite que si un día migro, por poner un ejemplo, de Mysql

a Oracle, bastará con cambiar el driver. Para poder utilizar ADOdb, me he descargado las

bibliotecas y he incluido la carpeta ADOdb en el directorio de la aplicación.

A continuación, explicaré el código de la clase “baseDatos”:

En primer lugar se debe incluir dos archivos de la carpeta ADOdb5: “adodb-

errorhandler.inc.php” y “adodb.inc.php”. Este último archivo contiene todas las funciones

usadas por todas las clases de bases de datos.

error_reporting(E_ALL); // pasa cualquier mensaje de error al

manejador de errores

//para poder utilizar adodb, incluimos lo siguiente (Carpeta adodb5 de

nuestro proyecto):

include('C:\xampp\htdocs\zonaentrenadores\adodb5\adodb-

errorhandler.inc.php');

include('C:\xampp\htdocs\zonaentrenadores\adodb5\adodb.inc.php');

class baseDatos {

private $servidor='localhost' ; //servidor donde se encuentra

la BD

private $usuario='root';//nombre del usuario que puede acceder

a la BD

private $contrasena='admin';//contraseña poder acceder a la BD

private $nombreBD='efmareologrono'; //nombre de la BD

private $driver='mysqlt';//tipo de servidor: mysqlt para

transacciones

private $conexion;//variable para la conexión

//Obtener conexión

public function getConexion() {

return $this->conexion;

}

Para conectar con la base de datos tengo que crear un objeto de conexión usando la

función ADONewConnection($driver). El driver que utilizo para que funcionen las

transacciones sin ningún problema es ‘mysqlt’. Una vez creado el objeto conexión, llamo a la

función Connect ($servidor, $usuario, $contraseña, $nombreBD) para abrir la conexión.

//Conectar a la BD efmareologrono

public function conectar(){

$this->conexion = ADONewConnection($this->driver);

$this->conexion->Connect($this->servidor,$this-

>usuario,$this->contrasena,$this->nombreBD);

}

76

Para desconectar una conexión establecida utilizo la siguiente función:

//Desconectar de la BD efmareologrono

public function desconectar()

{

$this->conexion->close();

}

El último aspecto a tratar son las transacciones. Adodb5 permite tratar de una forma

muy sencilla las denominadas transacciones inteligentes.

Para comenzar las transacciones utilizo la función llamada comenzarTransaccion(), que

indica que se empieza una transacción invocando StartTrans().

Y para completar la transacción utilizo la función CompletarTransaccion(), la cuál

invoca a CompleteTrans(). La gran ventaja es que detecta cuando ocurre un error SQL, y

procesa, según sea necesario, Rollback o Commit.

//Comenzar transacción

public function comenzarTransaccion()

{

$this->conexion->StartTrans();

}

//Confirmar o cancela transacción: Commit o Rollback

public function CompletarTransaccion()

{

$this->conexion->CompleteTrans();

}

}

?>

Capa lógica de negocio

La capa de lógica de negocio está compuesta por las clases: empleado, administrador,

entrenador, equipo, partido, padre, jugador, y esJugadoPor.

No voy a entrar en detalles sobre todos los atributos y operaciones que tienen cada

clase, pero sí voy a mostrar y explicar varios métodos.

En primer lugar, he elegido el método visualizarEmpleados() que devuelve un array

llamado Empleados con todos los datos de los Empleados de la Escuela de Fútbol de Mareo en

Logroño.

public function visualizarEmpleados()

{


$BD->conectar();

$consulta="SELECT * FROM empleado ";

$empleados=array();

//Ejecutar consulta


//Contamos el numero total de resultados, es decir, numero de

filas

$numero_filas = $resultado->RecordCount();

for($i=0;$i<$numero_filas;$i++){

77

$empleado=new Empleado();

//Array con el resultado de una fila y mueve el

apuntador de datos interno hacia adelante.

$fila= $resultado->FetchRow();

//Creo empleado con los datos de la primera fila

$empleado->set_dni($fila[0]);

$empleado->set_nombreUsuario($fila[1]);

$empleado->set_contrasena($fila[2]);

$empleado->set_rol($fila[3]);

$empleado->set_nombre($fila[4]);

$empleado->set_apellido1($fila[5]);


$empleado->set_telefono($fila[7]);

$empleado->set_email($fila[8]);

$empleado->set_direccion($fila[9]);

$empleado->set_localidad($fila[10]);

$empleado->set_cp($fila[11]);

$empleado->set_puesto($fila[12]);

$empleados[$i]=$empleado; //Añadir al array cada

empleado

}

$BD->desconectar();

return $empleados;

}

La estructura a seguir en la mayoría de métodos que forman las clases en la capa de

lógica de negocio es muy similar. A continuación, la explico:

En primer lugar creo un objeto de tipo “baseDatos”, que como anteriormente he

comentado pertenece a la capa de persistencia, y lo conecto a la base de datos.


$BD->conectar();

Después declaro una variable con el valor de la consulta MySql que voy a realizar. En

este caso, la consulta devolverá todos los empleados de la Escuela de Fútbol de Mareo en

Logroño.

$consulta="SELECT * FROM empleado ";

Se ejecuta y guardo el resultado en una variable con ese mismo nombre.

//Ejecutar consulta


Para conocer el número de resultados que devuelve la consulta realizada utilizo la

función RecordCount(), y lo almaceno en la variable numero_filas.

//Contamos el numero total de resultados, es decir, numero de filas

$numero_filas = $resultado->RecordCount();

Una vez que conozco el número de filas, se van añadiendo, hasta que el bucle llegue a

la última fila, al array empleados todos los objetos empleado creados en cada fila.

for($i=0;$i<$numero_filas;$i++){

$empleado=new Empleado();

//Array con el resultado de una fila y mueve el

apuntador de datos interno hacia adelante.

78

$fila= $resultado->FetchRow();

//Creo empleado con los datos de la primera fila

$empleado->set_dni($fila[0]);

$empleado->set_nombreUsuario($fila[1]);

$empleado->set_contrasena($fila[2]);

$empleado->set_rol($fila[3]);

$empleado->set_nombre($fila[4]);



$empleado->set_telefono($fila[7]);

$empleado->set_email($fila[8]);

$empleado->set_direccion($fila[9]);

$empleado->set_localidad($fila[10]);

$empleado->set_cp($fila[11]);

$empleado->set_puesto($fila[12]);

$empleados[$i]=$empleado; //Añadir al array cada

empleado

}

Se desconecta de la base de datos.

$BD->desconectar();

Se devuelve el array empleados con el resultado de los empleados de la Escuela de

Fútbol de Mareo en Logroño.

return $empleados;

Codificar y decodificar una cadena a UTF-8

Para que la aplicación Web gestión de estadísticas muestre correctamente los acentos

y las letras propias de nuestro idioma como puede ser la letra ñ, al igual que otras letras con

diéresis, utilizaré en toda la aplicación Web la codificación de caracteres UTF-8.

Por este mismo motivo, en la base de datos “efmareologrono” he elegido el juego de

caracteres latin1_spanish_ci para definir todas las tablas que la componen.

Por ello, siempre que la aplicación Web quiera mostrar información de la base de

datos, y añadir o modificar en ella, debo codificar o decodificar los datos para una correcta

utilización de los caracteres. A continuación, detallo como lo he realizado:

Decodificar una cadena UTF-8

Tengo que utilizar esta función de PHP utf8_decode cuando voy a añadir, modificar o

eliminar algún dato desde la aplicación gestión de estadísticas. Con ello consigo que la

aplicación y la base de datos no tengan errores con los caracteres o acentos introducidos. Un

ejemplo de código en el que utilizo esta función es el siguiente:

$nombre = mysql_real_escape_string(utf8_decode($_POST['nombre']));

Para que la base de datos pueda tratar la variable nombre correctamente, decodifico

el valor (nombre) que ha sido enviando por un formulario.

79

Codificar una cadena a UTF-8

En la aplicación gestión de estadísticas tengo que utilizar esta función de PHP

utf8_encode siempre que quiera mostrar información proveniente de la base de datos

“efmareologrono”. Con ello consigo la correcta visualización de todos los caracteres en la

aplicación. Un ejemplo de código en el que utilizo esta función es el siguiente:

utf8_encode($nuevoEmpleado->get_nombre());

Codifico el valor nombre de un empleado capturado de la base de datos para

mostrarlo correctamente en la aplicación gestión de estadísticas.

Añadir Empleado

Para acabar, voy a mostrar a continuación toda la funcionalidad necesaria para

modificar la información almacenada en la aplicación gestión de estadísticas.

Este ciclo conlleva a la existencia de multitud de formularios con los que poder

introducir y modificar todos los datos almacenados en la aplicación. Estos datos serán

validados por las funciones que se incluyen en el fichero “funcionesValidar” dentro de la

carpeta “validar” de la aplicación “zonaEntrenadores” (carpeta principal de la aplicación

gestión de estadísticas), para no permitir la entrada de valores que no cumplan los formatos

establecidos.

Dentro de esta página se va a diferenciar entre dos tipos de código: el que está

orientado al diseño y el que obtiene la funcionalidad (recibe las solicitudes y presenta los

resultados). Esto último existe en todos los archivos que componen la capa de presentación, lo

que permite poder comunicarse con la capa de lógica de negocio.

Código orientado al diseño: “aniadirEmpleado.php”

La página empieza incluyendo el archivo “seguridad.php” explicado anteriormente y el

archivo “cabecera.php”, que contiene la versión de HTML que usa la página, el enlace de la

hoja de estilos, el inicio del contenedor que compone toda la página y el contenedor con la

imagen utilizada para la cabecera en todas las páginas.

En las siguientes líneas se declaran dos contenedores (menuPrincipal y

menuSecundario) que componen el menú y el submenú de la página.

<?php

include_once("../disenoWeb/cabecera.php");

include_once("../../seguridad/seguridad.php");

?>

<div class="menuPrincipal">

<ul>

<li><a href="visualizarEmpleado.php">Empleados</a></li>

<li><a

href="../administrador/visualizarAdministrador.php">Administradores</a

></li>

<li><a

href="../entrenador/visualizarEntrenador.php">Entrenadores</a></li>

<li><a href="../equipo/visualizarEquipo.php">Equipos</a></li>

<li><a href="../jugador/visualizarJugador.php">Jugadores</a></li>

<li><a href="../partido/visualizarPartido.php">Partidos</a></li>

<li><a

href="../esJugadoPor/visualizarEsjugadoPor.php">Estadísticas</a></li>

<li><a href="../padre/visualizarPadre.php">Padres</a></li>

</ul>

</div>

80

<div class="menuSecundario">

<ul>

<li><a href="visualizarEmpleado.php">Visualizar empleados</a></li>

<li><a class="webActual">Añadir empleado</a></li>

<li><a href="modificarEmpleado.php">Modificar empleado</a></li>

<li><a href="eliminarEmpleado.php">Eliminar empleado</a></li>

</ul>

</div>

A continuación, creo el formulario con todos los datos necesarios para añadir el

empleado y una serie de “textbox” donde puede escribir el usuario. Una vez que el usuario

pulse el botón, en este caso “Añadir”, los datos serán enviados ocultos (method=POST) a la

página “aniadirEmpleado1.php” (valor actión del formulario, es decir, la acción que va a

realizar el formulario una vez se pulse el botón).

<div class="principal">

<form action="aniadirEmpleado1.php" method="post">

<table width="auto" cellspacing=?"0" cellpadding=?"0" border=?"0"

align="center">?

<tr>

<th class="separador" colspan="4" bgcolor="#e1b600">Añadir

Empleado</th>

</tr>

<tr>


<label for="dni">DNI:</label>

</td>

<td><input type="text" name="dni" maxlength="9" /></td>

<td class="celdaAsterisco">*</td>

<td class="celdaCampos">Formato: 12345678A</td>

</tr>

<tr>


<label for="nombre_usuario">Nombre usuario:</label>

</td>

<td><input type="text" name="nombre_usuario" maxlength="15"

/></td>

<td class="celdaAsterisco">*</td>

<td class="celdaCampos">Máximo 50 carácteres, compuesto por

nombre y apellido</td>

</tr>

<tr>

<td colspan="4" class="boton"><input class="botonFormulario"

type="submit" value="Añadir"></td>

</tr>

</table>

</form>

</div>

Para acabar con el código encargado del diseño de la página, se incluye el nombre de

usuario que está en la sesión, un enlace para salir de ella y el archivo “footer.php” que

contiene la información sobre los derechos de autor de la aplicación y el cierre del contenedor

que compone toda la página.

<div class="pie">

<table width="100%">

<tr>

<td width="50%">Conectado como: <?php echo $_SESSION['usuario']

?></td>

81

<td width="50%" align="right"><a class="cerrarSesion"

href="../../seguridad/cerrarSesion.php">Cerrar Sesión></a>

</td>

</tr>

</table>

</div>

<?php

include_once("../disenoWeb/footer.php");

?>

Código orientado a la funcionalidad, es decir, recibe las solicitudes y presenta los

resultados: “aniadirEmpleado1.php”

El código empieza incluyendo las clases necesarias:

<?php

include_once("../../negocio/empleado.php");

include_once("../../negocio/administrador.php");

include_once("../../negocio/entrenador.php");

include_once("../../negocio/validar/funcionesValidar.php");

Después recojo las variables enviadas por el formulario (se recogen por el método

post: $_POST) y compruebo si está o no alguna vacía. Si alguna está vacía se redirige a la

página “datosIncorrectos.php” en la que se muestra el error de que los datos introducidos no

cumplen los formatos establecidos, y el formulario para rellenar otra vez.

if (empty($_POST['dni']) || empty($_POST['nombre_usuario']) ||

empty($_POST['contrasena']) || empty($_POST['rol']) ||

empty($_POST['nombre']) || empty($_POST['apellido_1']) ||

empty($_POST['apellido_2']) || empty($_POST['telefono']) ||

empty($_POST['email']) || empty($_POST['direccion']) ||

empty($_POST['localidad']) || empty($_POST['cp']) ||

empty($_POST['puesto']))

{

include_once("datosIncorrectos.php");

}

Si todas las variables contienen datos, los almaceno en variables, evito inyección y

decodifico caracteres.

else

{

//Almaceno en variables los datos recogidos en el formulario,

evito inyeccion, y decodifico ñ y acentos

$dni = mysql_real_escape_string(utf8_decode($_POST['dni']));

$nombre_usuario =


$contrasena =

mysql_real_escape_string(utf8_decode($_POST['contrasena']));

$rol = mysql_real_escape_string(utf8_decode($_POST['rol']));

$nombre = mysql_real_escape_string(utf8_decode($_POST['nombre']));

$apellido_1 =

mysql_real_escape_string(utf8_decode($_POST['apellido_1']));

$apellido_2 =

mysql_real_escape_string(utf8_decode($_POST['apellido_2']));

$telefono =

mysql_real_escape_string(utf8_decode($_POST['telefono']));

$email = mysql_real_escape_string(utf8_decode($_POST['email']));

$direccion =

mysql_real_escape_string(utf8_decode($_POST['direccion']));

82

$localidad =

mysql_real_escape_string(utf8_decode($_POST['localidad']));

$cp = mysql_real_escape_string(utf8_decode($_POST['cp']));

$puesto = mysql_real_escape_string(utf8_decode($_POST['puesto']));

Antes de añadir el Empleado, valido los datos introducidos para comprobar que son

correctos.

Si son correctos, compruebo si existen o no el DNI introducido, el teléfono, el nombre

de usuario o el email. Si existe alguno de ellos, devuelvo error (deben ser únicos) y en caso

contrario añado Empleado.

En este caso, el Empleado añadido puede tener el rol de Administrador, Entrenador u

Otro Empleado. Sea uno u otro, se realizar uno de estos tres casos:

- Si Rol es igual a “Administrador”, se crea el objeto Administrador y se añade con los

datos introducidos un nuevo Administrador. La aplicación mostrará que el Empleado

se ha añadido correctamente.

- Si Rol es igual a “Entrenador”, redirecciono a una nueva página para que se agreguen

los datos necesarios para añadir un nuevo Entrenador. Una vez agregado el

Entrenador, se mostrará que el Empleado se ha añadido correctamente.

- Si Rol es igual a “Otro empleado”, la aplicación mostrará que el Empleado se ha

añadido correctamente.

$empleado->aniadirEmpleado($dni, $nombre_usuario,$contrasena, $rol,

$nombre, $apellido_1, $apellido_2, $telefono, $email, $direccion,

$localidad, $cp, $puesto);

if($rol=='administrador')

{

//No hace falta validar el DNI, ya que ya estᠶalidado al aañadir el empleado

$administrador = new administrador();

$id_administrador = NULL;

$administrador->aniadirAdministrador($dni, $id_administrador);

include_once("aniadidoCorrecto.php");

}

elseif ($rol=='entrenador')

{

include_once('aniadirEntrenador.php');

}

else

{

include_once('aniadidoCorrecto.php');

}

83


En el apartado anterior, prototipos de interfaz, se mostraban los bocetos de como se

iban a estructurar las Interfaces de la aplicación gestión de estadísticas. A continuación,

muestro las Interfaces definitivas de la aplicación con algunas modificaciones respecto a la

estructura del boceto.

Dos aspectos que he añadido respecto a los bocetos son: un submenú para cada

componente del menú principal e información sobre el nombre del Empleado que ha iniciado

sesión en la aplicación gestión de estadísticas.

Login:

La figura 54 muestra la interfaz de acceso a la aplicación gestión de estadísticas.

Figura 54: Interfaz login

Si se introduce un nombre de usuario y contraseña incorrectos la aplicación mostrará

la figura 55:

84

Figura 55: Interfaz login incorrecto

Si por el contrario, accedo correctamente a la aplicación, se mostrará el “index”

correspondiente a los privilegios que tiene el Empleado sobre la aplicación. Es decir, si el

Empleado que accede tiene rol Administrador, se mostrará la interfaz de la figura 56 y en caso

contrario la interfaz de la figura 57.

Index Administrador:

Figura 56: Interfaz index administrador

85

Index Empleado:

Figura 57: Interfaz index empleado

Resultados de las pruebas unitarias

A continuación compruebo que los resultados de las pruebas unitarias diseñadas en el

proceso anterior son los esperados. Solamente se muestran varias pruebas:

Prueba Unitaria 1

Descripción Acceso correcto de un Empleado con rol Administrador

Entradas Nombre usuario: administrador Contraseña: proyecto2012


Salida Esperada Conectado correctamente: Rol Administrador.

Salida Obtenida Conectado correctamente: Rol Administrador.

Prueba Correcta SÍ.

Prueba Unitaria 2

Descripción Acceso correcto de un Empleado con rol Entrenador

Entradas Nombre usuario: abelsierra Contraseña: 6934bohece


Salida Esperada Conectado correctamente: Rol Entrenador.

Salida Obtenida Conectado correctamente: Rol Entrenador.


86

Prueba Unitaria 3

Descripción Acceso incorrecto de un Empleado. La contraseña no existe en la BD.

Entradas Nombre usuario: abelsierra Contraseña: contrasena



Salida Obtenida Nombre usuario o contraseña incorrectos


Prueba Unitaria 4

Descripción Acceso incorrecto de un Empleado. El nombre usuario y la contraseña no existen en la BD.

Entradas Nombre usuario: “ ” Contraseña: “ “



Salida Obtenida Nombre usuario o contraseña incorrectos


Prueba Unitaria 5

Descripción Modificación de la contraseña correcta de un Empleado

Entradas Contraseña1: 97t242p7 Contraseña2: 97t242p7


Salida Esperada La contraseña se ha modificado

Salida Obtenida La contraseña se ha modificado


Prueba Unitaria 6

Descripción Modificación de la contraseña incorrecta de un Empleado. Las contraseñas no son iguales.

Entradas Contraseña1: aaaaaa77 Contraseña2: aaaaaa78

Clases cubiertas CCE-2

Salida Esperada Las Contraseñas son diferentes. No se ha modificado la Contraseña

Salida Obtenida Las Contraseñas son diferentes. No se ha modificado la Contraseña


87

Prueba Unitaria 7

Descripción Modificación de la contraseña incorrecta de un Empleado. Las contraseñas no contienen números y letras.

Entradas Contraseña1: aaaaaaaa Contraseña2: aaaaaaaa



Salida Obtenida Los datos introducidos no cumplen los formatos establecidos. La Contraseña no se ha modificado


Prueba Unitaria 8

Descripción Modificación de la contraseña incorrecta de un Empleado. Las contraseñas no tienen el número mínimo de caracteres (8).

Entradas Contraseña1: aa Contraseña2: aa

Clases cubiertas CCE-1, CCE-4


Salida Obtenida Los datos introducidos no cumplen los formatos establecidos. La Contraseña no se ha modificado


88

Ciclo 3: Control de las faltas de asistencia a los entrenamientos

Análisis

Introducción

En este tercer y último ciclo del sistema voy a incrementar a la aplicación gestión de

estadísticas las funcionalidades necesarias para gestionar las faltas de asistencia al

entrenamiento. Además, cuando un empleado o administrador añada una falta de

entrenamiento, la aplicación enviará automáticamente al padre, madre o tutor/a del jugador

un mensaje correo electrónico y un mensaje de texto a móvil avisando de la falta de asistencia

al entrenamiento del jugador.

Casos de Uso

Gestionar control de faltas de asistencia a los entrenamientos

En este apartado voy a refinar en primer lugar el caso de uso “Gestionar falta

entrenamiento”:

Figura 58: Diagrama de casos de uso para la gestión de una falta de entrenamiento.

Caso de uso 60: Visualizar falta entrenamiento

- Definición: esta operación permitirá al empleado o al administrador visualizar las faltas

de asistencia a un entrenamiento de un jugador.

- Precondición: el empleado o el administrador desea visualizar las faltas de asistencia a

un entrenamiento de un jugador.

- Postcondición: se muestran las faltas de asistencia a un entrenamiento de un jugador.

Caso de uso 61: Añadir falta entrenamiento

- Definición: esta operación permitirá al empleado o al administrador añadir la falta de

asistencia a un entrenamiento de un jugador.

89

- Precondición: el empleado o el administrador desea añadir la falta de asistencia a un

entrenamiento de un jugador.

- Postcondición: se añaden la falta de asistencia a un entrenamiento de un jugador.

Caso de uso 62: Modificar falta entrenamiento

- Definición: esta operación permitirá al empleado o al administrador modificar la falta

de asistencia a un entrenamiento de un jugador.

- Precondición: el empleado o el administrador desea modificar la falta de asistencia a

un entrenamiento de un jugador.

- Postcondición: se modifica la falta de asistencia a un entrenamiento de un jugador.

Caso de uso 63: Eliminar falta entrenamiento

- Definición: esta operación permitirá al empleado o al administrador eliminar la falta de

asistencia a un entrenamiento de un jugador.

- Precondición: el empleado o el administrador desea eliminar la falta de asistencia a un


- Postcondición: se elimina la falta de asistencia a un entrenamiento de un jugador.

Además, voy a detallar los casos de uso: Control faltas de asistencia al entrenamiento y

Recibir faltas asistencia generados en el diagrama de la visión general. Los diagramas de casos

de uso que definen los requisitos que debe cumplir esta función son los siguientes:

La figura 59 muestra el diagrama de casos de uso del empleado y del administrador

para el control de faltas de asistencia al entrenamiento.

Figura 59: Diagrama de casos de uso para añadir una falta de asistencia a un entrenamiento.

Caso de uso 64: Añadir falta entrenamiento

- Definición: esta operación permitirá al empleado o al administrador añadir una falta

de entrenamiento de un jugador.

90

- Precondición: el empleado o el administrador desea añadir una falta de

entrenamiento.

- Postcondición: se añade la falta de entrenamiento.

Caso de uso 65: Enviar email

- Definición: esta operación enviará un email al Padre notificando una falta de

entrenamiento del jugador.

- Precondición: la aplicación desea enviar un mail al padre con una falta de


- Postcondición: se envía el email al padre con una falta de entrenamiento del jugador.

Caso de uso 66: Enviar SMS

- Definición: esta operación enviará un SMS al padre notificando una falta de


- Precondición: la aplicación desea enviar un SMS al padre con una falta de


- Postcondición: se envía el SMS al padre con una falta de entrenamiento del jugador.

La figura 60 muestra el diagrama de casos de uso del padre para recibir falta de

asistencia al entrenamiento de un jugador.

Figura 60: Diagrama de casos de uso para recibir falta de asistencia a un entrenamiento.

Caso de uso 67: Recibir email

- Definición: esta operación permitirá al padre recibir un email notificando una falta de


- Precondición: el padre desea recibir un mail con una falta de entrenamiento del

jugador.

- Postcondición: el Padre recibe la falta de entrenamiento del jugador mediante email.

Caso de uso 68: Recibir SMS

- Definición: esta operación permitirá al padre recibir un SMS notificando una falta de


91

- Precondición: el padre desea recibir un SMS con una falta de entrenamiento del

jugador.

- Postcondición: el padre recibe la falta de entrenamiento del jugador mediante SMS.


RF.1: gestión de una falta de entrenamiento



visualizar, añadir, eliminar y modificar las faltas de entrenamientos almacenadas en la base de

datos para mantenerla actualizada.

Casos de uso: el requisito se deriva de los casos de uso 60.-Visualizar falta de entrenamiento,

61.-Añadir falta de entrenamiento, 62.- Modificar falta de entrenamiento y 63.- Eliminar falta

de entrenamiento.

RF.2: añadir una falta de entrenamiento

Cualquier empleado o administrador podrá añadir la falta de asistencia a un entrenamiento de

un jugador mediante la aplicación Web.

Casos de uso: el requisito se deriva de los casos de uso 64.-Añadir falta de entrenamiento

RF.3: enviar falta de entrenamiento por email

Al añadir el empleado o el administrador una falta de asistencia a un entrenamiento de un

jugador, se notificará por email al padre, madre o tutor del jugador que previamente ha sido

almacenado en la aplicación junto al jugador.

Casos de uso: el requisito se deriva de los casos de uso 65.-Enviar email

RF.4: enviar falta de entrenamiento por SMS

Al añadir el empleado o el administrador una falta de asistencia a un entrenamiento de un

jugador, se notificará por SMS al padre, madre o tutor del jugador que previamente ha sido

almacenado en la aplicación junto al jugador.

Casos de uso: el requisito se deriva de los casos de uso 66.-Enviar SMS

RF.5: recibir falta de entrenamiento por email

Una vez añadida la falta de entrenamiento por el administrador o el empleado, el padre del

jugador recibirá la notificación por email sobre dicha falta.

Casos de uso: el requisito se deriva de los casos de uso 67.-Recibir email

RF.6: recibir falta de entrenamiento por SMS

Una vez añadida la falta de entrenamiento por el administrador o el empleado, el padre del

jugador recibirá la notificación por SMS sobre dicha falta.

Casos de uso: el requisito se deriva de los casos de uso 68-Recibir SMS

92

Clases de análisis

El diagrama de clases UML de este tercer ciclo es una ampliación del segundo. Como se

puede observar, me veo en la necesidad de añadir las clases entrenamiento, email y SMS.

Figura 61: UML. Clases de análisis ampliado.

Clases

Entrenamiento: contiene los datos necesarios para conocer las faltas al entrenamiento de los

jugadores.

Email: representa la clase que permite a la aplicación enviar un email al padre de un jugador

con la falta de asistencia al entrenamiento.

SMS: representa la clase que permite a la aplicación enviar un SMS al padre de un jugador con

la falta de asistencia al entrenamiento.

93

Diseño

Diseño de la base de datos

Entidad relación ampliado

En este ciclo me veo en la necesidad de añadir una nueva tabla a la base de datos. A

continuación, muestro el diagrama de Entidad Relación creado en el segundo ciclo, con una

nueva entidad llamada Entrenamiento, que contendrá todos los datos necesarios para

almacenar todas las faltas al entrenamiento de los jugadores de la Escuela de Fútbol de Mareo

en Logroño.

Figura 62: Entidad relación ampliado

94

La entidad Entrenamiento contiene el identificador de la falta, la fecha, el estado de si

está o no justificada y el motivo. La clave primaria de la entidad es el identificador de falta.

Una vez añadida esta entidad, no hace falta insertar nada más porque ya se dispone en

la entidad padre del número de teléfono como del correo electrónico al que van a ser enviados

el SMS y el email.

Cabe destacar que la aplicación no almacena los SMS y emails mandados al padre del

jugador respecto a la falta de asistencia al entrenamiento de su hijo. Si bien es cierto, que los

SMS son almacenados por la herramienta utilizada para enviar SMS (intelliSMS).

Modelo conceptual ampliado

Una vez detallada la nueva entidad que va a tener la base de datos, procedo a realizar

la transformación al modelo conceptual.

Figura 63: Modelo conceptual ampliado

95

Diagrama de base de datos ampliado

A partir del diagrama de entidad-relación y el conceptual se ha definido la estructura final de las tablas de la base de datos.

Figura 64: Diagrama de base de datos ampliado

96

Clases de diseño

En este apartado voy a detallar el diagrama de clases mostrado en el apartado de

clases de análisis.

A continuación, muestro las clases de diseño, junto a todos sus atributos y su

constructor. Para facilitar la legibilidad solo se han incluido varias operaciones y no se han

añadido los métodos Get y Set de las clases.

Figura 65: Clases de diseño ampliado

97

Clases de negocio añadidas

La clase Entrenamiento contiene todos los datos necesarios para almacenar todas las

faltas al entrenamiento de los jugadores de la Escuela de Fútbol de Mareo en Logroño. Por

ello, está relacionada con la clase Jugador, lo que permite conocer las faltas de entrenamiento

que tiene cada jugador.

Además, las clases Email y SMS están relacionadas tanto con la clase Entrenamiento

como con la clase Padre, lo que permite conocer la información necesaria al enviar un Email o

un SMS.

Especificación de pruebas unitarias

En este apartado se va a especificar las pruebas mínimas a realizar una vez acabada la

construcción del ciclo control de faltas de asistencia a los entrenamientos.

Como he realizado en el segundo ciclo, primero identificaré las clases de equivalencia y

después se originarán los casos de prueba correspondientes.

Para no extenderme en demasía, solo se muestra una prueba.

Clases de equivalencia

Se separarán una por una las pantallas de la aplicación Web con el fin de facilitar su

identificación.

Cada clase de equivalencia se identificará con un número de identificación. Prefijo de

la página que pertenezca, un guion y el número de clase de equivalencia.

Añadir Falta Entrenamiento (AFE)

Esta clase de equivalencia corresponde con la página de añadir una falta de

entrenamiento.



Fecha

Formato La fecha es correcta AFE-1 La fecha no es correcta AFE-2

Jugador

Existe El jugador existe en la BD AFE-3 El jugador no existe en la BD

AFE-4

Fecha - Jugador

Existe Falta La falta no existe Enviar Email Enviar SMS

AFE-5 La falta ya existe AFE-6

98

Identificación casos de prueba

En este apartado se crearán los casos de prueba una vez obtenidas las clases de

equivalencia.

Añadir Falta Entrenamiento (AFE)

Prueba Unitaria 1

Casos válidos

Descripción Falta entrenamiento añadida correctamente

Entradas Fecha falta entrenamiento: 2012/01/06 Datos jugador:

Nombre: Victor Apellido 1: Marin Apellido 2: Mateo Equipo: Primera Alevin

Clases cubiertas AFE-1, AFE-3, AFE-5

Salida Esperada Falta entrenamiento añadida correctamente. Se ha enviado email y SMS notificando la falta al padre del jugador.

Prueba Unitaria 2

Casos no válidos

Descripción Falta de entrenamiento no añadida. Ya existe la falta de entrenamiento.




Salida Esperada La falta de entrenamiento ya existe. Falta de entrenamiento no añadida.

Prueba Unitaria 3

Casos no válidos

Descripción Error formato fecha

Entradas Fecha falta entrenamiento: “ ” Datos jugador:


Clases cubiertas AFE-2

Salida Esperada La fecha introducida no cumple el formato establecido.

99

Prueba Unitaria 4

Casos no válidos

Descripción Error no existe jugador


Nombre: Pepe Apellido 1: Marin Apellido 2: Mateo Equipo: Primera Alevin


Salida Esperada El jugador introducido no existe. Añada primero el jugador.

100

Construcción

Tecnología utilizada

Para la implementación de este tercer ciclo he utilizado:

- PHPMailer: clase PHP para enviar emails basada en el componente active server

ASPMail. Con PHPMailer puedo enviar emails vía sendmail, PHP mail(), o con SMTP

(Protocolo Simple de Transferencia de Correo). En mi caso he utilizado el envío SMTP

por varias razones:

o Permite enviar los emails en un tiempo menor.

o Permite enviar emails en formato HTML y con archivos adjuntos. Actualmente

en la aplicación no será necesario, pero sí en una posible actualización de la

aplicación en el futuro.

o Permite enviar emails con múltiples destinatarios.

o Y por último, y por lo que principalmente he escogido esta alternativa,

permite utilizar un servidor SMTP con autentificación. Gracias a esto, puedo

enviar correos, en mi caso desde una cuenta Gmail, y evitar la instalación de

un servidor de correo.

- IntelliSMS: es un kit de desarrollo de software (SDK) que permite enviar mensajes SMS

desde un script PHP. Descargar, usar y distribuir esta librería PHP es gratuita. Por el

contrario, el envío de cada SMS es de pago.

Código relevante

Todo el código necesario para enviar un email o un SMS va incluido dentro de la clase

email y la clase sms.

Enviar email

Anteriormente, he citado que la clase PHPMailer ofrece la posibilidad de enviar emails

de una forma sencilla a través del servidor SMTP. Para su utilización, he descargado dicha clase

y he incluido la carpeta “PHPmailer” en el directorio de la aplicación (dentro de la carpeta

“Negocio”).

A continuación, explico el código de la clase Email:

En primer lugar, debo instanciar dos archivos de la carpeta “PHPMailer”:

“class.phpmailer.php” y “class.smtp.php”. Este último archivo lo añado para poder utilizar el

servidor SMTP.

Además, inicializo las variables con los datos necesarios para poder mandar un email

desde mi dirección. En mi caso, el servicio de correo electrónico que voy a utilizar es Gmail.

<?php

//Incluimos estas dos clases de PHPMailer para poder enviar Email

include_once('PHPMailer/class.phpmailer.php');

include_once('PHPMailer/class.smtp.php'); //Para envío por SMTP

class email

{

101

private $emailRemitente = "[email protected]";//email desde

donde se envía el correo. private $nombreRemitente = "EF Mareo Logroño>; //Nombre con el que

se va a mostrar el emisor

private $contrasena = "proyecto2012"; //Contraseña

private $autentificacion = true; //Indica si el servidor necesita

autentificación

private $seguridad = "ssl"; //certificado de seguridad necesario

private $host = "smtp.gmail.com"; //servidor SMTP

private $puerto = 465; //puerto SMPT de Gmail

private $caracteres = 'UTF-8'; //Codificación de caracteres para

mostrar correctamente los acentos y las ñ

Para enviar un email utilizo la función “enviarEmail”:

public function enviarEmail($destinatario,$asunto,$cuerpo)

{

$email = new PHPMailer();

En primer lugar, creo una variable “$email” de tipo PHPMailer que servirá para almacenar

toda la información referente al email:

- El servidor de correo utilizado es SMTP.

$email->IsSMTP();

- La codificación de los caracteres para su correcta visualización en el email (UTF-8):

$email->CharSet = $this->caracteres;

- Si el servidor necesita o no autentificación (True):

$email->SMTPAuth = $this->autentificacion;

- La seguridad del servidor. En este caso el certificado de seguridad SSL utilizado por

Gmail:

$email->SMTPSecure = $this->seguridad;

- El servidor SMTP de Gmail (‘smtp.gmail.com):

$email->Host = $this->host;

- El puerto SMTP utilizado por Gmail (Puerto 465):

$email->Port = $this->puerto;

- El nombre de usuario y la contraseña del correo electrónico Gmail:

$email->Username = $this->emailRemitente;

$email->Password = $this->contrasena;

- La dirección de correo al que se le quiere enviar el email:

$email->AddAddress($destinatario);

- El asunto y el cuerpo del email que se quiere enviar:

$email->Subject = $asunto; //asunto

$email->Body = $cuerpo; //cuerpo

102

- El nombre que quiero mostrar al enviar el email:

$email->FromName = $this->nombreRemitente;

- El correo electrónico desde donde envio el email:

$email->From = $this->emailRemitente;

Una vez almacenados todos los datos, se envía el email:

$email->Send();

Enviar SMS

Anteriormente, he comentado que el kit de desarrollo de software (SDK) de IntelliSMS

permite enviar mensajes SMS desde un script PHP. Para su utilización, he descargado dicho

script y lo he incluido en la carpeta intelliSMS en el directorio de la aplicación (dentro de la

carpeta Negocio).

A continuación, explico el código de la clase sms:

<?php

include_once("intelliSMS/SendScripts/IntelliSMS.php");

//Para enviar SMS, se requiere que en el archivo php.ini este:

// allow_url_fopen = On

// track_errors = On

Este código se tiene a disposición dentro de la página Web de IntelliSMS. Yo lo que he

hecho es adaptarlo a la aplicación para poder enviar SMS.

En primer lugar, debo instanciar el archivo “IntelliSMS.php” ubicado en la carpeta

“IntelliSMS”.

Después inicializo la variable $nombreRemitente con el nombre que quiero que

muestre al enviar el SMS.

private $nombreRemitente = "EFMareoLogroño;

Por último, para enviar un SMS utilizo la siguiente función:

public function enviarSMS ($telefono,$cuerpo)

{

$objIntelliSMS = new IntelliSMS();

$objIntelliSMS->Username = 'abelsuco';

$objIntelliSMS->Password = '97t242p7';

$nuevoTelefono="34$telefono"; //34 Prefijos España

$objIntelliSMS->SendMessage($nuevoTelefono, $cuerpo, $this-

>nombreRemitente); //Telefono donde se manda el sms, cuerpo del sms y

nombre o número del remitente

}

Como se puedo observar, creo una variable de tipo IntelliSMS que servirá para

almacenar toda la información referente al SMS: el nombre de usuario y contraseña

correspondientes al registro de IntelliSMS y el teléfono junto con prefijo del país. (España =34;

antes del número de teléfono).

Por último, se envía el SMS mediante la función SendMessage, a la que le paso el

teléfono, el cuerpo del mensaje y el nombre del remitente.

103

Añadir Falta Entrenamiento

Las funciones “enviarSMS” y “enviarEmail” son utilizadas al añadir una falta de

entrenamiento.

Ya que he comentado anteriormente, en el segundo ciclo, un ejemplo de código muy

parecido a este, solamente voy a entrar en detalles en lo que respecta a las funciones enviar

email y enviar SMS.

Siempre que un empleado o un administrador añadan una falta de entrenamiento

correctamente, se enviará automáticamente un email y un SMS al padre del jugador.

Para ello, inicializo una variable de tipo email para llamar a la función enviarEmail con

los parámetros destinatario (correo electrónico del padre), asunto y cuerpo del email.

$mandarEmail = new email();

$mandarEmail->enviarEmail($destinatario, $asunto, $cuerpo);

Por último, inicializo una variable de tipo sms para llamar a la función enviarSMS con

los parámetros número de teléfono y cuerpo del sms.

$mandarSMS = new sms();

$mandarSMS->enviarSMS($telefono, $cuerpo);


En este apartado voy a mostrar las interfaces que intervienen al gestionar una falta de


Visualizar Falta Entrenamiento:

Figura 66: Interfaz visualizar falta entrenamiento

104

Añadir Falta Entrenamiento:

Figura 67: Interfaz añadir falta entrenamiento (Administrador)

Falta Entrenamiento añadida correctamente:

Figura 68: Interfaz falta entrenamiento añadida correctamente (Administrador)

105

Modificar Falta Entrenamiento:

Figura 69: Interfaz modificar falta entrenamiento (Administrador)

Eliminar Falta Entrenamiento:

Figura 70: Interfaz eliminar falta entrenamiento (Administrador)

106

Resultados de las pruebas unitarias

A continuación, compruebo que los resultados de las pruebas unitarias diseñadas en el

proceso anterior son los esperados. Solamente se muestran varias pruebas:

Prueba Unitaria 1

Descripción Falta entrenamiento añadida correctamente




Salida Esperada Falta entrenamiento añadida correctamente. Se ha enviado email y SMS notificando la falta al padre del jugador.

Salida Obtenida Falta entrenamiento añadida correctamente. Se ha enviado email y SMS notificando la falta al padre del jugador.

Prueba Correcta SI

Prueba Unitaria 2

Descripción Falta de entrenamiento no añadida. Ya existe la falta de entrenamiento.




Salida Esperada La falta de entrenamiento ya existe. Falta de entrenamiento no añadida.

Salida Obtenida La falta de entrenamiento ya existe. Falta de entrenamiento no añadida.


Prueba Unitaria 3

Descripción Error formato fecha

Entradas Fecha falta entrenamiento: “ ” Datos jugador:



Salida Esperada La fecha introducida no cumple el formato establecido.

Salida Obtenida La fecha introducida no cumple el formato establecido.


107

Prueba Unitaria 4

Descripción Error no existe jugador


Nombre: Pepe Apellido 1: Marin Apellido 2: Mateo Equipo: Primera Alevin


Salida Esperada El jugador introducido no existe. Añada primero el jugador.

Salida Obtenida El jugador introducido no existe. Añada primero el jugador.


Pruebas de aceptación

Tras realizar las pruebas de aceptación en relación a los requisitos mínimos marcados

al comienzo de la aplicación, se da a la aplicación como válida y terminada.

108

Bibliografía

Libros

- El libro oficial de Joomla!

Jennifer Marriott, Elin Waring Anaya Multimedia, 2011

- Desarrollo Web con PHP y MySQL. (PHP 5 y MySQL 4.1 y 5)

Luke Welling, Laura Thompson Anaya Multimedia, 2005

- Fundamentos de Sistemas de Bases de Datos

Ramez Elmasri, Shamkant B. Navathe Addison Wesley, 2007

- Curso de CSS

Christopher Schmitt Anaya Multimedia, 2010

Referencias Web

- Programación PHP

http://www.desarrolloweb.com/php/ http://www.forosdelweb.com/f18/ http://www.phpya.com.ar/

- PHP Manual

http://php.net/manual/es/index.php

- PHPMailer

http://phpmailer.worxware.com/

- Joomla!

http://www.joomlaspanish.org/

- Plantillas y módulos Joomla! Gavick

http://www.gavick.com/

- ADOdb

http://adodb.sourceforge.net/

- MySQL, Developer Zone

http://dev.mysql.com/

- Apache Friends XAMPP

http://www.apachefriends.org/es/xampp.html

- IntelliSMS SMS Gateway

http://www.intellisms.co.uk/

http://www.desarrolloweb.com/php/

http://www.forosdelweb.com/f18/

http://www.phpya.com.ar/

http://php.net/manual/es/index.php

http://phpmailer.worxware.com/

http://www.joomlaspanish.org/

http://www.gavick.com/

http://adodb.sourceforge.net/

http://dev.mysql.com/

http://www.apachefriends.org/es/xampp.html

http://www.intellisms.co.uk/

109

- Api Google Maps

https://developers.google.com/maps/?hl=es

- Wikipedia, la enciclopedia libre.

http://es.wikipedia.org/

Apuntes

- Base de datos. - Diseño de Bases de datos. - Programación de Bases de datos. - Ingeniería del Software.

https://developers.google.com/maps/?hl=es

http://es.wikipedia.org/

110

Anexo A: Manual usuario Administración Joomla! (Back-end)

Conceptos básicos

- Plantillas: la plantilla (template) proporciona el aspecto visual para la aplicación Web.

- Componentes: son pequeñas aplicaciones independientes entre sí que gestionan la

información dentro de Joomla!. Los componentes añaden distintas funcionalidades a

Joomla! y lo convierten en mucho más que una Web de artículos o noticias. La

instalación estándar de Joomla! incluye:

o Componente que gestiona los contenidos: com_content.

o Componente que administra y muestra la página principal del sitio Web:

com_frontpage.

o Componente encargado de administrar los contactos y enviar los mensajes por

email que escriben desde el formulario los usuarios: com_contact.

o Componente de administración de banner: com_banners.

o Componente de encuestas y votaciones: com_poll.

o Componente de gestión y publicación de enlaces: com_weblinks.

o Componentes de sindicación de noticias (hacia otros sitios: com_rss y desde

otros sitios: com_newsfeeds.

o Componente que genera las ventanas internas que contienen otras páginas

externas (iframes): com_wrapper.

o Componente de mensajería interna: com_messages.

o Componente del buscador interno: com_search.

o Los componentes relacionados con funciones de usuario: com_login,

com_user, y com_registration.

- Módulos: son extensiones o complementos de Joomla! que nos permiten añadir

bloques de información secundaria en diferentes posiciones o zonas de la plantilla. El

ejemplo más claro de módulo es el menú principal (mod_mainmenu) que facilita la

navegación por el sitio Web.

- Plugins: son extensiones que realizan dentro de Joomla! una amplia variedad de

funciones relacionadas fundamentalmente con la autentificación de usuarios, el

funcionamiento del buscador interno o con la edición de contenidos. Por ejemplo,

plugin Google Maps utilizado en la aplicación Web.

111

Acceso a la Administración (Back-end)

Para acceder al panel de administración de la aplicación (Back-end), introduce la

siguiente URL: http://localhost/j17/administrator y le mostrará el formulario de acceso.

Introduzca el Nombre de usuario (“admin”) y contraseña (“proyecto2012”) en los

respectivos campos y pulse el botón acceder.

Panel de Control

Una vez haya iniciado sesión, acceda al Panel de Control del Administrador (siempre

que quiera volver a esta pantalla, pulse la opción Sitio->Panel de Control en el menú):

Las diferentes partes en las que se divide el Panel de Control del Administrador son:

1) Menú para acceder a todas las funciones disponibles de administración (Back-end).

Además, en la parte derecha del menú se encuentra la información de los usuarios no

conectados al front-end (aplicación de visualización) y de los conectados a la

administración, los mensajes privados que ha recibido, el enlace para ver la

visualización de la aplicación Web y el enlace para finalizar sesión (Finalizar).

2) Iconos de acceso rápido a las funciones más utilizadas del Panel de Control del

Administrador.

http://localhost/j17/administrator

112

3) Información sobre los usuarios conectados, los artículos populares y los últimos

artículos añadidos a la aplicación Web.

Gestor multimedia

Puede acceder de varias formas:

1) Menú -> Contenido -> Gestor Multimedia

2) Acceso directo “Gestor Multimedia” en los iconos de acceso rápido

Se mostrará la siguiente pantalla:

Todas las imágenes que contiene la aplicación Web están en la carpeta

“imágenes_web”. La lista desplegable sirve para acceder a las subcarpetas.

Se recomienda añadir a la subcarpeta “principal” las imágenes que va a utilizar en la

aplicación Web.

113

Administrar contenido


1) Menú -> Contenido -> Gestor de categorías o Gestor de artículos.

2) Acceso directo “Gestor de categorías” o “Gestor de artículos” en los iconos de acceso

rápido.

Existe una jerarquía en Joomla! para administrar el contenido:

1) Categorías: contenedores que en su interior están los Artículos de Contenido u

otras subcategorías.

2) Artículos de contenido: textos e imágenes que va a mostrar la aplicación Web.

Gestor de categorías: Muestra todas las categorías de su aplicación Web. Su aplicación

ya está completa, no debe tocar ningún apartado de esta sección.

Gestor de artículos: Muestra todos los artículos de Contenido de su aplicación Web.

114

Esta sección dispone de las siguientes operaciones:

- Nuevo: creé un nuevo artículo de contenido para su aplicación Web.

- Editar: edite un artículo ya existente en su aplicación Web.

- Publicar: publique el artículo en la aplicación Web.

- Despublicado: artículo que no aparece en la aplicación Web. Puede ser antiguo o que

ya no tiene interés en mostrarlo.

- Papelera: elimine el artículo seleccionado.

Añadir artículo:

Cree un nuevo artículo con la función “Nuevo” anteriormente citada. Solo debe

modificar lo que se nombra a continuación:

Título: el título que le va a dar al Artículo de Contenido.

Alias: el alias que le va a dar al Artículo de Contenido. Debe ser un nombre sin espacios.

Categoría: seleccione la categoría a la que pertenece el artículo.

Texto Artículo: escribe el texto o añade la imagen que desee.

IMPORTANTE: si añade una imagen al artículo, para su correcta visualización, debe tener

600px de anchura y 346px de altura.

Creado por: pulse seleccionar usuario y seleccione el usuario que lo ha creado: EF Mareo.

Se recomienda justificar el texto. Además dispone de diferentes estilos de letra a su

disposición.

Por último, pulsar sobre el botón “Guardar y Cerrar” y el artículo estará listo para su

publicación.

Administrar contenido módulo


1) Menú -> Extensiones -> Gestor de módulos.

2) Acceso directo “Gestor de módulos” en los iconos de acceso rápido.

115


Se muestran todos los módulos instalados en la aplicación.

Módulo últimas noticias: Módulo para gestionar el contenido de las últimas noticias de la


Para actualizar la información que aparece en el módulo, siga los siguientes pasos:

1) Accede al módulo Últimas noticias del Gestor de módulos.

2) Accede al menú de la derecha a la pestaña “Diapositivas”. Se mostrará lo siguiente:

116

Visualización diapositiva.

Diapositiva publicada. Si pulsa sobre el icono, puede despublicarla.

Eliminar diapositiva

Editar diapositiva

Ordenar diapositiva. Orden de visualización en la aplicación Web.

IMPORTANTE: Solo puede haber cuatro diapositivas publicadas.

3) Pulse sobre añadir nueva diapositiva. Se mostrará lo siguiente:

Tipo de contenido: artículo

Imagen: pulse sobre seleccionar y buscar la imagen que quiera añadir en el Gestor

multimedia. Se recomienda almacenar la imagen en la subcarpeta “Principal” de la

carpeta “imágenes_web”.

IMPORTANTE: la imagen se debe guardar para su correcta visualización en 637 x

346.

Extensión de e imagen acceso se deja como está.

Estado: publicado

Título: como su propio nombre indica, el título de la diapositiva que va aparecer en

el módulo de la aplicación Web.

Artículo: pulse sobre el botón ”select” para añadir el artículo al que está

relacionado la diapositiva.

117

Módulo Actualidad EF Mareo: Módulo para gestionar el contenido de la actualidad de la


Cada artículo que añade a la categoría “Actualidad” será insertado automáticamente

por orden de fecha a este módulo.

Si el artículo dispone de imagen, se mostrará en el módulo una miniatura de la imagen

relacionada al artículo.

118

Administrar usuarios


1) Menú -> Sitio -> Gestor de usuarios.

2) Acceso directo “Gestor de usuarios” en los iconos de acceso rápido.


Puede acceder a las diferentes funciones: nuevo, editar, eliminar, reconstruir, opciones

y nuevo.

Administrar inscripciones

Las inscripciones rellenadas mediante los formularios de la aplicación Web, tanto de la

escuela como del campus, serán enviadas automáticamente al correo de la Escuela de Fútbol

de Mareo en Logroño: [email protected]

mailto:[email protected]

119

Anexo B: Actas de Reuniones

Acta Reunión 1

Fecha: 03/11/2011

Lugar: Despacho 224. Edificio Vives

Hora de Inicio 10:30

Hora de Fin: 11:30

Reunión con: Juan José Olarte Larrea

Temas a tratar: Revisión del Documento de Objetivos del Proyecto (DOP)

Desarrollo: Se revisó que se había completado correctamente el proceso de creación del DOP.

Acta Reunión 2

Fecha: 01/02/2012



Hora de Fin: 10:30


Temas a tratar: Revisión del Análisis

Desarrollo: Se revisó que se había completado correctamente el proceso de creación del análisis.

Acta Reunión 3

Fecha: 02/03/2012



Hora de Fin: 13:00


Temas a tratar: Revisión y aceptación del ciclo 1

Desarrollo: Se revisó la documentación generada para la memoria y se realizaron las pruebas de aceptación referentes a este primer ciclo

Acta Reunión 4

Fecha: 13/05/2012



Hora de Fin: 12:30


Temas a tratar: Revisión y aceptación de los ciclos 2 y 3

Desarrollo: Se revisó la documentación generada para la memoria y se realizaron las pruebas de aceptación referentes segundo y tercer ciclo.

120

Acta Reunión 5

Fecha: 01/06/2012



Hora de Fin: 11:00


Temas a tratar: Aceptación del proyecto

Desarrollo: Reunión dedicada a revisar toda la información referente a la memoria. Además se realizaron las pruebas de aceptación del sistema.

121

Anexo C: Contenido del CD adjunto

En este anexo se describen los contenidos del CD adjunto. Son los siguientes:

- Memoria: la presente memoria en formato .pdf.

- Directorio aplicación Web Joomla (carpeta “j17”).

- Directorio aplicación gestión de estadísticas y control de faltas de asistencia a los

entrenamientos (carpeta “zonaentrenadores”).

- Directorio BD: script de la base de datos.

- Configuración: nombres de usuarios y contraseñas para la aplicación en formato

.txt.

trabajo fin de estudios - biblioteca.unirioja.es · el objetivo del proyecto es la creación de una...

Documents