Explotación del inventario toponímico gallego-portugués antiguo

UNIVERSIDAD DE SANTIAGO DE COMPOSTELA ESCUELA T´ ECNICA SUPERIOR DE INGENIER´ IA Explotaci´on del inventario topon´ımico gallego-portugu´es antiguo Memoria del trabajo Autor: Andrea Rey Presas Directores: Jos´e Ram´on R´ıos Viqueira Fco Xavier Varela Barreiro Grado en Ingenier´ıa Inform´atica Junio 2019 Trabajo de Fin de Grado presentado en la Escuela T´ecnica Superior de Ingenier´ıa de la Universidad de Santiago de Compostela para la obtenci´on del Grado en Ingenier´ıa Inform´atica D. Jos´e Ram´on R´ıos Viqueira, Profesor del Departamento de Electr´onica y Computaci´on de la Universidad de Santiago de Compostela, y D. Fco Xavier Varela Barreiro, Profesor del Departamento de Filolog´ıa Gallega de la Universidad de Santiago de Compostela, INFORMAN: Que la presente memoria, titulada (Explotaci´on del inventario topon´ımico gallego-portugu´es antiguo), presentada por D˜na. Andrea Rey Presas para superar los cr´editos correspondientes al Trabajo de Fin de Grado de la titulaci´on del Grado en Ingenier´ıa Inform´atica, se realiz´o bajo nuestra direcci´on en los Departamentos de Electr´onica y Computaci´on y Filolog´ıa Gallega de la Universidad de Santiago de Compostela. Y para que as´ı conste a los efectos oportunos, expiden el presente informe en Santiago de Compostela, a (28 de Junio de 2019): El director, El codirector, La alumna, Jos´e Ram´on R´ıos Viqueira Fco Xavier Varela Barreiro Andrea Rey Presas i ii Resumen El prop´osito de este Trabajo de Fin de Grado es el de, como su propio nombre indica generar una aplicaci´on para la explotaci´on del inventario topon´ımico gallego-portugu´es. Para poder hacer esto se har´a un estudio de la forma en la que se guardan los datos actualmente y se propondr´a un nuevo modelo y se har´a una interfaz de usuario para poder mostrar esta informaci´on con los filtros adecuados para facilitar la b´usqueda. En este documento, se ir´an describiendo los pasos que se dar´an para poder hacer esto posible as´ı como el contexto en el que se incluye y se realiza este trabajo, ya que actualmente el Instituto da Lingua Galega, que es la entidad que posee este inventario, tiene m´as proyectos abiertos sobre esta tem´atica. Por este motivo, este proyecto no solo facilitar´a la b´usqueda de informaci´on para fines educativos o de investigaci´on, si no que puede ayudar a mejorar otros campos de trabajo actuales. iii iv ´ Indice general 1. Introducci´on 1 1.1. Motivaci´on y contexto . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2. Acta de constituci´on del proyecto . . . . . . . . . . . . . . . . . . 2 1.3. Glosario ................................ 2 1.4. Objetivos ............................... 3 2. Gesti´on del proyecto 5 2.1. Alcance de la soluci´on . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Descripci´on del alcance . . . . . . . . . . . . . . . . . . . . 5 2.1.2. Entregables del proyecto . . . . . . . . . . . . . . . . . . . 6 2.1.3. Criterios de aceptaci´on . . . . . . . . . . . . . . . . . . . . 7 2.1.4. Supuestos del proyecto . . . . . . . . . . . . . . . . . . . . 8 2.1.5. Exclusiones del proyecto . . . . . . . . . . . . . . . . . . . 8 2.2. Gesti´on de los interesados y las comunicaciones . . . . . . . . . . 8 2.2.1. Gesti´on de los interesados . . . . . . . . . . . . . . . . . . 8 2.2.2. Plan de gesti´on de las comunicaciones . . . . . . . . . . . . 10 2.2.2.1. Jerarqu´ıa de las comunicaciones . . . . . . . . . . 10 2.2.2.2. Metodolog´ıa y t´ecnicas de las comunicaciones . . 11 2.2.2.3. Flujo de informaci´on . . . . . . . . . . . . . . . . 11 2.2.2.4. Medici´on e informes del desempe˜no del trabajo . 12 2.3. Metodolog´ıa empleada . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4. Planificaci´on temporal . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4.1. EDT.............................. 15 2.4.2. Gesti´on del cronograma . . . . . . . . . . . . . . . . . . . 22 2.4.2.1. Actividades . . . . . . . . . . . . . . . . . . . . . 22 2.4.2.2. Diagrama de hitos . . . . . . . . . . . . . . . . . 22 2.4.2.3. Cronograma . . . . . . . . . . . . . . . . . . . . . 23 2.4.3. Seguimiento.......................... 25 2.5. Plan de gesti´on de recursos humanos . . . . . . . . . . . . . . . . 26 2.5.1. Roles y responsabilidades . . . . . . . . . . . . . . . . . . 26 2.5.1.1. Matriz RACI . . . . . . . . . . . . . . . . . . . . 27 2.6. Recursosf´ısicos ............................ 28 2.7. Plan de gesti´on de costes . . . . . . . . . . . . . . . . . . . . . . . 28 v 2.7.1. Unidades de medida . . . . . . . . . . . . . . . . . . . . . 28 2.7.2. Presupuesto del proyecto . . . . . . . . . . . . . . . . . . . 28 2.7.2.1. Costes personales . . . . . . . . . . . . . . . . . . 28 2.7.2.2. Costes materiales . . . . . . . . . . . . . . . . . . 29 2.7.2.3. Costes indirectos . . . . . . . . . . . . . . . . . . 29 2.7.2.4. Costes total de ITGPA . . . . . . . . . . . . . . . 29 2.8. Plan de gesti´on de riesgos . . . . . . . . . . . . . . . . . . . . . . 30 2.8.1. Calendario........................... 30 2.8.2. Definiciones de la probabilidad e impacto de los riesgos . . 31 2.8.3. Matriz de probabilidad e impacto . . . . . . . . . . . . . . 31 2.8.4. Estrategias de acci´on . . . . . . . . . . . . . . . . . . . . . 32 2.8.5. Listado de riesgos . . . . . . . . . . . . . . . . . . . . . . . 32 2.8.6. Incidencias........................... 36 2.9. Plan de gesti´on de la configuraci´on . . . . . . . . . . . . . . . . . 36 3. An´alisis 37 3.1. Requisitos de la interfaz gr´afica . . . . . . . . . . . . . . . . . . . 38 3.2. Requisitos del Software . . . . . . . . . . . . . . . . . . . . . . . . 39 3.2.1. Requisitos de informaci´on . . . . . . . . . . . . . . . . . . 39 3.2.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . 42 3.2.3. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . 44 3.2.3.1. Actores ....................... 46 3.2.3.2. Casos de uso . . . . . . . . . . . . . . . . . . . . 46 3.2.3.2.1. Listado de casos de uso . . . . . . . . . 46 3.2.3.2.2. Diagrama de casos de uso . . . . . . . . 56 3.2.4. Matriz de trazabilidad . . . . . . . . . . . . . . . . . . . . 58 4. Dise˜no preliminar 59 4.1. Dise˜nodesoftware .......................... 59 4.1.1. Diagrama de arquitectura . . . . . . . . . . . . . . . . . . 59 4.1.2. Diagrama de contexto . . . . . . . . . . . . . . . . . . . . 59 4.2. Dise˜no de la base de datos . . . . . . . . . . . . . . . . . . . . . . 59 4.2.1. Modelo entidad-relaci´on . . . . . . . . . . . . . . . . . . . 60 4.2.2. Modelo relacional . . . . . . . . . . . . . . . . . . . . . . . 63 4.2.3. Diccionario de datos . . . . . . . . . . . . . . . . . . . . . 69 4.3. Dise˜nogr´afico............................. 85 4.3.1. Dise˜no de interfaces . . . . . . . . . . . . . . . . . . . . . . 85 4.3.2. Storyboard .......................... 88 4.3.2.1. B´usqueda b´asica y variantes . . . . . . . . . . . . 88 4.3.2.2. B´usqueda filtrada . . . . . . . . . . . . . . . . . . 89 4.3.2.3. B´usqueda geogr´afica . . . . . . . . . . . . . . . . 91 vi 5. Incremento uno. B´usqueda y exploraci´on convencional 93 5.1. Dise˜nodetallado ........................... 93 5.1.1. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . 93 5.1.2. Diagramas de secuencia . . . . . . . . . . . . . . . . . . . 95 5.2. Implementaci´on............................ 96 5.2.1. Basededatos......................... 96 5.2.1.0.1. Creaci´on de la base de datos . . . . . . . 96 5.2.1.0.2. ETL de datos geogr´aficos . . . . . . . . 96 5.2.1.0.3. Scripts de inserci´on . . . . . . . . . . . . 99 5.2.1.0.4. Configuraci´on del servidor geogr´afico . . 100 5.2.2. P´aginaweb .......................... 101 5.2.2.0.1. P´agina responsive . . . . . . . . . . . . . 101 5.2.2.0.2. Filtros . . . . . . . . . . . . . . . . . . . 104 5.2.2.0.3. Lista de resultados y tablas . . . . . . . 104 5.3. Pruebas ................................ 109 5.3.1. Basededatos......................... 109 5.3.2. Aplicaci´on web . . . . . . . . . . . . . . . . . . . . . . . . 110 5.3.2.1. Evaluaci´on heur´ıstica de la usabilidad . . . . . . 110 5.3.2.2. Evaluaci´on con usuarios finales . . . . . . . . . . 111 5.3.3. Pruebas funcionales . . . . . . . . . . . . . . . . . . . . . . 112 5.3.4. Soluci´on a defectos encontrados . . . . . . . . . . . . . . . 114 6. Incremento dos. B´usqueda y exploraci´on geogr´afica 117 6.1. Dise˜no detallado . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.1.1. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . 117 6.1.2. Diagramas de secuencia . . . . . . . . . . . . . . . . . . . 117 6.2. Implementaci´on............................ 118 6.2.1. Basededatos......................... 118 6.2.2. P´aginaweb .......................... 119 6.3. Pruebas ................................ 124 6.3.1. Aplicaci´on web . . . . . . . . . . . . . . . . . . . . . . . . 125 6.3.1.1. Evaluaci´on heur´ıstica de la usabilidad . . . . . . 125 6.3.1.2. Evaluaci´on con usuarios finales . . . . . . . . . . 126 6.3.2. Pruebas funcionales . . . . . . . . . . . . . . . . . . . . . . 127 6.3.3. Soluci´on a defectos encontrados . . . . . . . . . . . . . . . 130 7. Conclusiones y trabajo futuro 133 7.1. Conclusiones.............................. 133 7.2. Trabajofuturo ............................ 134 7.2.1. Basededatos......................... 134 7.2.2. Protecci´on de los datos de la base de datos . . . . . . . . . 135 7.2.3. Falta de datos de la base de datos . . . . . . . . . . . . . . 135 7.2.4. P´aginaweb .......................... 136 vii 2CAP´ ITULO 1. INTRODUCCI ´ ON informaci´on siguiendo un esquema que la relacione. A mayores la interfaz gr´afica no es muy actual y amigable visualmente. Por lo que, la raz´on de realizaci´on de este proyecto, es mejorar dicha p´agina y base de datos, con la inclusi´on de un modelo relacional que agrupe la base de datos del ILG y diferentes bases de datos de dominio p´ublico que aporten la componente geogr´afica de forma que sea posible a˜nadir un mapa en el que tambi´en se pueda ver parte de la informaci´on. El motivo por el cual se hace este proyecto es por tanto ayudar a la docencia e investigaci´on en este campo, ofreciendo la posibilidad de realizar una mayor cantidad de b´usquedas, y sobre todo permitiendo ver los resultados sin problema de una forma gr´afica y clara. Este proyecto est´a altamente relacionado con otros que se est´an realizando actualmente, por ejemplo, otro TFG para la inclusi´on de los datos en la plataforma que vamos a realizar as´ı como con la investigaci´on que se sigue realizando actualmente en el ILG para aumentar el listado de documentos que tienen. 1.2. Acta de constituci´on del proyecto El acta de constituci´on del proyecto se puede encontrar en el ap´endice A Acta de constituci´on del proyecto, anteproyecto. 1.3. Glosario Se listan a continuaci´on una serie de t´erminos relevantes en el entorno en el que nos encontramos y que pueden dar lugar a duda. An´alisis: En ciencias de la computaci´on, an´alisis de software es el proceso automatizado de analizar el comportamiento del software. Estas t´ecnicas de an´alisis intentan encontrar y mejorar en un software cuestiones de efectividad, optimizaci´on y seguridad. Base de datos: Conjunto de datos pertenecientes a un mismo contexto y almacenados sistem´aticamente para su posterior uso. Dise˜no: En ciencias de la computaci´on, el dise˜no de software es el proceso de visionado y definici´on de soluciones software a uno o m´as conjuntos de problemas. Forma de un top´onimo: Literalidad del top´onimo, tal y como aparece en el documento al que haga referencia. ITGPA: “Inventario Topon´ımico Galego Portugu´es Antigo”. Conjunto de documentos del ILG que trataremos de explotar de la mejor manera posible en este trabajo. 1.4. OBJETIVOS 3 Instituto da Lingua Galega (ILG): Instituto universitario perteneciente a la Universidad de Santiago de Compostela, creado en 1971 y dedicado a la investigaci´on ling¨u´ıstica del gallego. Realiza actividades de postgrado, formaci´on de expertos en lengua gallega, y asesor´ıa t´ecnica y normativa del gallego. Lema: Conjunto de variantes de una palabra (gr´aficas, fon´eticas, morfol´ogicas, l´exicas y sintagm´aticas). Macrolema: Conjunto de top´onimos que comparten la misma denominaci´on, pero difieren en su referente geogr´afico. Es por tanto una unidad politopon´ımica. Sistema de informaci´on: Conjunto de elementos orientados al tratamiento y administraci´on de datos e informaci´on, organizados y listos para su uso posterior, generados para cubrir una necesidad o un objetivo. Sistema de informaci´on geogr´afica (SIG): Cualquier sistema de informaci´on capaz de integrar, almacenar, editar, analizar, compartir y mostrar la informaci´on geogr´aficamente referenciada. Toponimia: Estudio del origen y el significado de los nombres propios de los lugares. Top´onimo: Nombre propio de lugar. 1.4. Objetivos Por lo tanto, y en relaci´on al apartado anterior, ser´a necesaria la creaci´on de una interfaz nueva y actualizada y que servir´a para buscar informaci´on en los documentos gestionados actualmente por el ILG, es decir, se implementar´an de nuevo los filtros y se a˜nadir´an unos nuevos para poder hacer b´usquedas sobre estos documentos. Por lo que podemos identificar la creaci´on del modelo de la base de datos como una tarea fundamental para poder conseguir este objetivo. A mayores, se crear´a un mapa con el que se podr´an visualizar datos con componente geogr´afico, para poder estudiar toda esta informaci´on de un modo m´as visual. Por lo que es necesario utilizar base de datos de dominio p´ublico que nos otorguen informaci´on sobre la geograf´ıa mundial y las componentes geom´etricas que la forman. En el listado de objetivos m´as espec´ıficos se hace referencia a la calidad que se espera conseguir en relaci´on a la calidad de las consultas o a la mejora en el guardado de los datos, pero no por ello se debe dejar de lado el intentar conseguir una interfaz elegante, amigable y sobre todo, ´util, ya que como hemos dicho, esta plataforma est´a orientada a la investigaci´on y docencia. 4CAP´ ITULO 1. INTRODUCCI ´ ON A continuaci´on se muestra la tabla 1.1 sobre los objetivos del proyecto, es decir, aquellas cosas que se espera que el software haga una vez finalizado el proyecto y mediante las cuales se podr´a medir si este ha cumplido las expectativas. Nombre Descripci´on Acotaci´on temporal Medici´on (Criterios de ´exito) C´odigo Mayores posibilidades de b´usqueda Inclusi´on de mayor cantidad de filtros y combinaciones de b´usqueda Inmediatamente Mayor n´umero de filtros OBJ.1 Minimizar inconsistencias de datos Los datos en la base de datos se guardar´an de forma que se minimicen las inconsistencias en los datos que vienen derivadas del almacenamiento redundante de los mismos Inmediatamente Menor tama˜no de la base de datos para la misma cantidad de datos OBJ.2 Exploraci´on del componente geogr´afico del resultado a trav´es de una interfaz basada en mapas Se incluir´a un mapa mediante el cual se podr´a explorar el componente geogr´afico relacionado con los top´onimos que aparecen en los documentos Inmediatamente Funcionamiento del mapa incluido OBJ.3 Tabla 1.1: Objetivos del proyecto. Cap´ıtulo 2 Gesti´on del proyecto 2.1. Alcance de la soluci´on 2.1.1. Descripci´on del alcance El prop´osito del proyecto que se est´a desarrollando es el de crear una nueva p´agina web para la explotaci´on del Inventario Top´onimico Galego-Portugu´es para el Instituto da Lingua Galega. En concreto se crear´a una nueva base de datos con un esquema relacional donde poder guardar todos los datos que el equipo de fil´ologos ha obtenido durante estos a˜nos, sin repeticiones, lo que garantizar´a menos inconsistencias de los datos y m´as tipos de b´usquedas posibles para sacarle el mayor partido a un inventario topon´ımico que se est´a utilizando en varios proyectos actualmente y que puede ser una gran fuente para futuras investigaciones y docencia. Dicha base de datos, contendr´a datos proporcionados por el ILG, relativos a todos los documentos, top´onimos u obras con los que trabajan actualmente, y se a˜nadir´an datos relativos a la geograf´ıa de dichos top´onimos de distintas bases de datos. A mayores de lo que hay actualmente y que se mejorar´a como ha sido comentado, se har´a una interfaz completamente nueva, que sea m´as amigable y moderna y que incluir´a como pieza central de la misma un mapa, donde se podr´an visualizar las componentes geogr´aficas de los datos de la base de datos que se acaba de explicar. En el siguiente documento se definir´a la propuesta de soluci´on y los pasos a seguir para la planificaci´on y el posterior desarrollo del proyecto. De este modo, al finalizar este trabajo, tendremos el c´odigo de una nueva p´agina web sostenida sobre una nueva y eficiente base de datos y la documentaci´on necesaria para su mantenimiento y futuras ampliaciones de modo que sea un proyecto no solo actual si no con vistas a mejorar en un futuro. Es importante resaltar que, si bien se ver´a a lo largo del trabajo apartados relativos a la inclusi´on de datos proporcionados por el ILG, en realidad no es 5 6CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO competencia de este trabajo la inclusi´on de dichos datos en el sistema que se est´a creando, sino solamente la inclusi´on de los datos geogr´aficos. De todos modos, esto es necesario hacerlo para poder realizar una fase de pruebas completa. 2.1.2. Entregables del proyecto A lo largo del proyecto se entregar´a a los tutores en los siguientes plazos, que se pueden ver en las figuras 2.1 y 2.2 la informaci´on correspondiente. Figura 2.1: Entregables del proyecto Figura 2.2: Entregables del proyecto Comentamos ahora que informaci´on contendr´ıa cada entregable: Entrega de la planificaci´on: Apartados relativos a la gesti´on del proyecto como la gesti´on de los interesados, costes o tiempo. Anexos necesarios para aumentar la informaci´on relacionada. Entrega del an´alisis: Apartados relativos al an´alisis del proyecto, como el listado de requisitos del proyecto. Entrega del dise˜no preliminar: Apartados relativos al dise˜no inicial del proyecto, donde se ver´an los primeros diagramas de clases o de arquitectura. Entrega del m´odulo BEC: Apartados de dise˜no, implementaci´on y pruebas del primer incremento del proyecto. Donde se realizar´an las funcionalidades actuales para no perder nada con el cambio del sistema actual al que se est´a proponiendo. 2.1. ALCANCE DE LA SOLUCI ´ ON 7 Entrega del m´odulo BEG: Apartados de dise˜no, implementaci´on y pruebas del segundo incremento del proyecto. Donde se a˜nadir´an las funcionalidades relativas a las consultas geogr´aficas. Entrega de la fase final: Proyecto completo, memoria y c´odigo. Los entregables que no se han explicado detalladamente hacen referencia a los hitos donde no se entrega informaci´on. A la finalizaci´on del proyecto, se entregar´a al comit´e de evaluaci´on la siguiente informaci´on: Memoria del proyecto impresa. CD con el c´odigo fuente, diagramas UML, diagramas de Gantt, memoria del proyecto y cualquier anexo que se considere necesario durante la realizaci´on de este trabajo. 2.1.3. Criterios de aceptaci´on A mayores de los criterios acad´emicos mediante los cuales se decide si un TFG es v´alido o no, los criterios de aceptaci´on de este proyecto se basan en que, al ser una aplicaci´on de cara al p´ublico, ha de cumplir sus expectativas, adem´as de que este trabajo ha de ser lo suficientemente completo, exhaustivo y espec´ıfico de tal manera que el c´odigo que lo acompa˜na pueda ser modificado seg´un futuros requisitos. Por lo tanto, dentro de los criterios de aceptaci´on podemos encontrar: El documento relativo a la memoria del proyecto tendr´a los apartados necesarios debidamente cubiertos, entre los que se encuentran: apartado de planificaci´on (con la gesti´on temporal, de riesgos, de la documentaci´on o alcance e interesados del proyecto), apartado de an´alisis (con el an´alisis de requisitos o de la base de datos), apartado de dise˜no (con subapartados relacionados con distintos y diagramas y explicaciones relativas a la gesti´on de la base de datos y el dise˜no del software) y un apartado conclusiones para una correcta finalizaci´on del trabajo. Se har´a tambi´en un apartado para cada una de las iteraciones con la informaci´on que se considere necesaria dentro de cada uno de ellos. El c´odigo tiene que ser elegante, sin errores, y que proporcione una funcionalidad r´apida y eficiente. La p´agina web y el dise˜no de la base de datos ha de ser lo suficientemente buena para el ILG y cumplir sus expectativas de interfaz y funcionalidades. En general, el producto se considerar´a aceptable cuando se cumplan sus objetivos, descritos anteriormente. 8CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO 2.1.4. Supuestos del proyecto Para la creaci´on de este proyecto, se supone la participaci´on del ILG para proporcionar requisitos y, sobre todo, datos con los que trabajar y la disponibilidad de las tecnolog´ıas de software libre empleadas. 2.1.5. Exclusiones del proyecto A continuaci´on, se listan una serie de exclusiones del proyecto. Una exclusi´on se refiere a todo aquello que podr´ıa interpretarse que se incluir´a en el software, pero en este caso no es as´ı. Inclusi´on de datos: La p´agina web no permitir´a la inclusi´on de nuevos datos al inventario. Esto ha de hacerse mediante un gestor de bases de datos con el comando correspondiente. Modificaci´on de datos: La p´agina web no permitir´a la modificaci´on de los datos del inventario. Esto ha de hacerse mediante un gestor de bases de datos con el comando correspondiente. Usuarios: La p´agina web no permitir´a la creaci´on de usuarios de ning´un tipo. 2.2. Gesti´on de los interesados y las comunicaciones Como se trata de un proyecto con un grupo de trabajo y una lista de interesados peque˜na, se ha decidido unir estas dos secciones en una, de modo que sea m´as relevante su lectura, ya que, de ambas subsecciones hemos eliminado apartados que en este proyecto carecen de sentido. 2.2.1. Gesti´on de los interesados Se a˜nade la tabla 2.1 con los interesados del proyecto. Se a˜nade informaci´on m´as especifica en las tablas 2.2 y 2.3. Como se puede ver hemos citado 4 interesados, la alumna encargada de realizar el proyecto, en car´acter de jefa de proyecto, as´ı como el tutor como parte fundamental del equipo de trabajo. El cotutor y el ILG como entidad, est´an ambos situados en calidad de cliente. 2.2. GESTI ´ ON DE LOS INTERESADOS Y LAS COMUNICACIONES 9 Identificaci´on Nombre Empresa / grupo / Dpto / Puesto Rol en el proyecto Identificador Andrea Rey Presas Alumna Realizadora del proyecto IT.1 Jos´e Ram´on R´ıos Viqueira Profesor de la universidad Tutor del proyecto IT.2 Fco Xavier Varela Barreiro Profesor de la universidad Cotutor del proyecto IT.3 ILG Administraci´on p´ublica Beneficiarios IT.4 Tabla 2.1: Interesados del proyecto. ID Evaluaci´on Clasificaci´on ID Requisitos/ prioridades Expectativas principales Influencia potencial Fase de inter´es Interno / externo Apoyo/ neutral/ opositor IT.1 Cumplir con el plan del proyecto Logro del objetivo del proyecto Alto Todo el proyecto Interno Apoyo IT.2 Asistir en tutor´ıas y colaborador en an´alisis y dise˜no Logro del objetivo del proyecto Alto Todo el proyecto Interno Apoyo IT.3 Asistir en tutor´ıas y servir de enlace con el ILG Logro del objetivo del proyecto y los requisitos del ILG Alto Todo el proyecto Interno/ Externo Apoyo IT.4 Proveer de requisitos y datos de prueba P´agina web m´as completa y actual Medio Inicio del proyecto y fase de an´alisis Externo Apoyo Tabla 2.2: Interesados del proyecto. 10 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO ID Requisitos Expectativas/Intereses IT.1 -Cumplir con el plan del proyecto -Cumplir con los requisitos del ILG -Hacer un trabajo eficiente -Hacer una presentaci´on correcta -Dominio de las tecnolog´ıas usadas -Demostrar conocimientos suficientes sobre el campo de trabajo (ingenier´ıa inform´atica) Obtener un buen trabajo final -Obtener experiencia como directora y trabajadora en un proyecto real -Obtener la aprobaci´on del comit´e -Aprobar el trabajo -Obtener la aprobaci´on del ILG y que se use la aplicaci´on de manera oficial IT.2 -Asistir en tutor´ıas -Resoluci´on de dudas de la tecnolog´ıa -Colaboraci´on en dise˜no y an´alisis de la aplicaci´on -Obtener un buen trabajo final IT.3 -Asistir en tutor´ıas -Resoluci´on de dudas relativas a requisitos de la aplicaci´on -Servir de enlace con el ILG -Obtener un buen trabajo final -Cumplir con los requisitos del ILG IT.4 -Especificar los requisitos de forma clara -Proporcionar los datos del proyecto -Obtener una p´agina nueva amigable y funcional -Mayor facilidad para b´usqueda de datos Tabla 2.3: Registro de interesados. 2.2.2. Plan de gesti´on de las comunicaciones Aunque sea un proyecto relativamente peque˜no, y el equipo de trabajo sea muy reducido, teniendo en cuenta la gesti´on de los interesados, es necesario establecer un plan para la gesti´on de los mismos. 2.2.2.1. Jerarqu´ıa de las comunicaciones Para la correcta realizaci´on del proyecto es prioritario mantener bien comunicadas a todas las partes interesadas. Para mostrar estas comunicaciones, se muestra a continuaci´on el diagrama 2.3, que simboliza la jerarqu´ıa de comunicaciones. Como se puede ver en la figura 2.3, los dos profesores a cargo del trabajo hablan entre ellos y con la alumna encargada de realizarlo al mismo nivel. A mayores, el ´unico contacto con el Instituto da Lingua Galega es el cotutor, Fco 2.2. GESTI ´ ON DE LOS INTERESADOS Y LAS COMUNICACIONES 11 Xavier Varela Barreiro, mediante el cual se conocer´an los requisitos y opiniones del ILG. Andrea Rey Presas José Ramón Ríos Viqueira Fco Xavier Varela Barreiro ILG Figura 2.3: Jerarqu´ıa de comunicaciones 2.2.2.2. Metodolog´ıa y t´ecnicas de las comunicaciones Las t´ecnicas m´as utilizadas para intercambio de informaci´on y comunicaciones ser´an el correo electr´onico y las reuniones presenciales. 2.2.2.3. Flujo de informaci´on Teniendo presente el diagrama de jerarqu´ıa de las comunicaciones presentado anteriormente, vamos a mostrar ahora el diagrama del flujo de la informaci´on, 2.4, que muestra, como su propio nombre indica el flujo de todas las comunicaciones del proyecto y la acci´on que representan. Andrea Rey Presas José Ramón Ríos Viqueira Fco Xavier Varela Barreiro ILG Informar, colaborar Colaborar Informar Feedback Informar, colaborar Feedback, colaborar Colaborar Colaborar Figura 2.4: Flujo de informaci´on 18 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO Figura 2.10: EDT. Fase de dise˜no. 2.4. PLANIFICACI ´ ON TEMPORAL 19 Figura 2.11: EDT. Incremento 1. B´usqueda y exploraci´on convencional 20 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO Figura 2.12: EDT. Incremento 2. B´usqueda y exploraci´on geogr´afica 2.4. PLANIFICACI ´ ON TEMPORAL 21 Figura 2.13: EDT. Fase final. 22 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO 2.4.2. Gesti´on del cronograma 2.4.2.1. Actividades El listado de actividades, as´ı como sus recursos asociados y su coste temporal y monetario puede verse en el ap´endice A, Diagrama de Gantt. Estas actividades, que est´an dentro de paquetes de trabajo, son el nivel m´as bajo de planificaci´on y representan cada una de las cosas que es necesario hacer para la correcta finalizaci´on en tiempo y alcance del trabajo. 2.4.2.2. Diagrama de hitos Se muestra a continuaci´on una tabla con todos los hitos del proyecto 2.4. Esta informaci´on tambi´en puede verse en el anexo correspondiente, Diagrama de Hitos, ver A.1 Nombre de la tarea Fecha Responsable Entrega de la planificaci´on vie 15/03/19 Andrea Entrega del an´alisis mi´e 03/04/19 Andrea Entrega del dise˜no preliminar mar 16/04/19 Andrea Entrega del m´odulo de BEC mar 21/05/19 Andrea Fin del incremento 1 jue 23/05/19 Andrea Entrega del m´odulo de BEG mar 11/06/19 Andrea Fin del incremento 2 jue 13/06/19 Andrea Entrega de la fase final vie 21/06/19 Andrea Presentaci´on del proyecto ITGPA jue 18/07/19 Andrea Fin del proyecto ITGPA jue 18/07/19 Andrea Tabla 2.4: Diagrama de hitos 1Las fechas de los hitos son orientativas debido a la incapacidad de conocer exactamente cu´ando se podr´an hacer las revisiones de cada uno de las fases del proyecto. 2.4. PLANIFICACI ´ ON TEMPORAL 23 2.4.2.3. Cronograma El cronograma se encuentra en el archivo ap´endice A, Diagrama de Gantt.2 En este cronograma est´an reflejadas la mayor´ıa de las tareas que hay que llevar a cabo para la finalizaci´on de este proyecto, adem´as de los hitos planificados de entrega. Las tareas faltantes ser´ıan, en realidad, todas aquellas tareas de documentaci´on que habr´ıa que ir haciendo paralelamente a las actividades que s´ı est´an reflejadas en la planificaci´on, y que m´as que aportar informaci´on, entorpecer´ıan la lectura del diagrama. Algunas de las tareas que se pueden ver en el documento anexo, no tendr´ıan que ser realizadas en todos los casos, v´ease aquellas que se basan en resolver errores, ya que puede no haberlos. En este caso, no ser´ıa necesario rehacer la planificaci´on, ya que simplemente contar´ıamos con un colch´on para futuros imprevistos. A mayores de las actividades para llevar a cabo lo que es el producto en s´ı, hay algunas que se basan en la correcta gesti´on del proyecto, como la planificaci´on o el control. Aunque no modifican directamente el producto, son completamente necesarias para llevarlo a cabo como tareas subsidiarias. El trabajo est´a dise˜nado para realizarse de forma secuencial, debido a que el equipo de trabajo est´a conformado por una ´unica persona. En un trabajo con un equipo m´as grande, las predecesoras de las tareas podr´ıan modificarse de tal modo que estas pudiesen hacerse en paralelo. En el cronograma tambi´en se ven tareas de tiempo cero. Los llamados hitos de entrega y control, estos hitos est´an reflejados en el apartado correspondiente y sirven tambi´en para marcar el final de una l´ınea base. Para poder entender correctamente el anexo, es necesario saber que se han modificado las horas m´aximas por d´ıa, tal y como se puede ver en la figura 2.14, para ajustarnos a la estimaci´on prevista en el anteproyecto y a la restricci´on horaria de de ECTS. 2Cuando se cre´o este cronograma ya se conoc´ıan fechas exactas de algunas reuniones y por eso se han colocado expl´ıcitamente. Aquellas reuniones posteriores, aunque no fuesen en la fecha exacta indicada, no afecta al desarrollo del proyecto, puesto que se puede seguir trabajando por otra rama, ya sea en otras tareas del mismo paquete de trabajo que no est´en directamente relacionadas o con la b´usqueda de informaci´on sobre tecnolog´ıas. 24 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO Figura 2.14: Modificaci´on de las horas de un proyecto. Comentar finalmente que la herramienta de programaci´on utilizada para realizar el cronograma ha sido Microsoft Project 2016. Se a˜nade a continuaci´on, un par de capturas 2.15 y 2.16 a modo de resumen del cronograma que se puede ver en el anexo. Figura 2.15: Gantt del proyecto 2.4. PLANIFICACI ´ ON TEMPORAL 25 Figura 2.16: Gantt del proyecto 2.4.3. Seguimiento Una vez comenzado el proyecto, en cada una de las tareas de seguimiento que se han comentado se iba revisando el cronograma del mismo. Despu´es de un an´alisis m´as detallado y del conocimiento real de las tecnolog´ıas que se iban a usar y de c´omo iban a usarse, se vio que algunas de las tareas que hab´ıan sido previamente planeadas no era necesario hacerlas. Adem´as, al conocer con un an´alisis m´as preciso, la dificultad que entra˜naba el trabajo con la nueva base de datos, se dio mucha m´as importancia a algunas tareas de dise˜no de la que previamente se le hab´ıa asignado. Por tanto, lo que se pretende representar en este apartado, es que el cronograma va variando con el tiempo, y no por ello simboliza una mala planificaci´on inicial, sino que, de una planificaci´on inicial, es necesario saber adaptarse. Finalmente, despu´es de terminar todos los apartados del proyecto, se ha obtenido un diagrama de Gantt final, que puede verse en el anexo A. Como puede verse, la mayor diferencia entre ambos fue la reducci´on del apartado de implementaci´on de c´odigo para la p´agina web, ya que finalmente, no se ha hecho c´odigo de servidor, pero ha aumentado considerablemente tanto el tiempo dedicado a la creaci´on del modelo de la base de datos, como a los scripts de inserci´on de datos en ella. Esto es debido a los problemas de que se han tenido para lograr casar unos datos con los de otra base de datos distinta, ya que, recordemos, finalmente hemos llegado a unir 3 bases de datos en una. Se a˜nade a continuaci´on, un par de capturas 2.17 y 2.18 a modo de resumen del cronograma que se puede ver en el anexo. 26 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO Figura 2.17: Gantt de seguimiento del proyecto Figura 2.18: Gantt de seguimiento del proyecto 2.5. Plan de gesti´on de recursos humanos 2.5.1. Roles y responsabilidades Se lista a continuaci´on los recursos humanos que participan en el proyecto, con los roles que han de desempe˜nar. Andrea Rey Presas: Jefe/a de proyecto, analista, dise˜nadora, administradora de bases de datos, experta en pruebas, programadora, gestora del 2.5. PLAN DE GESTI ´ ON DE RECURSOS HUMANOS 27 repositorio, responsable de cambios. Estos dos ´ultimos hacen referencia a la gesti´on de la configuraci´on del proyecto. Por tanto, podemos determinar que este recurso ser´a el encargado de realizar en s´ı el trabajo de fin de grado, haciendo un trabajo transversal en el que se pongan a prueba competencias en todos los campos de un proyecto de software, desde gesti´on a an´alisis o creaci´on de c´odigo. Jos´e Ram´on R´ıos Viqueira: Analista, dise˜nador, administrador de bases de datos. Este recurso, tendr´a un papel m´as de dise˜no y an´alisis de los datos y el sistema, siendo su visi´on fundamental para el buen dise˜no del sistema. Fco Xavier Varela Barreiro: Analista. El trabajo de este recurso, que se puede considerar como parte del equipo de trabajo y como cliente a la vez, es el de analizar los requisitos para que el proyecto cumpla todas las especificaciones. 2.5.1.1. Matriz RACI 3Se muestra en el cuadro 2.5 la matriz de responsabilidades de cada implicado en el desarrollo del proyecto. Consideramos como responsabilidades cada uno de los paquetes de trabajo que se pueden ver en el EDT. Debido a grandes similitudes entre algunos paquetes, se han unido en una misma responsabilidad. Responsabilidad / Roles Andrea Jos´e Ram´on Xavier Planificaci´on A/R Control A/R I I Estado del arte A/R An´alisis de las interfaces del sistema A/R An´alisis de la GUI A/R C An´alisis del software A/R I Revisi´on del an´alisis A/R R R Dise˜no de la arquitectura del sistema A/R C Dise˜no de la base de datos ITGPA BD A/R R C Dise˜no del software A/R I I 3R = Responsible (persona responsable de ejecutar la tarea) A = Accountable (persona con responsabilidad ´ultima sobre la tarea) (A ⇒R) C = Consult (persona a la que se consulta sobre la tarea) I = Inform (persona a la que se debe informar sobre la tarea) 34 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO RS-5 Desconocimiento de las tecnolog´ıas a usar Descripci´on La alumna no conoce todas las tecnolog´ıas que ha de usar a lo largo del proyecto. Probabilidad Alta. Impacto Alto. Indicadores No aplica. Estrategia Minimizaci´on. Acci´on Dise˜no del Gantt teniendo en cuenta esto y dejando un tiempo para el aprendizaje. Tabla 2.16: RS-5 Desconocimiento de las tecnolog´ıas a usar RS-6 Errores no encontrados en las pruebas Descripci´on Las pruebas no comprueban la validez de todo el sistema y quedan errores sin encontrar. Probabilidad Media. Impacto Alto. Indicadores Una vez finalizado el proyecto, o en fases que ya no corresponda, se encuentran errores en el software. Estrategia Prevenci´on. Acci´on Dise˜no y ejecuci´on exhaustiva de varios tipos de pruebas. Revisi´on con los tutores de esta parte. Tabla 2.17: RS-6 Errores no encontrados en las pruebas RS-7 No aprobaci´on del ILG del trabajo propuesto Descripci´on Una vez finalizado el proyecto, este no convence al ILG que decide no adoptarlo como futura p´agina web para la explotaci´on del inventario topon´ımico gallego-portugu´es antiguo. Probabilidad Media. Impacto Medio. Indicadores Despu´es de la finalizaci´on del proyecto, y posiblemente despu´es de su defensa, el ILG comunica que no desea utilizarlo como p´agina web. Estrategia Aceptaci´on. Acci´on No aplica. Tabla 2.18: RS-7 No aprobaci´on del ILG del trabajo propuesto 2.8. PLAN DE GESTI ´ ON DE RIESGOS 35 RS-8 P´erdida de informaci´on Descripci´on A lo largo del proyecto, se pierde alg´un fichero, o una parte, que conten´ıa informaci´on valiosa. Probabilidad Baja. Impacto Alta. Indicadores Desaparici´on de dicha informaci´on. Estrategia Prevenci´on. Acci´on Seguir correctamente la gesti´on de la configuraci´on. Tabla 2.19: RS-8 P´erdida de informaci´on RS-9 Fallo en el port´atil de desarrollo Descripci´on Un fallo estropear´ıa el ordenador port´atil de la alumna, lo que imposibilitar´ıa, al menos durante un tiempo, su uso para el desarrollo del proyecto. Probabilidad Baja. Impacto Alta. Indicadores El port´atil no funciona. Estrategia Minimizaci´on. Acci´on Utilizar ordenadores de la USC u ordenadores presentes en casa de la alumna. Valerse del repositorio online para no perder informaci´on. Tabla 2.20: RS-9 Fallo en el port´atil de desarrollo RS-10 No disponibilidad de la informaci´on Descripci´on El no tener la informaci´on necesaria, impedir´ıa parte de la implementaci´on y har´ıa imposible las pruebas y la presentaci´on de la aplicaci´on. Probabilidad Media. Impacto Alta. Indicadores No se puede obtener informaci´on para rellenar la base de datos. Estrategia Minimizaci´on. Acci´on Usar datos inventados en el caso de que falte informaci´on sobre los documentos del ITGPA y buscar alternativas en el caso de que falten datos geogr´aficos. Tabla 2.21: RS-10 No disponibilidad de la informaci´on 36 CAP´ ITULO 2. GESTI ´ ON DEL PROYECTO RS-11 No disponibilidad de los tutores Descripci´on El no poder quedar con los tutores del proyecto en determinadas ocasiones, debido a otros compromisos, ralentizar´ıa el trabajo. Probabilidad Media. Impacto Alta. Indicadores No se pueden realizar reuniones. Estrategia Minimizaci´on. Acci´on Reprogramar el orden de las tareas a realizar. Tabla 2.22: RS-11 No disponibilidad de los tutores Como se puede ver, la mayor´ıa de los riesgos tienen un alto impacto, y por tanto una exposici´on al riesgo alta, por lo que no haremos distinciones entre riesgos m´as o menos importantes, y se solucionar´an aquellos que sea posible, tal y como se ha comentado en las tablas anteriores en los apartados ’Estrategia’ y ’Acci´on’. 2.8.6. Incidencias Una vez avanzado el proyecto, se fueron dando una serie de riesgos de los que se hab´ıan planificado. Estos fueron los siguientes. Mala planificaci´on y retraso en el proyecto - Debido a no tener en cuenta algunas de las tareas que fueron necesarias para realizar el proyecto, o considerar que iban a llevar menos tiempo, el Gantt del proyecto se retras´o en relaci´on a la planificaci´on. Por otro lado, el hecho de que algunas tareas finalmente no fuesen necesarias posibilit´o la finalizaci´on en plazo del trabajo. M´as informaci´on sobre este tema puede verse en el apartado relativo a Planificaci´on temporal. Fallo en el port´atil de desarrollo - En realidad, lo que sucedi´o no fue un fallo en el port´atil si no una limitaci´on de sus caracter´ısticas t´ecnicas. Debido a esto no fue posible cargar la totalidad de la base de datos geogr´afica, y solo se pudieron cargar datos relativos a Espa˜na. 2.9. Plan de gesti´on de la configuraci´on El plan de gesti´on de la configuraci´on puede verse en el ap´endice B Gesti´on de la Configuraci´on. Cap´ıtulo 3 An´alisis Se a˜nade a continuaci´on el apartado de an´alisis. En este cap´ıtulo se har´a un an´alisis exhaustivo sobre el sistema y los requisitos que ha de cumplir. Las tablas que se mostrar´an tendr´an algunos de los siguientes campos. Los niveles de los mismos se explican a continuaci´on: Importancia •Quedar´ıa bien: No es estrictamente necesario, pero ayudar´ıa a mejorar la calidad. •Importante: Pedido por el cliente o que se considera necesario para el sistema. •Vital: Indispensable para el sistema. Urgencia •Puede esperar: No es necesario implementarlo inmediatamente. •Hay presi´on: Es recomendable implementarlo puesto que es importante. •Inmediatamente: Tiene prioridad m´axima, es necesario implementarlo lo antes posible. Estado •En construcci´on: Est´a en las fases iniciales del proyecto. •Verificado: Ha superado las fases de prueba y funciona perfectamente. •Validado: Ha superado las pruebas de validaci´on. Estabilidad •Baja: Lo m´as probable es que cambie de especificaciones durante el proyecto. 37 38 CAP´ ITULO 3. AN ´ ALISIS •Media: Puede que cambie de especificaciones durante el proyecto. •Alta: No se espera que cambie de especificaciones durante el proyecto. 3.1. Requisitos de la interfaz gr´afica Se a˜nade a continuaci´on el listado de requisitos que ha de cumplir la interfaz gr´afica que se dise˜nar´a posteriormente para cumplir las expectativas del cliente en cuanto a amabilidad y facilidad de uso de esta. Estos se pueden ver en las tablas 3.1 - 3.3. RG.01 Seguir principios heur´ısticos de Nielsen Descripci´on La p´agina web tiene que seguir los principios heur´ısticos de Nielsen de modo que sea c´omoda y amable para el usuario. Se explicar´a con m´as detalle en el apartado de dise˜no. Importancia Vital. Urgencia Inmediatamente. Estado Validado. Estabilidad Alta. Tabla 3.1: RG.01 - Seguir principios heur´ısticos de Nielsen RG.02 Permitir cambios en el modo de visualizaci´on. Descripci´on La aplicaci´on tiene que permitir alternar entre la b´usqueda filtrada y la geogr´afica de manera c´omoda y sencilla. Importancia Vital. Urgencia Inmediatamente. Estado Validado. Estabilidad Media. Tabla 3.2: RG.02 - Permitir cambios en el modo de visualizaci´on 3.2. REQUISITOS DEL SOFTWARE 39 RG.03 B´usqueda simple y b´usqueda exhaustiva Descripci´on La aplicaci´on tiene que presentar filtros para una b´usqueda simple que salgan por defecto, y la opci´on de mostrar m´as filtros para una b´usqueda m´as exhaustiva. Estos estar´an ocultos por defecto, para no saturar al usuario, pero la forma de desplegarlos debe ser clara y sencilla. Importancia Quedar´ıa bien. Urgencia Hay presi´on. Estado Validado. Estabilidad Media. Tabla 3.3: RG.03 - B´usqueda simple y b´usqueda exhaustiva 3.2. Requisitos del Software Se a˜naden a continuaci´on los requisitos que ha de cumplir el Software del sistema. Entre ellos podemos encontrar requisitos de informaci´on, no funcionales y funcionales, donde se especificar´an adem´as los casos de uso. 3.2.1. Requisitos de informaci´on Los requisitos de informaci´on representan los tipos de informaci´on que el sistema debe mantener para funcionar correctamente. Se pueden en las tablas 3.4 y 3.11 RI.01 Informaci´on de obras Descripci´on El sistema en todo momento tiene que tener disponible la informaci´on de las obras que forman parte del ITGPA. Importancia Vital. Urgencia Inmediatamente. Estado Validado. Estabilidad Media. Tabla 3.4: RI.01 - Informaci´on de obras 40 CAP´ ITULO 3. AN ´ ALISIS RI.02 Informaci´on de documentos Descripci´on El sistema en todo momento tiene que tener disponible la informaci´on de los documentos que forman parte del ITGPA. Estos documentos son los que conforman las obras de las que se hablan en el requisito RI.01. Importancia Vital. Urgencia Inmediatamente. Estado Validado. Estabilidad Media. Tabla 3.5: RI.02 - Informaci´on de documentos RI.03 Informaci´on de top´onimos Descripci´on El sistema en todo momento tiene que tener disponible la informaci´on de los top´onimos que forman parte del ITGPA y sus apariciones en los documentos del requisito RI.02. Importancia Vital. Urgencia Inmediatamente. Estado Validado. Estabilidad Media. Tabla 3.6: RI.03 - Informaci´on de top´onimos RI.04 Informaci´on de scriptors y notarios Descripci´on El sistema en todo momento tiene que tener disponible la informaci´on de los scriptors (y los notarios por los que est´an formados) que forman parte del ITGPA y que fueron los encargados de redactar los documentos del requisito RI.02. Importancia Vital. Urgencia Inmediatamente. Estado Validado. Estabilidad Media. Tabla 3.7: RI.04 - Informaci´on de scriptors y notarios 3.2. REQUISITOS DEL SOFTWARE 41 RI.05 Informaci´on de investigadores Descripci´on El sistema en todo momento tiene que tener disponible la informaci´on de los investigadores que hicieron posible el inventario. Tanto los que procesaron los documentos, como los que procesaron los top´onimos y dejar clara la diferencia entre ellos. Importancia Vital. Urgencia Inmediatamente. Estado Validado. Estabilidad Media. Tabla 3.8: RI.05 - Informaci´on de investigadores RI.06 Informaci´on de la interrelaci´on entre entidades del ILG Descripci´on El sistema en todo momento tiene que tener disponible la informaci´on de las entidades que forman parte del ILG, es decir, todas aquellas a las que hacen referencia los requisitos anteriores, y dejar clara las relaciones entre ellas. De modo que quede claro como un top´onimo aparece en un documento, en un lugar concreto, como un documento forma parte de una obra, y como tanto obras, como documentos, como scriptors pueden tener localizaciones asociadas que hacen referencia a la situaci´on geogr´afica de donde fueron escritos dichos archivos. Importancia Vital. Urgencia Inmediatamente. Estado Validado. Estabilidad Media. Tabla 3.9: RI.06 - Informaci´on de la interrelaci´on entre entidades del ILG 42 CAP´ ITULO 3. AN ´ ALISIS RI.07 Informaci´on externa Descripci´on El sistema en todo momento tiene que tener disponible la informaci´on relativa a los datos de los distintos mapas para poder obtener sus geometr´ıas. Importancia Vital. Urgencia Inmediatamente. Estado Validado. Estabilidad Media. Tabla 3.10: RI.07 - Informaci´on externa RI.08 Relaci´on de la informaci´on del ILG con informaci´on externa Descripci´on El sistema en todo momento tiene que tener disponible la informaci´on de c´omo se relaciona la informaci´on obtenida de la base de datos del ILG con la informaci´on obtenida de bases de datos de organismos p´ublicos, y a la que se hac´ıa referencia en el requisito RI.07. De modo que est´e claro c´omo se enlazan ambos tipos de informaci´on para poder mostrar las geograf´ıas de los top´onimos de los documentos. Importancia Vital. Urgencia Inmediatamente. Estado Validado. Estabilidad Media. Tabla 3.11: RI.08 - Relaci´on de la informaci´on del ILG con informaci´on externa 3.2.2. Requisitos no funcionales Los requisitos no funcionales representan restricciones que tiene que cumplir el sistema que no se expresen como uno de los dem´as tipos de requisitos. Especifica criterios que pueden usarse para juzgar la operaci´on de un sistema en lugar de sus comportamientos espec´ıficos, que ser´ıa trabajo de los requisitos funcionales. Los requisitos no funcionales del proyecto se pueden ver en las tablas 3.12-3.14 3.2. REQUISITOS DEL SOFTWARE 43 RNF.01 Tiempo de respuesta de la aplicaci´on Descripci´on La aplicaci´on tiene que tener un tiempo de respuesta lo m´as breve posible, teniendo que tardar menos de 1 segundo la carga de la lista de resultados o la tabla, o siendo inmediata la aparici´on de la ventana emergente para mostrar m´as informaci´on. Importancia Importante. Urgencia Inmediatamente. Estado Validado. Estabilidad Media. Tabla 3.12: RNF.01 - Tiempo de respuesta de la base de datos RNF.02 Protecci´on de datos Descripci´on Los datos personales que se incluyan en la base de datos tienen que estar correctamente protegidos. Importancia Vital. Urgencia Hay presi´on. Estado En construcci´on. Estabilidad Media. Tabla 3.13: RNF.02 - Protecci´on de datos RNF.03 Extensibilidad Descripci´on El dise˜no de la base de datos as´ı como el del Software debe tener en cuenta futuras modificaciones, y estar orientado a que se puedan a˜nadir m´as campos sin problema en el futuro. Importancia Quedar´ıa bien. Urgencia Hay presi´on. Estado Validado. Estabilidad Alta. Tabla 3.14: RNF.03 - Extensibilidad 50 CAP´ ITULO 3. AN ´ ALISIS CU.04 Ver informaci´on filtros en mapa Descripci´on El sistema debe comportarse tal y como se describe en el siguiente caso de uso cuando un usuario seleccione la opci´on ’Mapa’ en el men´u de la parte superior. Precondici´on - Escenario principal 1. Una vez que aparecen los datos en la lista de resultados, el usuario debe pulsar el bot´on ’Mapa’ de la parte superior de la pantalla 2. La aplicaci´on es redirigida hacia una nueva interfaz 3. Se cargan en el mapa los resultados de la lista Postcondici´on - Escenarios alternativos - Importancia Importante Urgencia Puede esperar Estado Validado Estabilidad Media Tabla 3.25: CU.04 - Ver informaci´on filtros en mapa 3.2. REQUISITOS DEL SOFTWARE 51 CU.05 Buscar en el mapa Descripci´on El sistema debe comportarse tal y como se describe en el siguiente caso de uso cuando un usuario seleccione la opci´on ’Mapa’ en el men´u de la parte superior. Precondici´on Que la opci´on ’B´usqueda geogr´afica’ del apartado filtros est´e activa. Escenario principal 1. La aplicaci´on es redirigida hacia una nueva interfaz 2. El usuario puede interaccionar con el mapa haciendo selecciones para buscar en determinadas zonas y visualizar la informaci´on Postcondici´on La lista de la p´agina principal se ir´a recargando con la informaci´on obtenida del mapa Escenarios alternativos 1. La aplicaci´on es redirigida hacia una nueva interfaz 2. El usuario puede interaccionar con el mapa haciendo selecciones para buscar en determinadas zonas y visualizar la informaci´on 3. El usuario tambi´en puede usar los filtros durante su interacci´on con el mapa Importancia Importante Urgencia Puede esperar Estado En construcci´on Estabilidad Media Tabla 3.26: CU.05 - Buscar en el mapa 52 CAP´ ITULO 3. AN ´ ALISIS CU.06 Ver informaci´on Descripci´on El sistema debe comportarse tal y como se describe en el siguiente caso de uso cuando un usuario seleccione el hiperenlace ’Info’ en la parte de abajo de la interfaz Precondici´on - Escenario principal 1. El usuario selecciona la opci´on ’Info’ 2. Se abre una ventana emergente con informaci´on sobre el ITGPA. Postcondici´on El usuario obtiene la informaci´on necesaria Escenarios alternativos - Importancia Importante Urgencia Hay presi´on Estado Validado Estabilidad Alta Tabla 3.27: CU.06 - Ver informaci´on CU.07 Ver ayuda Descripci´on El sistema debe comportarse tal y como se describe en el siguiente caso de uso cuando un usuario seleccione el hiperenlace ’Ayuda’ en la parte de abajo de la interfaz Precondici´on - Escenario principal 1. El usuario selecciona la opci´on ’Ayuda’ 2. Se abre una ventana emergente una explicaci´on sobre c´omo usar la aplicaci´on y que significa cada uno de los t´erminos utilizados. Postcondici´on El usuario obtiene la informaci´on necesaria Escenarios alternativos - Importancia Vital Urgencia Inmediatamente Estado Validado 3.2. REQUISITOS DEL SOFTWARE 53 CU.07 Ver ayuda Estabilidad Alta Tabla 3.28: CU.07 - Ver ayuda CU.08 Ver contacto Descripci´on El sistema debe comportarse tal y como se describe en el siguiente caso de uso cuando un usuario seleccione el hiperenlace ’Contacto’ en la parte de abajo de la interfaz Precondici´on - Escenario principal 1. El usuario selecciona la opci´on ’Contacto’ 2. Se abre una ventana con toda la informaci´on necesaria para contactar con el ILG. Postcondici´on El usuario obtiene la informaci´on necesaria Escenarios alternativos - Importancia Importante Urgencia Hay presi´on Estado Validado Estabilidad Alta Tabla 3.29: CU.08 - Ver contacto 54 CAP´ ITULO 3. AN ´ ALISIS CU.09 Ordenar tabla Descripci´on El sistema debe comportarse tal y como se describe en el siguiente caso de uso cuando un usuario pulse sobre la cabecera de la tabla una vez cargados los datos sobre ella Precondici´on Que la tabla tenga al menos dos filas de resultados Escenario principal 1. El usuario ha realizado el caso de uso ’Ver resultados b´usqueda filtrada’ 2. El usuario pulsa sobre una de las celdas de la cabecera de la tabla y la tabla se actualiza siguiendo ese criterio de ordenaci´on. Postcondici´on Se modifican los par´ametros de la tabla de forma que la pr´oxima vez que se ordene por esa celda sea en sentido contrario Escenarios alternativos - Importancia Estar´ıa bien Urgencia Hay presi´on Estado Validado Estabilidad Alta Tabla 3.30: CU.08 - Ordenar tabla Este segundo listado hace referencia a casos de uso realizados por el sistema despu´es de una acci´on del usuario. Van de la tabla 3.30 a la 3.33. CU.10 Actualizar lista Descripci´on El sistema debe comportarse tal y como se describe en el siguiente caso de uso cuando se realice una b´usqueda con los filtros. Precondici´on - Escenario principal 1. La aplicaci´on actualiza la lista de resultados con los resultados de la consulta Postcondici´on - Escenarios alternativos - 3.2. REQUISITOS DEL SOFTWARE 55 CU.10 Actualizar lista Importancia Vital Urgencia Inmediatamente Estado Validado Estabilidad Media Tabla 3.31: CU.10 - Actualizar lista CU.11 Actualizar tabla Descripci´on El sistema debe comportarse tal y como se describe en el siguiente caso de uso cuando se seleccione una opci´on de la lista de resultados Precondici´on - Escenario principal 1. La aplicaci´on actualiza la tabla de resultados con la informaci´on relativa a la selecci´on del usuario Postcondici´on - Escenarios alternativos - Importancia Vital Urgencia Inmediatamente Estado Validado Estabilidad Media Tabla 3.32: CU.11 - Actualizar tabla CU.12 Actualizar mapa Descripci´on El sistema debe comportarse tal y como se describe en el siguiente caso de uso cuando se haga uso del mapa informativo Precondici´on - Escenario principal 1. La aplicaci´on actualiza el mapa con la informaci´on de la lista de la p´agina principal Postcondici´on - 56 CAP´ ITULO 3. AN ´ ALISIS CU.12 Actualizar mapa Escenarios alternativos 1. La aplicaci´on actualiza el mapa con la informaci´on relativa a las consultas sobre el mapa del usuario Importancia Vital Urgencia Inmediatamente Estado En construcci´on Estabilidad Media Tabla 3.33: CU.12 - Actualizar mapa 3.2.3.2.2. Diagrama de casos de uso Se a˜nade a continuaci´on el diagrama de casos de uso del sistema. En el se pueden ver los casos de uso redactados anteriormente y las relaciones que tienen entre ellos. Como se puede ver en la figura 3.1, el actor ’Usuario’ est´a ligado directamente a los ochos casos de uso explicados en el listado inicial, pues son los que ´el produce directamente, nos referimos por tanto a los casos de uso coloreados en azul. Se puede ver, adem´as, como los otros tres casos de uso, los que marcamos en verde, est´an ligados a los otros con ’includes’, lo que implica que, por ejemplo, siempre que se efect´ue una ’B´usqueda filtrada’, obligatoriamente se efectuar´a ’Actualizar lista’. Esto quiere decir, que aunque el usuario no est´e ejecutando directamente la acci´on de actualizar la lista (que podr´ıa a˜nadirse mediante un bot´on), el sistema autom´aticamente lo har´a cuando se considere necesario. A mayores, tambi´en hay ’extends’, como entre ’Descargar informaci´on’ y ’Ver resultados b´usqueda filtrada’, lo que implica que para que se pueda ejecutar el caso de uso ’Descargar informaci´on’ debe haberse ejecutado previamente ’Ver resultados b´usqueda filtrada’. Este diagrama tambi´en est´a referenciado en el anexo A, diagrama de casos de uso, por si se desea una visi´on m´as precisa del mismo. 3.2. REQUISITOS DEL SOFTWARE 57 Figura 3.1: Diagrama de casos de uso 58 CAP´ ITULO 3. AN ´ ALISIS 3.2.4. Matriz de trazabilidad Se a˜nade a continuaci´on la matriz de trazabilidad 3.34, donde podremos ver la relaci´on de los requisitos funcionales con los casos de uso. RF.01 RF.02 RF.03 RF.04 RF.05 RF.06 RF.07 CU.01 X - - - - - - CU.02 X X - - - - - CU.03 X X X - - - - CU.04 X - - X - - - CU.05 - - - X X - - CU.06 -----XCU.07 -----XCU.08 -----XCU.09 X - - - - - X CU.10 X - - - - - - CU.11 X - - - - - - CU.12 X - - X X - - Tabla 3.34: Matriz de trazabilidad Cap´ıtulo 4 Dise˜no preliminar Se a˜nade a continuaci´on, el cap´ıtulo de dise˜no de la aplicaci´on. En esta secci´on haremos un dise˜no preliminar del sistema, que se podr´a retocar y ampliar su detalle dentro de cada uno de los apartados de dise˜no de los incrementos. Se har´a adem´as una propuesta de c´omo ser´ıa la interfaz gr´afica. 4.1. Dise˜no de software A continuaci´on, se a˜nadir´an una serie de diagramas para aclarar la forma que tiene el sistema. 4.1.1. Diagrama de arquitectura En la figura 4.1, se puede ver el diagrama de arquitectura de nuestro sistema. En ´el, se puede comprobar que el sistema est´a formado por una base de datos, de la cual detallaremos su dise˜no m´as adelante, la propia arquitectura del servidor geogr´afico, que har´a de enlace entre esta base de datos y la aplicaci´on web. Para ello utilizaremos la interfaz WFS. 4.1.2. Diagrama de contexto En la figura 4.2 se puede ver el diagrama de contexto. Con ´el lo que se pretende mostrar es las interacciones que tiene el sistema con agentes externos. En este caso, como se puede ver, solo tiene interacciones con el usuario, ya que las bases de externas est´an descargadas e incluidas como parte del sistema ITGPA. 4.2. Dise˜no de la base de datos Se a˜nade a continuaci´on el dise˜no de la base de datos para ITGPA. Este es posiblemente el apartado m´as importante, ya que es el n´ucleo del sistema que 59 66 CAP´ ITULO 4. DISE ˜ NO PRELIMINAR CLAVE EXTERNA: idToponimo REFERENCIA Toponimo (id) Borrado: Restringido, Actualizaci´on: Cascada EditorO (editor, acronimoO) CLAVE PRIMARIA: editor, editorO CLAVE EXTERNA: acronimoO REFERENCIA Obra (acronimo) Borrado: Restringido, Actualizaci´on: Cascada Scriptor (id, nombreConFormula, notarioVarios, notarioPrimerNotario, formaLiteralJurisdiccion, idJustificacion, idToponimoL4) CLAVE PRIMARIA: id CLAVE EXTERNA: notarioVarios REFERENCIA Notario (id) Borrado: Restringido, Actualizaci´on: Cascada CLAVE EXTERNA: notarioPrimerNotario REFERENCIA Notario (id) Borrado: Restringido, Actualizaci´on: Cascada CLAVE EXTERNA: idJustificacion REFERENCIA Justificacion (id) Borrado: Restringido, Actualizaci´on: Cascada CLAVE EXTERNA: idToponimo REFERENCIA Toponimo (id) Borrado: Restringido, Actualizaci´on: Cascada Notario (id, formaLiteral, formaModerna) CLAVE PRIMARIA: id Justificacion (id, valor) CLAVE PRIMARIA: id Lengua (id, valor) CLAVE PRIMARIA: id LenguaDocumento (idLengua, idDoc) CLAVE PRIMARIA: idLengua, idDoc CLAVE EXTERNA: idLengua REFERENCIA Lengua (id) Borrado: Restringido, Actualizaci´on: Cascada CLAVE EXTERNA: idDoc REFERENCIA Documento (id) Borrado: Restringido, Actualizaci´on: Cascada LenguaDocumentoOriginal (idLengua, idDoc) CLAVE PRIMARIA: idLengua, idDoc CLAVE EXTERNA: idLengua REFERENCIA Lengua (id) Borrado: Restringido, Actualizaci´on: Cascada CLAVE EXTERNA: idDoc REFERENCIA Documento (id) Borrado: Restringido, Actualizaci´on: Cascada 4.2. DISE ˜ NO DE LA BASE DE DATOS 67 LenguaToponimo (idLengua, idAparecer) CLAVE PRIMARIA: idLengua, idAparecer CLAVE EXTERNA: idLengua REFERENCIA Lengua (id) Borrado: Restringido, Actualizaci´on: Cascada CLAVE EXTERNA: idAparecer REFERENCIA Aparecer (id) Borrado: Restringido, Actualizaci´on: Cascada InvestigadorCGPA (id, nombre, apellidos) CLAVE PRIMARIA: id InvestigadorITGPA (id, nombre, apellidos) CLAVE PRIMARIA: id Aparecer (id, idDocumento, idToponimo, numPagina, formaToponimicaLiteral, advocacionModernizada, errata, formaAutentica, formaOnomastica, bibliograf´ıa, contextoTextual, tipoLengua, idInvestigadorITGPA, procesarFechaITGPA, idEstructuraToponimica, idTransmisionToponimica) CLAVE PRIMARIA: id CLAVE EXTERNA: idDocumento REFERENCIA Documento (id) Borrado: Restringido, Actualizaci´on: Cascada CLAVE EXTERNA: idToponimo REFERENCIA Toponimo (id) Borrado: Restringido, Actualizaci´on: Cascada CLAVE EXTERNA: idInvestigadorITGPA REFERENCIA InvestigadorITGPA (id) Borrado: Restringido, Actualizaci´on: Cascada CLAVE EXTERNA: idEstructuraToponimica REFERENCIA EstructuraToponimica (id) Borrado: Restringido, Actualizaci´on: Cascada CLAVE EXTERNA: idTransmisionToponimica REFERENCIA TransmisionToponimica (id) Borrado: Restringido, Actualizaci´on: Cascada EstructuraToponimica (id, valor) CLAVE PRIMARIA: id TransmisionToponimica (id, valor) CLAVE PRIMARIA: id Toponimo (id, lema1, lema2, lema3, advocacion, tipo1, tipo2, tipo3, idNomenclator, tipo, codigoINE) CLAVE PRIMARIA: id OtrasDenominacionesToponimo (idToponimo, denominacion) 68 CAP´ ITULO 4. DISE ˜ NO PRELIMINAR CLAVE PRIMARIA: idToponimo, denominaci´on CLAVE EXTERNA: idToponimo REFERENCIA Toponimo (id) Borrado: Restringido, Actualizaci´on: Cascada Diocesis (idToponimo) CLAVE PRIMARIA: idToponimo CLAVE EXTERNA: idToponimo REFERENCIA Toponimo (id) Borrado: Restringido, Actualizaci´on: Cascada Arciprestado (idToponimo, idToponimoDiocesis) CLAVE PRIMARIA: idToponimo CLAVE EXTERNA: idToponimo REFERENCIA Toponimo (id) Borrado: Restringido, Actualizaci´on: Cascada CLAVE EXTERNA: idToponimoDiocesis REFERENCIA Diocesis (idToponimo) Borrado: Restringido, Actualizaci´on: Cascada Parroquia (idToponimo, idToponimoArciprestado, idToponimoL4) CLAVE PRIMARIA: idToponimo CLAVE EXTERNA: idToponimo REFERENCIA Toponimo (id) Borrado: Restringido, Actualizaci´on: Cascada CLAVE EXTERNA: idToponimoArciprestado REFERENCIA Arcirprestado (idToponimo) Borrado: Restringido, Actualizaci´on: Cascada CLAVE EXTERNA: idToponimoL4 REFERENCIA L4 (idToponimo) Borrado: Restringido, Actualizaci´on: Cascada L0 (idToponimo, pol´ıgono, codigoL0) CLAVE PRIMARIA: idToponimo CLAVE EXTERNA: idToponimo REFERENCIA Toponimo (id) Borrado: Restringido, Actualizaci´on: Cascada L1 (idToponimo, pol´ıgono, codigoL1, idToponimoL0) CLAVE PRIMARIA: idToponimoL0 CLAVE EXTERNA: idToponimo REFERENCIA Toponimo (id) Borrado: Restringido, Actualizaci´on: Cascada CLAVE EXTERNA: idToponimoL0 REFERENCIA L0 (idToponimo) Borrado: Restringido, Actualizaci´on: Cascada L2 (idToponimo, pol´ıgono, codigoINE, idToponimoL1) CLAVE PRIMARIA: idToponimo CLAVE EXTERNA: idToponimo REFERENCIA Toponimo (id) Borrado: Restringido, Actualizaci´on: Cascada 4.2. DISE ˜ NO DE LA BASE DE DATOS 69 CLAVE EXTERNA: idToponimoL1 REFERENCIA L1 (idToponimo) Borrado: Restringido, Actualizaci´on: Cascada L4 (idToponimo, pol´ıgono, codigoINE, idToponimoL2) CLAVE PRIMARIA: idToponimo CLAVE EXTERNA: idToponimo REFERENCIA Toponimo (id) Borrado: Restringido, Actualizaci´on: Cascada CLAVE EXTERNA: idToponimoL2 REFERENCIA L2 (idToponimo) Borrado: Restringido, Actualizaci´on: Cascada Lugar (idToponimo, punto, idTipologia) CLAVE PRIMARIA: idToponimo CLAVE EXTERNA: idToponimo REFERENCIA Toponimo (id) Borrado: Restringido, Actualizaci´on: Cascada CLAVE EXTERNA: idTipologia REFERENCIA TipologiaReferencial (id) Borrado: Restringido, Actualizaci´on: Cascada L4Lugar (idToponimoL4, idToponimoLugar) CLAVE PRIMARIA: idToponimoL4, idToponimoLugar CLAVE EXTERNA: idToponimoL4 REFERENCIA l4 (id) Borrado: Restringido, Actualizaci´on: Cascada CLAVE EXTERNA: idToponimoLugar REFERENCIA Lugar (idToponimo) Borrado: Restringido, Actualizaci´on: Cascada TipologiaReferencial (id, valor) CLAVE PRIMARIA: id 4.2.3. Diccionario de datos A continuaci´on, se a˜nade el diccionario de datos. En la primera tabla, se puede ver la informaci´on de las entidades que hay, que representan y el n´umero de instancias que puede haber de ellas. A mayores, para algunas, en el anexo C, est´a especificado los datos que permiten, por ser estos listas cerradas. 70 CAP´ ITULO 4. DISE ˜ NO PRELIMINAR Entidad Descripci´on N´umero de instancias Ver anexo TipoEmisorDestinatario Tipo de la persona que env´ıa o recibe el documento N´umero fijo de posibilidades de una lista S´ı Emisor Persona que env´ıa el documento Tantos como emisores de documentos distintos haya S´ı Destinatario Persona que recibe el documento Tantos como destinatarios distintos haya S´ı Transmisi´on Modo de transmisi´on del documento N´umero fijo de posibilidades de una lista S´ı Documento Documento antiguo que se est´a estudiando Tantos como documentos distintos haya No Scriptor Grupo de personas que redactaron el documento Tanto como scriptors distintos haya No Notario Persona encargada de redactar el documento Tantos como notarios distintos haya No Justificacion Motivo que explica por qu´e se escribi´o un documento N´umero fijo de posibilidades de una lista S´ı Obra Conjunto de documentos Tantos como obras distintas haya S´ı Investigador Persona f´ısica que estudia un campo Ninguna No InvestigadorITGPA Investigador parte del grupo ITGPA que procesa top´onimos Tantos como investigadores distintos del ITGPA haya No InvestigadorCGPA Investigador parte del grupo CGPA que procesa documentos Tantos como investigadores distintos del CGPA haya No 4.2. DISE ˜ NO DE LA BASE DE DATOS 71 Entidad Descripci´on N´umero de instancias Ver anexo Lengua Idioma en el que se escribe una determinada palabra o conjunto de palabras N´umero fijo de posibilidades de una lista S´ı Toponimo Nombre propio de lugar Tantos como top´onimos haya entre las bases de datos mundiales y los documentos No EstructuraToponimica Estructura en la que est´a representado un top´onimo N´umero fijo de posibilidades de una lista S´ı TransmisionToponimica Forma de transmisi´on de un top´onimo N´umero fijo de posibilidades de una lista S´ı EntidadDesaparecida Top´onimo que no existe en la actualidad Ninguna No EntidadDenotada Top´onimo que existe en la actualidad Ninguna No Eclesiastica Top´onimo que es una entidad eclesi´astica Ninguna No Diocesis Tipo de entidad eclesi´astica de mayor nivel Tantas como di´ocesis haya No Arciprestado Tipo de entidad eclesi´astica de nivel medio Tantas como arciprestazgos haya No Parroquia Tipo de entidad eclesi´astica de menor nivel Tantas como parroquias haya No Civil Top´onimo que es una entidad civil Ninguna No L0 Tipo de entidad civil de mayor nivel Tantas como pa´ıses haya No 72 CAP´ ITULO 4. DISE ˜ NO PRELIMINAR Entidad Descripci´on N´umero de instancias Ver anexo L1 Tipo de entidad civil de segundo nivel Tantas como comunidades aut´onomas (o equivalentes en otros pa´ıses) haya No L2 Tipo de entidad civil de tercer nivel Tantas como provincias (o equivalentes en otros pa´ıses) haya No L4 Tipo de entidad civil de menor nivel Tantas como municipios haya No Lugar Cada uno de los lugares referidos en el Nomenclator Tantas como entradas haya en el nomenclator, eliminando duplicados con otras tablas de entidades civiles No TipologiaReferencial Tipo que presenta el top´onimo N´umero fijo de posibilidades de una lista S´ı Tabla 4.1: Diccionario de datos. 4.2. DISE ˜ NO DE LA BASE DE DATOS 73 A mayores, como se puede ver en la figura 4.2, se ven reflejados los tipos de datos de cada uno de los atributos, si es obligatorio que est´en o no, y caracter´ısticas de las relaciones entre las entidades. 74 CAP´ ITULO 4. DISE ˜ NO PRELIMINAR Entidad/ Relaci´on Atributos Descripci´on Tipo de dato N M D P OR TipoEmisorid Clave que identifica un tipo de emisor o destinatario varchar[5] S´ı No No - - Destinatario valor Valor en cuesti´on varchar[100] S´ı No No - - Emisor identidad Identidad del emisor del documento varchar[500] S´ı No No - - Destinatario identidad Identidad del receptor del documento varchar[500] S´ı No No - - Transmisi´on identidad Clave que identifica un m´etodo de transmisi´on varchar[5] S´ı No No - - tipolog´ıa Tipo de m´etodo en cuesti´on varchar[500] S´ı No No - - Documento id N´umero descriptivo del documento integer S´ı No No - - a˜noOI Inicio del rango en que se cree que se public´o el libro original int S´ı No No - - a˜noOF Fin del rango en que se cree que se public´o el libro original int S´ı No No - 1 1Si es igual a a˜noOI, el ILG est´a seguro de la publicaci´on 4.2. DISE ˜ NO DE LA BASE DE DATOS 75 Entidad/ Relaci´on Atributos Descripci´on Tipo de dato N M D P OR a˜noCI Inicio del rango en que se cree que se public´o la copia int S´ı No No - 2 a˜noCF Fin del rango en que se cree que se public´o la copia int S´ı No No - 3 mes Mes de publicaci´on int S´ı No No - 4 dia D´ıa de publicaci´on int S´ı No No - 5 textoGeografiaMencionada Parte del documento con la aparici´on de top´onimos text S´ı No No - - tipoLenguaDocumento Tipo de codificaci´on de la lengua del documento que nos ocupa varchar[50] S´ı No No - - tipoLenguaOriginal Tipo de codificaci´on de la lengua del documento original en el que puede estar basado el que nos ocupa varchar[50] S´ı No No - - 2Si es igual al a˜noOI,es el original 3Si es igual al a˜noOF,es el original 4Del original en caso de copia 5Del original en caso de copia 82 CAP´ ITULO 4. DISE ˜ NO PRELIMINAR Entidad/ Relaci´on Atributos Descripci´on Tipo de dato N M D P OR lema2 Palabra que nombra al top´onimo varchar[100] S´ı No No - 6 lema3 Palabra que nombra al top´onimo varchar[100] S´ı No No - 7 advocacion Advocaci´on en su forma moderna varchar[100] S´ı No No - - otrasDenominaciones Distintas formas de nombrar al mismo top´onimo varchar[100] S´ı S´ı No - - idNomenclator Id que aparece en la base de datos del Nomenclator int S´ı No No - 8 tipo Tipo de la jerarqu´ıa a la que pertenece el top´onimo varchar[100] S´ı No No - - codigoINE C´odigo identificativo en el nomenclator espa˜nol. Solo se rellenar´a para Espa˜na, en L2 y L4 int S´ı No No - - 6Se usa para ponerlo en varios idiomas en casos con varias denominaciones 7Se usa para ponerlo en varios idiomas en casos con varias denominaciones 8Usado solo para algunos top´onimos espa˜noles 4.2. DISE ˜ NO DE LA BASE DE DATOS 83 Entidad/ Relaci´on Atributos Descripci´on Tipo de dato N M D P OR lugarEdicion formaLiteral Lugar de edici´on de la obra en la forma en la que sale en dicha obra varchar[100] S´ı No No - - EntidadDesaparecida EntidadDenotada Eclesiastica Civil Diocesis Arciprestado Parroquia L0 poligono Forma geom´etrica del terreno geometry S´ı No No - - codigoL0 C´odigo identificativo de L0 en las bases de datos oficiales int S´ı No No - - L1 poligono Forma geom´etrica del terreno geometry S´ı No No - - codigoL1 C´odigo identificativo de L1 en las bases de datos oficiales int S´ı No No - - 84 CAP´ ITULO 4. DISE ˜ NO PRELIMINAR Entidad/ Relaci´on Atributos Descripci´on Tipo de dato N M D P OR L2 poligono Forma geom´etrica del terreno geometry S´ı No No - - codigoINE C´odigo identificativo de L2 en las bases de datos oficiales int S´ı No No - - L4 poligono Forma geom´etrica del terreno geometry S´ı No No - - codigoINE C´odigo identificativo de L4 en las bases de datos oficiales int S´ı No No - - lugar punto Punto en el que se sit´ua un lugar concreto en el mapa geometry S´ı No No - - Tipologiaid Clave que identifica una tipolog´ıa varchar[10] S´ı No No - - Referencial valor Nombre de la tipolog´ıa en cuesti´on varchar[100] S´ı No No - - Tabla 4.2: Diccionario de datos. 4.3. DISE ˜ NO GR ´ AFICO 85 4.3. Dise˜no gr´afico Todos los dise˜nos utilizados en este apartado pueden encontrarse en el anexo A, propuesta gr´afica. 4.3.1. Dise˜no de interfaces En esta secci´on pondremos la idea inicial propuesta por el cliente, tal y como se puede ver en la figura 4.7 y la propuesta gr´afica que gener´o, que se puede ver en las figuras 4.8-4.10, despu´es de realizar modificaciones en una de las reuniones. Para cada una de las im´agenes de la propuesta, explicaremos las medidas utilizadas para mejorar la IPO9de la aplicaci´on. Figura 4.7: Idea inicial de interfaz. Como se puede ver en la figura 4.7, la propuesta dada por el cliente, m´as la puntualizaci´on de que, en general, deber´ıa tener una estructura similar a la p´agina web actual, explicada en el apartado de ’Motivaci´on y contexto’, es el de una p´agina dividida en secciones con los filtros a la izquierda y los resultados a la derecha, y como pone arriba, dividiendo la b´usqueda en tres formas principales. Por tanto, se han creado las tres im´agenes que se pueden ver a continuaci´on. En la figura 4.8 podemos ver la p´agina principal de la aplicaci´on. En ella destacan los colores blanco y gris, sobre un fondo aclarado de una playa gallega. La elecci´on de colores se ha hecho en base a que resulte visualmente c´omoda y poco recargada, sin colores que fatiguen la vista, ya que se puede suponer que si bien, usuarios espor´adicos, la usen poco tiempo, investigadores del ILG pueden dedicar mucho tiempo a su uso. 9Interacci´on persona-ordenado: ”La disciplina dedicada a dise˜nar, evaluar e implementar sistemas inform´aticos interactivos para el uso humano”[4] 86 CAP´ ITULO 4. DISE ˜ NO PRELIMINAR Figura 4.8: P´agina principal. En la zona superior, hay un men´u con los t´erminos ’Listaxe’ y ’Mapa’, resaltando en gris el que est´a escogido en el momento actual. A la derecha se ve un desplegable donde tambi´en estar´an estos t´erminos para pantallas m´as reducidas. En la zona inferior, pueden verse a la derecha las opciones ’Info’, ’Axuda’ y ’Contacto’, para obtener la informaci´on relativa a cada una de estas opciones, informaci´on sobre el ITGPA, ayuda sobre c´omo utilizar la aplicaci´on o qu´e formas hay de contactar con el ILG. La zona central de la imagen se divide a su vez en tres secciones, la parte de filtros, la parte de resultados y la tabla informativa. Las dos primeras, al tener un tama˜no fijo, se mantendr´an siempre en la p´agina de modo que sea muy f´acil para el usuario, modificar la selecci´on que se est´a viendo en la tabla. En esta tabla aparece la informaci´on que se indica en el encabezado para la selecci´on del listado de resultados. En la secci´on ’Filtros’, se pueden ver los filtros b´asicos, que se acordar´an con el cotutor, y un desplegable para los filtros exhaustivos, de modo que el usuario no quede saturado con demasiadas opciones, sino que pueda escoger el nivel de detalle con el que quiere buscar. Aparece tambi´en abajo de esta secci´on el bot´on para buscar y para borrar los filtros impuestos. Justo encima de ellos aparece un ’check-box’ para seleccionar la b´usqueda geogr´afica, de modo que el mapa no sirva solo para visualizar la informaci´on, sino que se pueda utilizar directamente para realizar b´usquedas, filtrando sobre ´el. La secci´on del centro ’Resultados’, se actualiza con la b´usqueda realizada en la secci´on anterior, por defecto, si no se realiza ninguna b´usqueda, aparecer´an los top´onimos modernos por orden alfab´etico ascendente. Finalmente, la secci´on relativa a la tabla. Esta aparecer´a por defecto vac´ıa, y se rellenar´a con la informaci´on relativa a la selecci´on marcada en el apartado ’Resultados’. El encabezado de la tabla sirve como forma de ordenar los resultados, por cada uno de ellos y de forma ascendente o descendente. La cabecera de 4.3. DISE ˜ NO GR ´ AFICO 87 la tabla contendr´a los t´erminos que vienen a continuaci´on, que explicar´an el contenido de las columnas: ’Cronolox´ıa’, ’Obra’, ’Node documento’, ’Xeograf´ıa do notario’, ’Lingua do documento’, ’Transmisi´on textual’, ’Forma topon´ımica literal’, ’Lingua da forma topon´ımica literal’, ’Nome do notario (forma regularizada ´a moderna)’ y ’Lema moderno’. A la izquierda de la tabla se pueden ver unos ’check-boxs’ que se usar´an para marcar que informaci´on se quiere descargar. En la parte superior tenemos la opci´on de marcarlos todos o ninguno. A la derecha del bot´on ’Descargar’ situado encima de la esquina superior derecha de la tabla, se puede ver un desplegable para seleccionar el formato de descarga. De esta forma, la p´agina principal de la aplicaci´on intenta ser sobria y elegante, con colores claros como se ha explicado anteriormente. Para ver la informaci´on, es necesario un n´umero de ’clicks’ de rat´on m´ınimos, ya que simplemente hay que seleccionar los filtros deseados (o ninguno), la opci´on favorita de los resultados y la informaci´on aparecer´a directamente. A mayores, se intenta que la p´agina no est´e recargada, por lo que se a˜naden desplegables para selecciones m´as espec´ıficas (filtros exhaustivos y formato de descarga), aunque esto a˜nade ’clicks’ de rat´on, hace la interfaz m´as clara y c´omoda de usar. Para ir a la figura 4.9, es necesario pulsar sobre una de las filas de la tabla. Figura 4.9: P´agina principal, m´as informaci´on. En la figura superior, se puede ver que, el resto de la informaci´on que no aparece en la tabla aparece en una ventana emergente al pulsar sobre una de las opciones. En este pop-up, tenemos varias pesta˜nas para ver toda la informaci´on que el cliente desee incluir. Se genera un fondo gris sobre el resto de la p´agina para centrar la atenci´on del usuario en la ventana central. La informaci´on se muestra de esta manera por dos motivos, el primero es no sobrecargar la tabla, ya que, si se a˜nade mucha informaci´on, puede pasar que las columnas sean demasiado finas con lo que la informaci´on no se ver´ıa, o que cada resultado tenga varias filas lo que podr´ıa ser confuso. El otro motivo es poder ver 88 CAP´ ITULO 4. DISE ˜ NO PRELIMINAR toda la informaci´on sin tener que descargar ning´un archivo, y que esto se haga solo por motivos espec´ıficos relativos, por ejemplo, a la investigaci´on. Finalmente, en la figura 4.10, se puede ver la p´agina relativa al mapa, como marca el men´u superior con el destacado en gris. Figura 4.10: P´agina del mapa. En esta p´agina se mantienen las secci´on de filtros y se sustituye la tabla por un mapa. En la zona en blanco a la derecha del mapa, se pondr´a la leyenda de este o incluso opciones para la b´usqueda filtrada si es que se ha marcado el ’check-box’ relativo a este tema en la secci´on de filtros. Este mapa tendr´a zonas o puntos marcados que se corresponder´an con los resultados de la lista que se puede ver en ’index’, y para cada uno de ellos, al pulsar sobre ´el saldr´a una tabla para seleccionar una de las opciones, que se corresponder´an con la informaci´on que saldr´ıa en la tabla de la pesta˜na explicada anteriormente. Tambi´en estar´a habilitada la ventana emergente para dar m´as informaci´on. 4.3.2. Storyboard En este apartado explicaremos con m´as detalle el funcionamiento de la p´agina web. Para esto, utilizaremos las im´agenes del dise˜no ense˜nadas anteriormente, con una serie de flechas numeradas. Pondremos tres ejemplos, con algunas variantes dentro del mismo, aunque cabr´ıan m´as posibilidades de uso. 4.3.2.1. B´usqueda b´asica y variantes En este primer ejemplo. Explicaremos c´omo realizar una b´usqueda b´asica, c´omo funcionan los botones de ayuda y c´omo descargar. En la figura 4.11, podemos ver la p´agina principal de la aplicaci´on. B´usqueda b´asica 4.3. DISE ˜ NO GR ´ AFICO 89 Figura 4.11: B´usqueda b´asica y variantes Si nos fijamos en la flecha no1, vemos que podemos seleccionar un resultado directamente, sin utilizar los filtros, ya que por defecto aparecen top´onimos actuales ordenados alfab´eticamente de forma ascendente. La flecha no2, nos indica que autom´aticamente la tabla se recarga con la informaci´on y podremos verla directamente, con lo que concluir´ıa la b´usqueda b´asica. Descarga Por otro lado, las flechas no3 nos indican que podemos seleccionar cualquiera de los ’check-box’ a la izquierda de la tabla, o los que hay en la parte superior. Este paso no es necesario realizarlo siempre, pero si se hace, debe ser despu´es de aquellos marcados por las flechas no1 y 2. La flecha no4 indica la situaci´on del bot´on para efectuar la descarga. No est´a marcado, pero a la derecha del bot´on marcado por la flecha no4, tenemos el desplegable para seleccionar el formato, esto debe hacerse antes de pulsar el bot´on comentado. Informaci´on, ayuda y contacto Lo explicado por la flecha no5, es la situaci´on de los enlaces para obtener informaci´on, ayuda o modo de contacto. Esto puede hacerse en cualquier momento de cualquier operaci´on o incluso sin haber realizado ning´un paso antes. De hecho, se recomienda que, de no ser un usuario familiarizado con el inventario, se consulte la ayuda antes de hacer cualquier otra cosa. 4.3.2.2. B´usqueda filtrada La b´usqueda filtrada se explica a trav´es de las figuras 4.12 y 4.13. En la figura 4.12, podemos ver como la flecha no1 indica la secci´on de filtros. En ella, el usuario podr´a seleccionar todas las opciones que desee de la b´usqueda 90 CAP´ ITULO 4. DISE ˜ NO PRELIMINAR Figura 4.12: B´usqueda filtrada, primera p´agina simple o desplegar m´as filtros pulsado en desplegable en b´usqueda exhaustiva. Despu´es de realizar la selecci´on, pulsar´a el bot´on ’Buscar’ marcado por la flecha no2 y el sistema realizar´a la b´usqueda que rellenar´a la lista de resultados. Seguidamente, seleccionar´a uno de los resultados marcados por la flecha no3 y la tabla se actualizar´a con la informaci´on relacionada. Pulsando sobre una de las filas, tal y como indica la flecha no4 llegaremos a la p´agina que se puede ver en la figura 4.13. Figura 4.13: B´usqueda filtrada, segunda p´agina Tal y como se puede ver en la figura 4.13, el pulsar sobre una fila genera una ventana emergente con m´as informaci´on sobre la selecci´on escogida. Las flechas no5 indican la posibilidad del usuario de marcar cada una de las pesta˜nas que contendr´an informaci´on distinta. Obviamente, estas pesta˜nas tendr´an nombres m´as indicativos que ’Informaci´on’. En el momento que termine de consultar la informaci´on deseada, el usuario pulsar´a el bot´on marcado por la flecha no6 para volver a la interfaz de la figura 4.12. 4.3. DISE ˜ NO GR ´ AFICO 91 4.3.2.3. B´usqueda geogr´afica La b´usqueda geogr´afica se explica a trav´es de las figuras 4.14 y 4.15. Figura 4.14: B´usqueda geogr´afica, primera p´agina Como se puede ver en la figura 4.14, la diferencia entre una b´usqueda normal y una geogr´afica est´a en la secci´on de filtros. Para poder hacer una b´usqueda geogr´afica, despu´es de marcar los filtros deseados, es importante que el usuario marqu´e el ’check-box’ se˜nalado por la flecha no1 antes de darle a buscar. En este momento, el usuario puede realizar todos los pasos especificados para la ’B´usqueda filtrada’, en especial el no2 y no3. En el momento que quiera hacer la b´usqueda geogr´afica, debe pulsar el hiperenlace marcado por la flecha no2. Esto lo llevar´a a la interfaz que se puede ver en la figura 4.15. Figura 4.15: B´usqueda geogr´afica, segunda p´agina En la figura superior se puede ver un mapa, en la aplicaci´on real est´e tendr´ıa marcados los top´onimos que se obtuviesen por la selecci´on marcada en ’B´usqueda filtrada’ y que coinciden con la lista de resultados de dicha interfaz. La flecha no3 98CAP´ ITULO 5. INCREMENTO UNO. B ´ USQUEDA Y EXPLORACI ´ ON CONVENCIONAL Figura 5.3: Ayudante de postgis. 9. Insertar desde lugarNomenclator a la tabla Toponimo de la base de datos los campos necesarios. 10. Insertar en la tabla Lugar los datos. Haciendo para ello un join entre lugarNomenclator y Toponimo por idNomenclator. En este punto tambi´en es necesario pasar de las coordenadas en latitud y longitud a punto, usando el sistema de coordenadas correcto. 11. Finalmente, tenemos que rellenar la tabla L4Lugar, que simboliza la relaci´on entre L4 y Lugar, ya que un lugar puede estar en varios municipios y un municipio tener muchos lugares. Para ello hacemos un join entre la tabla toponimo y lugarMunicipio por el idNomenclator y entre lugarMunicipio y l4 por codigoINE. De esta forma, conseguimos las claves primarias de las dos tablas, ya que en este caso la tabla toponimo est´a representando a la tabla lugar. El c´odigo para realizar los pasos anteriores se puede ver en el A ’C´odigo’-’BD’, en el archivo ’InsercionDatosGeograficos’ En lo referente a las estructuras auxiliares, es necesario hacer un par de apreciaciones. Se puede ver en el c´odigo, que finalmente se han tenido que hacer modificaciones en algunas tablas, o dejar de meter algunos datos planeados por la 5.2. IMPLEMENTACI ´ ON 99 imposibilidad de hacerlo. Esto ha sido debido a una serie de problemas que se detallan a continuaci´on: Como se puede ver, el script est´a dividido en dos secciones, la introducci´on de datos para Espa˜na, y para el resto del mundo, y dentro de est´a ´ultima divisi´on, vuelven a dividirse. Esto es debido a que debido a limitaciones en el ordenador de desarrollo, y al tama˜no de la base de datos con la que se est´a trabajando, no ha sido posible introducir datos de todos los pa´ıses, y solo se han introducido para las pruebas datos de Espa˜na. De todos modos, aunque se pudiesen insertar todos, teniendo en cuenta que para Espa˜na adem´as tenemos que trabajar con el Nomenclator, es necesario replicar los pasos distintivos. En la tabla gadm36, un mismo municipio puede estar dividido en dos filas distintas, con dos ids distintos aun con mismo nombre si es que su geometria no est´a completamente unida. Un ejemplo puede ser ’Sevilla’. Por tanto, hay que agruparlos por provincia, ya que puede darse el caso de tener dos municipios con el mismo nombre en provincias distintas que s´ı son distintos. Hay un par de casos en que dos municipios distintos, con distinto name 4 tienen el mismo varname 4 y adem´as est´an en la misma provincia. Se ha comprobado, y son municipios distintos, por lo que no se puede guardar el varname 4 de los municipios, ya que puede dar problemas. Finalmente, Ceuta y Melilla tambi´en suponen un problema, ya que no salen en la tabla L2. 5.2.1.0.3. Scripts de inserci´on A mayores, tanto para realizar las pruebas como la demo del TFG, es necesario insertar datos proporcionados por el ILG. En este caso pueden verse en el A ’C´odigo’-’BD’, en el archivo ’insercionDatosILG’. Este c´odigo tiene que ejecutarse despu´es del indicado en el apartado anterior. Es importante dividir este archivo en dos partes, seg´un lo que se hace en cada una de ellas. La primera parte, hace referencia a los inserts de los datos de las tablas que contienen un par id-valor. Estos datos siempre hay que a˜nadirlos a la base de datos para su correcto funcionamiento, y pueden ser a˜nadidos m´as inserts, si con el tiempo se clasifican siguiendo otras categor´ıas. Lo que se pretende marcando los tipos de esta forma, es que la inclusi´on o eliminaci´on de tipos no implique una modificaci´on de la estructura de la base de datos. En el apartado de creaci´on de la base de datos, se puede ver que algunos ’create table’ tienen ’checks’ para 100CAP´ ITULO 5. INCREMENTO UNO. B ´ USQUEDA Y EXPLORACI ´ ON CONVENCIONAL garantizar tipos. La diferencia entre unos y otros radica en la creencia de que los tipos que tienen checks no van a ser modificados a lo largo del tiempo. Por otro lado, en este archivo tambi´en se pueden ver una serie de consultas para introducir datos procedentes de Excels. Estos datos vienen proporcionados por el ILG, y como se ha comentado son para pruebas del sistema. En el momento en que el otro sistema, diferente del alcance de este TFG, est´e listo para la inclusi´on de datos no ser´ıa necesario ejecutar dicho c´odigo. Tenemos adem´as otro archivo donde se puede ver la creaci´on de una serie de vistas. Esto se hace ya que las consultas a la base de datos se har´an a trav´es de las capas copiadas a Geoserver. En este tipo de peticiones, solo podremos usar la condici´on ’WHERE’ de SQL, por lo que es necesario tener todos los datos en una ´unica tabla. 5.2.1.0.4. Configuraci´on del servidor geogr´afico Finalmente, tenemos que a˜nadir las vistas y tablas que hemos creado en los apartados anteriores al servidor de mapas, en nuestro caso, Geoserver. La explicaci´on de c´omo configurarlo est´a en D, ’Manual de usuario’. Una vez correctamente configurado, tenemos que crear un nuevo almac´en de datos. Para hacer esto, pulsamos sobre el enlace que aparece marcado por la flecha no1 en la figura 5.4. El men´u lateral est´a disponible en todas las p´aginas, y pulsando sobre ´el en verdad llegamos a la p´agina que se puede ver en la figura. A continuaci´on, tenemos que pulsar sobre ’Agregar un nuevo almac´en’, que aparece marcado por la flecha no2. Figura 5.4: Creamos un almac´en de datos En la p´agina que nos aparezca, simplemente tenemos que seleccionar la opci´on ’PostGIS - PostGIS Database’ y posteriormente cubrir los campos que se nos 5.2. IMPLEMENTACI ´ ON 101 pidan con los datos de la base de datos que hemos creado en PostgreSQL. Una vez tengamos creado el almac´en, es necesario a˜nadir las capas (ya sean tablas o vistas) que hemos creado. Para hacer esto, tal y como aparece en la figura 5.5, pulsamos sobre ’Capas’ y posteriormente sobre ’Agregar nuevo recurso’. Figura 5.5: Creamos una capa En la pantalla siguiente, en el desplegable, tenemos que seleccionar el almac´en de datos que acabamos de crear, y seguidamente escoger, entre todas las vistas y tablas que tiene esa base de datos, la que queremos y pulsar en ’Publicar’. En la pantalla que saldr´a a continuaci´on, podremos ver los datos de la capa que estamos a˜nadiendo, lo m´as importante de esta pantalla es lo que aparece en la figura 5.6. Es muy importante que, para las tablas con componente geom´etrica, rellenemos los datos pulsando sobre ’Calcular desde los datos’ para la primera y ’Calcular desde el encuadre nativo’ para la segunda. En el momento en que abajo de todo le demos a guardar, tendremos la capa publicada y podremos acceder a ella desde el c´odigo de la aplicaci´on. 5.2.2. P´agina web 5.2.2.0.1. P´agina responsive En este primer incremento, se ha hecho una parte importante de la p´agina web. Lo primero, es realizar un esquema por el que puedan guiarse ambas p´aginas de la aplicaci´on, llamaremos ’index’ a la p´agina principal, y ’p´agina mapa’ a la otra. Lo primero que se realiz´o fue conseguir que la p´agina fuera responsive1, esto 1El dise˜no web responsive o adaptativo es una t´ecnica de dise˜no web que busca la correcta visualizaci´on de una misma p´agina en distintos dispositivos. 102CAP´ ITULO 5. INCREMENTO UNO. B ´ USQUEDA Y EXPLORACI ´ ON CONVENCIONAL Figura 5.6: Configuramos una capa lo explicaremos con una serie de capturas que pondremos a continuaci´on. Para explicar este apartado, no se hab´ıan realizado los filtros y las tablas, por lo tanto, hemos puesto texto de ejemplo en dichas secciones. En la figura 5.7 podemos ver el index, en una pantalla completa. En ella podemos ver el men´u superior que se ve´ıa en la propuesta gr´afica, de mismo modo que los filtros laterales. Ambas secciones tienen un bot´on para ocultarlas, de lo que hablaremos m´as adelante. En el men´u superior, se ve resaltada la p´agina en la que estamos, tal y como se hab´ıa previsto. A mayores tenemos un pie de p´agina, que est´a presente en todo momento debido a su limitado tama˜no y la informaci´on que tiene. En este pie de p´agina est´an los tres enlaces comentados en la propuesta gr´afica y a mayores un bot´on con una flecha hacia arriba. Este bot´on sube la p´agina hasta arriba en cualquier momento, de modo que facilita la vida al usuario y mejora la IPO comentada en el apartado de Dise˜no Gr´afico. Por otro lado, en la figura 5.8 podemos ver de nuevo el index, pero con un tama˜no de pantalla reducido. En im´agenes no se aprecia, pero estos men´us de los que habl´abamos arriba se han ocultado autom´aticamente con una animaci´on de salida. Esto se hace para que la p´agina puede usarse con comodidad en cualquier dispositivo, independiente de su tama˜no. Obviamente, cuando la ventana vuelva a hacerse grande, los men´us aparecer´an con una animaci´on de entrada, excepto si los usuarios los hab´ıan ocultado por ellos mismos, de modo que no tengan que seleccionar si quieren o no los men´us cada vez que disminuyan el tama˜no de su navegador. Como se puede comprobar comparando las figuras 5.7 y 5.8, cuando los men´us est´an visibles, en el men´u superior en la esquina derecha, tenemos una flecha hacia arriba que indica que puede quitarse, y en los filtros tenemos una ’x’ para 5.2. IMPLEMENTACI ´ ON 103 Figura 5.7: Interfaz web responsive. P´agina grande, con men´us. Figura 5.8: Interfaz web responsive. P´agina peque˜na, sin men´us. Figura 5.9: Interfaz web responsive. P´agina peque˜na, con men´us. cerrarlos. Cuando los men´us no est´an, en la esquina superior derecha tenemos una flecha hacia abajo para indicar que se puede desplegar algo, y en los filtros tenemos un icono desplegable al lado del t´ıtulo de la secci´on. Finalmente, en las figuras 5.9 y 5.10, vemos la interfaz gr´afica en las dos versiones que nos quedan, p´agina peque˜na con men´us desplegados, y p´agina grande sin ellos. Obviamente, no es necesario tener ambos u ocultos o desplegados en el mismo momento, de hecho, si los filtros aparecen, pero el men´u superior no, el tama˜no de la secci´on lateral se har´a m´as grande de modo que el espacio se aproveche al m´aximo. 104CAP´ ITULO 5. INCREMENTO UNO. B ´ USQUEDA Y EXPLORACI ´ ON CONVENCIONAL Figura 5.10: Interfaz web responsive. P´agina grande, sin men´us. 5.2.2.0.2. Filtros Si ahora nos centramos en la parte lateral, en el apartado de filtros, hemos hecho una serie de modificaciones para implementarlo correctamente. Para explicarlo, usaremos las figuras 5.11 y 5.12. Como se puede ver, en la figura 5.11, podemos ver el filtrado b´asico. En ´el, tenemos una serie de campos, divididos en secciones que el usuario puede ir rellenando. Es importante la primera l´ınea, donde escogemos la categor´ıa de b´usqueda. Esta marca el tipo de los resultados que saldr´an en la columna correspondiente, y debido a la incapacidad de dejar este punto sin seleccionar, est´a puesto por defecto ’Forma moderna’ tal y como se ha comentado anteriormente. Obviamente, los botones del fondo, de ’activar busca xeogr´afica’ o la lupa y la papelera, que sirven para buscar y eliminar las selecciones, tienen la utilidad que su propio nombre indica y que hemos explicado a lo largo del proyecto. Dichos botones, pueden verse en la figura 5.12. Otra parte fundamental de la figura 5.11, es el enlace que pone ’ver filtros exhaustivos’ al final de la misma. Pulsando sobre ´el, llegamos a la figura 5.12. Se ha decido incluir los filtros exhaustivos dentro de los bloques a los que pertenecen y no en un desplegable, para que toda la informaci´on sobre el mismo tema apareciese junta, ya que as´ı parece m´as natural. Se les ha puesto un color de letra diferente, para que sean f´acilmente diferenciables, de modo que no sea necesario volver a leer todos los filtros para encontrar las diferencias, lo que se espera que sea m´as c´omodo para el usuario. Obviamente la utilidad del enlace ha cambiado, y ahora sirve para que estos filtros vuelvan a ser invisibles. 5.2.2.0.3. Lista de resultados y tablas Otra parte fundamental de este primer incremento era la creaci´on de la lista de resultados y de la tabla que ofrece m´as informaci´on sobre los mismos. 5.2. IMPLEMENTACI ´ ON 105 Figura 5.11: Filtrado b´asico. Figura 5.12: Filtrado exhaustivo. Para ello, se ha generado a la derecha de los filtros una secci´on donde se pueden ver los Top´onimos Modernos de la base de datos. Como se puede ver en la figura 5.13 se nos indica en la parte superior, el tipo de informaci´on que estamos viendo con el t´ıtulo ’Top´onimos Modernos’, este t´ıtulo variar´ıa junto con la informaci´on si seleccionamos cualquier otro de los tipos presentes en los filtros explicados en el apartado anterior. La lista aparecer precargada al iniciar la p´agina, lo que se ha conseguido metiendo una petici´on a los datos presentes en ’Geoserver’ en la funci´on JavaScript que se ejecuta al cargar la p´agina. document.ready() El c´odigo es el siguiente: $.ajax({ url: URL, method: ’POST’, success: function (data) { console.log(data); for(var i = 0; i < data.features.length; i++) { 106CAP´ ITULO 5. INCREMENTO UNO. B ´ USQUEDA Y EXPLORACI ´ ON CONVENCIONAL Figura 5.13: Listado de resultados if(Cookies.get(’imprimirLista’) == ’lema1’){ a =[data.features[i].properties.lema1]; }else{ a =[data.features[i].properties.formatoponimicaliteral]; } $("#listaResultados ul").append(’<li>’+a+’</li>’); } }); Aunque no se puede ver en el fragmento de c´odigo anterior, estamos haciendo una consulta a una de las vistas creadas en la base de datos (de modo que podamos acceder a todos los datos juntos), y estos datos se convierten a una lista en el bucle for, lista que es la que se muestra en pantalla. Antes de generar una consulta 5.2. IMPLEMENTACI ´ ON 107 nueva (en la que se mostrar´ıan todos los resultados posibles), nos aseguramos de que no hubiese una creada en base a los filtros. Todo el c´odigo est´a disponible en el anexo A ’C´odigo’ - ’Web’ Seleccionado cualquiera de las entradas de dicha lista, se recargar´a la tabla de la derecha, que en un principio aparecer vac´ıa, con la informaci´on correspondiente. Esta tabla se puede ver en la figura 5.14 Figura 5.14: Tabla de resultados Esta carga de datos tambi´en se ha generado con una petici´on. En el momento en que se pulse sobre cualquiera de las entradas, para hacerlo, se ha configurado un evento de rat´on asociado a los ’li’ de la lista anterior, y se ha cargado la informaci´on tal y como aparecer a continuaci´on. Se puede ver que la forma de hacerlo es la misma que se ha comentado anteriormente. $.ajax({ url: URL, type:"POST", success: function (data) { console.log(data); for(var i = 0; i < data.features.length; i++) { //Cronolog´ıa de la copia (que es por donde hemos buscado) if(data.features[i].properties.transmisiontextual == ’Copia’){ $("#tablaResultados table").append( ’<tr id="’+[data.features[i].properties.idaparecer]+’">’+ +’<td></td>’ +’<td>’+’Inicio:’+[data.features[i].properties.anhoci]+ ’\nFin:’+[data.features[i].properties.anhocf]+’</td>’ +’<td>’+[data.features[i].properties.obra]+’</td>’ +’<td>’+[data.features[i].properties.numdocumento]+’</td>’ +’<td>’+[data.features[i].properties.geografianotario]+’</td>’ +’<td>’+[data.features[i].properties.lenguadocumento]+’</td>’ +’<td>’+[data.features[i].properties.transmisiontextual]+’</td>’ + ’<td>’+[data.features[i].properties.formatoponimicaliteral]+’</td>’ 114CAP´ ITULO 5. INCREMENTO UNO. B ´ USQUEDA Y EXPLORACI ´ ON CONVENCIONAL PB.05 Selecci´on de m´as informaci´on Requisitos involucrados RF.02 - Mostrar m´as informaci´on Descripci´on Seleccionar un resultado de la tabla abre una ventana emergente con m´as informaci´on Resultado esperado Al seleccionar uno de los resultados de la tabla se abre una ventana emergente que ocupa toda la pantalla con m´as informaci´on al respecto de la fila seleccionada. Estar´a conformada por 4 pesta˜nas interactivas cada una con una informaci´on espec´ıfica. Resultado obtenido El resultado obtenido Estado Superado Tabla 5.5: PB.05 - Selecci´on de m´as informaci´on 5.3.4. Soluci´on a defectos encontrados 1. Duplicados en la lista: Para poder hacer esto, dentro de la petici´on HTTP realizada hacemos una comprobaci´on en JavaScript de si ese objeto objeto estaba ya en un array o no. El resultado final quedar´ıa como en la figura 5.16. 2. Duplicados en la tabla: Se resuelve de la misma forma que el problema anterior, pero filtrando por id de aparici´on. A mayores, es necesario imprimir las diferencias (en este caso lengua de documento y top´onimo). El resultado final quedar´ıa como en la figura 5.17. 3. Mala cronolog´ıa: Se modifica el c´odigo para que ense˜ne el campo correcto de la base de datos. 5.3. PRUEBAS 115 Figura 5.16: Nuevo listado de resultados Figura 5.17: Nuevo tabla de resultados 116CAP´ ITULO 5. INCREMENTO UNO. B ´ USQUEDA Y EXPLORACI ´ ON CONVENCIONAL Cap´ıtulo 6 Incremento dos. B´usqueda y exploraci´on geogr´afica Se a˜nade a continuaci´on el incremento 2, b´usqueda y exploraci´on geogr´afica. En este incremento nos hemos centrado en mejorar la funcionalidad de la p´agina web, as´ı como introducir funcionalidades relativas a la visualizaci´on de los datos mediante el mapa. 6.1. Dise˜no detallado 6.1.1. Diagrama de clases Se a˜nade a continuaci´on, en la figura 6.1, el diagrama de clases actualizado para este incremento, como se puede ver, las estructuras que lo conforman son las mismas, y simplemente se han a˜nadido una serie de funciones que permiten la correcta visualizaci´on de los nuevos datos. 6.1.2. Diagramas de secuencia Si comparamos el diagrama de secuencia de la figura 6.2 con el del incremento anterior, se ver´a que el flujo de llamadas es b´asicamente el mismo, aunque estemos contemplando un caso de uso distinto, en este caso ’CU.04 - Ver informaci´on filtros en mapa’. Esto es debido a que la forma de tratar los datos, tanto para la lista de resultados como para el mapa es similar, la base sigue siendo la misma. La diferencia entre uno y otro radica en la forma de mostrar estos datos, siendo las consultas al servidor an´alogas tanto para rellenar la lista como el mapa, y tanto como para rellenar la tabla de index.html como la de la tabla que se genera autom´aticamente al pulsar sobre uno de los puntos. En este caso, tal y como se puede ver en la figura 6.2, para mostrar la informaci´on en el mapa, tenemos que realizar la misma consulta al servidor de mapas, 117 118CAP´ ITULO 6. INCREMENTO DOS. B ´ USQUEDA Y EXPLORACI ´ ON GEOGR ´ AFICA Figura 6.1: Diagrama de clases. pero para dos vistas en vez de una, ya que no es lo mismo mostrar pol´ıgonos que puntos. Se ha decidido crear dos vistas a mayores y no reutilizar la del incremento 1 para simplificar el despliegue de datos en la lista de la p´agina principal, donde no ser´ıa necesario realizar las dos consultas. Una vez los datos est´an en el mapa, y pulsando sobre el enlace que aparece en el marcador de localizaci´on, se abre la tabla, que es lo mismo que ocurr´ıa pulsando sobre uno de los resultados de la lista. Para representar el correcto orden de acciones, se han usado nombres de funciones ficticios. Por ejemplo ’introducirDatos’ que estar´ıa representando una acci´on del usuario que se basar´ıa en escribir en los campos de un formulario. 6.2. Implementaci´on En este apartado, se a˜nade la implementaci´on del sistema para este segundo incremento. Tanto de la base de datos como de la aplicaci´on. 6.2.1. Base de datos En este caso, teniendo en cuenta que la base de datos ya la hab´ıamos configurado y preparado en su totalidad para el incremento n´umero uno, lo ´unico que fue necesario hacer para este segundo apartado del proyecto, fue crear las vistas que 6.2. IMPLEMENTACI ´ ON 119 Figura 6.2: Diagrama de secuencia. Ver informaci´on filtros en mapa fueron necesarias para mostrar la informaci´on en el mapa, y cargar estas vistas, y las tablas con informaci´on geogr´afica en Geoserver. De nuevo, la creaci´on de las vistas se puede ver en el anexo A en ’C´odigo’ - ’BD’. 6.2.2. P´agina web La aplicaci´on web ha sido la que m´as cambios ha sufrido en este segundo incremento. Por una parte, para facilitar la usabilidad de la p´agina web, y para cumplir con uno de los requisitos del cliente, se hizo que la cabecera de la tabla fuese ’clickable’ y sirviese para ordenar la informaci´on. Como se puede ver en la figura 6.3, la columna por la cual se est´a ordenando en cada momento, se puede ver con la flecha distintiva que presenta, adem´as esta flecha nos indica si se est´a ordenando ascendente o descendentemente, ya que var´ıa con cada ’click’ que le demos. Por defecto, cuando cambiemos de una columna a otra, en la nueva siempre se ordenar´a de forma ascendente, y tendremos que seleccionarla dos veces seguidas 120CAP´ ITULO 6. INCREMENTO DOS. B ´ USQUEDA Y EXPLORACI ´ ON GEOGR ´ AFICA Figura 6.3: Cabecera de la tabla como forma de ordenar para que ordene de otra forma. Para hacer esto posible, ha sido necesario crear una serie de funciones auxiliares que indiquen, que celda de la cabecera est´a pulsando el usuario y adem´as si es la primera o la segunda iteraci´on que realiza sobre esa celda. Finalmente, ha sido necesario modificar el filtro de la petici´on al servidor para a˜nadir el par´ametro nuevo por el cual queremos ordenar y el orden que ha de seguir. Figura 6.4: Botones del pie de p´agina Otra de las partes que se implementaron en este incremento, fueron los tres enlaces de la zona inferior izquierda de la p´agina: ayuda, informaci´on y contacto. Que se pueden ver en la captura 6.4 Aunque no a˜naden una funcionalidad importante a la p´agina web por ellos mismos, son altamente necesarios para aportar informaci´on sobre el proyecto que realiza el ILG, qui´enes son o c´omo utilizar la p´agina de forma ´optima para sacarle el m´aximo partido. Para mostrar la informaci´on de cada uno de ellos, se ha implementado una ventana emergente que aparezca al seleccionar la palabra del pie de p´agina, del mismo modo que se hizo con la ventana emergente para mostrar m´as informaci´on en la tabla de resultados en el incremento anterior. El aspecto de cada una de ellas se puede ver en las figuras 6.5 - 6.7 A mayores de lo explicado en el bot´on ’Ayuda’, parece importante recalcar que esta memoria cuenta con un manual de usuario, donde se explica c´omo desplegar el sistema, entre otras cosas, para poder acceder a esta opci´on ’Ayuda’. Dicho manual est´a en el anexo D. En relaci´on a la tabla de resultados, se a˜nadi´o m´as informaci´on, de forma que ahora no solo aparece el nombre del top´onimo, sino el tipo que representa. Esto 6.2. IMPLEMENTACI ´ ON 121 Figura 6.5: Ventana emergente de informaci´on mejora la usabilidad ya que de un vistazo y sin tener que acceder a los datos de la tabla, un usuario puede diferenciar si el top´onimo ’Ourense’, hace referencia al municipio o a la provincia. Finalmente, posiblemente la parte m´as importante de este incremento, y la que marca una diferencia m´as grande con respecto a la interfaz gr´afica anterior es la implementaci´on del mapa para la visualizaci´on de resultados. Para incluir el mapa en la p´agina web ha sido necesario usar la librer´ıa de JavaScript ’Leaflet’, que permite le visualizaci´on de mapas en un div. Al mapa que hemos creado le hemos a˜nadido una capa de OpenStreetMap, que es un proyecto colaborativo para crear mapas editables y libres, de forma que aparezca de fondo un mapa del mundo sobre el que comparar los resultados que obtengamos. Como se adelant´o en el apartado relativo al diagrama de secuencia, para poder hacer la consulta al servidor geogr´afico, hemos creado dos nuevas vistas en PostgreSQL y las hemos a˜nadido a Geoserver. Estas vistas, son exactamente iguales a la vista utilizada en los filtros en el incremento 1 pero con dos peculiaridades. La primera es que, obviamente, tienen una columna con la componente geogr´afica. Y la segunda es que hemos dividido los top´onimos seg´un sean lugares o no. Esto es debido a que, aunque en PostgreSQL dij´esemos que tanto puntos como pol´ıgonos eran de tipo ’geometry’, Geoserver los divide entre ’Point’ y ’MultyPolygon’. Esto hace que no podamos mostrarlos todos con la misma funci´on, y que sea necesario hacer dos iteraciones de b´usqueda para poder imprimir los datos como les corresponda. Estas dos consultas se pueden ver a continuaci´on, la primera donde se cargan los multipol´ıgonos y la segunda donde se cargan los puntos. 122CAP´ ITULO 6. INCREMENTO DOS. B ´ USQUEDA Y EXPLORACI ´ ON GEOGR ´ AFICA Figura 6.6: Ventana emergente de ayuda Figura 6.7: Ventana emergente de contacto A˜nadimos los pol´ıgonos: var a; $.ajax({ url: URL, method: ’POST’, success: function (data) { console.log(data); var adaLayer = L.geoJson(data, { onEachFeature: function(feature, featureLayer) { var marker = featureLayer.bindPopup(feature.properties.lema1); marker.on(’click’, function(){ Cookies.set(’seleccionLista’, marker._popup.getContent()); // alert(marker._popup.getContent()); marker._popup.setContent(feature.properties.lema1 + ’ 6.2. IMPLEMENTACI ´ ON 123 | <a href="javascript:void(0)" onclick="abrirPopupTablaMapa()"> </a>’) }); } }); adaLayer.addTo(mymap); } }); Creamos y a˜nadimos los puntos: $.ajax({ url: URL, method: ’POST’, success: function (data) { console.log(data); var adaLayer = L.geoJson(data, { onEachFeature: function(feature, featureLayer) { var marker = L.marker([feature.geometry.coordinates[0], feature.geometry.coordinates[1]]). addTo(mymap).bindPopup(feature.properties.lema1); marker.on(’click’, function(){ Cookies.set(’seleccionLista’, marker._popup.getContent()); marker._popup.setContent(feature.properties.lema1 + ’ | <a href="javascript:void(0)" onclick="abrirPopupTablaMapa()"> /a>’) }); } }); } }); Esto permite que, tal y como se puede ver en la figura 6.8, se puedan mostrar a la vez datos del municipio y de los lugares espec´ıficos, representados por el marcador. Esta informaci´on, como se ha dicho en varias ocasiones, hace referencia a la que sal´ıa en la lista. Como se puede apreciar en las figuras 6.9 y 6.10 la informaci´on es exactamente la misma. A mayores ha sido necesario buscar una forma de a˜nadir la tabla que ten´ıamos en el incremento anterior. Esto se ha hecho de la siguiente manera. Como se puede ver en la figura 6.10 cuando pulsas sobre el marcador o sobre la capa del pol´ıgono que aparece en el mapa, se abre un popup con el nombre del top´onimo y un icono. Este icono sirve de enlace para que se abra la tabla de la figura 6.11 como una ventana emergente. Si se compara con la tabla de la p´agina principal de la aplicaci´on se ver´a que es completamente igual, lo que, no solo mantiene un estilo coherente en toda la aplicaci´on, si no que se presupone 130CAP´ ITULO 6. INCREMENTO DOS. B ´ USQUEDA Y EXPLORACI ´ ON GEOGR ´ AFICA PB.11 Probar el contacto Requisitos involucrados RF.06 - Visualizaci´on de ayuda, info y contacto Descripci´on El enlace de ’Contacto’ del pie del pie de p´agina debe desplegar la forma de contactar con el ILG Resultado esperado Desde cualquiera de las p´aginas de la aplicaci´on, si se pulsa el enlace de ’Contacto’ del pie de p´agina, se debe abrir una ventana emergente con la informaci´on necesaria Resultado obtenido El resultado obtenido Estado Superado Tabla 6.6: PB.11 - Probar el contacto PB.12 Ordenar la tabla Requisitos involucrados RF.07 - Ordenar resultados Descripci´on Une vez se despliegue resultados sobre la tabla, la cabecera debe servir como forma de ordenarlos Resultado esperado Pulsando sobre cada una de las celdas de la cabecera, debe comprobarse que la primera vez que se pulsa ordena de forma ascendente, y a partir de ah´ı, si se pulsa un nopar de veces, de forma descendente e impar ascendente. Es necesario comprobar todas las celdas y observar los resultados que se despliegan para garantizar completamente esta prueba Resultado obtenido El resultado obtenido Estado Superado Tabla 6.7: PB.12 - Ordenar la tabla 6.3.3. Soluci´on a defectos encontrados Se listan a continuaci´on las acciones realizadas para subsanar los errores. 1. Ordenar cronol´ogicamente: Se a˜nadi´o una nueva funci´on que gestionase la ordenaci´on mediante la cronolog´ıa. Ahora la cabecera de la tabla tiene el aspecto que se puede ver en la figura 6.12. 2. Una ´unica fecha para el rango de a˜nos: Se hizo una comprobaci´on de forma que dependiendo de si se da el caso de ser el mismo a˜no o no, se imprime 6.3. PRUEBAS 131 Figura 6.12: Cabecera de la tabla como forma de ordenar una cosa u otra por pantalla. 3. Alinear a la izquierda: Se modific´o el archivo CSS a˜nadiendo el c´odigo necesario para adecuarse a los requisitos del cliente. 132CAP´ ITULO 6. INCREMENTO DOS. B ´ USQUEDA Y EXPLORACI ´ ON GEOGR ´ AFICA Cap´ıtulo 7 Conclusiones y trabajo futuro Una vez finalizado el trabajo, se ha creado este apartado para comentar las cosas que pueden haber quedado pendientes y qu´e es lo que se ha conseguido con este proyecto. 7.1. Conclusiones Una vez finalizado el proyecto que engloba este TFG, hemos conseguido una base de datos, con un modelo entidad-relaci´on complejo, que contempla todas las posibilidades de uso actuales, y algunas futuras y que evita duplicados lo que llevar´a a una base de datos m´as segura en lo que a consistencia de datos se refiere. Un base de datos con un dise˜no que podr´ıa ampliarse en el futuro y a la que, a d´ıa de hoy podr´ıa sac´arsele mucho m´as partido incluyendo nuevas formas de b´usqueda, ya sea a˜nadiendo b´usquedas geogr´aficas o modificando los filtros actuales, citados como requisito del cliente, de forma que se busque mostrar las relaciones entre top´onimos y notarios, la huella geogr´afica de un documento, una obra o una persona. Hemos logrado tambi´en una aplicaci´on con una interfaz completamente nueva, que permite la visualizaci´on de los datos de una forma mucho m´as sencilla que la versi´on anterior, y que adem´as nos permite ver estos datos en un mapa, con las facilidades para la extrapolaci´on de conclusiones que esto puede llegar a dar. Se puede decir, que hemos mejorado lo que hab´ıa antes sin perder la esencia que lo hac´ıa posible. En general, con el fin de este proyecto, hemos conseguido desarrollar un proyecto completo que ha dado lugar a un producto completamente funcional que podr´ıa instalarse y empezar a usarse inmediatamente. Para los usuarios de la aplicaci´on, hemos creado una interfaz m´as amable y actual, que le permitir´a ver los datos con mayor facilidad, y debido a la base de datos de la que los usuarios no son conscientes, hemos podido mostrar muchos m´as datos que en la aplicaci´on anterior, ya que los hemos interconectado de una 133 134 CAP´ ITULO 7. CONCLUSIONES Y TRABAJO FUTURO forma nueva y m´as ´util. De cara al ILG, este proyecto puede ser la puerta a la posibilidad de recuperar la explotaci´on de un inventario que estaba en parte parada, la posibilidad de seguir estudiando estos top´onimos y documentos de una forma m´as sencilla, y la posibilidad de mantener este estudio vivo y llevarlo a las nuevas generaciones. Personalmente, como ingeniera, este proyecto me ha formado en nuevas tecnolog´ıas que no conoc´ıa, me ha dotado de la experiencia de realizar un proyecto de Software entero, me ha hecho conocer qu´e es el trabajo en un proyecto real, con un cliente de verdad con necesidades reales y actuales. Me ha hecho aprender y lograr unir los conocimientos que he adquirido en toda la carrera y, adem´as, me ha formado, aunque fuese un poco, en conocimientos de otras ´areas completamente distintas a la m´ıa. 7.2. Trabajo futuro Se a˜nade a continuaci´on una serie de puntos que se considera importante, o al menos interesante, tener en cuenta durante el mantenimiento de la aplicaci´on, ya sea para adecuarla a la legislaci´on si se le da un uso real o para mejorar ciertos aspectos de funcionalidad. 7.2.1. Base de datos La base de datos ha sido creada para que todos los campos de la misma puedan ser NULL. Esto en s´ı no es un error, ya que, en el momento de creaci´on de la base, no se ten´ıa claro que atributos pod´ıan o no estar ausentes en algunos casos. En el momento en que el ILG tenga clara esta informaci´on, es necesario que se haga una modificaci´on de la base de datos de modo que se a˜nadan estas restricciones. Algunas tablas, como ’EstructuraToponimica’ est´an definidas con un par clave valor, esto podr´ıa modificarse en un futuro, cuando las ideas sobre este apartado cambien por parte del ILG. Modificar la relaci´on de la tabla ’obra’ con los top´onimos de modo que una editorial pueda estar relacionada con varios sitios Meter en Toponimo campos relativos a la etimolog´ıa del mismo, como la forma antigua o la lengua en la que estaba. Est´a pendiente de decisiones del ILG. Introducir posibles valores para el nivel tres de tipolog´ıa documental. Teniendo en cuenta la cantidad de los mismos, plantearse si ser´ıa mejor hacer una tabla con restricciones. 7.2. TRABAJO FUTURO 135 Los campos de tipolog´ıa que utiliza el ILG y el Nomenclator no se corresponden, por lo que no se puede guardar la tipolog´ıa de los lugares sacados del Nomenclator en la base de datos. Ser´ıa interesante estudiar esto para llegar a un punto en que s´ı se correspondan para poder introducir toda la informaci´on disponible en la base de datos. 7.2.2. Protecci´on de los datos de la base de datos En relaci´on tambi´en a la base de datos, es importante comentar que parte de los datos que se van a guardar en ella son datos personales de los trabajadores que han colaborada para que la creaci´on del conjunto de datos sea posible. Estos datos son sus nombres y apellidos, y est´an diferenciados seg´un sean trabajadores para el ITGPA o el CGPA. Por tanto, como trabajadores de la universidad, y siendo esto un trabajo para la misma no ha sido necesario pedir consentimiento expreso para el guardado de sus datos personales. De todos modos, estos siguen siendo datos de car´acter personal, considerados por el Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Org´anica 15/1999, de 13 de diciembre, de protecci´on de datos de car´acter personal, en su art´ıculo 81.1, datos de car´acter personal de nivel b´asico. Por lo tanto, no es necesario que est´en encriptados, pero en el momento en que la aplicaci´on se ponga en marcha, ser´a necesario que cumpla las medidas de seguridad de nivel b´asico, especificadas en el Cap´ıtulo III: ’Medidas de seguridad aplicables a ficheros y tratamientos automatizados’, Secci´on 1.a: ’Medidas de seguridad de nivel b´asico’ del Real Decreto 1720/2007. 7.2.3. Falta de datos de la base de datos Los datos introducidos en la base de datos son para pruebas, los scripts de inserci´on de dichos datos habr´ıa que revisarlos llegado el momento de poner en funcionamiento la aplicaci´on, para que est´en cubiertos todos los campos del modelo. A mayores, se proporciona un script para la inserci´on de una tabla con los nombres de los pa´ıses, para traducir la columna de gadm36, pero hay una diferencia de 10 pa´ıses entre ambas tablas, con lo que habr´ıa que buscar una mejor forma de hacerlo. Por otro lado, hay un n´umero distinto de municipios a nivel espa˜nol entre el Nomenclator y la base de datos geonames que se ha utilizado para las geometr´ıas. Esto provoca que pueda darse el caso de no encontrar un municipio o que este no tenga una geometr´ıa, por lo que habr´ıa que buscar una base de datos con datos geogr´aficos m´as actualizada. Si bien es cierto que contabilizando el node municipios espa˜noles que tiene, la tabla gadm36 parece que es v´alida, o que incluso tiene de m´as, el hecho de que se puedan unir varios municipios en uno solo con un 136 CAP´ ITULO 7. CONCLUSIONES Y TRABAJO FUTURO nombre distinto, hace que las consultas que filtran por nombre, no proporcionen informaci´on precisa. En general, ha dado bastantes problemas el uso de geonames mezclado con el nomenclator, por lo que de cara a al futuro, podr´ıa ser interesante buscar alternativas de bases de datos geogr´aficas distintas. 7.2.4. P´agina web En relaci´on a la p´agina web, ser´ıa necesario revisar los siguientes puntos: Dentro de lo que son las funcionalidades de la p´agina web, ser´ıa necesario implementar la funcionalidad del bot´on ’Descargar’. Ser´ıa necesario preparar el popup de informaci´on sobre un resultado de la tabla para que mostrase im´agenes. Habr´ıa que realizar el c´odigo para efectuar consultas espaciales sobre el mapa que ya ha sido introducido en la aplicaci´on. De forma que el hecho de, por ejemplo, seleccionar un rect´angulo sobre el mapa sea uno de los filtros de b´usqueda, en ese caso, limitado a esa zona. Bibliograf´ıa [1] Documentaci´on de GitLab. https://docs.gitlab.com/ee/README.html. Consultado el 8 de Marzo de 2019. [2] Documentaci´on de GitLab. Crear una rama. https://docs.gitlab.com/ ee/gitlab-basics/create-branch.html. Consultado el 8 de Marzo de 2019. [3] Documentaci´on de GitLab. Proceso de merge. https://docs.gitlab.com/ ee/gitlab-basics/add-merge-request.html. Consultado el 8 de Marzo de 2019. [4] B. Hefley. Curricula for Human-Computer Interaction. 1992. [5] Roger S. Pressman. Ingenier´ıa del software: Un enfoque practico. Cap´ıtulo 27, gesti´on del cambio. 137 138 BIBLIOGRAF´ IA Ap´endice A Contenido del DVD Se muestra a continuaci´on la estructura del directorio del DVD. En cada una de esas carpetas, con los nombres mencionados se encuentran los ap´endices mencionados a lo largo de la memoria. C´odigo •BD ◦Importar ◦creacionDatos.sql ◦insercionDatosGeograficos.sql ◦insercionDatosILG.sql ◦creacionVistas.sql •Web ◦ITGPA Documentaci´on •Memoria del proyecto ◦ARP MEM Memoria del proyecto •Propuesta gr´afica ◦ARP PG PropuestaGrafica •Acta de constituci´on del proyecto, anteproyecto ◦ARP ACP Anteproyecto.pdf •Diagrama de clases ◦ARP DC DiagramaDeClases.uml •Diagrama de casos de uso ◦ARP DCU DiagramaCasosDeUso.uml 139