TRABAJO FIN DE GRADO. Ampliación de la aplicación de realización de prácticas de bases de datos

TRABAJO FIN DE GRADO Título Ampliación de la aplicación de realización de prácticas de bases de datos Autor/es Juan Francisco Diez Léglise Director/es Francisco José García Izquierdo Facultad Facultad de Ciencias, Estudios Agroalimentarios e Informática Titulación Grado en Ingeniería Informática Departamento Curso Académico 2013-2014

Ampliación de la aplicación de realización de prácticas de bases de datos, trabajo fin de grado de Juan Francisco Diez Léglise, dirigido por Francisco José García Izquierdo (publicado por la Universidad de La Rioja), se difunde bajo una Licencia Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los titulares del copyright. El autor Universidad de La Rioja, Servicio de Publicaciones, 2014 publicaciones.unirioja.es E-mail: publicaciones@unirioja.es

FACULTAD DE CIENCIAS, ESTUDIOS AGROALIMENTARIOS E INFORMÁTICA TRABAJO FIN DE GRADO GRADO EN INGENIERÍA INFORMÁTICA A AMPLIACIÓN DE LA APLICACIÓN DE REALIZACIÓN DE PRÁCTICAS DE BASES DE DATOS Autor: Juan-Francisco Diez Léglise Director: Francisco José García Izquierdo S Septiembre 2014

CONTENIDO CONTENIDO Contenido... 3 Resumen... 7 Abstract... 9 1 Contexto del proyecto... 11 2 Alcance... 13 2.1 Ingeniería Inversa... 13 2.2 Denegación de servicio... 13 2.3 Mejoras de la aplicación... 14 2.3.1 Funcionalidad de prueba de ejercicios... 14 2.3.2 Desbloqueo de sesiones... 14 2.3.3 Reinicio de una sesión de prácticas... 14 2.3.4 Control de las sesiones de repaso... 15 3 Gestión del Trabajo Fin de Grado... 17 3.1 Estructura de descomposición del trabajo... 17 3.2 planificación... 20 3.3 Seguimiento del trabajo... 22 3.3.1 Reuniones... 22 3.3.2 Gestión de cambios... 23 3.4 Metodología de desarrollo... 25 4 Ingeniería Inversa... 27 4.1 Tecnologías... 27 4.1.1 Spring y Struts2... 27 4.1.2 Maven... 29 4.1.3 Tiles... 30 4.1.4 Hibernate... 30 4.1.5 Bootstrap, jqgrid y Codemirror... 30 4.2 Estructura de la aplicación... 31 5 Denegación de servicio... 35 5.1 Configuración de las reglas de mitigación... 35 5.1.1 Análisis... 36 5.1.2 Diseño e implementación... 40 AMPLIACIÓN DE LA APLICACIÓN DE REALIZACIÓN DE PRÁCTICAS DE BASES DE DATOS 3

CONTENIDO 5.1.3 Despliegue... 43 5.1.4 Pruebas... 44 5.2 Panel de control DoS... 45 5.2.1 Análisis... 45 5.2.2 Diseño e implementación... 46 6 Mejoras de la aplicación... 53 6.1 Funcionalidad de prueba de ejercicios... 53 6.1.1 Análisis... 53 6.1.2 Diseño e implementación... 53 6.1.3 Pruebas... 55 6.2 Desbloqueo de sesiones... 55 6.2.1 Análisis... 55 6.2.2 Diseño e implementación... 55 6.2.3 Pruebas... 56 6.3 Reinicio de una sesión de prácticas... 57 6.3.1 Análisis... 57 6.3.2 Diseño e implementación... 58 6.3.3 Pruebas... 59 6.4 Control de las sesiones de repaso... 59 6.4.1 Análisis... 59 6.4.2 Diseño e implementación... 60 6.4.3 Pruebas... 67 6.5 Despliegue... 67 7 Conclusiones... 69 7.1 Con respecto a la realización del trabajo... 69 7.2 Con respecto a los objetivos académicos... 69 7.3 Líneas futuras... 70 7.3.1 Wsdmcadmin... 70 7.3.2 Aplicacionbd... 71 Bibliografía... 73 Libros... 73 Sitios web... 73 Artículos, tutoriales... 73 Anexo I - Reuniones... 75 Anexo II Manual de usuario wsdmcadmin... 79

CONTENIDO Instalación... 79 Gestión de usuarios... 80 Gestión DoS... 81 Reglas Configuradas... 81 IPs Detectadas... 82 Lista Negra... 82 Anexo III manual de usuario de la aplicación de prácticas de Bases de Datos... 85 Gestión de Ejercicios... 85 Creación/Modificación de un ejercicio... 85 Panel profesor... 86 Gestión de Repasos... 87 AMPLIACIÓN DE LA APLICACIÓN DE REALIZACIÓN DE PRÁCTICAS DE BASES DE DATOS 5

RESUMEN RESUMEN Este Trabajo Fin de Grado (en adelante TFG) es una continuación del anterior de D. Diego Díez Ricondo con el que pretendo seguir mejorando la aplicación para las prácticas de la asignatura de Bases de Datos (Grado en Ingeniería Informática - 1º Curso - Código 824). Las líneas del proyecto pretenden hacerla más robusta y ofrecer al profesor más funcionalidad de control sobre la resolución y creación de ejercicios, así como en el control de las sesiones prácticas y de repaso de la asignatura. Ambas líneas de trabajo fueron sugeridas por los profesores de la asignatura. La primera de ellas, la robustez, apareció ya que se observaron problemas de estabilidad del servidor que albergaba la aplicación. Para mitigar estos problemas se analizan los registros del servidor para averiguar las causas que hacen que este sea inestable y aportar las soluciones apropiadas. En este sentido, se desarrolla una herramienta que permita prevenir ataques de tipo de denegación de servicio (en adelante DoS). La segunda línea de trabajo pretende mejorar la interacción del profesor con la aplicación y solucionar algún problema detectado en la misma. En esta parte del TFG entra en juego la ingeniería inversa dónde se ha tenido que asimilar tanto las tecnologías como la estructura empleadas en la aplicación. A partir esta ingeniería inversa, desarrollamos las mejoras de la aplicación (funcionalidad de prueba de nuevos ejercicios, desbloqueo de sesiones, reinicio de una sesión de prácticas y control de la sesiones de repaso). Esta secuencia de tareas permite conservar la calidad del software existente. AMPLIACIÓN DE LA APLICACIÓN DE REALIZACIÓN DE PRÁCTICAS DE BASES DE DATOS 7

ABSTRACT ABSTRACT In line with the end-of-degree project of D. Diego Diez Ricondo, we pretend to improve the web application for the Databases course (Computer Science Degree - 1º Year - Code 824). The project achieve is to make the application more robust and offer to the teacher more functionality to exercises resolution and creation, and although to course practice session control. Both lines of investigation were suggested by the course teachers. First of all, robustness topic appears during the last course when teachers observed availability issues on the web server. To solve this problems, we trace the server logs to find the origin of the failures and provide appropriates solutions. In that way, we configure a newly server, acquired by the Department of Mathematics y Computing, and we also create a tool to prevent Denial of Service (DoS) attacks. The second line tries to boost the teacher interaction with the web application and solve some trouble we detected. In this part, we made web reverse engineering assuming technologies and program structure used by the application. From this reverse engineering, we develop the new functionalities of the web application (new functionality to test new exercises, session unlock, practice session reset and control of review session). This sequence of tasks allows for maintaining the current code quality. AMPLIACIÓN DE LA APLICACIÓN DE REALIZACIÓN DE PRÁCTICAS DE BASES DE DATOS 9

CAPÍTULO 1 CONTEXTO DEL PROYECTO 1 CONTEXTO DEL PROYECTO Como versa el título, este Trabajo Fin de Grado (en adelante TFG) trata de mejorar la aplicación utilizada en la asignatura de Bases de Datos del Grado en Ingeniería Informática de la Universidad de La Rioja impartida durante el primer curso. Dicha aplicación fue desarrollada por D. Diego Díez Ricondo. La primera versión fue presentada en el año 2010 con ocasión del Proyecto Fin de Carrera y fue evolucionando hasta la versión actual presentada en el año 2013 durante la defensa del TFG. Si atendemos a la guía docente de la asignatura de Bases de Datos, el objetivo principal de la misma es el conocimiento y dominio del lenguaje SQL permitiendo así al alumno crear y manipular bases de datos relacionales. La aplicación ha permitido que los alumnos se centren a nivel de prácticas en este objetivo abstrayéndolos de las tareas de instalación de los distintos Sistemas de Gestión de Bases de Datos (en adelante SGBD). Pero no todo es para el alumno. La aplicación ha permitido a los profesores mejorar el desarrollo de las clases prácticas. En efecto el profesor puede manejar desde la aplicación todos los elementos que intervienen desde los esquemas de las bases de datos hasta la planificación de las sesiones prácticas para cada grupo. Como añadido permite proponer a los alumnos ejercicios de repaso para que los puedan realizar desde su casa permitiéndoles afianzar tanto los conceptos teóricos como los prácticos. La evolución de la primera versión a la segunda no es un simple lavado de cara a nivel de la interfaz de usuario sino que se han recogido las experiencias vividas por los profesores para realizar una mejora sustancial en el funcionamiento de la misma. En este sentido cabe destacar el módulo de análisis del lenguaje SQL que permite ofrecer ayuda activa a los alumnos mientras tratan de resolver los ejercicios. Es decir, se ha tratado de ofrecer al alumno un tutor inteligente, que no trata de sustituir al profesor, que permita al alumno mediante el análisis y la reflexión llegar a una solución adecuada para el ejercicio propuesto. Sin embargo el esfuerzo realizado en la interfaz de usuario permite ofrecer tanto al alumno como al profesor de una experiencia más agradable y para ello se han utilizado las últimas tecnologías existentes (JQuery, Ajax, Tiles, ). Dicha aplicación se ha venido utilizando durante el desarrollo de los cursos académicos que van desde el 2010 hasta el 2013. La primera versión se instaló en un servidor, que disponía el departamento de Matemáticas y Computación: yaiza.unirioja.es. Este servidor utiliza un sistema Windows Server para ofrecer multitud de servicios entre los que se encuentran el servidor de aplicaciones Tomcat, los servidores de bases de datos MySQL y Microsoft SQL Server y alguna otra herramienta necesaria para la administración del mismo. Durante los distintos cursos académicos, se observaron multitud de problemas de estabilidad del servidor sin llegar a una conclusión sobre el causante del problema. AMPLIACIÓN DE LA APLICACIÓN DE REALIZACIÓN DE PRÁCTICAS DE BASES DE DATOS 11

CAPÍTULO 2 ALCANCE 2 ALCANCE El trabajo consta de varias fases. La primera nos permitirá estudiar la estructura y las tecnologías implantadas en la aplicación. Al final de esta fase tendremos un conocimiento profundo de la aplicación. La segunda trata de solucionar la inestabilidad observada en el servidor anterior (yaiza.unirioja.es). El objetivo de esta fase es asegurar la disponibilidad del servicio. En una tercera fase se aportan mejoras a la nueva versión de la aplicación realizada por D. Diego Diez Ricondo. Estas mejoras provienen de las sugerencias de los profesores de la asignatura y tratan fundamentalmente de aumentar la interacción del profesor con la aplicación. 2.1 INGENIERÍA INVERSA Al realizar una reingeniería de una aplicación, es inevitable realizar un proceso de ingeniería inversa aunque en este caso se parte del código fuente de la aplicación. Por lo tanto en esta fase se estudiarán tanto las tecnologías como la estructura de la aplicación. Cabe destacar la necesidad de formación en muchas de las tecnologías que se usan en la aplicación. Además de ellas aprenderemos en gran parte cómo se ha estructurado la aplicación. 2.2 DENEGACIÓN DE SERVICIO En esta fase se creará un producto software independiente en el cuál se solucionarán alguna de las posibles causas de inestabilidad. En particular se mitigarán ataques de tipo DoS 1. La herramienta requerirá de un acceso controlado a la misma teniendo en cuenta que la aplicación resultante trabajará a nivel de administración del servidor web. Para integrar una seguridad mínima se implementarán las técnicas necesarias para asegurar que en ningún momento los datos de los usuarios estén disponibles en texto plano. La herramienta de control de ataques DoS asegurará no sólo que no se realicen dichos ataques a la aplicación sino a otros servicios que se puedan implementar en el servidor. Esto incluye por lo tanto la posibilidad de crear nuevas reglas para nuevos servicios que pueda ofrecer el servidor. La herramienta de control de ataques DoS permitirá añadir o eliminar a los causantes de dichos ataques en el cortafuegos del servidor para denegar o permitir, respectivamente, el tráfico proveniente de dichos ataques. Estas acciones las realizarán los administradores de la herramienta aplicando los criterios que estimen necesarios. Para la acción de añadir el causante de un ataque en el cortafuegos, se preverá una automatización para que la aplicación por si misma pueda denegar el tráfico de este. 1 Ver el capítulo 5, Denegación de servicio AMPLIACIÓN DE LA APLICACIÓN DE REALIZACIÓN DE PRÁCTICAS DE BASES DE DATOS 13

CAPÍTULO 2 ALCANCE 2.3 MEJORAS DE LA APLICACIÓN Los profesores de la asignatura han detectado la falta de ciertas funcionalidades y problemas respecto a las sesiones de los alumnos, las cuales se quedaban "colgadas" bajo ciertas circunstancias. En esta fase del proyecto se dan soluciones a un conjunto de peticiones realizada por los profesores. Estas mejoras deben aumentar la funcionalidad de la aplicación sobre todo respecto al profesor. En efecto, a la finalización de este TFG, el profesor podrá gestionar de manera más eficiente tanto las prácticas pertenecientes a la asignatura como las sesiones de repaso voluntarias de los alumnos. Dentro de estas mejoras se eligieron las que más se necesitaban para un desarrollo satisfactorio de la asignatura: Funcionalidad para que el profesor pueda probar los resultados de los nuevos ejercicios creados Una solución para desbloquear las sesiones de los alumnos Una herramienta en la interfaz de la aplicación que permita borrar los resultados de una sesión de prácticas de un alumno para que pueda reiniciarla Nuevas funcionalidades para que las sesiones de repaso sean grabadas para a posteriori poder realizar un análisis estadístico sobre los datos. 2.3.1 FUNCIONALIDAD DE PRUEBA DE EJERCICIOS La funcionalidad se incluirá en el formulario de creación y edición de un ejercicio. Deberá, al estilo de lo que ocurre con la realización de ejercicios del alumno, presentar en una tabla los resultados de la consulta. 2.3.2 DESBLOQUEO DE SESIONES En algunas ocasiones los alumnos no pueden realizar la sesión práctica por encontrarse bloqueados en la realización de otra sesión. En este caso se automatizará el control de realizaciones prácticas asegurando que el alumno pueda realizar la sesión práctica presencial. Para este punto no se realizará ninguna herramienta de tipo gráfica al ser el proceso totalmente automático. 2.3.3 REINICIO DE UNA SESIÓN DE PRÁCTICAS Debido al solapamiento de presentación de las prácticas entre grupos consecutivos en el horario de clases, puede ocurrir que un alumno inicie una sesión de prácticas sin que esta corresponda a la de su grupo de prácticas (por ejemplo, porque haya entrado antes de hora en el grupo de prácticas anterior). Esto repercute en el correcto funcionamiento de las prácticas presenciales, donde cada grupo de prácticas realiza ejercicios distintos, ya que el alumno no podía realizar los ejercicios de su grupo. En este caso se realizará un añadido al panel del profesor para que este pueda reiniciar una sesión de prácticas para un alumno determinado. Este reinicio implica el borrado de los ejercicios realizados erróneamente. Todos los datos de la sesión borrada serán enviados al alumno para que las pueda conservar o aprovechar para la resolución de ejercicios.

CAPÍTULO 2 ALCANCE 2.3.4 CONTROL DE LAS SESIONES DE REPASO Actualmente las sesiones de repaso no generan ningún dato que pueda ser analizado o aprovechado por los profesores de la asignatura para la reflexionar sobre la docencia de la misma. En esta mejora se almacenarán todos los datos relacionados con las sesiones de repaso. Se realizará una herramienta gráfica aprovechable para las posibles tutorías que estos ejercicios puedan generar facilitando al profesor la consulta de lo que el alumno ha hecho con anterioridad. Por expreso deseo de los clientes, la herramienta no integrará ninguna facilidad de exportación de datos o de realización de informes de los datos almacenados. Estas acciones se realizarán mediante un acceso directo a las tablas de la base de datos. AMPLIACIÓN DE LA APLICACIÓN DE REALIZACIÓN DE PRÁCTICAS DE BASES DE DATOS 15

CAPÍTULO 3 GESTIÓN DEL TRABAJO FIN DE GRADO 3 GESTIÓN DEL TRABAJO FIN DE GRADO En este apartado se presentará las fases de planificación y control de las distintas etapas del proyecto. El parámetro fundamental de control del proyecto será el tiempo máximo de realización del mismo representado por las 300 horas correspondientes a los créditos de la asignatura según el plan de estudio vigente sin menospreciar la calidad ni la corrección del mismo. 3.1 ESTRUCTURA DE DESCOMPOSICIÓN DEL TRABAJO Para poder realizar una planificación adecuada, lo primero que realizaremos será la descomposición del trabajo (en adelante EDT) a realizar. En la siguiente imagen se pueden ver todas las partes del mismo: Ilustración 1 - Estructura de descomposición del trabajo En cada tarea de las pertenecientes a 7/R111/801G-3 Ingeniería Inversa y 7/R111/801G-4 Mejoras en la aplicación se subdividirán en las ya típicas de análisis, diseño, implementación, despliegue y pruebas. AMPLIACIÓN DE LA APLICACIÓN DE REALIZACIÓN DE PRÁCTICAS DE BASES DE DATOS 17

CAPÍTULO 3 GESTIÓN DEL TRABAJO FIN DE GRADO Para poder entender este diagrama, expondremos el diccionario de la EDT. Código Nombre Descripción 7/R111/801G-1 7/R111/801G-1.1 7/R111/801G-1.2 7/R111/801G-1.3 7/R111/801G-1.4 7/R111/801G-1.5 7/R111/801G-1.6 Dirección del TFG Análisis Previo Planificación Reuniones Seguimiento y Control Calidad Gestión de Cambios Análisis inicial que surge de las reuniones con el tutor del proyecto y con los clientes. Permite realizar la planificación de una manera más real ya que se define el alcance del TFG. En este paquete de trabajo se integra la definición de los roles del equipo, la realización del EDP, la descripción y estructura de los entregables, la definición de las actividades a realizar, la estimación temporal de las actividades, el diagrama de hitos y el diagrama de Gantt. Se integran también apartados sobre herramientas de comunicación, gestión de cambios, gestión de la calidad e identificación de riesgos del proyecto. Recoge todas las reuniones. Todas se documentarán con una convocatoria que será comunicada con antelación suficiente para la correcta preparación y su acta correspondiente aprobada por los asistentes. Se incluye el estado del TFG así como las posibles incidencias ocurridas durante el mismo. Se incluyen las actualizaciones de la herramienta del departamento. Se gestionará la calidad de proyecto definiendo en un primer momento la lista de requisitos de cada producto y posteriormente realizando el seguimiento del cumplimiento de estos requisitos de calidad. Al ocurrir una petición de cambio sobre el alcance del proyecto, se tomará la decisión de aceptar el cambio o no (interno o externo). Este proceso quedará documentado para obtener una trazabilidad de los cambios. 7/R111/801G-2 Ingeniería Inversa Se estudiarán todas las tecnologías así como la estructura de la aplicación para llegar a una comprensión profunda del desarrollo de la misma. 7/R111/801G-3 Denegación de Servicio

CAPÍTULO 3 GESTIÓN DEL TRABAJO FIN DE GRADO Código Nombre Descripción 7/R111/801G-3.1 7/R111/801G-3.2 7/R111/801G-4 Configuración de Reglas de Mitigación Panel de Control de DOS Mejoras en la aplicación Se realizarán pruebas para obtener las reglas más adecuadas para la mitigación de la denegación de servicios. Se evaluará el número de peticiones por segundos que puedan venir de una determinada IP. El producto final consistirá en un panel de control donde queden reflejadas las IPs que han hecho saltar la regla definida en el anterior apartado. Los profesores podrán eliminar las IPs de la lista negra que generará la regla de mitigación. 7/R111/801G-4.1 Botón de prueba Se añadirá un botón para la prueba de los ejercicios nuevos y también de los editados. 7/R111/801G-4.2 Desbloqueo de sesiones Se mejorará la gestión de las sesiones de tal forma que no existan realizaciones prácticas pendientes de una sesión a otra. 7/R111/801G-4.3 Reinicio de la sesión Se añadirá una acción para que a criterio del profesor el alumno pueda volver a realizar una sesión práctica. 7/R111/801G-4.4 7/R111/801G-5 7/R111/801G-5.1 7/R111/801G-5.2 Control de las sesiones de repaso Documentación del TFG Realización de la Memoria Presentación del Producto Se implementarán los artilugios necesarios para obtener todos los datos de las sesiones de repaso. La memoria es un entregable del TFG y por lo tanto se prestará especial atención a los formatos del mismo así como su corrección (tanto gramática como técnica). Para realizar la defensa del TFG, se creará una presentación de los trabajos realizados. 7/R111/801G-5.3 Grabación de CDs Se grabará la documentación y el producto final en soporte digital Tabla 1 - Diccionario de la EDT AMPLIACIÓN DE LA APLICACIÓN DE REALIZACIÓN DE PRÁCTICAS DE BASES DE DATOS 19

CAPÍTULO 3 GESTIÓN DEL TRABAJO FIN DE GRADO 3.2 PLANIFICACIÓN Para la planificación, tal y como se ha mencionado anteriormente, se tendrá en cuenta la limitación en horas definida en la guía docente del TFG. Teniendo en cuenta la extensión del diagrama de Gantt resultante, se ha decidido presentarlo primero en su extensión completa con las fases principales del mismo para después presentar el detalle de cada fase haciéndolo más legible. El inicio del proyecto se fecha en la primera semana de Febrero y la finalización del mismo en la última semana de Julio. La dedicación diaria al proyecto se acota a 4 horas de lunes a viernes. Esto representa una duración total de 15 semanas. Teniendo en cuenta el calendario académico la fecha final del trabajo se situaría en la última semana de Mayo. Debido a mis responsabilidades profesionales existentes se ampliará el plazo de finalización del proyecto para terminarlo en la última semana de Julio.

CAPÍTULO 3 GESTIÓN DEL TRABAJO FIN DE GRADO Ilustración 2 - Diagrama de Gantt del trabajo AMPLIACIÓN DE LA APLICACIÓN DE REALIZACIÓN DE PRÁCTICAS DE BASES DE DATOS 21

CAPÍTULO 3 GESTIÓN DEL TRABAJO FIN DE GRADO 3.3 SEGUIMIENTO DEL TRABAJO En un trabajo con limitaciones temporales y cumplimientos de objetivos, es fundamental gestionar el seguimiento del mismo. Este seguimiento persigue varios objetivos que deben ser comunes a cualquier proyecto: tiempo, coste y calidad. El seguimiento del trabajo nos ha permitido reajustar cualquiera de estos parámetros ante un incidente del mismo. Para ello se han tenido que identificar los riesgos del mismo. Con la limitación de tiempo de un TFG, se ha tenido que sacrificar una parte del control de calidad del proyecto limitándolo al control de calidad del código generado. Aún así dicho control de calidad se ha reducido al mínimo para cumplir con el alcance expuesto en el capítulo anterior. 3.3.1 REUNIONES Se han realizado varias reuniones durante el transcurso del proyecto. Se pueden distinguir dos tipos: reuniones con el tutor y reuniones con el cliente. Las primeras se han venido realizando periódicamente de una manera informal debido a mi presencia diaria en las actividades del departamento con motivo de la realización de una beca del mismo. Esta particularidad de cercanía con el tutor ha permitido que la comunicación fuese fluida y casi instantánea. En todo momento mi tutor de TFG conocía el estado del proyecto y las incidencias del mismo. Para apoyar estas reuniones informales, se han creado documentos intermedios con dos objetivos fundamentales: el primero es disponer de documentos intermedios para que perduren durante la realización del proyecto y el segundo adelantar la redacción de esta memoria para así minimizar el tiempo asignado. Por el contrario las reuniones con los clientes se han venido desarrollando bajo el formato tradicional. Teniendo en cuenta que dichas reuniones implicaban varias personas, lo primero que se hizo fue mandar una convocatoria de reunión con todos los datos necesarios para su realización. En el transcurso de las mismas se apuntaban los acuerdos a los que se han llegado. Esto permitió realizar las actas de reunión que pueden ver en el anexo I.

CAPÍTULO 3 GESTIÓN DEL TRABAJO FIN DE GRADO 3.3.2 GESTIÓN DE CAMBIOS A lo largo del proyecto han surgido modificaciones en el alcance que nos han hecho modificar la estimación temporal del mismo. En efecto, en un primer momento, dentro de las mejoras en la aplicación, evaluamos la realización de un módulo de detección de copiado. Este módulo iba a permitir a los profesores de la asignatura detectar los posibles plagios de los alumnos. La utilización del módulo tenía un objetivo didáctico ya que el fin perseguido por la asignatura es el aprendizaje del lenguaje SQL. No se perseguía como meta la sanción de los alumnos sino una mejor acción tutelar de los mismos. Lo primordial en la toma de decisiones respecto a lo que se iba a hacer para mejorar la aplicación fue priorizar lo que realmente era necesario para impartir lo mejor posible la asignatura. Sin embargo se realizó un primer análisis de viabilidad del módulo de detección de copia con la ayuda de documentos 2 y trabajos 3 realizados en esta área aunque la mayoría se centrasen en la detección de plagio en documentos y no en un lenguaje como SQL. Esto implica que se tuvo que remodelar la planificación del proyecto para mantener los plazos de tiempo y calidad ya que la variable de coste en un TFG no existe. Como resultado se obtuvo la planificación expuesta en el apartado Planificación. El resultado del seguimiento de esta planificación se puede observar en la siguiente tabla: 2 Detecting near-duplicate documents using sentence-level features and supervised learning - Yung-Shen Lin, Ting-Yi Liao, Shie-Jue Lee Elsevier 2012 Detection of Source Code Similitude in Academic Environments - ANDRÉS M. BEJARANO, LUCY E. GARCÍA, EDUARDO E. ZUREK - Universidad del Norte, Colombia 2012 Detección automática de plagio: de la copia exacta a la paráfrasis - Alberto Barrón-Cedeño, Marta Vila y Paolo Rosso Universidad Politécnica de Valencia, Universidad de Barcelona - 2010 3 ONLINE ASSESSMENT AND CHECKING OF SQL: DETECTING AND PREVENTING PLAGIARISM Gordon Russell, Andrew Cumming Napier University 2005 IMPROVING THE STUDENT LEARNING EXPERIENCE FOR SQL USING AUTOMATIC MARKING - Gordon Russell, Andrew Cumming Napier University 2004 Efficient Near Duplicate Document Detection for Specialized Corpora Shreyes Seshasai MIT - 2009 AMPLIACIÓN DE LA APLICACIÓN DE REALIZACIÓN DE PRÁCTICAS DE BASES DE DATOS 23

CAPÍTULO 3 GESTIÓN DEL TRABAJO FIN DE GRADO Código EDT Nombre Estimado Real % consumido 7/R111/801G-1 Dirección del TFG 7/R111/801G-1.1 Análisis Previo 2:00 2:30 125,00% 7/R111/801G-1.2 Planificación 5:30 5:15 95,45% 7/R111/801G-1.3 Reuniones 9:00 9:45 108,33% 7/R111/801G-1.4 Seguimiento y Control 10:00 11:15 112,50% 7/R111/801G-1.5 Calidad 3:30 4:30 128,57% 7/R111/801G-1.6 Gestión de Cambios 6:00 6:45 112,50% 7/R111/801G-2 Ingeniería Inversa 54:00 58:00 107,41% 7/R111/801G-3 Denegación de Servicio 7/R111/801G-3.1 Configuración de Reglas de Mitigación 20:00 20:20 101,67% 7/R111/801G-3.2 Panel de Control DOS 40:00 44:40 111,67% 7/R111/801G-4 Mejoras de la aplicación 7/R111/801G-4.1 Botón de prueba de ejercicios 14:00 14:15 101,79% 7/R111/801G-4.2 Desbloqueo de sesiones 12:00 12:30 104,17% 7/R111/801G-4.3 Reinicio de la sesión 36:00 35:30 98,61% 7/R111/801G-4.4 Control de las sesiones de repaso 70:00 72:40 103,81% 7/R111/801G-5 Documentación del TFG 18:00 19:30 108,33% Total 300:00 317:25 105,81% Tabla 2 - Seguimiento de la planificación temporal En general, las estimaciones de tiempos se han ido cumpliendo con leves desviaciones al alza. En total del trabajo, se ha desviado el cumplimiento de tiempo en 17,42 horas (5,81%). Consideramos esta desviación como aceptable dentro de un trabajo de esta magnitud ya que no supera el 10%.

CAPÍTULO 3 GESTIÓN DEL TRABAJO FIN DE GRADO 3.4 METODOLOGÍA DE DESARROLLO Aunque las metodologías Ágiles como Scrum están muy de moda, para este tipo de proyecto cuyo equipo de desarrollo se limita a una persona, se ha estimado que estas metodologías no se adaptan suficientemente bien. Por lo tanto se ha optado por utilizar una metodología más tradicional como la iterativa incremental. A final de cada incremento se obtiene una nueva funcionalidad que se puede desplegar y probar por tener entidad suficiente para ello. Esta metodología permite asimismo que en cada nuevo incremento se pueda iterar sobre los incrementos anteriores. Está metodología se adapta perfectamente a equipos con un solo desarrollador y por lo tanto es la elegida. En cada iteración se han ido realizando las fases habituales del desarrollo de software: Análisis, Diseño, Implementación, Despliegue y Pruebas. Como es habitual para un trabajo de desarrollo de software, se ha usado Git como programa para el control de versiones. La finalidad de la utilización de un control de versiones es que en caso de incidente con el puesto dónde se desarrolla el trabajo se dispongo de un punto de recuperación y que se pueda volver hacia atrás en caso necesario. Además el control de versiones es un punto importante para la generación de la documentación ya que podemos ver cualquier modificación realizada. AMPLIACIÓN DE LA APLICACIÓN DE REALIZACIÓN DE PRÁCTICAS DE BASES DE DATOS 25

CAPÍTULO 4 INGENIERÍA INVERSA 4 INGENIERÍA INVERSA Para poder cumplir con los objetivos del proyecto, primero analizaremos las tecnologías y la estructura de la aplicación de realización de ejercicios de la asignatura de Bases de Datos. Al heredar una aplicación también se limita las elecciones de tecnologías y estructuración de paquetes y clases. Sin embargo se presenta un reto de asimilación de toda la información para poder mantener ambas características. 4.1 TECNOLOGÍAS Tal y como aparece en la memoria del TFG de D. Diego Díez Ricondo, las tecnologías utilizadas para la aplicación son numerosas. Exponemos a continuación la lista de las mismas: Frameworks MVC Java: Spring y Struts2 Gestión de dependencias y creación de proyectos: Java Maven Framework de plantillas para las vistas: Tiles ORM: Hibernate Gestión de logs con: Log4j Pool de conexiones: Druid Framework HTML, CSS y Javascript: Bootstrap Editor SQL: Codemirror Parser SQL: AkibanSQL Contenedor web: Tomcat Presentación de resultados de bases de datos: jqgrid Dada la amplitud de tecnologías utilizadas, al planificar la fase de reingeniería, tuvimos que elegir las tecnologías que se iban a necesitar para optimizar la formación en las mismas. Asimismo, y dada la experiencia profesional adquirida, algunas de estas tecnologías ya eran conocidas. A continuación se esgrimirán algunas pinceladas de los estudios realizados para así entender mejor las decisiones tomadas en la realización de las demás partes de este TFG. Las tecnologías que no aparecen a continuación son o bien conocidas o no utilizadas para el trabajo realizado. 4.1.1 SPRING Y STRUTS2 Spring es un framework amplísimo que no está centrado únicamente en dar solución al patrón MVC. En efecto Spring pretende abarcar todo el desarrollo de aplicaciones empresariales entre las cuales se encuentran las aplicaciones web. En este proyecto se utiliza Spring en conjunción con un framework totalmente dedicado al desarrollo web con MVC como Struts2. Por lo tanto es crucial saber qué papel juegan ambos dentro de la aplicación. En el caso de Spring, este es usado esencialmente como gestor de las inyecciones de dependencias. En efecto, cualquier framework actual que se precie implementa la inyección de dependencias de clases. Esta técnica se basa en el uso de patrones, en este caso el patrón Singleton, y permite evitar la creación de objetos explícita lo que facilita la creación de código. Basta con crear la propiedad en un objeto que tenga AMPLIACIÓN DE LA APLICACIÓN DE REALIZACIÓN DE PRÁCTICAS DE BASES DE DATOS 27

CAPÍTULO 4 INGENIERÍA INVERSA como tipo otro objeto listo para ser inyectado. Es fundamental plantear bien la inyección de dependencias antes de desarrollar el código para no llegar a problemas de referencias circulares. Además se usan también las anotaciones para gestionar más eficazmente la aplicación. Estos dos puntos resultan de vital importancia para posteriormente entender el código de la aplicación. En el caso de Struts2, que se beneficia de las facilidades de Spring, se aprovecha la estructuración en el desarrollo de aplicaciones web Java. Para entender el código debe quedar muy claro cómo trabaja Struts2. Este framework nos facilita el front controller por lo que en el desarrollo de una aplicación todo pasa por las acciones (Action). Uno de los objetivos de este framework es que cada clase sólo realice el trabajo que tenga que hacer. Para entenderlo es necesario tener en cuenta el flujo de las peticiones en el propio framework: Ilustración 3 - Flujo de una petición en Struts2 4 Como podemos ver, cuando una petición llega al servidor, el front controller la redirige a una acción determinada. Sin embargo, antes de ejecutar la acción, la petición pasa a través de una pila de interceptores que nos permiten pre procesar los datos. Un interceptor clásico es el de la validación de datos. Estos interceptores nos permiten modificar el flujo normal de la aplicación si detectamos problemas con los datos. Por ejemplo si uno de los datos de un formulario no pasa la validación entonces podemos volver al formulario de donde proviene ese dato sin tener que ejecutar todo el código de la acción. La pila de interceptores por las que pasa la petición se define en el fichero de configuración del framework. 4 Traducido del diagrama presentado en el libro Donald Brown, Chad Michael Davis, and Scott Stanlick. Struts2 in Action. Manning, Mayo 2008. ISBN: 193398807X en la pág. 15

CAPÍTULO 4 INGENIERÍA INVERSA Hay que tener en cuenta que los interceptores no sólo sirven para pre procesar los datos sino que también permiten un post procesamiento. En efecto antes de devolver la vista correspondiente a la acción, se recorre de nuevo la pila de interceptores pero en este caso en sentido contrario. Las acciones en sí sirven para redirigir la petición a la vista. Pero antes de esto pueden ejecutar código. Este código se suele empaquetar en los servicios de la aplicación (generalmente se encuentran en un paquete llamado service). Estos servicios son los encargados de realizar las acciones con los datos enviados. Se comunican con la capa de persistencia (clases contenidas generalmente en el paquete dao) y devuelven el resultado a la acción que toma las decisiones para mostrar la vista adecuada. 4.1.2 MAVEN Maven es una herramienta especializada en proyectos Java. Permite gestionar de una forma sencilla las dependencias del proyecto con las librerías externas. Tiene la funcionalidad de resolver las dependencias de las librerías incluidas en el proyecto gracias a su repositorio de librerías. También dispone de numerosos plugins que permiten extender su funcionalidad. Como ejemplo citaremos un plugin que permite minimizar los ficheros CSS y JS del proyecto. Esto permite mejorar el rendimiento de la aplicación al minimizar la ocupación de estos ficheros y por lo tanto facilitar la descarga de los mismos. Esta herramienta es considerada un estándar de facto para la realización de proyectos como lo puede ser ant para aplicaciones escritas en C por ejemplo. Se considera como una herramienta cuasi obligatoria en entornos Java cuando se trata de realizar un desarrollo continuo ya que permite automatizar la creación del paquete final evitando manipulaciones manuales. También tiene muy en cuenta la realización de pruebas de código dejando entrever en su estructura básica su necesidad. Para ilustrar esto, expondremos la estructura creada por Maven para una aplicación web Java: Ilustración 4 - Estructura de aplicación con Maven En el fichero XML, pom.xml, se configuran todas las necesidades de la aplicación. Permite controlar el número de versión de la aplicación. Dicho número lo utiliza de sufijo para el war que genera pudiendo así mantener varias versiones del mismo. AMPLIACIÓN DE LA APLICACIÓN DE REALIZACIÓN DE PRÁCTICAS DE BASES DE DATOS 29