registro de formación del profesorado de la rioja · php + mysql, ya que tanto las tres...
TRANSCRIPT
Javier Rojas Ostiategui
Juan José Olarte Larrea
Facultad de Ciencias, Estudios Agroalimentarios e Informática
Grado en Ingeniería Informática
2014-2015
Título
Director/es
Facultad
Titulación
Departamento
TRABAJO FIN DE GRADO
Curso Académico
Registro de formación del profesorado de La Rioja
Autor/es
© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2015
publicaciones.unirioja.esE-mail: [email protected]
Registro de formación del profesorado de La Rioja, trabajo fin de gradode Javier Rojas Ostiategui, dirigido por Juan José Olarte Larrea (publicado por la
Universidad de La Rioja), se difunde bajo una LicenciaCreative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.
Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los titulares del copyright.
I
Resumen
El Centro de Formación, Innovación y Asesoramiento en Materia Educativa, es un organismo que
oferta formación a los docentes riojanos. Actualmente dispone de un servicio de registro de
formación en el que los profesores pueden consultar sus títulos e incluir nuevos.
Es un sistema antiguo que posee tres problemas fundamentales: En algunas ocasiones aparece
información duplicada o contradictoria, implica procesos manuales de gran cantidad de datos y
como resultado el servicio de consulta sólo se actualiza a intervalos irregulares.
Este trabajo fin de grado, plantea una solución que integrará varias bases de datos en una sola
y provee una base sólida para futuras ampliaciones.
Abstract
The Center of Education, Innovation and Educational Advice, is an organization that offers
training to La Rioja teachers. Currently, it keeps a training service record where teachers can
consult their own certificates and include new ones.
This old record has three fundamental problems: 1. sometimes, part of the information
appears duplicated or showing contradictory data, 2. it involves manual data treatment and as
a result of this, 3. the processes consultation service is only updated at irregular intervals.
This end of degree work, presents a solution that integrates multiple databases into a single
one and settles a solid base for future extensions.
II
Tabla de contenido
Resumen ..................................................................................................................................... I
Abstract ....................................................................................................................................... I
Tabla de contenido ..................................................................................................................... II
Tabla de figuras ........................................................................................................................ VII
1 Introducción ....................................................................................................................... 1
1.1 Antecedentes ............................................................................................................... 1
1.2 Objetivos ...................................................................................................................... 2
1.3 Integrantes y relaciones ............................................................................................... 3
1.4 Decisiones y justificación .............................................................................................. 3
1.5 Riesgos ......................................................................................................................... 5
2 Planificación y seguimiento ................................................................................................. 7
2.1 Calendario .................................................................................................................... 7
2.2 Hitos del Trabajo fin de grado ....................................................................................... 7
2.3 Diagrama de Gantt ....................................................................................................... 8
2.4 Estudio de carga de trabajo .......................................................................................... 9
3 Gestión del proyecto......................................................................................................... 11
3.1 Seguimiento ............................................................................................................... 11
3.2 Re-planificaciones ...................................................................................................... 12
3.3 Comparativa tiempo estimado y real .......................................................................... 12
4 Análisis ............................................................................................................................. 13
4.1 Definiciones................................................................................................................ 13
4.2 Descripción general del sistema ................................................................................. 13
III
4.3 Actores ....................................................................................................................... 14
4.4 Diagrama de casos de uso .......................................................................................... 14
4.5 Catálogo de requisitos funcionales ............................................................................. 16
4.6 Catálogo de requisitos no funcionales ........................................................................ 17
4.7 Especificación del entorno del sistema ....................................................................... 18
4.8 Diagrama de clases, modelo conceptual ..................................................................... 19
5 Diseño .............................................................................................................................. 20
5.1 Arquitectura de la aplicación ...................................................................................... 20
5.2 Diagrama de clases refinado, adaptado a Symfony ..................................................... 21
5.3 Diagrama relacional .................................................................................................... 23
5.4 Estructura de directorios ............................................................................................ 24
5.5 Definición de interfaces de usuario ............................................................................ 25
5.6 Diseño de la migración ............................................................................................... 30
6 Implementación ................................................................................................................ 32
6.1 Generación de los modelos ........................................................................................ 32
6.2 Codificación de los controladores ............................................................................... 33
6.3 Codificación de las vistas ............................................................................................ 34
6.4 Flujo de ejecución....................................................................................................... 36
6.5 Tratamiento de transacciones .................................................................................... 37
6.6 Proceso de migración ................................................................................................. 38
6.7 Pruebas de migración ................................................................................................. 39
6.8 Bibliotecas y bundles de terceros ............................................................................... 39
7 Pruebas............................................................................................................................. 40
IV
7.1 Pruebas unitarias de la iteración 2 .............................................................................. 40
7.2 Pruebas de integración de la iteración 2 ................................................................... 41
7.3 Pruebas de implantación de la iteración 2 .................................................................. 42
7.4 Pruebas en producción paralela ................................................................................. 42
8 Conclusiones ..................................................................................................................... 43
8.1 Lecciones aprendidas ................................................................................................. 43
8.2 Puntos fuertes del nuevo registro de formación ......................................................... 44
8.3 Mejoras de para la iteración 3 .................................................................................... 44
9 Bibliografía ....................................................................................................................... 45
10 Agradecimientos ............................................................................................................... 45
Anexo I: Análisis preliminar del sistema de gestión de cursos del CeFIAME (G1) ......................... 1
Conclusiones del análisis preliminar:....................................................................................... 1
Anexo II: estudio de frameworks basados en PHP+SQL ............................................................... 1
Symfony2................................................................................................................................ 1
Silex ........................................................................................................................................ 1
Zend Framework..................................................................................................................... 1
CodeIgniter ............................................................................................................................. 2
Laravel .................................................................................................................................... 2
Yii ........................................................................................................................................... 2
Conclusión .............................................................................................................................. 3
Bibliografía ............................................................................................................................. 4
Anexo III: Instalación y puesta en marcha del entorno de trabajo (Linux) ................................... 1
Descargar e instalar el paquete de Symfony ........................................................................... 1
V
Crear la aplicación Symfony .................................................................................................... 1
Arrancar la aplicación ............................................................................................................. 2
Comprobar la configuración de nuestra aplicación. ................................................................ 3
Instalar Composer .................................................................................................................. 4
Crear un virtual host para nuestra aplicación en el servidor .................................................... 5
Configuración de Phpstorm .................................................................................................... 7
Comenzar a modificar el proyecto .......................................................................................... 9
Trucos ................................................................................................................................... 18
Bibliografía ........................................................................................................................... 18
Anexo IV: Estructura de un proyecto en Symfony. ...................................................................... 1
El directorio web .................................................................................................................... 1
El directorio de la aplicación (app) .......................................................................................... 2
El directorio fuente (src) ......................................................................................................... 3
Antes de empezar, crea el bundle ........................................................................................... 3
Bibliografía ........................................................................................................................... 10
Anexo V: Análisis de las bases de datos del registro antiguo ....................................................... 1
Conclusiones........................................................................................................................... 2
Anexo VI: Detalle de consultas del proceso de migración. .......................................................... 1
Valoración de pérdida de información. ................................................................................... 4
Anexo VII: Manual para el docente ............................................................................................. 1
Acceso a la consulta del registro ............................................................................................. 1
Consultas de formaciones ....................................................................................................... 2
Cambiar clave o email ............................................................................................................. 4
VI
Anexo VIII: Manual para administrativos .................................................................................... 1
Acceso al registro.................................................................................................................... 1
Registro de formaciones ......................................................................................................... 2
Nuevas formaciones ............................................................................................................... 2
Búsqueda de formaciones ...................................................................................................... 6
Anexo IX: Chuleta para desarrollar en Symfony .......................................................................... 1
Anexo X: Actas ............................................................................................................................ 1
VII
Tabla de figuras
Estructura actual del registro de formación. ............................................................. 2
Iteraciones del proyecto. .......................................................................................... 4
Calendario de TFG. .................................................................................................... 7
Diagrama de Gantt. ................................................................................................... 8
Horas estimadas para cada tarea. ............................................................................. 8
Distribución horaria por mes. .................................................................................... 9
Carga horaria semanal por mes. ................................................................................ 9
Carga horaria mensual total. ................................................................................... 10
Estado comparativo del TFG vs los demás a 15 de abril de 2015. ............................ 11
Horas dedicadas a cada tarea. ............................................................................. 12
Comparativa entre horas estimadas y horas reales. ............................................. 12
Diagrama de casos de uso de la aplicación. ......................................................... 14
Diagrama de clases de la aplicación. .................................................................... 19
Cooperación entre modelo, vista y controlador. .................................................. 20
Diagrama de clases refinado ................................................................................ 21
Diagrama de clases refinado. ............................................................................... 22
Diagrama relacional............................................................................................. 23
Estructura de directorios. .................................................................................... 25
Metáforas visuales para Imprimir, modificar datos y volver. ................................ 25
Diagrama de navegación. .................................................................................... 26
Detalle de formulario de acceso. ......................................................................... 27
Detalle de front-end: consulta de certificados. .................................................... 27
VIII
Detalle de back-end: nuevo profesor. .................................................................. 28
Detalle de back-end: Registro de certificados. ..................................................... 29
Diagrama de correspondencia de tablas antiguas y nuevas. ................................ 30
Extracto de comparación de datos. ..................................................................... 31
Bundles generados. ............................................................................................. 32
Ejemplo de código de relación uno a varios. ........................................................ 33
Ejemplo de firma de métodos del controlador. ................................................... 33
Extractos de código más representativos del método createEntity ...................... 34
Esquema de archivos y directorios de las vistas de BackendBundle. .................... 35
Ejemplo de pantalla con las cinco secciones destacadas. ..................................... 35
Llamada al controlador general desde la plantilla user.html.twig ........................ 36
Código del método loadForm en entities.js ......................................................... 37
Tablas de la bd intermedia generada en la migración. ......................................... 38
Métodos del controlador genérico. ..................................................................... 40
Esquema relacional de G1 ......................................................................................... 1
Esquema relacional de G1 ......................................................................................... 2
Tendencias en el uso de frameworks a nivel mundial, según google Trends. ............. 2
Encuesta realizada a desarrolladores desde la página phpframeworks.com. ............. 3
Estructura de proyecto en Symfony. ......................................................................... 1
Página de bienvenida. ............................................................................................... 2
Página de configuración. ........................................................................................... 3
Ajustes de Phpstorm. ................................................................................................ 7
Perfiles de ejecución en Phpstorm. Pantalla 1. .......................................................... 8
IX
Perfiles de ejecución en Phpstorm. Pantalla 2. .......................................................... 8
Perfiles de ejecución en Phpstorm. Pantalla 3. .......................................................... 9
Consola de Symfony. ............................................................................................... 10
Código de entidad de ejemplo. ............................................................................... 12
Controlador de la entidad de ejemplo. ................................................................ 15
Formulario de la entidad de ejemplo. .................................................................. 15
Vista de la entidad de ejemplo. ........................................................................... 16
Fichero yml de enrutamiento general de la aplicación. ........................................ 16
Fichero yml de enrutamiento del bundle de ejemplo .......................................... 17
Fichero yml de enrutamiento del bundle de ejemplo modificado ........................ 17
Vista del mantenimiento para la entidad de ejemplo. ......................................... 18
Esquema de bases de datos del registro de formaciones propias. ............................. 1
Esquema de bases de datos del registro de formaciones externas. ........................... 1
1
1 Introducción
1.1 Antecedentes
El Centro de Formación, Innovación y Asesoramiento en Materia Educativa, en adelante
CeFIAME, es un organismo que oferta formación a los docentes riojanos. Actualmente dispone
de un servicio de registro de formación en el que los profesores pueden consultar sus títulos e
incluir nuevos.
El registro está dividido en dos partes:
Registro de formación de las acciones formativas propias del CeFIAME.
Registro de formación de entidades externas.
Cada una de ellas posee su propia base de datos (bd) local y no hay comunicación entre ellas.
El CeFIAME también ofrece un servicio de consulta a los docentes en el que, a través de una
tercera aplicación, pueden comprobar los títulos que tienen inscritos mediante un usuario y una
clave. Esta aplicación posee a su vez una tercera bd en la que convive la información de todas las
acciones formativas. Por tanto, para los docentes no existe distinción entre las acciones
formativas externas o las propias.
Como consecuencia de este planteamiento han surgido tres problemas fundamentales:
En ocasiones ha surgido información duplicada o contradictoria de cursos en las bases
de datos de acciones formativas propias y externas.
Es necesario realizar un proceso manual de fusión de ambas bd con cierta periodicidad
para poder mostrar los datos en el servicio de consulta.
La información del servicio de consulta sólo se actualiza a intervalos irregulares, por lo
que da lugar a malentendidos y errores de tramitación.
También existe otra aplicación de gestión de cursos, que almacena horarios, aulas, temarios,
inscripciones y asistencia. El nuevo registro de formación debe ser compatible con ella.
2
1.2 Objetivos
El objeto de este TFG es desarrollar y documentar una aplicación que aúne las tres bases de
datos, automatice el proceso de consulta por parte de los usuarios y elimine los tres problemas
citados anteriormente.
Estructura actual del registro de formación.
1.2.1 Objetivos operativos
Especificar, diseñar e implementar el nuevo registro de formación del profesorado de La Rioja,
de acuerdo con la planificación detallada en el Punto 2. Incluyendo:
Sistema unificado de registro de acciones formativas.
Estandarizará el proceso de registro de títulos propios y externos.
Gestionará la introducción concurrente de información por parte de los
administrativos.
Implementará un sistema de búsquedas e informes.
Sistema de consulta de títulos registrados.
Permitirá el acceso de docentes a la consulta de sus formaciones.
Implementara un sistema de búsquedas e informes que los docentes podrán
imprimir.
El sistema deberá ser modular y estar preparado para la futura integración con el sistema de
gestión de cursos, otra aplicación específica que el CeFIAME utiliza para administrar los cursos
que oferta. Se puede consultar el análisis del sistema de gestión de cursos en el Anexo I.
1.2.2 Objetivos académicos
Aprovechar la realización del proyecto para actualizar mis conocimientos sobre:
Gestión de proyectos.
Lenguajes, entornos de desarrollo integrados (IDEs) y Frameworks.
BD propia BD externa BD web Fusión
Reg. Propio Reg. Externo Consulta web
3
1.3 Integrantes y relaciones
Santos Agudo: Tutor de TFG en la empresa.
Reuniones semanales de seguimiento de una hora de duración.
Resumen informal diario de diez minutos.
Comunicación por email de los diferentes entregables del proyecto.
Puntualmente colaboración en aspectos concretos del proyecto.
Juan José Olarte: Tutor de TFG en la UR.
Comunicación semanal a través de entregables por medio de la plataforma de TFG.
Uso del email para solucionar dudas sencillas.
Reuniones presenciales en caso de ser necesario.
Noelia y José Ramón: Administrativos que trabajan con el actual sistema de registro.
Reuniones presenciales para recoger requisitos durante el análisis, presentar el diseño de
interfaces y presentar las pruebas de integración.(Actas 9, 10 y 11)
1.4 Decisiones y justificación
1.4.1 Tecnologías
Tras el estudio del ecosistema de aplicaciones usadas para la gestión del CeFIAME, Santos y yo
acordamos utilizar PHP + MySQL, ya que tanto las tres aplicaciones del registro como el sistema
de gestión de cursos y los servidores de los que se dispone usan estas tecnologías.
También decidimos utilizar Symfony 2 como framework, ya que es uno de los frameworks más
robustos, obliga a aplicar muy buenas prácticas de programación, es apto para desarrollos de
gran tamaño y es muy modular. Por contra, Symfony tiene fama merecida de ser muy complejo,
por ello nuestro proyecto contemplará más tiempo de documentación y formación y menos de
desarrollo que en un proyecto normal.
En el Anexo II se detalla el estudio de frameworks basados en PHP que he llevado a cabo. En el
Acta 4, con fecha 18 de febrero, se detallan estos acuerdos.
4
1.4.2 Metodología
Por un lado se dispone de una colección de requisitos cerrada, se tiene experiencia en proyectos
similares y que se conocen los lenguajes que se van a utilizar. Por el contrario, el uso de Symfony,
desconocido por los integrantes del proyecto, y la necesidad de realizar una migración compleja
pueden suponer un riesgo que produzca bloqueos y retrasos.
Por eso se ha optado por un modelo iterativo-incremental: para minimizar la incertidumbre se
combinará con el desarrollo de prototipos que ayuden a comprender mejor el framework y
presenten a los administrativos una visión parcial de la futura aplicación, destapando posibles
requisitos ocultos.
Iteraciones del proyecto.
Prototipo 1 Prototipo 2 Registro iteración 1 Registro iteración 2 Registro iteración 3
Análisis Diseño
Implementación Pruebas
5
Los dos primeros prototipos tendrán como fin familiarizarse con el framework. Se desarrollarán
durante en final del análisis y el diseño. El primero será un mero ejemplo con la tabla usuarios,
el segundo se añadirá la gestión de roles y una primera versión aproximada de la interfaz del
back-end.
La iteración 1 contendrá los requisitos del back-end: gestión de usuarios y roles, series y tablas
maestras. La iteración 2 añadirá el registro de formaciones, el front-end y consolidará la interfaz.
Ambas se darán durante el desarrollo.
La iteración 3 se llevará a cabo durante el periodo de pruebas con funcionamiento paralelo del
antiguo y nuevo registro. Servirá para corregir errores y pulir funcionalidades en un entorno real
y sin peligro.
1.5 Riesgos
1.5.1 Riesgos específicos del proyecto
1.5.1.1 Migración
Actualmente, las tres bases de datos almacenan datos de 120.000 títulos y 4000 profesores.
Toda esta información se encuentra triplicada, y se han observado inconsistencias tales como
identificadores similares que corresponden a diferentes profesores. Por tanto, existe riesgo de
pérdida de datos y generación de tuplas espurias al fusionar las tres bases de datos.
Para minimizarlo se dedicará un apartado específico del diseño al diseño de la migración y se le
dedicarán 20 horas del proyecto, dentro de la fase de pruebas.
1.5.1.2 Uso de Symfony
Como se ha podido comprobar en el estudio de Frameworks del Anexo II, Symfony es uno de los
más exigentes para los principiantes. Existen riesgos de bloqueos y retrasos durante la fase de
desarrollo. Para compensarlos, se usará un sistema de prototipos, que represente aspectos
concretos del sistema, y se dedicará a la búsqueda de documentación 55 horas, paralelas a las
55 que se dedicarán al diseño.
6
1.5.2 Riesgos generales de cualquier proyecto
1.5.2.1 Pérdida de información
Los datos relevantes de se tendrán en cuenta en el plan de copias de seguridad son:
Programas, licencias y configuraciones del equipo de trabajo.
Datos: memoria, documentación y aplicación.
Para proteger los programas, licencias y configuraciones del equipo de desarrollo se usará
virtualización. Las características del sistema son: Sistema Operativo Linux Mint con PhpStorm,
Apache, PHP, MySQL y Symfony todos configurados e interrelacionados. El tamaño de la
máquina es de 8 GB. Se realizará una copia semanal de la máquina virtual completa, se
almacenarán las dos últimas copias en un disco duro externo.
Para la memoria, documentación y aplicación, se realizará una copia diaria usando Dropbox. En
caso de pérdida de información se podrá recuperar usando el propio sistema de restauración de
Dropbox. El espacio necesario en la nube estimado es de 2 GB.
La pérdida del resto de datos se considerará un riesgo marginal aceptable.
1.5.2.2 Planificación incorrecta
Se realizará un cambio en la estimación de fechas en el Plan del Proyecto, orientándolas hacia
una estimación más acorde con la realidad. Se han calculado 20 horas más en la planificación
para este tipo de riesgos.
Dado que las fechas de entrega académicas son mucho más estrictas que las requeridas por
este proyecto, también puede entregarse la segunda iteración y proseguir con la tercera tras la
presentación.
1.5.2.3 Ausencia del director académico de la U.R.
No cabe duda que su ausencia repercutirá tanto en el cumplimiento de los plazos del
proyecto como en su calidad final. Si la ausencia va a ser corta, se aplazará la reunión y se
proseguirá con las siguientes tareas del proyecto. Si por el contrario la ausencia va a ser
prolongada se buscará el consejo puntual de otro profesor.
7
2 Planificación y seguimiento
2.1 Calendario
Teniendo en cuenta las características del proyecto y sus riesgos, se aprobó el siguiente
calendario. Los días festivos se encuentran sombreados en gris y los hitos remarcados con borde
grueso. Los acuerdos se recogen en el Acta 5.
enero febrero marzo
l m x j v s d l m x j v s d l m x j v s d
1 2 3 4 1 1
5 6 7 8 9 10 11 2 3 4 5 6 7 8 2 3 4 5 6 7 8
12 13 14 15 16 17 18 9 10 11 12 13 14 15 9 10 11 12 13 14 15
19 20 21 22 23 24 25 16 17 18 19 20 21 22 16 17 18 19 20 21 22
26 27 28 29 30 31 23 24 25 26 27 28 23 24 25 26 27 28 29
30 31
abril mayo junio
l m x j v s d l m x j v s d l m x j v s d
1 2 3 4 5 1 2 3 1 2 3 4 5 6 7
6 7 8 9 10 11 12 4 5 6 7 8 9 10 8 9 10 11 12 13 14
13 14 15 16 17 18 19 11 12 13 14 15 16 17 15 16 17 18 19 20 21
20 21 22 23 24 25 26 18 19 20 21 22 23 24 22 23 24 25 26 27 28
27 28 29 30 25 26 27 28 29 30 31 29 30
Calendario de TFG.
2.2 Hitos del Trabajo fin de grado
Se han planteado los siguientes hitos para el TFG:
5 de febrero: inicio de TFG.
19 de febrero: fin planificación.
26 de febrero: fin análisis. Entrega de la planificación y el análisis.
2 de abril: fin diseño, documentación y creación de prototipos. Entrega del diseño.
30 abril: fin desarrollo.
21 mayo: fin de la implantación y pruebas. Entrega de la memoria completa.
31 de mayo: fin de TFG.
5 de junio: fecha estimada de depósito de TFG.
15 de junio: fecha estimada de defensa de TFG.
8
2.3 Diagrama de Gantt
La distribución de las tareas quedaría de la siguiente manera. Los tres hitos más importantes son
los que implican entrega de documentación al tutor.
Diagrama de Gantt.
Horas estimadas para cada tarea.
05-feb. 25-feb. 17-mar. 06-abr. 26-abr. 16-may. 05-jun.
análisis
documentación
diseño
desarrollo
pruebas
seguimiento
20h 7%
55h 18%
55h 18%
70h 23%
60h 20%
40h 14%
HORAS POR TAREA
análisis documentación diseño
desarrollo pruebas seguimiento
Entrega planificación y análisis
Entregar diseño
Entregar memoria
9
La búsqueda de documentación y el diseño serán las fases más importantes en este proyecto,
con una carga horaria estimada de 55 horas cada una. Los prototipos se realizarán también
paralelamente durante el mes de marzo y abril.
2.4 Estudio de carga de trabajo
Con este calendario y distribución de tareas, la carga de trabajo queda de la siguiente manera.
febrero marzo abril mayo
h/semana 10 25 30 25
semanas 3 4 3 4
h/mes 30 100 90 100
horas totales 320
Distribución horaria por mes.
Como puede observarse se han calculado 20 horas extra para compensar riesgos (detallados en
el punto 1.5) y posibles imprevistos. Poco a poco se ampliará el esfuerzo dedicado al proyecto
hasta abril, cuando finaliza el desarrollo y vuelve a bajar durante las pruebas y el cierre del
proyecto. También se ha previsto así para poder realizar en mayo un esfuerzo extra, en caso de
ser necesario.
Carga horaria semanal por mes.
0
5
10
15
20
25
30
35
febrero marzo abril mayo
h/semana
10
Aunque abril será el mes más intenso en carga de trabajo, la Semana Santa hace que el cómputo
total de horas sea menor en este mes.
Carga horaria mensual total.
0
20
40
60
80
100
120
febrero marzo abril mayo
h/mes
11
3 Gestión del proyecto
3.1 Seguimiento
Durante el desarrollo del proyecto se han cumplido las fases y los hitos a la perfección, hasta
llegar al desarrollo. Durante el análisis y el diseño se han llevado a cabo los dos prototipos
funcionales usando las herramientas de Symfony sin ningún contratiempo.
Sin embargo, a la hora de implementar las siguientes iteraciones, implementando el controlador
genérico y el uso de Ajax se ha constatado cómo la curva de aprendizaje de Symfony es mucho
más pronunciada de lo esperado. Como consecuencia el desarrollo pasó de las 70 horas
planificadas a 120 reales.
Por otro lado, además de realizar un seguimiento individual, se aprovechó la herramienta
facilitada por la UR para realizar un seguimiento comparativo con el resto de proyectos que sirvió
para comprobar que el desarrollo del proyecto se encontraba en todo momento dentro de la
media.
Estado comparativo del TFG vs los demás a 15 de abril de 2015.
12
3.2 Re-planificaciones
Como ya se ha comentado, el desarrollo de las iteraciones 1 y 2 llevó casi el doble de tiempo
del estimado, por lo que se optó por dejar la tercera iteración y el periodo de pruebas en
producción paralela con el sistema antiguo para después de la presentación del TFG. El proyecto
pasó de 300 a 310 horas.
Horas dedicadas a cada tarea.
3.3 Comparativa tiempo estimado y real
Comparativa entre horas estimadas y horas reales.
20h 6%
55h 18%
55h 18%120h 39%
20h 6%40h 13%
HORAS POR TAREA
análisis documentación diseño desarrollo pruebas seguimiento
0
20
40
60
80
100
120
140
13
4 Análisis
4.1 Definiciones
Actividad o acción formativa: cada una de las actividades que se llevan a cabo para completar
aportar formación al profesorado, muchos de los campos de las acciones formativas serán
replicados en los certificados.
Formación o certificado: título que se expide al completar una actividad y que conlleva el
reconocimiento de unas horas de formación. Puede ser propia del CeFIAME o de un organismo
externo. Siempre van ligadas a un usuario con el rol de profesor. Pueden tener diferentes
modalidades de formación: cursos, simposios, mesas redondas, charlas, proyectos de innovación
educativa, grupos de trabajo… También hay que registrar el modo en el que participó el profesor
(modo de participación): alumno, participante, ponente, coordinador… Cada certificado posee
un código único. El certificado debe replicar los datos de la acción formativa a la que pertenece.
Modalidad de formación: marca el tipo de actividad formativa, pueden ser cursos, simposios,
mesas redondas, charlas…
Modo de participación: determina la manera en la que un profesor participó en una acción
formativa: ponente, asistente, colaborador, alumno, coordinador…
Serie: código de dos cifras al final del código único de certificado. Se asigna una serie a cada
administrativo, varios administrativos pueden compartir una misma serie.
4.2 Descripción general del sistema
El nuevo registro de formación de CeFIAME debe permitir a los administrativos introducir los
datos de acciones formativas propias y de entidades externas de manera sencilla y con una
interfaz única. También debe ofrece un servicio de consulta web en el que los profesores puedan
acceder a los títulos que han depositado.
El sistema deberá ser modular y estar preparado para la futura integración con el sistema de
gestión de cursos.
14
4.3 Actores
El registro de formación contará con tres roles de usuario:
Administrador: administra el sistema, tiene permisos para acceder a todo el back-end.
Administrativo: introduce las actividades y formaciones y gestiona profesores.
Profesor: consulta los títulos de las acciones formativas en las que ha participado.
4.4 Diagrama de casos de uso
Diagrama de casos de uso de la aplicación.
Administrador
Administrativo
Profesor
Registrar
formación
Gestionar
profesores
Registrar actividad
Gestionar
series
Gestionar los
modos de
participación
Gestionar
administrativos
Gestionar
roles
Generar
listados Modificar sus
datos personales
Consultar sus
certificados
Gestionar las
modalidades
formación
15
4.4.1 Especificación de casos de uso
4.4.1.1 Registrar actividades
Para registrar una nueva actividad se debe buscar siempre si ya existe en la base de datos. Si es
nueva, la búsqueda previa debe llevar a una semejante para poder importar sus datos y agilizar
el proceso.
Nombre: Registrar actividades
Descripción: El administrativo introduce una nueva actividad
Actores: administrativo
Precondición: El administrativo debe estar autenticado en el sistema.
Flujo normal: En el menú principal selecciona actividad/nueva Introduce el nombre, modalidad y la entidad. El sistema busca actividades que coincidan en parte del nombre o la entidad.
Si no hay resultados de la búsqueda el administrativo continúa introduciendo el resto de campos.
Si ha hay resultados de la búsqueda se le permite copiar todos los campos a la nueva, hace las modificaciones y confirma.
Postcondición: Se añade una nueva actividad a la aplicación.
4.4.1.2 Registrar formación
Para registrar una nueva formación se debe comprobar si pertenece a una actividad.
Nombre: Registrar formación
Descripción: El administrativo introduce una formación de un profesor
Actores: administrativo
Precondición: El administrativo debe estar autenticado en el sistema.
Flujo normal: Se busca la actividad. Se usa plantilla como plantilla para generar la formación (el certificado) y se obliga a introducir el profesor, las horas y modo de participación. Se genera el número de registro con la serie asignada al administrativo.
Postcondición: Se añade el certificado a la formación del profesor. No se debe poder modificar una actividad de la que se haya emitido un certificado.
El resto de casos de uso son triviales y no se incluyen por razones de espacio.
16
4.5 Catálogo de requisitos funcionales
Administrador.
o gestionar roles.
Modificar rol.
o Gestionar administrativos.
Crear administrativo.
Modificar administrativo.
Asignar rol a administrativo.
Borrar administrativo.
o Gestionar los modos de participación y modalidades de participación.
Crear modo de participación.
Modificar modo de participación.
Borrar modo de participación.
o Gestionar series de numeración en certificados.
Crear serie.
Asignar serie a administrativo.
Modificar contadores de la serie.
Administrativo.
o Gestionar profesores.
Crear profesor.
Modificar profesor.
o Buscar certificados, acciones formativas y profesores.
o Registrar formación: se guardan el certificado de un profesor.
o Generar listados por acción formativa o por profesor.
Profesor.
o Acceder al sistema
Con usuario y clave.
Futura ampliación con certificado digital.
o Modificar sus datos personales.
o Consultar listados de sus títulos.
17
4.6 Catálogo de requisitos no funcionales
Cumplimiento de estándares.
o Interfaz de la aplicación: HTML5, CSS3.
o Página del gobierno de La Rioja XHTML 1.0 (el registro irá embebido en ella)
o Calidad de código
Codificación estándar básica PSR1.
Guía de estilo de codificación PSR2.
Estándar de auto carga de clases PSR0 (sustituido por PSR4).
Accesibilidad.
o (WCAG)Pautas de Accesibilidad al Contenido en la Web, nivel de Conformidad "A".
o Futura ampliación a nivel de Conformidad "Doble A".
Seguridad.
o HTTPS.
o Futura ampliación: Acceso al sistema con certificado digital.
Requisitos legales.
o La inscripción del fichero en la AEPD y la supervisión de la seguridad la llevará a
cabo el responsable del Servicio.
Licencia del código.
o Los derechos de autoría y explotación del producto pertenecerán al CeFIAME.
Interfaz.
o El sistema deberá visualizarse de forma correcta, al menos, en los navegadores de
uso más extendido (Chrome, Firefox e Internet Explorer).
o No se contempla que se adapte a dispositivos móviles.
o En el back-end
Anticipación: La aplicación deberá anticiparse a las necesidades del
administrativo en especial en la introducción de datos en el formulario de
registro de formación.
Autonomía: proveerá al administrativo un ambiente flexible para que
pueda aprender rápidamente a usar la aplicación.
Consistencia: los elementos comunes aparezcan situados en la misma
posición de forma ordenada y coherente, dando una imagen de unidad.
o En el front-end
Simplicidad: irá destinada tanto a usuarios con conocimientos amplios en
informática como a profanos en la materia.
Interfaz similar a la actual.
18
4.7 Especificación del entorno del sistema
El nuevo registro de formación estará alojado en un conjunto de servidores con las siguientes
especificaciones:
4.7.1 Entorno hardware
Servidor.
o Dos procesadores Intel Xeon de cuatro núcleos cada uno.
o 4GB de memoria RAM.
o Dos discos duros SAS de 300GB montados en RAID 1.
Servidor de copias de seguridad.
o Procesador Pentium D a 3.6 GHz.
o 1GB de memoria RAM.
o Dos discos duros de 256 GB montados en RAID 1
4.7.2 Entorno software
Sistema operativo CentOS 5.11
Servidor Apache 2.2.29
o Complemento SSL.
o Complemento Open SSL.
Certificado SSL de la empresa thawte.
Gestor de dominios Web host manager y Cpanel 11.44.2
PHP 5.3.29
XDebug 2.1.2
PhpMyadmin 3.4.10.1
MySQL 5.1.73
19
4.8 Diagrama de clases, modelo conceptual
Diagrama de clases de la aplicación.
rol
nombredescripcion
usuario
nrpnombreapellidostratamientodnidirecciónlocalidademailcentrousuarioclavefecha_solicitudfecha_aprobado
1..* 1..*
formacion
denominaciónfinalizaciónhorasfecha_creacióntxt_origenidiomafecha_inscripciónnumeroRegistro
1 *
modo_participación
nombrefinalizaciónhoras
1
*
actividad
denominaciónfinalizaciónhorasfecha_creacióntxt_origenidioma
1*
entidad_organizadora
códigonombredescripciónparticipación
*
1
serie
códigonúmero
*1
modalidad_formación
denominacióndetermterminantecontracción
*
1
20
5 Diseño
5.1 Arquitectura de la aplicación
Se utilizará una particularización de la arquitectura tradicional de tres capas: el patrón Modelo
Vista Controlador, en adelante MVC. Consiste en tres tipos de objetos: el modelo que es el objeto
de la aplicación, la vista que es su representación y el controlador que define el modo en que la
interfaz reacciona a la entrada del usuario. El controlador controla el flujo de la aplicación, pide
al modelo aquello que el usuario solicita, y le devuelve (al usuario) una representación del
modelo a través de la vista. De esta manera, la lógica relacionada con los datos se incluye en el
modelo, el código de la presentación en la vista y la lógica de la aplicación en el controlador.
Cooperación entre modelo, vista y controlador.
En Symfony cada parte del patrón MVC se divide a su vez en varios componentes, de los que nos
debemos encargar durante la implementación:
Parte del patrón Componentes
Controlador El Controlador frontal: el punto único de acceso a la aplicación. Los filtros, las acciones y los objetos request, response y sesión.
Vista El Layout de la aplicación, las plantillas de los módulos, los slots, los partials, los componentes y los helpers
Modelo
El mapeo objeto-relacional (ORM), los formularios, las extensiones propias que el programador realice de las clases del ORM y las clases y funciones propias que el programador construya para implementar la lógica de negocio.
Se detalla el uso de estos elementos en el punto 6: Implementación y los Anexos III y IV.
Controlador Modelo Vista BD
21
LibraryRepositiory
+findByFormacionesByFinalizacion(id:int,fecha_ini: date,fecha_fin: date): formaciones[]+isValidFNMT(usuario: usuario): bool+tieneUsuarioRole(rol: rol, usuarios: usuario[]): usuario[]+actualizaRole(usuario: usuario, rolViejo: rol, rolNuevo: rol): void+getUsersOfActividadFormacion($actividadFormacion): usuario[]+getFilteredRoles(sql: string):rol[]+getFilteredUsers(sql: string): usuario[]+getFilteredSerie(sql: string): serie[]+getFilteredModosParticipacion(sql: string): modo_participación[]+getFilteredActividadesFormacion(sql: string): actividad[]+getFilteredEntidadesOrganizadoras(sql: string): entidad_organizadora[]+getFilteredModalidadesFormacion(sql: string): modalidad_formacion[]
5.2 Diagrama de clases refinado, adaptado a Symfony
El framework impone algunas restricciones sobre las clases, en este caso añade el campo id
(existen formas de eliminarlo, pero no es recomendable). En las relaciones, además de la
multiplicidad, tenemos que definir la visibilidad, por ejemplo si un usuario puede acceder a las
formaciones no implica que las formaciones puedan acceder a los usuarios. En nuestro caso todas
las relaciones son bidireccionales.
5.2.1 Notas sobre el diagrama de clases
Todas las clases tienen métodos CRUD (create, read, update, delete) que, por simplicidad,
no se reflejan en el diagrama.
El método serialize en usuario sirve para almacenar su estado en un momento dado,
forma parte de la interfaz “AdvancedUserInterface”, que hay que implementar
obligatoriamente en Symfony cuando se trabaja con usuarios.
La clase formación almacena información redundante (modalidad_formación: string y
entidad_organizadora: string). En el siguiente apartado (5.3.1 Redundancia y des-
normalización) se explica su necesidad.
La entidad LibraryRepository es una colección de métodos que afectan a varias clases.
Las guías de estilo de Symfony (y en general del modelo vista-controlador) recomiendan
crear estas bibliotecas en lugar de incluir los métodos estáticos dentro de clases
concretas.
Diagrama de clases refinado
22
rol
-id: int-nombre: string-descripcion: string
usuario
-id: int-nombre: string-apellidos: string-tratamiento: string-dni: string-nrp: string-dirección: string-localidad: string-email: string-centro: string-usuario: string-clave: string-salt: string-fecha_solicitud: date-fecha_aprobado: date-activo: bool-pendiente_activacion: bool-bloqueado: bool-serie: serie-roles: rol[]
+addFormacion(formacion formacion): void+removeFormacion(formacion formacion): void+getFormaciones():void+serialize():void
1..*1..*
formacion
-id: int-denominación: string-finalización: date-horas: string-modo_participación: string-modalidad_formación: string-entidad_organizadora: string-fecha_creación: date-idioma: string-fecha_inscripción: date-numeroRegistro: string-usuario: usuario-participación: modo_participación -actividad: actividad
1
*
modo_participación
-id: int-deniminacion: string-numero: int
1
*
actividad
-id: int-denominación: string-fecha_creación: date-inicio: date-finalización: date-horas: int-lugar: string-número: int -modalidad_formación: modalidad_formación-entidad_organizadora: entidad_organizadora
1
*
entidad_organizadora
-id: int-denominación: string-artículo: string
*
1
serie
-id: int-número: int-contador_actividad: int-contador_formación: int
*1
modalidad_formación
-id: int-denominación: string-determterminante: string-contracción: string-número: int
*1
Diagrama de clases refinado.
23
rol
id: INT(11)nombre: VARCHAR(50)descripcion: VARCHAR(50)
usuario
id: INT(11)nombre: VARCHAR(50)apellidos: VARCHAR(50)tratamiento: VARCHAR(50)dni: VARCHAR(50)nrp: VARCHAR(50)dirección: VARCHAR(50)localidad: VARCHAR(50)email: VARCHAR(50)centro: VARCHAR(50)usuario: VARCHAR(50)clave: VARCHAR(50)salt: VARCHAR(50)fecha_solicitud: DATETIMEfecha_aprobado: DATETIMEactivo: BOOLpendiente_activacion: BOOLbloqueado: BOOLserie: INT(11)
formacion
id: INT(11)denominación: VARCHAR(255)finalización: DATETIMEhoras: INT(4)modo_participación: VARCHAR(70)modalidad_formación: VARCHAR(80)entidad_organizadora: VARCHAR(80)fecha_creación: DATETIMEidioma: VARCHAR(50)fecha_inscripción: DATETIMEnumeroRegistro: VARCHAR(50)usuario:INT(11)participación: INT(11) actividad: INT(11)
modo_participación
id: INT(11)deniminacion: VARCHAR(70)numero: INT(11)
actividad
id: int(11)denominación: VARCHAR(255)fecha_creación: DATETIMEinicio: DATETIMEfinalización: DATETIMEhoras: INT(4)lugar: VARCHAR(60)número: INT(11)modalidad_formacion: INT(11)entidad_organizadora: INT(11)
entidad_organizadora
id: INT(11)denominación: VARCHAR(255)artículo: VARCHAR(5)
serie
id: INT(11)número: VARCHAR(2)contador_actividad: INT(11)contador_formación: INT(11)
modalidad_formación
id: INT(11)denominación: VARCHAR(80)determterminante: VARCHAR(5)contracción: VARCHAR(7)número: INT(11)
usuario_rol
rol_id: INT(11)usuario_id: INT(11)
5.3 Diagrama relacional
A partir del modelo conceptual Symfony genera el conjunto de tablas y los métodos CRUD. El que
sea un proceso automático, no significa que sea perfecto, en este caso hemos tenido que
transformar las relaciones M a N en nuevas entidades de manera manual para que Symfony
genere el esquema de la base de datos. El resultado es el siguiente:
Diagrama relacional
24
5.3.1 Redundancia y des-normalización
La tabla formación (que almacena los certificados) tiene claves ajenas a las otras tablas pero se
almacena también el valor de los campos. Por ejemplo, en el caso de modo de participación
podemos ver la clave ajena participación: INT(11) y el valor modo_participacion: VARCHAR(70).
Esto ocurre con todas sus claves ajenas excepto con usuario-formación, que se comporta de
manera normal.
Esta redundancia es necesaria porque la información de esta tabla es información consolidada,
indeleble: representa certificados emitidos cuyos datos tiene que coincidir con la copia impresa.
La replicación de datos en esta tabla palía el problema de inconsistencia de datos (que se detalla
en el apartado 5.6) que surge al fusionar las antiguas bases de datos.
Esta duplicación también permite la agilización de las consultas más comunes dentro de la
aplicación: la del listado de los datos de los certificados de un usuario concreto.
Por otro lado se mantienen las claves ajenas con un funcionamiento normal, sobre todo la de
actividad-formación para poder realizar consultas como las fechas de inicio y finalización de la
actividad que se certifica.
5.4 Estructura de directorios
Como se detalla en el “Anexo IV: Estructura de un proyecto en Symfony”, los proyectos deben
dividirse en paquetes o Bundles. En este caso se ha decidido dividir el proyecto en cuatro:
BdBundle: base de datos y funciones de acceso.
LoginBundle: gestión de acceso de los usuarios a la aplicación.
BackendBundle: Back-end, gestión para los perfiles de administrativo y administrador.
RegistroFormaciónBundle: Front-end donde el profesor consulta la formación.
BdBundle se encargará de la gestión de toda la base de datos, y será necesario para la ejecución
de los otros tres bundles.
LoginBundle BackendBundle RegistroFormaciónBundle
BdBundle
25
La estructura de directorios quedará de la siguiente manera:
Estructura de directorios.
En el Anexo IV: Estructura de un proyecto Symfony se detalla el contenido de las carpetas app y
bin.
5.5 Definición de interfaces de usuario
5.5.1 Principios de diseño de la interfaz
En el back-end, primará la eficacia con respecto a la apariencia, las bases para su diseño serán:
Anticipación: se garantizará con autocompletando los datos del profesor, y la actividad
al teclear una cadena similar en nombre, apellidos y nombre de la actividad.
Autonomía: incluirá una sección de ayuda contextual.
Consistencia: los elementos comunes aparezcan situados en la misma posición de forma
ordenada y coherente, dando una imagen de unidad.
En el front-end, la sencillez y el mantenimiento del aspecto anterior serán fundamentales:
Simplicidad: se implementarán únicamente las funciones indispensables para el
profesor.
Uso de botones con metáforas visuales similares a las que usa la aplicación de consulta
web en la actualidad.
Metáforas visuales para Imprimir, modificar datos y volver.
26
5.5.2 Diagrama de navegación de la aplicación
El flujo de navegación estará claramente diferenciado entre el front y el back-end, a partir del
punto de entrada de la aplicación. Por otro lado, la gestión de todos los ficheros maestros se
llevará a cabo a través de los formularios “Área de trabajo y Opciones”, lo que aumentará la
modularidad y la simplicidad.
Formulario de registro
Fron-end Back-end
ImprimirModificar
datos personales
Salir
Usuarios Roles SeriesModos
participaciónModalidades
formaciónActividades formación
Registro
Área de trabajo
Buscar por usuario
Buscar por actividad
Área de trabajo
Opcioes
Diagrama de navegación.
27
5.5.3 Detalle de las interfaces
El formulario de acceso a la aplicación tendrá un campo de usuario, correspondiente al DNI, una
contraseña y un captcha. También dará acceso a otro formulario de recuperación de clave. Una
característica adicional es la posibilidad de habilitar el acceso mediante certificado digital.
Accesos al Registro de Formación
16342390UsiarioContraseña
Letras
Acceder
¿Olvidó su contraseña?
Detalle de formulario de acceso.
Una vez se accede al front-end se muestra la lista de certificados del usuario, pudiéndose ordenar
ascendente o descendentemente por cualquier columna. También muestra los accesos a
imprimir, modificar datos del perfil y volver.
Registro de Formación
Detalle de front-end: consulta de certificados.
28
El back-end tendrá un aspecto menos minimalista, ya que buscará reducir el número de pantallas
y pulsaciones para introducir los datos. Se dividirá en tres columnas:
1- Menú, mostrará los elementos adecuados para cada perfil.
2- Zona de trabajo
3- Zona de ayuda, con mensajes que ayuden en la tarea en función del contexto.
Zona de administración
Área de trabajoOpciones disponibles
AyudaAdministrador
Administrativo
Series
Usuarios
Actividades de formación
Modos de participación
Profesores
Entidades organizadoras
Modalidades de formación
Registro de Formación
Roles de usuario
Opciones disponiblesArea de trabajo
Registro
Volver
Id:NombreApellidosDNIE-mailTratamiento
Guardar
Detalle de back-end: nuevo profesor.
29
La pantalla más importante, y la más utilizada por los administrativos será la del registro de
certificados de las diferentes actividades. Desaparece la zona de ayuda para poder mostrar todos
los campos en una sola pantalla. Introduciendo parte del nombre, DNI o email del usuario y la
denominación de la actividad se autocompletarán el resto de campos y generará un número de
registro único.
Registro de actividades
Administrador
Administrativo
Series
Usuarios
Actividades de formación
Modos de participación
Profesores
Entidades organizadoras
Modalidades de formación
Registro de Formación
Roles de usuario
Búsqueda por usuarioArea de trabajo Búsqueda por actividad
Registro
Volver
Id:NombreApellidosDNIE-mailTratamiento
Número de registro
Registar
Id:DeniminaciónFecha iniFecha finHorasTipo
Usuario Actividad
Modo de particiapación
Horas
Fecha
Detalle de back-end: Registro de certificados.
30
5.6 Diseño de la migración
En el “Anexo V: Análisis de las bases de datos del antiguo registro” se hace un estudio de la
estructura de las bases de datos que integran el registro actualmente. En este apartado nos
centraremos en las equivalencias entre tablas y la consistencia de los datos que almacenan.
Registro de formaciones propias Registro de formaciones externas Nuevo registro de formación
Diagrama de correspondencia de tablas antiguas y nuevas.
modo_participación
Modo
participación
Modo
participación
rol
usario_rol
formación
usuario
actividad
serie
entidad_organizadora
modalidad_formación
Docentes Docentes
Registro General
Registro General
Modalidad
Formación
Modalidad
Formación
Actividades de
formación
Actividades de
formación
Entidad
organizadora
Entidad
organizadora
31
Por otro lado, se ha observado que hay datos incongruentes entre las dos bases de datos, por
ejemplo, en la tabla entidades_organizadoras pueden observarse lo siguiente:
Nº Entidad Denominación Nº Entidad Denominación
1 Centro de prof. Logroño 1 Centro de prof. Logroño
21 Universidad de Zaragoza 21 Universidad de Zaragoza
37 Sindicato C.S.I.-C.S.I.F. 37 Sindicato C.S.I.-C.S.I.F.
49 Universidad Rovira i Virgil 49 Universidad de Siena
50 Internationa Summer School 50 Internationa Summer School
74 Ministerio Educación Francia 74 M. Educación de Francia
Formaciones externas (8301 registros) Formaciones propias (730 registros)
Extracto de comparación de datos.
Tal y como se muestra en el ejemplo, los datos coinciden hasta el registro 48, a partir de éste
punto hay dos tipos de discordancias:
Mismo código para diferente entidad (número 49).
Mismo código, misma entidad, pero escrita de diferente manera (número 74).
Esto ocurre en todas las tablas de maestros: Modos de participación, modalidades de
participación y lo que es peor, en la tabla de docentes.
Es necesario decidir los datos de qué tabla van a servir como base de la migración en cada caso
y definir las consultas que realizarán la fusión. En el Punto 6.4 se detalla estas consultas, y en el
6.5 las pruebas para comprobar la validez de los datos.
En la reunión del 22 de abril (Acta 10) se decide utilizar la base de datos de entidades externas
como base para la migración.
5.6.1 Valoración de pérdida de información.
Al tener información contradictoria en las tablas, resulta imposible no perder información
mediante procesos automáticos, sería necesario que una persona revisara personalmente los
registros y decidiera. (Ver Figura 26, Extracto de comparación de datos)
Como solución de compromiso se ha acordado replicar datos de las tablas problemáticas en la
tabla de formaciones. Por ejemplo vemos que en la tabla formaciones aparece el nombre de la
entidad organizadora, además de la relación con la tabla entidades organizadoras. Todos
aquellos datos que no se repliquen se perderán, en apartado 5.3 y 5.3.1 se especifican qué
campos conservaremos.
32
6 Implementación
6.1 Generación de los modelos
Como ya se ha comentado en el diseño, la aplicación se compone de cuatro bundles.
Bundles generados.
BdBundle se encarga del acceso a toda la base de datos, por lo que es el único que posee
modelos directamente relacionados con tablas de la bd. El resto de bundles se apoyan en él. Las
entidades están generadas automáticamente pero ha habido que añadir, como es lógico, todas
las relaciones.
33
Ejemplo de código de relación uno a varios.
6.2 Codificación de los controladores
En una aplicación Symfony típica, un controlador realiza llamadas al modelo para obtener la
información de la bd. Podemos generar los controladores con métodos CRUD (Create, Read,
Update, Delete) de manera automática, en la carpeta “Controller/<Entidad>Controller.php” del
bundle correspondiente. Ver Anexo III para más detalles.
En este caso (y en la mayoría de aplicaciones de gestión), a muchas de las entidades les afectan
las mismas funcionalidades. Por ello se ha creado un único controlador para todas ellas. En
“BackendBundle/Controller/EntitiesController.php” se encuentra toda la lógica de control.
Los métodos tienen tres parámetros de entrada fundamentales:
Request: objeto de tipo Symfony\Component\HttpFoundation\Request que almacena
una petición http.
Entity: la entidad sobre la que se aplicará el método.
Id: valor de la clave principal en la entidad.
Ejemplo de firma de métodos del controlador.
34
El código interno de los métodos no es una sucesión de condicionales en función del tipo de
entidad, sino que se parte de unas variables que se inicializan con los tipos de entidad y sus datos
y se juega con las llamadas a funciones para que encajen para todas. De esta manera, al añadir
un nuevo tipo de entidad a la aplicación los métodos del controlador siguen funcionando sin
tocar el código del controlador general.
Extractos de código más representativos del método createEntity
6.3 Codificación de las vistas
Symfony también genera vistas estándar para consultar, insertar, actualizar y borrar entidades.
En el Anexo III se detalla el proceso y los resultados. Estas vista funcionan, pero suelen ser inútiles
en aplicaciones reales dada su extrema rigidez y sencillez. En este proyecto se han generado
desde cero. Se encuentran en cada bundle en “Resources/views”.
Para el diseño de los paneles, botones y demás controles se ha utilizado un tema de jqGrid, al
que se ha sobrescrito desde el archivo src/BackendBundle/Resources/Public/css/custom.css
35
Esquema de archivos y directorios de las vistas de BackendBundle.
La plantilla general del Backend se ha dividido en cinco secciones, cada una corresponde a una
plantilla.twig: cabecera, menú, tabs, help y pie.
Ejemplo de pantalla con las cinco secciones destacadas.
36
La principal complejidad está en la sección tabs, que carga una plantilla u otra en función de la
entidad que estemos manejando. Todo el contenido de tabs se carga mediante Ajax, por lo que
su funcionamiento está ligado al archivo “Resources/public/js/entities.js”. En entities.js se
encuentra el código que recarga cada tab, todos los autocompletados y las búsquedas.
6.4 Flujo de ejecución
El nuevo registro de formación es una aplicación Symfony que cumple con los estándares, por lo
que su flujo de ejecución es: Se accede a una ruta que llama a un controlador que puede o no
acceder al modelo para devolver una vista que a su vez contiene más rutas.
Sin embargo, el uso de Ajax y de un controlador único para todas las entidades hace que éste
flujo tenga ciertas particularidades que ilustraré con un ejemplo.
6.4.1 Ejemplo de flujo de ejecución de modificar datos de usuario
Tras habernos identificado como administrador accedemos a la pantalla de gestión de maestros
La aplicación carga la plantilla principal compuesta a su vez por las cinco secciones. En tabs es
donde se realizarán todas las llamadas al controlador general con los parámetros: request, entity
e id. La diferencia con una aplicación típica es que las llamadas al controlador se realizan
mediante control de eventos en JavaScript. En este caso el evento onclick:
Llamada al controlador general desde la plantilla user.html.twig
La función loadForm tomara el parámetro path y lanza la petición al controlador. En este caso la
ruta será ‘/bakend/entities/do/editEntity/2345‘. Los demás parámetros se usan para pintar la
información.
37
Código del método loadForm en entities.js
De esta manera el archivo entities.js es el que controla todas las llamadas al controlador genérico
(EntitiesController.php), juntos forman el eje principal de las peticiones. Con esto conseguimos
que la aplicación tenga mucha mayor fluidez y no dé saltos al no tener que recargar
continuamente pantalla tras pantalla.
El bundle RegistroFormacionBundle funciona de manera análoga: formacion.js envía las
peticiones a RegistroController.php, consiguiendo una experiencia de usuario mucho más fluida.
6.5 Tratamiento de transacciones
La actualización de algunas entidades requiere el uso de transacción. El control de transacciones
se lleva a cabo en EntitiesController.php, con las funciones:
beforeSave<Entidad>
afterSave<Entidad>
Si se añaden entidades que requieran transacciones se deben implementar sus respectivas
funciones siguiendo esta convención.
38
6.6 Proceso de migración
Tal y como se especifica en el diseño de la migración solo se toma la información de las bases
de datos de formaciones propias y externas, desechando la bd de consulta web. Se parte de una
primera fusión en Access de las bases de datos registro de formaciones propias (F) y externas (R),
en la que se duplican las tablas.
Tablas de la bd intermedia generada en la migración.
El proceso comienza insertando en la nueva tabla DocentesFormYRecon los todos los registros
de las tablas DocentesR y DocentesF (por este orden). Con esto se obtienen todos los datos de
los docentes. Muchos están repetidos, por lo que se realiza otra consulta que inserta en
DocentesNoRepetidos los docentes una única vez, con un nuevo id. Si hay repetidos se toma el
primero que se encuentra, el de la antigua tabla DocentesR, por lo que si hay discordancia entre
los datos de ambas bd se priorizan los de las tablas de formaciones externas, tal y como se
indica en el diseño de la migración (Punto 5.6)
39
Para cada docente de la tabla DocentesNoRepetidos se consulta su formación en Registro
GeneralR y Registro GeneralF, sin usar su id (diferente en ambas bd) sino la combinación de su
DNI, su nombre y aplellidos, y se inserta en FormYReconoc. Para rellenar los campos modos de
participación, entidad organizadora y actividad se usan sub-consultas. El resto de maestros se
toman de la base de datos de formaciones externas.
6.6.1 Valoración de la pérdida de información
Con este proceso de migración se mantiene la gran mayoría de la información a excepción de:
La relación entre formación y actividad.
La relación entre formación y entidad.
La relación entre formación y modo de participación.
Esto se produce cuando la actividad, entidad o modo de participación está duplicada en las bases
de datos antiguas con id diferentes.
Con la replicación de datos en la tabla formaciones y la restricción de no modificar los certificados
se salva este gran problema.
6.7 Pruebas de migración
Durante las pruebas de migración se constató la inconsistencia de los datos tal y como se detalla
en el apartado anterior.
6.8 Bibliotecas y bundles de terceros
En el proyecto se han usado tres bibliotecas de terceros:
La biblioteca JavaScript JQuery para presentar y manipular los datos.
La biblioteca jqGrid, versión gratuita basada en JQuery, para la presentación de los datos
en todas las rejillas de la aplicación.
Módulo para Symfony Gregwar, de Grégoire Passaul, suministrada bajo licencia libre que
genera captcha.
40
7 Pruebas
Las pruebas son una parte fundamental en este proyecto, ya que manejará datos de carácter
personal que estarán expuestos en Internet. Su objetivo principal es garantizar un nivel razonable
de calidad y seguridad en el tratamiento de estos datos.
El plan de pruebas cuenta con los siguientes niveles de pruebas:
7.1 Pruebas unitarias de la iteración 2
Los proyectos Symfony están preparados para la ejecución de baterías de unit test de manera
relativamente sencilla, pero la re-planificación redujo el número de horas dedicadas a esta tarea
por lo que se desarrollaron pruebas de caja negra. Aunque, como es lógico, se realizaron casos
de pruebas unitarias de forma paralela a la construcción del sistema para todos y cada uno de
los métodos de las distintas clases.
Los métodos más intensamente testados han sido los del controlador genérico:
Métodos del controlador genérico.
41
Por ejemplo, para el caso método createEntity (request, entity, Id): Response
Núm. de prueba Unit1
Descripción Se crea un objeto de tipo Entidad de usuario
Entada request
entity: User. id: null.
Resultado esperado
Se crea el objeto y muestra mensaje de confirmación
Resultado real Correcto
Comentarios
Esta prueba se repite con entidades de tipo User, Rol, Modo de participación, Modalidad,
Actividad y entidad.
El proceso es el mismo para editEntity, deleteEntity y el resto de métodos.
7.2 Pruebas de integración de la iteración 2
Se han llevado a cabo verificaciones asociadas a grupos de componentes. Los casos de prueba
han sido los siguientes:
Crear, borrar, modificar y buscar:
o usuario.
o rol.
o modo de participación.
o modalidad de formación.
42
o actividades de formación.
o entidades organizadoras.
Asignar rol a usuario.
Nueva formación.
o Búsqueda de actividad.
o Búsqueda de docente.
o Generación de número de registro.
Buscar formación, por actividad y por usuario.
o Comprobar que no es modificable.
Las fichas de prueba han seguido la siguiente plantilla:
Número de prueba Int1
Descripción Se crea introducen los datos de un nuevo usuario en el formulario, se pulsa aceptar y se muestra mensaje de confirmación.
Entada Nombre, Apellidos, DNI, email, tratamiento.
Resultado esperado Se crea el objeto, se almacena en la bd y muestra mensaje de confirmación
Resultado real Correcto
Comentarios
7.3 Pruebas de implantación de la iteración 2
Estas pruebas incluyen las verificaciones necesarias para asegurar que el sistema funcionará
correctamente en el entorno de operación. Se han verificado:
El correcto acceso a bd: urls, claves seguras, usuarios de limitados con privilegios
limitados.
Versiones correctas de: Php, MySql y Apache.
Correcto funcionamiento de los bundles y componentes de terceros.
Correcto acceso y visualización desde versiones actualizadas de Explorer, Firefox y
Chrome.
7.4 Pruebas en producción paralela
Como ya se ha comentado en la planificación del TFG, estas pruebas se desarrollarán desde el
mes de septiembre hasta noviembre. Consistirán en que los dos administrativos (Noelia y José)
trabajen de manera paralela con el antiguo y el nuevo registro. Durará tres meses y las
conclusiones que se extraigan conllevarán el desarrollo de la iteración 3.
43
8 Conclusiones
Reflexionando sobre los problemas que han surgido con este TFG se refuerza mi idea de que
siempre es más fácil empezar desde cero una aplicación que continuar a partir de otra. En este
caso la migración resultó ser la parte más compleja del proyecto, planteando problemas de
información incongruente, y diferencias de formatos.
Otra idea que confirma cada vez más mi experiencia es no juzgar con excesiva dureza el trabajo
de otros: puede tratarse de soluciones que se amplían, que pasan por muchas manos, que
carecen de documentación, que acaban siendo algo muy diferente a cómo fueron concebidas y
que se usan décadas enteras sin realizar mantenimientos. También encontramos soluciones
temporales que terminan siendo eternas: en este caso una simple base de datos en Access pasó
a duplicarse para dar otro servicio y se amplió posteriormente con una aplicación web en php
para mostrar datos por Internet, todo esto llevado a cabo por diferentes personas y sin
documentación.
Por otro lado he constatado que la curva de aprendizaje de Symfony es más pronunciada de lo
que se publicita, a cada paso se nota que es un framework robusto, que impone altos estándares
de calidad para que la aplicación funcione. Por mucho que te documentes y hagas ejemplos, no
sabrás lo que vas a necesitar hasta que los necesites. Por ello es tan importante realizar una
planificación flexible (que permita cumplir los hitos, sea cual sea el contratiempo), más aún que
hacerla pormenorizada.
A pesar de los quebraderos de cabeza que me haya podido dar, utilizar un framework que obliga
a utilizar buenas prácticas en la programación, la nomenclatura y la organización, redundará en
una mejora del código y la estructura de mis futuros proyectos use Symfony o no.
8.1 Lecciones aprendidas
He actualizado mis conocimientos sobre PhpStorm, Symfony, Git, nuevas normas de
estilo de código y otro enfoque del MVC.
He comprendido la necesidad de unos altos niveles de organización de proyectos web.
He afianzado mis conocimientos sobre las herramientas JQuery y jqGrid.
He constatado la necesidad de generar una documentación organizada y pormenorizada
que facilite la tarea de mantener y mejorar el proyecto a los desarrolladores que vaya a
estar a cargo del él en el futuro.
44
8.2 Puntos fuertes del nuevo registro de formación
Está construido sobre un framework muy estable y muy testado y he seguido las
principales recomendaciones de desarrollo, lo que garantiza cierta confianza en su
seguridad y estabilidad.
Es totalmente escalable y flexible: puedo añadir nuevos Bundles, modificar la versión de
php necesaria para la ejecución, actualizar o reducir la versión de una o varias partes del
proyecto sin afectar al resto.
El uso de Ajax (sobre todo en las búsquedas) hace que el manejo de la aplicación sea
mucho más ágil que otras aplicaciones web.
El uso del controlador genérico garantiza un fácil escalabilidad para la futura integración
con el programa G1.
He cumplido con los objetivos del proyecto en el plazo establecido siguiendo un plan de
manera metódica y organizada, y lo he plasmado con el uso de la aplicación de TFG y con
la presente memoria.
8.3 Mejoras de para la iteración 3
Durante el final de las pruebas de integración se contempló aprovechar la modularidad del nuevo
registro de formación para incrementar la seguridad.
Como ya se describe en el diseño, el nuevo registro tiene la siguiente estructura de paquetes:
Se decidió no mantener en el servidor de consulta BackendBundle, quedando dos versiones de
la aplicación, una preparada para el acceso público y que sólo permite la consulta:
Puede consultarse en: http://www.larioja.org/npRioja/default/defaultpage.jsp?idtab=745130
Y otra a la que únicamente accederán los administrativos y el súper-administrador:
Ambas acceden a la misma BD, pero con usuarios de base de datos con diferentes permisos.
LoginBundle BackendBundle RegistroFormaciónBundle
BdBundle
LoginBundle RegistroFormaciónBundle
BdBundle
LoginBundle BackendBundle
BdBundle
45
9 Bibliografía
http://symfony.com/doc/current/book/index.html
http://librosweb.es/libro/symfony_2_x/
http://symfony.com/blog/introducing-the-symfony-demo-application
http://www.w3.org/
http://www.w3schools.com/
http://php.net/
https://librosweb.es/libro/css/
http://symfony.com/doc/current/quick_tour/the_big_picture.html
http://stackoverflow.com/
http://www.webdeveloper.com/forum/
10 Agradecimientos
A Irene por aguantar mi trabajo de después del trabajo.
A Juanjo por darme la libertad para llevar a cabo el proyecto tal y como creí conveniente.
A Santos por permitirme ser su pupilo de Symfony.
A Ignacio, director del CeFIAME, y a la Consejería de Educación de La Rioja por darme todas las
facilidades para ayudarme a realizar este trabajo.
1
Anexo I: Análisis preliminar del sistema de gestión de cursos del
CeFIAME (G1)
El sistema de gestión de cursos del CeFIAME, en adelante G1, consiste en una
aplicación web basada en PHP y una base de datos MySQL.
Con respecto al código, G1 está programado sin utilizar ningún framework y no sigue
ninguna arquitectura en la que se diferencien capas.
No existe documentación sobre la base de datos, por lo que se ha importado el
esquema a Workbench y se ha generado el esquema. Se puede observar que el
programa se organiza en torno al concepto de actividad o acción formativa, como
puede verse en el diagrama relacional de sus tablas (Figuras 1 y 2). También puede
comprobarse que hay 40 tablas sin relación alguna, dentro de las cuales 4 no se
utilizan.
Conclusiones del análisis preliminar:
Para garantizar la perfecta compatibilidad es recomendable que el registro de
formación se desarrolle usando una bd SQL y PHP, lo que facilitaría la comunicación
y permitiría compartir un servidor para ambas aplicaciones, si fuera necesario.
Aunque G1 no produce errores en su funcionamiento diario, queda patente que es
recomendable rediseñarlo y re-implementarlo. Es importante que el nuevo registro
de formación permita integrar una nueva versión de G1 en un futuro cercano.
1
Esquema relacional de G1
2
Esquema relacional de G1
1
Anexo II: estudio de frameworks basados en PHP+SQL
A la hora de abordar el desarrollo de una aplicación web uno puede verse tentado a
desarrollar sus propias librerías. Personalmente pienso que eso es un gran error. Esa
filosofía está bien mientras uno está estudiando y formándose, para entender mejor
cómo funcionan las cosas, pero en cuanto estamos en el mercado laboral y tenemos
que ofrecer a nuestros clientes productos de calidad en un plazo de tiempo
razonable, pensar que nosotros solos somos capaces de desarrollar todas estas
librerías, con una calidad similar que las comunidades de desarrolladores
experimentados, suena un tanto pretencioso.
A continuación voy a realizar un somero estudio de los principales frameworks
basado en PHP y MySQL:
Symfony2
Symfony se ha convertido en uno de los frameworks más usados en la actualidad para
el desarrollo de proyectos de casi cualquier tamaño. Usa el patrón de diseño modelo
vista controlador, además tiene componentes complementarios como sistema de
plantillas, traducción, rutas (REST), sistema de ficheros y una lista bastante
interesante.
Silex
Silex es un micro-framework que desciende directamente de Symfony. Simplifica
algunos aspectos, como el uso del modelo vista controlador. Tiene una curva de
aprendizaje menor que Symfony, aunque puede no ser apto para proyectos muy
grandes.
Zend Framework
Zend Framework es un framework fácil de entender, bien documentado y que
cumple varias funciones de forma segura, eficiente y modular (si así lo queremos).
Incorpora el modelo vista controlador, además de tener sistema de rutas, sistema de
generación de formularios y sistema de traducción. Incorpora una capa de
compatibilidad con bases de datos de distintos proveedores, para hacer los proyectos
más uniformes y fácilmente portables.
2
CodeIgniter
CodeIgniter es considerado uno de los frameworks más rápidos actualmente,
implementando de forma ligera el patrón de diseño MVC. Sigue siendo uno de los
más usados pero tiene grandes carencias con respecto a Symfony, por ejemplo: en
realidad no tiene mapeo objeto-relacional, ni sistema de plantillas.
Laravel
En este caso, Laravel incorpora al igual que los anteriores MVC, pero además viene
con funcionalidades para crear aplicaciones RESTful y gestionar de forma compatible
y más ligera las bases de datos. Gran parte de Laravel está formado por
dependencias, especialmente de Symfony, esto implica que el desarrollo de Laravel
dependa también del desarrollo de sus dependencias. Tiene una documentación
amplia y clara.
Yii
Yii es un framework PHP, libre (licencia BSD), basado en programación orientada a
objetos y que implementa el patrón de diseño MVC. Puede ser utilizado para todo
tipo de aplicaciones Web. Es adecuado para desarrollar aplicaciones de gran tráfico
como portales, foros, sistemas de administración de contenidos (CMS),... gracias a
sus soluciones de caché sofisticadas.
Ahora voy a observar comparar la popularidad de algunos de estos frameworks.
Tendencias en el uso de frameworks a nivel mundial, según google Trends.
3
Encuesta realizada a desarrolladores desde la página phpframeworks.com.
Posteriormente realizamos dos prototipos de registro simple de usuarios, un en
Symfony y otro en Zend, para comprobar la complejidad y la calidad de la
documentación de manera superficial.
Conclusión
Para la elección del framework que usaremos en el proyecto, hemos tenido en cuenta
los siguientes aspectos, ordenados de más importante a menos:
Que tenga un desarrollo activo, que garantice la corrección de problemas de
seguridad, mejoras, etc.
Que tenga una comunidad activa.
Que tenga una buena documentación.
Que sea robusto y “estándar”.
Que soporte proyectos de tamaño medio y grande.
Impresiones durante la realización del prototipo.
Qué no hemos tenido en cuenta:
Curva de aprendizaje suave.
Simplicidad.
4
La elección final ha sido Symfony 2: es uno de los frameworks más robustos, aplica
muy buenas prácticas de programación, su sistema de plantillas twig es muy sencillo
de utilizar, aunque también puede usarse PHP como motor de plantillas y su
configuración es fácil de realizar. Además es la base de Silex y comparte muchas
dependencias con Laravel, por lo que lo aprendido con este framework será aplicable
a todos ellos.
Por contra, Symfony tiene fama merecida de ser muy complejo, por ellos nuestro
proyecto deberá contemplar mucho más tiempo de documentación y menos de
desarrollo que un proyecto normal, si todo sale bien.
Bibliografía
www.desarrolloweb.com
www.genbetadev.com
www.phpframeworks.com
http://www.cristalab.com
http://www.zfort.com
web de cada uno de los frameworks.
1
Anexo III: Instalación y puesta en marcha del entorno de trabajo
(Linux)
Descargar e instalar el paquete de Symfony
Abre la consola de comandos y ejecuta:
$ curl -LsS http://symfony.com/installer > symfony.phar
$ sudo mv symfony.phar /usr/local/bin/symfony
$ chmod a+x /usr/local/bin/symfony
Crear la aplicación Symfony
Crea un nuevo proyecto (estructura de carpetas, fuentes y dependencias) con el
siguiente comando:
$ symfony new my_project_name
Esto creará un nuevo proyecto Symfony con la siguiente estructura de carpetas.
Estructura de proyecto en Symfony.
Nota: en el Anexo IV se incluye una explicación detallada de un proyecto en Symfony.
2
Arrancar la aplicación
Symfony puede usar el servidor web de PHP para lanzar nuestras aplicaciones
mientras las estamos desarrollando. Vamos al directorio de nuestro proyecto, a la
carpeta app. Y ejecutamos server:run en la consola:
$ cd my_project_name/ $ php app/console server:run
Ahora podemos acceder a nuestra aplicación a través del puerto 8000:
http://localhost:8000
Página de bienvenida.
Cuando hayamos terminado de trabajar en la aplicación podemos parar en servidor
con server:stop
$ php app/console server:stop
3
Comprobar la configuración de nuestra aplicación.
Para comprobar si el entorno de ejecución está bien configurado debemos acceder
al archivo config.php
http://localhost:8000/config.php
Con esto accederemos a la página de configuración:
Página de configuración.
Normalmente está mal configurada la zona horaria del servidor, solución:
4
Y después introducimos la zona horaria
Ya solo queda dar permisos a las carpetas cache y logs dentro de app, para poder
reescribirlas:
Instalar Composer
Composer es el gestor de paquetes que usan las actuales aplicaciones PHP. Nos
servirá para descargar y actualizar nuestras aplicaciones Symfony y todas sus
dependencias de manera rápida.
$ curl -sS https://getcomposer.org/installer | php $ sudo mv composer.phar /usr/local/bin/composer
Y ahora ejecutamos el commando install:
$ cd my_project_name/ $ composer install
5
También se puede actualizar él mismo con
$ composer selfupdate
Crear un virtual host para nuestra aplicación en el servidor
Primero comprobamos que sitios tenemos habilitados, y posteriormente creamos el
nuevo. En este caso copio registro _formacion en prototipo para no tener que escribir
tanto:
El archivo debe quedar de la siguiente manera:
6
Para activar el Nuevo virtual host:
Y por último editar el archivo de hosts para poder entrar desde localhost:
En este caso:
Reiniciamos apache:
7
Y ya tenemos nuestra primera aplicación Smfony preparada:
Configuración de Phpstorm
Abrir el proyecto tal cual está en Phpstorm dejar que indexe (tarda tiempo en
recorrer todas las carpetas que crea Symfony).
Después habilitamos el plugin de Symfony2 desde ajustes:
Ajustes de Phpstorm.
8
Configuramos los perfiles de ejecución para aplicaciones web en PHP.
Perfiles de ejecución en Phpstorm. Pantalla 1.
Perfiles de ejecución en Phpstorm. Pantalla 2.
9
Perfiles de ejecución en Phpstorm. Pantalla 3.
Comenzar a modificar el proyecto
Todo proyecto Symfony se estructura en paquetes o bundles. Todo el código tiene
que estar dentro de uno de estos bundles. Por eso es muy importante pensar cómo
vamos a organizar nuestros proyectos antes comenzar a generar código sin ton ni
son. Esto es muy positivo porque obliga a que exista una estructura modular y
fácilmente ampliable. Volvemos a la obligación de usar buenas prácticas con
Symfony.
10
Para crear un Nuevo bundle lanzamos la consola de Symfony.
Consola de Symfony.
TRUCO: Con el commando list tenemos la ayuda
Vamos a generar nuestro primer modelo, generate:<lo que sea> genera
automáticamente el código de lo que queremos generar, en este caso nuestro primer
bundle.
11
Durante la creación también te instruye en buenas prácticas para denominar los
espacios de nombres.
Ahora vamos a generar el modelo propiamente dicho:
Saltará un asistente que nos ayudará a crear nuestro modelo fácilmente:
Elegimos annotation para especificar los formatos en los comentarios. Y comenzamos
a indicar los campos del modelo, que se reflejarán directamente en la base de datos.
Por defecto Symfony crea un campo id que será la clave.
12
El resultado es el siguiente, dentro del nuestra aplicación “prototipo1”, en el espacio
de nombres de “Javier”, en el bundle “ProtoBundle” se crea la entidad Persona.php
Código de entidad de ejemplo.
Ahora tenemos que configurar el acceso a la BD:
app/config/parameters.yml
13
host
user
password
Después generamos la base de datos y reiniciamos la consola de Symfony.
Lanzamos la consola y creamos el esquema con el comando doctrine.
Para modificar el esquema de la bd, primero usamos la opción --dump para ver qué
cambios producirá, esto no altera la BD:
Si estamos conformes ejecutamos el mismo comando con –force para modificar:
Generar los métodos crud (create, read, update, delete) del modelo, en este caso
persona
14
15
Vemos que ha generado el fichero del controlador
Controlador de la entidad de ejemplo.
Y el formulario, que luego usaremos para intercambiar valores de sus campos.
Formulario de la entidad de ejemplo.
16
Y las vistas de consulta, edición…
Vista de la entidad de ejemplo.
Ahora se configura el enrutado en los dos routing.yml, el genral y el del bundle.
Fichero yml de enrutamiento general de la aplicación.
17
En el del bundle por defecto es así:
Fichero yml de enrutamiento del bundle de ejemplo
Debería quedar así:
Fichero yml de enrutamiento del bundle de ejemplo modificado
18
Con estas rutas el mantenimiento de Persona debería funcionar:
Vista del mantenimiento para la entidad de ejemplo.
Trucos
Limpiar cache de symfony:
cache:clear --no-warmup
Bibliografía
http://symfony.com/doc/current/book/index.html
http://symfony.com/doc/current/book/installation.html#book-creating-
applications-without-the-installer
http://symfony.com/doc/current/book/installation.html#book-creating-
applications-without-the-installer
1
Anexo IV: Estructura de un proyecto en Symfony.
Por defecto todas las aplicaciones Symfony tienen la misma estructura de directorios:
app/: contiene la configuración de la aplicación.
src/: aquí se encuentra todo el código PHP de la aplicación.
vendor/: por convención aquí se guardan todas las librerías creadas por
terceros.
web/: este es el directorio web raíz y contiene todos los archivos que se
pueden acceder públicamente.
El directorio web
El directorio web raíz es el lugar donde se encuentran todos los archivos públicos y
estáticos tales como imágenes, hojas de estilo y archivos JavaScript. También es el
lugar donde se definen todos los controladores frontales, como por ejemplo el
siguiente:
// web/app.php
require_once __DIR__.'/../app/bootstrap.php.cache';
require_once __DIR__.'/../app/AppKernel.php';
use Symfony\Component\HttpFoundation\Request;
$kernel = new AppKernel('prod', false);
$kernel->loadClassCache();
$kernel->handle(Request::createFromGlobals())->send();
El archivo del controlador frontal (app.php en este ejemplo) es el archivo PHP que
realmente se ejecuta cuando utilizas una aplicación Symfony2 y su trabajo consiste
en arrancar la aplicaciónutilizando una clase del núcleo (AppKernel).
TRUCO: Tener un controlador frontal significa que se utilizan URL diferentes y más
flexibles que las de una aplicación PHP típica. Cuando se dispone de un controlador
frontal, las URL se formatean de la siguiente manera:
http://localhost/app.php/hello/Ryan
2
El controlador frontal, app.php, se ejecuta y la URL interna: /hello/Ryan se dirige
internamente según la configuración de enrutamiento.
Si además utilizas el módulo mod_rewrite de Apache, puedes forzar la ejecución
del archivo app.phpsin necesidad de incluirlo en la URL, por lo que así las URL son
todavía más limpias:
http://localhost/hello/Ryan
El directorio de la aplicación (app)
Como vimos en el controlador frontal, la clase AppKernel es el punto de entrada
principal de la aplicación y es la responsable de toda la configuración. Como tal, se
almacena en el directorio app/.
Esta clase debe implementar dos métodos que definen todo lo que Symfony necesita
saber acerca de tu aplicación. Ni siquiera tienes que preocuparte de estos métodos
durante el arranque — Symfony los rellena por ti con parámetros predeterminados.
registerBundles(): devuelve un array con todos los bundles necesarios para
ejecutar la aplicación.
registerContainerConfiguration(): carga el archivo de configuración de
recursos de la aplicación (consulta la sección Configurando la aplicación).
Durante el desarrollo de una aplicación, normalmente el directorio app/ solo los
utilizas para modificar la configuración y los archivos de enrutamiento en el
directorio app/config/
Este directorio también contiene el directorio caché de la aplicación (app/cache),
un directorio de logs(app/logs) y un directorio para archivos de recursos globales,
tales como plantillas (app/Resources).
TRUCO Carga automática: Al arrancar Symfony, se incluye un archivo especial
llamado vendor/autoload.php. Este archivo, creado por Composer, se encarga de
configurar el cargador automático de clases, que a su vez carga automáticamente
todos los archivos de tu aplicación que se encuentren en el directorio src/ y todas
las librerías externas configuradas en el archivo composer.json.
Gracias al cargador automático, nunca tendrás que preocuparte de usar
declaraciones include o require. Esto es posible porque Composer
utiliza namespace o espacio de nombres de una clase para determinar su ubicación
y así incluye automáticamente el archivo en el instante en que necesitas una clase.
3
El cargador automático ya está configurado para buscar cualquiera de tus clases PHP
en el directorio src/. Para que funcione la carga automática, el nombre de la clase y
la ruta del archivo deben seguir el mismo patrón:
Nombre de la clase: Acme\HelloBundle\Controller\HelloController
Ruta física del archivo: src/Acme/HelloBundle/Controller/HelloController.php
El directorio fuente (src)
En pocas palabras, el directorio src/ contiene todo el código real (código PHP,
plantillas, archivos de configuración, estilos, etc.) que pertenece a tu aplicación. De
hecho, al programar una aplicación Symfony, la mayor parte de tu trabajo se llevará
a cabo dentro de uno o más bundles creados en este directorio.
Antes de empezar, crea el bundle
Antes de empezar, tendrás que crear un bundle (que se podría traducir
como "paquete"). En Symfony2, un bundle es como un plugin, con la salvedad de que
todo el código de tu aplicación se almacena dentro de bundles.
Un bundle no es más que un directorio que almacena todo lo relacionado con una
función específica, incluyendo clases PHP, configuración, e incluso hojas de estilo y
archivos de Javascript.
Para crear un bundle llamado AcmeHelloBundle (por ejemplo), ejecuta el siguiente
comando y sigue las instrucciones en pantalla (acepta todas las opciones
predeterminadas):
$ php app/console generate:bundle --namespace=Acme/HelloBundle --format=yml
Sin que te des cuenta, se ha creado un directorio para el bundle
en src/Acme/HelloBundle. Además se ha añadido automáticamente una línea en el
archivo app/AppKernel.php para registrar el bundle en el núcleo de Symfony:
// app/AppKernel.php
public function registerBundles()
{
$bundles = array(
4
...,
new Acme\HelloBundle\AcmeHelloBundle(),
);
// ...
return $bundles;
}
Ahora que ya está configurado el bundle, puedes comenzar a construir tu aplicación
dentro del bundle.
Paso 1: Creando la ruta
Por defecto, el archivo de configuración de enrutamiento en una aplicación Symfony2
se encuentra enapp/config/routing.yml. Si lo prefieres, y al igual que en el resto
de la configuración en Symfony2, puedes utilizar el formato XML o PHP para
configurar tus rutas.
Si te fijas en el archivo de enrutamiento principal, verás que Symfony ya ha agregado
una entrada al generar el bundle AcmeHelloBundle:
# app/config/routing.yml
acme_hello:
resource: "@AcmeHelloBundle/Resources/config/routing.yml"
prefix: /
Esta directiva de configuración le dice a Symfony que cargue la configuración de
enrutamiento del archivo Resources/config/routing.yml que se encuentra en el
interior del bundle AcmeHelloBundle.
En otras palabras, puedes configurar tus rutas directamente en el
archivo app/config/routing.yml o puedes definirlas en varias partes de la
aplicación y después las importas desde ese archivo.
Ahora que el archivo routing.yml del bundle se importa desde el archivo de
enrutamiento principal de la aplicación, añade la nueva ruta que define la URL de la
página que estás a punto de crear:
# src/Acme/HelloBundle/Resources/config/routing.yml
5
hello:
path: /hello/{name}
defaults: { _controller: AcmeHelloBundle:Hello:index }
La ruta se compone básicamente de dos partes: el path, que es la URL con la que
debe coincidir la petición del usuario para activar la ruta, y un array
llamado defaults, que especifica el controlador que se ejecuta. Las partes de la URL
encerradas entre comillas indican que su valor puede variar. De esta
forma, {name} significa que las URL /hello/Ryan, /hello/Fabien o cualquier otra
URI similar coincidirá con esta ruta. El valor de las partes variables también se pasa al
controlador, que puede acceder a ellos a través del nombre asignado en la propia
ruta (name en este caso).
Paso 2: Creando el controlador
Cuando el usuario solicita la URL /hello/Ryan, se activa la ruta hello, a la que
corresponde el controlador AcmeHelloBundle:Hello:index, que es realmente el
código que se ejecuta. El segundo paso del proceso de creación de páginas consiste
precisamente en crear ese controlador.
La cadena AcmeHelloBundle:Hello:index es el nombre lógico del controlador, que
se traduce como el método indexAction() de una clase PHP
llamada Acme\HelloBundle\Controller\Hello. Crea en primer lugar este archivo
dentro de tu bundle AcmeHelloBundle:
// src/Acme/HelloBundle/Controller/HelloController.php
namespace Acme\HelloBundle\Controller;
use Symfony\Component\HttpFoundation\Response;
class HelloController{ }
En realidad, el controlador no es más que un método PHP que tú creas y Symfony
ejecuta. Aquí es donde el código utiliza la información de la petición para construir y
preparar el recurso solicitado. Salvo en algunos casos avanzados, el resultado final de
un controlador siempre es el mismo: un objeto Response de Symfony2.
Crea el método indexAction que Symfony ejecutará cuando se sirva la ruta hello:
// src/Acme/HelloBundle/Controller/HelloController.php
// ...
6
class HelloController
{
public function indexAction($name)
{
return new Response('<html><body>Hello '.$name.'!</body></html>');
}
}
El controlador es muy sencillo: crea un nuevo objeto de tipo Response y cuyo primer
argumento es el contenido que se utiliza para crear la respuesta enviada al usuario
(en este caso, una página HTML muy simple).
Si todo lo has configurado correctamente, la aplicación debe darte la bienvenida al
acceder a la siguiente URL:
http://localhost/app_dev.php/hello/Ryan
7
Paso 3 opcional: Creando la plantilla
Las plantillas te permiten mover toda la parte de la vista (es decir, el código HTML) a
un archivo separado y reutilizar diferentes partes del diseño de la página. En vez de
escribir el código HTML dentro del controlador, genera el código HTML a partir de
una plantilla:
// src/Acme/HelloBundle/Controller/HelloController.php
namespace Acme\HelloBundle\Controller;
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
class HelloController extends Controller
{
public function indexAction($name)
{
return $this->render('AcmeHelloBundle:Hello:index.html.twig', array('name' => $name));
// si utilizas PHP en vez de Twig
// return $this->render('AcmeHelloBundle:Hello:index.html.php', array('name' => $name));
}
}
NOTA: Para poder usar el método render(), tu controlador debe extender de la
claseSymfony\Bundle\FrameworkBundle\Controller\Controller, la cual añade
atajos para las tareas más comunes de los controladores. Esto se hace en el ejemplo
anterior añadiendo la declaración usedebajo del namespace y luego añadiendo
el extends Controller a la clase.
El método render() crea un objeto Response y le añade el contenido resultante de
renderizar la plantilla. Así que como cualquier otro controlador, el código anterior
realmente está devolviendo un objeto de tipo Response.
Ten en cuenta que puedes procesar las plantillas de dos formas diferentes. Por
defecto Symfony2 admite dos lenguajes de plantillas: las clásicas plantillas creadas
con PHP y las nuevas y concisas plantillas creadas con Twig. No te asustes porque
puedes elegir libremente cuál utilizar o incluso mezclar las dos en el mismo proyecto.
8
Al procesar la plantilla AcmeHelloBundle:Hello:index.html.twig, el controlador
utiliza la siguiente convención de nomenclatura:
NombreBundle:NombreControlador:NombrePlantilla
Este es el nombre lógico de la plantilla, que se traduce a un archivo físico utilizando
la siguiente convención:
</ruta/a/Nombrebundle>/Resources/views/<NombreControlador>/<NombrePlantilla>
En este caso, AcmeHelloBundle es el nombre del bundle, Hello es el controlador
e index.html.twig la plantilla:
{# src/Acme/HelloBundle/Resources/views/Hello/index.html.twig #}
{% extends '::base.html.twig' %}
{% block body %}
Hello {{ name }}!
{% endblock %}
<!-- src/Acme/HelloBundle/Resources/views/Hello/index.html.php -->
<?php $view->extend('::base.html.php') ?>
Hello <?php echo $view->escape($name) ?>!
Veamos la situación a través de la plantilla Twig línea por línea:
La etiqueta extends indica que se utiliza una plantilla padre donde se define
el diseño del sitio web.
La etiqueta block indica que todo su contenido se debe colocar dentro de un
bloque llamado body. Como se explicará más adelante, la plantilla padre
(base.html.twig) es la responsable de definir ese bloque y de mostrarlo en
la página HTML adecuadamente.
La plantilla padre se indica como ::base.html.twig, por lo que no incluye ni la parte
del nombre del bundle ni la del nombre del controlador (de ahí los dos puntos dobles
(::) al principio). Esto significa que la plantilla no se encuentra dentro de ningún
bundle, sino en el directorio app del proyecto:
9
{# app/Resources/views/base.html.twig #}
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>{% block title %}Welcome!{% endblock %}</title>
{% block stylesheets %}{% endblock %}
<link rel="shortcut icon" href="{{ asset('favicon.ico') }}" />
</head>
<body>
{% block body %}{% endblock %}
{% block javascripts %}{% endblock %}
</body>
</html>
<!-- app/Resources/views/base.html.php -->
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title><?php $view['slots']->output('title', 'Welcome!') ?></title>
<?php $view['slots']->output('stylesheets') ?>
<link rel="shortcut icon" href="<?php echo $view['assets']->getUrl('favicon.ico') ?>" />
</head>
<body>
<?php $view['slots']->output('_content') ?>
<?php $view['slots']->output('stylesheets') ?>
</body>
</html>
10
El archivo de la plantilla base define el diseño HTML y muestra el contenido del
bloque body que se definió en la plantilla index.html.twig. También muestra el
contenido de un bloque llamado title, que si quieres puedes definir en la
plantilla index.html.twig. Como no has definido ese bloque en la plantilla, se utiliza
el valor predeterminado "Welcome!".
Las plantillas son realmente útiles para generar y organizar el contenido de las
páginas de la aplicación. Una plantilla puede generar cualquier cosa, desde el código
HTML o CSS hasta cualquier otra cosa que el controlador tenga que devolver.
Dentro del ciclo petición/respuesta, el motor de plantillas simplemente es una
herramienta opcional. Recuerda que el objetivo de cada controlador es devolver un
objeto Response. Así que por muy potentes que sean, las plantillas son solo una
forma opcional de generar ese objeto Response.
Bibliografía
http://librosweb.es/libro/symfony_2_x/
http://symfony.com/doc/current/book/index.html
1
Anexo V: Análisis de las bases de datos del registro antiguo
El esquema de las bases de datos actuales es el siguiente:
Esquema de bases de datos del registro de formaciones propias.
Esquema de bases de datos del registro de formaciones externas.
2
Las bases de datos empezaron siendo dos copias clónicas, con una estructura y datos
similares, pero el flujo de trabajo a lo largo de los años ha hecho que los datos de
todas las tablas maestras sean diferentes entre ambas.
Por otro lado, la base de datos de formaciones propias ha sufrido remodelaciones:
se le puede comprobar que se le han añadido varios campos a la tabla “Docente” y
se han eliminado dos relaciones (presumiblemente accidentalmente).
Conclusiones
Atendiendo a la estabilidad de la base de datos es recomendable utilizar la base de
datos de entidades externas como base para la migración.
1
Anexo VI: Detalle de consultas del proceso de migración.
Se parte de una primera fusión de las bases de datos registro de formaciones
propias(F) y externas (R), en la que se duplican las tablas problemáticas.
1- Se insertan en una tabla común los datos de los docentes registrados en
formaciones externas.
INSERT INTO DocentesFormYRecon (NIF, Apellidos, Nombre, Tratamiento)
SELECT DocentesR.NIF, DocentesR.Apellidos, DocentesR.Nombre,
DocentesR.Tratamiento
FROM DocentesR;
2- Se insertan en una tabla común los datos de los docentes registrados en
formaciones propias.
2
SELECT DocentesF.NIF, DocentesF.Apellidos, DocentesF.Nombre,
DocentesF.Tratamiento INTO DocentesFormYRecon
FROM DocentesF;
3- Se eliminan los docentes repetidos en la tabla DocentesFormYRecon y se
insertan en DocentesNoRepetidos
SELECT DISTINCTROW DocentesFormYRecon.NIF,
First(DocentesFormYRecon.Apellidos) AS Apellidos,
First(DocentesFormYRecon.Nombre) AS Nombre, First(DocentesFormYRecon.Tratamiento) AS PrimeroDeTratamiento INTO
DocentesNoRepetidos
FROM DocentesFormYRecon GROUP BY DocentesFormYRecon.NIF
ORDER BY DocentesFormYRecon.NIF;
4- Se consulta la formación del registro propio de un docente.
SELECT DISTINCTROW [Registro GeneralF].NIF, DocentesF.Apellidos,
DocentesF.Nombre, [Actividades de formaciónF].Finalización, [Registro
GeneralF].Horas, [Modos de participaciónF].Denominación AS Participación, [Modalidades de formaciónF].Denominación AS [Modalidad Formación],
[Actividades de formaciónF].Denominación AS Denominación, [Entidades
OrganizadorasF].Denominación AS [Entidad Organizativa] INTO FormYReconoc
FROM DocentesF INNER JOIN ([Modos de participaciónF] INNER JOIN ([Modalidades de formaciónF] INNER JOIN ([Entidades OrganizadorasF] INNER
JOIN ([Actividades de formaciónF] INNER JOIN [Registro GeneralF] ON
[Actividades de formaciónF].[Nº Actividad] = [Registro GeneralF].[Nº Actividad]) ON [Entidades OrganizadorasF].[Nº Entidad] = [Actividades de
formaciónF].[Nº Entidad]) ON [Modalidades de formaciónF].[Nº Modalidad] =
[Actividades de formaciónF].[Nº Modalidad]) ON [Modos de participaciónF].[Nº Modo] = [Registro GeneralF].[Nº Modo]) ON
DocentesF.NIF = [Registro GeneralF].NIF
ORDER BY [Actividades de formaciónF].Finalización DESC;
5- Se consulta la formación del registro externo de un docente
INSERT INTO FormYReconoc (NIF, Apellidos, Nombre, Finalización, Horas,
Participación, [Modalidad Formación], Denominación, [Entidad Organizativa]
)
SELECT DISTINCTROW [Registro GeneralR].NIF, DocentesR.Apellidos,
DocentesR.Nombre, [Actividades de formaciónR].Finalización, [Registro GeneralR].Horas, [Modos de participaciónR].Denominación AS Participación,
[Modalidades de formaciónR].Denominación AS [Modalidad Formación],
3
[Actividades de formaciónR].Denominación AS Denominación, [Entidades
OrganizadorasR].Denominación AS [Entidad Organizativa]
FROM DocentesR INNER JOIN ([Modos de participaciónR] INNER JOIN ([Modalidades de formaciónR] INNER JOIN ([Entidades OrganizadorasR] INNER
JOIN ([Actividades de formaciónR] INNER JOIN [Registro GeneralR] ON
[Actividades de formaciónR].[Nº Actividad] = [Registro GeneralR].[Nº Actividad]) ON [Entidades OrganizadorasR].[Nº Entidad] = [Actividades de
formaciónR].[Nº Entidad]) ON [Modalidades de formaciónR].[Nº Modalidad] =
[Actividades de formaciónR].[Nº Modalidad]) ON [Modos de participaciónR].[Nº Modo] = [Registro GeneralR].[Nº Modo]) ON
DocentesR.NIF = [Registro GeneralR].NIF
ORDER BY [Actividades de formaciónR].Finalización DESC;
6- Comprobamos posibles diferencias entre las dos bases de datos.
SELECT FormYReconoc.NIF, FormYReconoc.Apellidos, FormYReconoc.Nombre,
FormYReconoc.Participación AS vieja, FormYReconocActual.Participación AS
Actual, FormYReconoc.Denominación, FormYReconoc.[Modalidad Formación],
FormYReconoc.[Entidad Organizativa], FormYReconoc.Finalización, FormYReconoc.Horas
FROM FormYReconocActual INNER JOIN FormYReconoc ON
FormYReconocActual.NIF=FormYReconoc.NIF WHERE (((FormYReconoc.Participación)<>FormYReconocActual!Participación)
AND ((FormYReconoc.Denominación)=FormYReconocActual!Denominación) AND
((FormYReconoc.[Modalidad Formación])=FormYReconocActual![Modalidad Formación]) AND ((FormYReconoc.[Entidad
Organizativa])=FormYReconocActual![Entidad Organizativa]) AND
((FormYReconoc.Finalización)=FormYReconocActual!Finalización) AND
((FormYReconoc.Horas)=FormYReconocActual!Horas));
7- Preparamos la tabla intermedia sag_tabla_usuarios para ir almacenando los
docentes en la nueva tabla usuarios.
INSERT INTO sag_tabla_usuarios (id, NIF, Apellidos, Nombre, tratamiento,
activo, pendiente_activacion, bloqueado )
SELECT sag_usuarios_web.id AS id, sag_usuarios_web.dni AS dni,
sag_usuarios_web.apellidos AS Expr2, sag_usuarios_web.nombre AS Expr3,
sag_usuarios_web.tratamiento AS Expr4, 1 AS activo, 0 AS pendiente_activacion, 0 AS bloqueado
FROM sag_usuarios_web;
8- Trabajamos la tabla intermedia para que no quede huecos en el contador de
ids.
4
INSERT INTO sag_tabla_usuarios_nuevos ( NIF, Apellidos, Nombre, tratamiento,
activo, pendiente_activacion, bloqueado )
SELECT sag_usuarios_web.dni AS Expr1, sag_usuarios_web.apellidos AS Expr2,
sag_usuarios_web.nombre AS Expr3, sag_usuarios_web.tratamiento AS Expr4, 1 AS activo, 0 AS pendiente_activacion, 0 AS bloqueado FROM
sag_usuarios_web;
9- Pasar docentes nuevos a la tabla docentes nuevos
INSERT INTO sag_tabla_usuarios_nuevos ( NIF, Apellidos, Nombre,
tratamiento, activo, pendiente_activacion, bloqueado )
SELECT DocentesNoRepetidos.NIF, DocentesNoRepetidos.Apellidos,
DocentesNoRepetidos.Nombre, DocentesNoRepetidos.PrimeroDeTratamiento, 1 AS
activo, 0 AS pendiente_activacion, 0 AS bloqueado
FROM DocentesNoRepetidos LEFT JOIN sag_usuarios_web ON DocentesNoRepetidos.NIF = sag_usuarios_web.dni
WHERE (((sag_usuarios_web.id) Is Null));
10- Consulta de comprobación para ver si los hemos importado todos los usuarios
correctamente.
SELECT sag_tabla_usuarios.id, sag_tabla_usuarios.NIF, sag_tabla_usuarios.Apellidos, sag_tabla_usuarios.Nombre,
sag_tabla_usuarios.tratamiento, sag_tabla_usuarios.activo,
sag_tabla_usuarios.pendiente_activacion, sag_tabla_usuarios.bloqueado
FROM sag_tabla_usuarios
WHERE (((sag_tabla_usuarios.NIF) Not In (select NIF from
sag_tabla_usuarios_nuevos)));
Con esto ya tenemos toda la información volcada en la nueva base de datos.
Valoración de pérdida de información.
Con este proceso de migración se mantiene la gran mayoría de la información a
excepción de la relación entre formación y actividad, cuando la actividad está
duplicada en ambas bases de datos.
1
Anexo VII: Manual para el docente
Acceso a la consulta del registro
Para acceder a la página de consulta de títulos registrados en el CeFIAME, acceda a
la dirección:
http://www.larioja.org/npRioja/default/defaultpage.jsp?idtab=745130
Los desde el CeFIAME recomendamos utilizar las últimas versiones de los
navegadores Mocilla Firefox y Chrome, aunque la página también soporta Internet
Explorer (versión 9 en adelante).
Introduzca su DNI, sin letra en el campo Usuario, y su contraseña en el campo
correspondiente. Teclee la secuencia de cinco números y letras que aparecen en la
imagen.
2
Consultas de formaciones
Consultar todo el historial de formaciones
Haga clic en “Todo el historial”
Aparecerá la lista de todas las formaciones registradas hasta la fecha, ordenadas de
más recientes a más antiguas.
Puede ordenar las formaciones por cualquier campo haciendo clic sobre su nombre.
En este ejemplo se ha ordenado la visualización de más a menos horas haciendo clic
sobre la palabra horas.
Puede imprimir la visualización actual de sus cursos haciendo clic en el botón.
NOTA: Tenga en cuenta que toda la información que consulte e imprima tiene un
carácter meramente informativo, sin ningún otro efecto.
3
Consultar todo el historial de formaciones
Haga clic en “Filtrar entre fechas”, si tiene dudas, haga clic en el botón “Ayuda”.
4
Cambiar clave o email
Haga clic en “Cambiar Email/clave”, si tiene dudas, haga clic en el botón “Ayuda”.
Recibirá un email confirmando el cambio de contraseña o email.
1
Anexo VIII: Manual para administrativos
Acceso al registro
Para acceder a la página de registro de títulos del CeFIAME, acceda a la dirección:
http://www.larioja.org/npRioja/default/defaultpage.jsp?idtab=745130
Los desde el CeFIAME recomendamos utilizar las últimas versiones de los
navegadores Mocilla Firefox y Chrome.
Introduzca su DNI, sin letra en el campo Usuario, y su contraseña en el campo
correspondiente. Teclee la secuencia de cinco números y letras que aparecen en la
imagen.
2
Registro de formaciones
La pantalla de registro de formaciones muestra tres opciones principales:
Búsqueda por actividad: permite realizar búsquedas de formaciones
pertenecientes a una actividad concreta.
Búsqueda por usuario: permite realizar búsquedas de formaciones
pertenecientes a un docente concreto.
Área de trabajo: Se activa cuando se presiona “Nuevo” y permite introducir
nuevos certificados. También muestra la información detallada de las
formaciones que se consultan en las otras dos pestañas.
Nuevas formaciones
Cuando se presiona “Nuevo” se muestra el área de trabajo vacía. Sólo hay que buscar
una actividad, un docente y un modo de participación. El resto de campos se rellenan
de manera automática cuando seleccionamos una opción.
Ahora se puede comenzar a registrar certificados, lo primero es elegir la fecha de
registro, que figurará en todos los certificados que emitamos en esta sesión.
3
Comience a teclear cualquier palabra de cualquier campo de la formación que quiere
introducir, por ejemplo “curso”.
En cuanto el sistema encuentre coincidencias (a partir de cuatro letras) le aparecerá
una pantalla emergente con el asistente de autocompletado.
4
Seleccione el curso del que quiere añadir formación y pulse cerrar o tecla “esc”. Se
autocompletarán todos los datos de la formación.
Dispone de tres opciones:
Editar, edita la formación modifica los datos de la formación de ahora en
adelante, los certificados ya emitidos conservarán los datos anteriores.
5
Añadir nuevo, añade la actividad a maestros y autocompleta los campos
Borrar datos, no borra la actividad, sino que limpia el certificado.
Los campos correspondientes al docente y al modo de participación funcionan de
manera análoga actividad.
Cuando rellene los tres apartados fundamentales el sistema le dejará registrar la
formación.
Generará un número de registro automático, y rellenará sus datos fundamentales en
base a la actividad de la que se introdujo
6
Si el registro está ya grabado aparecerá el mensaje “Registro de SOLO lectura” de la
siguiente manera:
Búsqueda de formaciones
Puede buscar en base a dos criterios fundamentales:
Búsqueda por actividad: permite realizar búsquedas de formaciones
pertenecientes a una actividad concreta.
Búsqueda por usuario: permite realizar búsquedas de formaciones
pertenecientes a un docente concreto.
Introduzca la cadena a buscar. El sistema buscará en cualquiera de los campos,
nombre, apellidos, dni…
7
El sistema mostrará un listado con los registros que coincidan con su búsqueda, podrá
desglosar los certificados por docente o por actividad.
Puede conocer todos los detalles de la formación haciendo doble clic sobre la que
desee.
Recuerde que no podrá modificar estas formaciones, ya que ya están registradas.
1
Anexo IX: Chuleta para desarrollar en Symfony
Arrancar servidor
php app/console server:run
php app/console server:stop
http://localhost:8000
http://localhost:8000/config.php
Composer
php composer.phar install
composer install
composer selfupdate
Cache
php app/cache cache:clear
php app/cache cache:clear --no-warmup
Assets
php app/console assets:install
php app/console assets:install --symlink
php app/console assets:install --symlink --relative
Esquemas
doctrine:generate:entity
doctrine:schema:update --dump -sql
doctrine:schema:update --force
doctrine:generate:crud
1
Anexo X: Actas
FECHA: 5 de febrero 2015
ACTA NÚMERO 1
ASISTENTES
Santos Agudo
Javier Rojas
COMUNICACIONES
Antecedentes del proyecto.
Planteamiento de situación actual.
Primera aproximación a los requisitos.
ACUERDOS
Planificación de seguimiento y reuniones.
o Reunión de seguimiento semanal todos los miércoles, a las 8:00.
o Estructura organizativa del proyecto.
Trabajo colaborativo, sin jefe de proyecto.
Integrantes del equipo de trabajo:
Santos Agudo.
Javier Rojas.
FIRMAS
Javier Rojas.
Responsable de proyecto.
2
FECHA: 5 de febrero 2015
ACTA NÚMERO 2
ASISTENTES
Juan José Olarte
Javier Rojas
COMUNICACIONES
Uso de la plataforma de TFG.
Concreción de entregables intermedios y finales.
Fechas de depósito y exposición del proyecto.
ACUERDOS
Planificación de seguimiento y reuniones.
o Comunicación semanal a través de entregables por medio de la
plataforma de TFG.
o Uso del email para concretar reuniones presenciales en caso de ser
necesario.
Presentar antes del 20 de febrero:
o Concreción de integrantes, antecedentes y objetivos generales del
proyecto.
o Análisis de requisitos.
o Estudio de alternativas y de viabilidad.
o Elección justificada de metodología y tecnologías. Planificación
inicial.
FIRMAS
Javier Rojas.
Responsable de proyecto.
FECHA: 11 de febrero 2015
3
ACTA NÚMERO 3
ASISTENTES
Santos Agudo
Javier Arza (Profesor de Inglés)-Participación puntual.
Javier Rojas
COMUNICACIONES
Presentación de:
o Formato de la memoria de proyecto.
o Resumen
o Introducción
Javier Arza corrige la traducción del resumen del proyecto
ACUERDOS
Santos Agudo propone correcciones en la introducción.
Se aceptan las correcciones.
Se concierta la siguiente reunión de seguimiento el miércoles 18 de febrero,
con el siguiente orden del día:
o Planificación y seguimiento.
o Análisis.
FIRMAS
Javier Rojas.
Responsable de proyecto.
4
FECHA: 18 de febrero 2015
ACTA NÚMERO 4
ASISTENTES
Santos Agudo
Javier Rojas
COMUNICACIONES
Presentación de:
o Informe comparativo de frameworks.
o Borrador de requisitos.
ACUERDOS
Utilizar como framework Synfony2.
Modificar algunos requisitos.
Se aplaza a la siguiente reunión la presentación de:
o Planificación y seguimiento.
o Análisis.
FIRMAS
Javier Rojas.
Responsable de proyecto.
5
FECHA: 25 de febrero 2015
ACTA NÚMERO 5
ASISTENTES
Santos Agudo
Javier Rojas
COMUNICACIONES
Presentación de:
o Planificación y seguimiento.
o Análisis.
ACUERDOS
o Se aprueba la planificación y seguimiento.
o Se aprueba el análisis.
FIRMAS
Javier Rojas.
Responsable de proyecto.
6
FECHA: 4 de marzo 2015
ACTA NÚMERO 6
ASISTENTES
Santos Agudo
Javier Rojas
COMUNICACIONES
Formación en Symfony (3 horas)
o Primeros pasos con Symfony.
ACUERDOS
Documentar el proceso de configuración y puesta en marcha del entorno de
trabajo: PhpStorm + Symfony y presentar para la siguiente reunión.
FIRMAS
Javier Rojas.
Responsable de proyecto.
7
FECHA: 11 de marzo 2015
ACTA NÚMERO 7
ASISTENTES
Santos Agudo
Javier Rojas
COMUNICACIONES
Formación en Symfony (1 hora)
o Proyectos en Symfony.
Presentación de documentación del proceso de configuración y puesta en
marcha del entorno de trabajo.
ACUERDOS
Aprobación de la documentación del proceso de configuración y puesta en
marcha del entorno de trabajo.
FIRMAS
Javier Rojas.
Responsable de proyecto.
8
FECHA: 18 de marzo 2015
ACTA NÚMERO 8
ASISTENTES
Santos Agudo
Javier Rojas
COMUNICACIONES
Formación en Symfony (1 hora)
o Proyectos en Symfony.
Presentación del diagrama de clases.
FIRMAS
Javier Rojas.
Responsable de proyecto.
9
FECHA: 25 de marzo 2015
ACTA NÚMERO 9
ASISTENTES
Noelia y José Ramón (Administrativos)
Javier Rojas
COMUNICACIONES
Presentación de bocetos de la interfaz.
Presentación de diagrama de navegación.
ACUERDOS
Modificaciones en la interfaz de introducción de certificados.
Aprobación de los bocetos de la interfaz y del diagrama de navegación.
FIRMAS
Javier Rojas.
Responsable de proyecto.
10
FECHA: 22 de abril 2015
ACTA NÚMERO 10
ASISTENTES
Noelia y José Ramón (Administrativos)
Santos Agudo
Javier Rojas
COMUNICACIONES
Presentación del análisis de las bases de datos del antiguo registro ANEXO V.
Presentación del plan de migración.
Justificación de la recomendación de utilizar la base de datos de entidades
externas como base para la migración
ACUERDOS
Utilizar la base de datos de entidades externas como base para la migración.
Aceptación de pérdida residual de información descrita en ANEXO VI
FIRMAS
Javier Rojas.
Responsable de proyecto.
11
FECHA: 21 de mayo 2015
ACTA NÚMERO 11
ASISTENTES
Noelia y José Ramón (Administrativos)
Santos Agudo
Javier Rojas
COMUNICACIONES
Presentación de la aplicación finalizada.
Presentación del manual para administrativos (Anexo IX).
Justificación de pequeñas modificaciones en la interfaz respecto del diseño.
Presentación del plan de pruebas durante el uso paralelo del antiguo y nuevo
registro.
ACUERDOS
Aceptación de la aplicación.
Modificar simplificar y reducir el manual para administrativos.
Aceptación del plan de pruebas.
FIRMAS
Javier Rojas.
Responsable de proyecto.