Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
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
Requisitos funcionales ....................................................................................................................... 32
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 funcionales ....................................................................................................................... 54
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
Requisitos funcionales ....................................................................................................................... 91
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
Escuela de Fútbol de Mareo en Logroño.
- 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
Escuela de Fútbol de Mareo en Logroño.
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.
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
48 Identificar actores 1
49 Crear casos de uso 6
50 Diagramas actividades 1
51 Documentación 2
14
52 Clases en análisis 7
53 Identificar clases 3
54 Diagrama de clases 3
55 Generar documentación 1
56 Documentación 2
57 Revisión análisis 1
58 Diseño 29
59 Diseño arquitectura del sistema 3
60 Diseño BD 5
61 Diagrama UML 3
62 Documentación 2
63 Diseño interfaces 4
64 Prototipos 4
65 Diseño clases 14
66 Identificar clases 7
67 Diagrama de clases 5
68 Generar documentación 2
69 Documentación 2
70 Revisión diseño 1
71 Construcción 117
72 Generación de código 110
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
78 Identificar actores 1
79 Crear casos de uso 3
80 Documentación 2
81 Clases en análisis 6
82 Identificar clases 3
83 Diagrama de clases 2
84 Generar documentación 1
85 Documentación 2
86 Revisión análisis 1
87 Diseño 16
88 Diseño arquitectura del sistema 2
89 Diseño BD 3
90 Diagrama UML 2
91 Documentación 1
92 Diseño interfaces 2
93 Prototipos 2
94 Diseño clases 6
95 Identificar clases 3
96 Diagrama de clases 2
97 Generar documentación 1
98 Documentación 2
99 Revisión diseño 1
100 Construcción 46
101 Generación de código 40
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
operaciones a realizar.
Caso de uso 6: Administrar temporadas
- Definición: esta operación permitirá al administrador gestionar las temporadas de los
diferentes equipos de la Escuela de Fútbol de Mareo en Logroño.
- Precondición: el usuario desea administrar las temporadas.
- Postcondición: se muestra el panel de control de las temporadas y las posibles
operaciones a realizar.
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
La figura 11 muestra el diagrama de casos de uso del administrador para la gestión de
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.
- Postcondición: se muestra el panel de control de contenidos al administrador.
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.
- Postcondición: se muestra el panel de control de contenidos al administrador.
28
La figura 12 muestra el diagrama de casos de uso del administrador para la gestión de
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.
- Postcondición: se muestra el panel de control de usuarios y las posibles operaciones a
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.
- Postcondición: se muestra el panel de control de usuarios y las posibles operaciones a
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.
La figura 14 muestra el diagrama de casos de uso del administrador para la gestión de
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
- Definición: esta operación permitirá a los usuarios que accedan a la aplicación Web,
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
- Definición: esta operación permitirá a los usuarios que accedan a la aplicación Web,
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
Escuela de Fútbol de Mareo en Logroño.
Caso de uso 24: Ver plantillas
- Definición: esta operación permitirá a los usuarios que accedan a la aplicación Web,
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.
Requisitos funcionales
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
Escuela de Fútbol de Mareo en Logroño.
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
Escuela de Fútbol de Mareo en Logroño.
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
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).
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
- Definición: esta operación permitirá al administrador añadir los datos de un nuevo
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
- Definición: esta operación permitirá al administrador modificar los datos de un
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
- Definición: esta operación permitirá al administrador eliminar los datos de un
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
- Definición: esta operación permitirá al administrador añadir los datos de un nuevo
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
- Definición: esta operación permitirá al administrador modificar los datos de un
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
- Definición: esta operación permitirá al administrador eliminar los datos de un
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
- Definición: esta operación permitirá al empleado o al administrador visualizar los datos
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
- Definición: esta operación permitirá al empleado o al administrador visualizar los datos
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
- Definición: esta operación permitirá al empleado o al administrador añadir los datos
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
- Definición: esta operación permitirá al empleado o al administrador eliminar los datos
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
- Definición: esta operación permitirá al empleado o al administrador visualizar los datos
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
- Definición: esta operación permitirá al empleado o al administrador añadir los datos
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
- Definición: esta operación permitirá al empleado o al administrador modificar los
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
- Definición: esta operación permitirá al empleado o al administrador eliminar los datos
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
estadísticas del partido de un jugador o de un equipo.
- 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
estadísticas del partido de un jugador o de un equipo.
- 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
- Definición: esta operación permitirá al empleado o al administrador visualizar los datos
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
- Definición: esta operación permitirá al empleado o al administrador añadir los datos
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
- Definición: esta operación permitirá al empleado o al administrador modificar los
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
- Definición: esta operación permitirá al empleado o al administrador eliminar los datos
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.
Requisitos funcionales
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
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 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
Esta aplicación será restringida y deberá permitir la recogida de datos sobre la Escuela de
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
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 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
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 y cada administrador tendrá control para
visualizar, añadir, eliminar y modificar los jugadores almacenados en la base de datos para
mantenerla actualizada.
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
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 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
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 y cada administrador tendrá control para
visualizar, añadir, eliminar y modificar las estadísticas almacenadas en la base de datos para
mantenerla actualizada.
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
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 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
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.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
diferentes equipos de la Escuela de Fútbol de Mareo en Logroño.
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
Escuela de Fútbol de Mareo en Logroño.
- 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).
Condición de entrada
Clases válidas Clases no válidas
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
Clases cubiertas AE-1, AE-3, AE-6
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: “ “
Clases cubiertas AE-2, AE-4
Salida Esperada Nombre usuario o contraseña incorrectos
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
Clases cubiertas CCE-1, CCE-3, CCE-6
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
Salida Esperada Los datos introducidos no cumplen los formatos establecidos. La Contraseña no se ha modificado
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
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 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 =
mysql_real_escape_string(utf8_decode($_POST['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 = new baseDatos();
$BD->conectar();
$consulta="SELECT * FROM empleado ";
$empleados=array();
//Ejecutar consulta
$resultado=$BD->getConexion()->Execute($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_apellido2($fila[6]);
$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 = new baseDatos();
$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
$resultado=$BD->getConexion()->Execute($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_apellido1($fila[5]);
$empleado->set_apellido2($fila[6]);
$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>
<td class="celdaLabel">
<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>
<td class="celdaLabel">
<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 =
mysql_real_escape_string(utf8_decode($_POST['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
Interfaces definitivas
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
Clases cubiertas AE-1, AE-3, AE-5
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
Clases cubiertas AE-1, AE-3, AE-6
Salida Esperada Conectado correctamente: Rol Entrenador.
Salida Obtenida Conectado correctamente: Rol Entrenador.
Prueba Correcta SÍ.
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
Clases cubiertas AE-2, AE-4
Salida Esperada Nombre usuario o contraseña incorrectos
Salida Obtenida Nombre usuario o contraseña incorrectos
Prueba Correcta SÍ.
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: “ “
Clases cubiertas AE-2, AE-4
Salida Esperada Nombre usuario o contraseña incorrectos
Salida Obtenida Nombre usuario o contraseña incorrectos
Prueba Correcta SÍ.
Prueba Unitaria 5
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
Salida Obtenida La contraseña se ha modificado
Prueba Correcta SÍ.
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
Prueba Correcta SÍ.
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
Clases cubiertas CCE-1, CCE-3, CCE-6
Salida Esperada Los datos introducidos no cumplen los formatos establecidos. La Contraseña no se ha modificado
Salida Obtenida Los datos introducidos no cumplen los formatos establecidos. La Contraseña no se ha modificado
Prueba Correcta SÍ.
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 Esperada Los datos introducidos no cumplen los formatos establecidos. La Contraseña no se ha modificado
Salida Obtenida Los datos introducidos no cumplen los formatos establecidos. La Contraseña no se ha modificado
Prueba Correcta SÍ.
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
entrenamiento de un jugador.
- 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
entrenamiento del jugador.
- 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
entrenamiento del jugador.
- Precondición: la aplicación desea enviar un SMS al padre con una falta de
entrenamiento del jugador.
- 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
entrenamiento del jugador.
- 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
entrenamiento del jugador.
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.
Requisitos funcionales
RF.1: gestión de una falta de entrenamiento
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 y cada administrador tendrá control para
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.
Condición de entrada
Clases válidas Clases no válidas
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.
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-6
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:
Nombre: Victor Apellido 1: Marin Apellido 2: Mateo Equipo: Primera Alevin
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
Entradas Fecha falta entrenamiento: 2012/01/06 Datos jugador:
Nombre: Pepe Apellido 1: Marin Apellido 2: Mateo Equipo: Primera Alevin
Clases cubiertas AFE-4
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);
Interfaces definitivas
En este apartado voy a mostrar las interfaces que intervienen al gestionar una falta de
entrenamiento de un jugador.
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
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.
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.
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-6
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 Correcta SÍ.
Prueba Unitaria 3
Descripción Error formato fecha
Entradas Fecha falta entrenamiento: “ ” Datos jugador:
Nombre: Victor Apellido 1: Marin Apellido 2: Mateo Equipo: Primera Alevin
Clases cubiertas AFE-2
Salida Esperada La fecha introducida no cumple el formato establecido.
Salida Obtenida La fecha introducida no cumple el formato establecido.
Prueba Correcta SÍ.
107
Prueba Unitaria 4
Descripción Error no existe jugador
Entradas Fecha falta entrenamiento: 2012/01/06 Datos jugador:
Nombre: Pepe Apellido 1: Marin Apellido 2: Mateo Equipo: Primera Alevin
Clases cubiertas AFE-4
Salida Esperada El jugador introducido no existe. Añada primero el jugador.
Salida Obtenida El jugador introducido no existe. Añada primero el jugador.
Prueba Correcta SÍ.
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/
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.
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.
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
Puede acceder de varias formas:
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
Puede acceder de varias formas:
1) Menú -> Extensiones -> Gestor de módulos.
2) Acceso directo “Gestor de módulos” en los iconos de acceso rápido.
115
Se mostrará la siguiente pantalla:
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
Escuela de Fútbol de Mareo en Logroño.
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
Escuela de Fútbol de Mareo en Logroño.
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
Puede acceder de varias formas:
1) Menú -> Sitio -> Gestor de usuarios.
2) Acceso directo “Gestor de usuarios” en los iconos de acceso rápido.
Se mostrará la siguiente pantalla:
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]
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
Lugar: Despacho 224. Edificio Vives
Hora de Inicio 10:00
Hora de Fin: 10:30
Reunión con: Juan José Olarte Larrea
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
Lugar: Despacho 224. Edificio Vives
Hora de Inicio 12:00
Hora de Fin: 13:00
Reunión con: Juan José Olarte Larrea
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
Lugar: Despacho 224. Edificio Vives
Hora de Inicio 11:00
Hora de Fin: 12:30
Reunión con: Juan José Olarte Larrea
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
Lugar: Despacho 224. Edificio Vives
Hora de Inicio 10:00
Hora de Fin: 11:00
Reunión con: Juan José Olarte Larrea
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.