Sistema de pregunta-respuesta basado en la aplicación de técnicas de anotación semántica en canales médicos de Youtube

UNIVERSIDAD DE SANTIAGO DE COMPOSTELA ESCUELA T´ ECNICA SUPERIOR DE INGENIER´ IA Sistema de pregunta-respuesta basado en la aplicaci´on de t´ecnicas de anotaci´on sem´antica en canales m´edicos de Youtube. Autor: Efr´en Rama Maneiro Directores: Manuel Lama Pen´ın Juan Carlos Vidal Aguiar Grado en Ingenier´ıa Inform´atica Julio de 2018 Trabajo de Fin de Grao 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. Manuel Lama Pen´ın, Profesor del Departamento de Electr´onica y Computaci´on de la Universidad de Santiago de Compostela, y D. Juan Carlos Vidal Aguiar, Profesor del Departamento de Electr´onica y Computaci´on de la Universidad de Santiago de Compostela, INFORMAN: Que la presente memoria, titulada Sistema de pregunta-respuesta basado en la aplicaci´on de t´ecnicas de anotaci´on sem´antica en canales m´edicos de Youtube, presentada por D. Efr´en Rama Maneiro para superar los cr´editos correspondientes al Trabajo de Fin de Grado de la titulaci´on de Grado en Ingenier´ıa Inform´atica, se realiz´o bajo nuestra direcci´on en el Departamento de Electr´onica y Computaci´on 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 Junio de 2018: O director, O codirector, O alumno, Manuel Lama Pen´ın Juan Carlos Vidal Aguiar Efr´en Rama Maneiro i ii ´ Indice general 1. Introducci´on 1 1.1. Motivaci´on............................... 1 1.2. Objetivos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . 5 2. El algoritmo pregunta-respuesta 7 2.1. Introducci´on.............................. 7 2.2. Filtradodev´ıdeos........................... 10 2.3. Comparativa de grafos . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Gesti´on del proyecto 15 3.1. Gesti´on del Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.1. Descripci´on del alcance del producto . . . . . . . . . . . . 15 3.1.2. Criterios de aceptaci´on del producto . . . . . . . . . . . . 15 3.1.3. Entregables del producto . . . . . . . . . . . . . . . . . . . 16 3.1.4. Exclusiones del proyecto . . . . . . . . . . . . . . . . . . . 16 3.1.5. Restricciones del proyecto . . . . . . . . . . . . . . . . . . 17 3.1.6. Supuestos del proyecto . . . . . . . . . . . . . . . . . . . . 17 3.2. Gesti´ondeRiesgos .......................... 17 3.2.1. Metodolog´ıa.......................... 17 3.2.2. Identificaci´on de riesgos . . . . . . . . . . . . . . . . . . . 18 3.2.3. An´alisis de riesgos . . . . . . . . . . . . . . . . . . . . . . 19 3.2.4. Planificaci´on de riesgos . . . . . . . . . . . . . . . . . . . . 25 3.2.5. Seguimiento y control . . . . . . . . . . . . . . . . . . . . . 26 3.3. Gesti´ondeCostes........................... 27 3.3.1. Costes directos . . . . . . . . . . . . . . . . . . . . . . . . 27 iii 3.3.2. Costes indirectos . . . . . . . . . . . . . . . . . . . . . . . 28 3.3.3. Costes totales del proyecto . . . . . . . . . . . . . . . . . . 29 3.4. Gesti´on de la Configuraci´on . . . . . . . . . . . . . . . . . . . . . 29 3.4.1. Herramientas empleadas . . . . . . . . . . . . . . . . . . . 29 3.4.2. Definici´on del sistema de configuraci´on . . . . . . . . . . . 29 3.4.3. Estructura del repositorio de documentaci´on . . . . . . . . 30 3.4.4. Gesti´on del c´odigo fuente . . . . . . . . . . . . . . . . . . . 30 3.4.5. Gesti´on de cambios . . . . . . . . . . . . . . . . . . . . . . 31 3.5. Gesti´on del Tiempo . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.5.1. Metodolog´ıa de desarrollo . . . . . . . . . . . . . . . . . . 32 3.5.2. Estructura de Descomposici´on del Trabajo . . . . . . . . . 33 3.5.3. Planificaci´on.......................... 37 4. An´alisis 45 4.1. Especificaci´on de requisitos . . . . . . . . . . . . . . . . . . . . . . 45 4.1.1. Actores ............................ 46 4.1.2. Casosdeuso ......................... 46 4.1.3. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . 57 4.1.4. Requisitos de informaci´on . . . . . . . . . . . . . . . . . . 60 4.2. Matrices de trazabilidad . . . . . . . . . . . . . . . . . . . . . . . 62 5. An´alisis de tecnolog´ıas y herramientas 65 5.1. Tecnolog´ıas de desarrollo . . . . . . . . . . . . . . . . . . . . . . . 65 5.1.1. Librer´ıas............................ 65 5.1.2. Frameworks .......................... 66 5.1.3. APIs.............................. 68 5.1.4. ADEGA............................ 68 5.1.5. Basesdedatos ........................ 72 5.1.6. Entornos de desarrollo integrado . . . . . . . . . . . . . . . 74 5.1.7. Lenguajes de programaci´on . . . . . . . . . . . . . . . . . 74 5.2. Tecnolog´ıas de documentaci´on . . . . . . . . . . . . . . . . . . . . 74 5.2.1. Emacs + L A T EX........................ 74 5.2.2. Git............................... 74 5.2.3. WBSTool ........................... 74 5.2.4. Microsoft Project . . . . . . . . . . . . . . . . . . . . . . . 75 iv 5.2.5. Enterprise Architect . . . . . . . . . . . . . . . . . . . . . 75 5.2.6. Draw.io ............................ 75 5.2.7. Lumzy............................. 75 6. Dise˜no e Implementaci´on 77 6.1. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . 77 6.2. Patrones de arquitectura software . . . . . . . . . . . . . . . . . . 78 6.3. Modelodedatos............................ 81 6.3.1. Dise˜no del modelo de datos en VoltDB . . . . . . . . . . . 81 6.3.2. Implementaci´on . . . . . . . . . . . . . . . . . . . . . . . . 83 6.4. Servidor Web (backend) ....................... 87 6.4.1. Diagrama de paquetes . . . . . . . . . . . . . . . . . . . . 87 6.4.2. Patrones de dise˜no software . . . . . . . . . . . . . . . . . 89 6.4.3. Diagramas de clases . . . . . . . . . . . . . . . . . . . . . 90 6.5. Diagramas de secuencia . . . . . . . . . . . . . . . . . . . . . . . . 104 6.5.1. Anotaci´on de v´ıdeos. . . . . . . . . . . . . . . . . . . . . . 105 6.5.2. B´usqueda de canales y v´ıdeos. . . . . . . . . . . . . . . . . 107 6.5.3. Mostrar v´ıdeos anotados . . . . . . . . . . . . . . . . . . . 109 6.5.4. Eliminar v´ıdeos anotados . . . . . . . . . . . . . . . . . . . 110 6.5.5. Actualizar v´ıdeos anotados . . . . . . . . . . . . . . . . . . 111 6.5.6. Procesamiento de consulta de usuario . . . . . . . . . . . . 112 6.6. Interfaces de usuario (frontend) ................... 114 6.6.1. Dise˜no de la interfaz de usuario . . . . . . . . . . . . . . . 114 6.6.2. Implementaci´on de la interfaz de usuario . . . . . . . . . . 116 7. Pruebas y validaci´on 119 7.1. Pruebas unitarias . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 7.2. Pruebas de integraci´on . . . . . . . . . . . . . . . . . . . . . . . . 124 7.3. Pruebas de validaci´on de requisitos . . . . . . . . . . . . . . . . . 126 7.3.1. Pruebas de validaci´on de requisitos funcionales. . . . . . . 126 7.3.2. Pruebas de validaci´on de requisitos no funcionales. . . . . 131 7.3.3. Matrices de trazabilidad . . . . . . . . . . . . . . . . . . . 132 7.4. Validaci´on de la interfaz de usuario. . . . . . . . . . . . . . . . . . 134 7.4.1. Heur´ısticos de Nielsen . . . . . . . . . . . . . . . . . . . . 134 7.4.2. Pruebas de usabilidad . . . . . . . . . . . . . . . . . . . . 136 v 8. Conclusiones y trabajo futuro 141 8.1. Conclusiones.............................. 141 8.2. Trabajofuturo ............................ 142 A. Manual t´ecnico de despliegue 145 A.1. Instalaci´on de VoltDB . . . . . . . . . . . . . . . . . . . . . . . . 146 A.2. Instalaci´on de ElasticSearch . . . . . . . . . . . . . . . . . . . . . 147 A.3. Despliegue de la aplicaci´on . . . . . . . . . . . . . . . . . . . . . . 147 B. Manual de usuario 149 vi ´ Indice de figuras 2.1. Grafo asociado a los subt´ıtulos de un v´ıdeo. . . . . . . . . . . . . 9 2.2. Ejemplo de intersecci´on de dos grafos. . . . . . . . . . . . . . . . . 12 2.3. Ejemplo de vecindario y c´alculo de la similaridad relacional. . . . 13 3.1. Estructura de carpetas de la documentaci´on del proyecto. . . . . . 30 3.2. ´ Arbol de directorios de los repositorios de c´odigo . . . . . . . . . . 31 3.3. Estructura de Descomposici´on del Trabajo (EDT) (2/2) . . . . . . 34 3.4. Diagrama de gantt resumen del proyecto. . . . . . . . . . . . . . . 38 3.5. Iniciaci´on del proyecto . . . . . . . . . . . . . . . . . . . . . . . . 39 3.6. Cronograma del incremento 1: b´usqueda y almacenamiento de los metadatos de los v´ıdeos de Youtube. . . . . . . . . . . . . . . . . 41 3.7. Cronograma del incremento 2: anotador de v´ıdeos seleccionados y almacenamiento de los mismos. . . . . . . . . . . . . . . . . . . . 42 3.8. Cronograma del incremento 3: sistema gestor de los v´ıdeos anotados 42 3.9. Cronograma del incremento 4: sistema pregunta-respuesta . . . . 43 3.10. Cronograma del cierre del proyecto. . . . . . . . . . . . . . . . . . 43 4.1. Subsistema de anotaci´on de videos . . . . . . . . . . . . . . . . . 47 4.2. Subsistema de gesti´on de v´ıdeos anotados . . . . . . . . . . . . . . 53 4.3. Subsistema de pregunta-respuesta . . . . . . . . . . . . . . . . . . 56 6.1. Diagrama de la arquitectura del sistema . . . . . . . . . . . . . . 78 6.2. Aplicaci´on de los patrones de arquitectura software . . . . . . . . 82 6.3. Modelo Entidad-Relaci´on de la base de datos VoltDB . . . . . . . 83 6.4. Diagrama de paquetes del backend ................. 88 6.5. Diagrama de clases del paquete Youtube. . . . . . . . . . . . . . . 91 6.6. Diagrama de clases del paquete DAO . . . . . . . . . . . . . . . . 95 vii 4CAP´ ITULO 1. INTRODUCCI ´ ON 1.2. Objetivos del sistema El objetivo principal del proyecto es el desarrollo de un sistema software proporcione los mecanismos que den soporte al ciclo de vida del sistema del sistema “pregunta-respuesta”, es decir, a la recuperaci´on de las fuentes de informaci´on, en nuestro caso v´ıdeos; a su anotaci´on; indexaci´on en el sistema; y recuperaci´on ante una consulta del paciente en lenguaje natural. De modo m´as preciso, se plantean los siguientes objetivos: OS-1.: Desarrollo de los componentes que permitan consultar los distintos canales de Youtube, recuperar metadatos y subt´ıtulos de los v´ıdeos, as´ı como anotar e indexar v´ıdeos. OS-2.: Desarrollo de una interfaz gr´afica para la gesti´on de la anotaci´on de los distintos v´ıdeos. En dicha interfaz ser´a posible seleccionar los distintos v´ıdeos que el administrador del sistema desea anotar e indexar, previsualizar los v´ıdeos que puedan resultar de inter´es, previsualizar los metadatos que est´an asociados a cada v´ıdeos, etc. OS-3.: Desarrollo de los componentes de la arquitectura orientada a servicios que permitan gestionar los v´ıdeos anotados en el sistema, es decir, que permita gestionar aquellos v´ıdeos que puede devolver el sistema preguntarespuesta como respuesta. OS-4.: Desarrollo de una interfaz gr´afica que permita actualizar la informaci´on asociada a los v´ıdeos anotados en el sistema, eliminar aquellos que hayan desaparecido de la plataforma Youtube y consultar aquellos v´ıdeos que hayan sido anotados en el sistema. OS-5.: Desarrollo de los componentes de la arquitectura orientada a servicios que permitan realizar y procesar consultas en lenguaje natural, as´ı como realizar b´usquedas teniendo en cuenta tanto el procesamiento de dicha b´usqueda como la base de datos de v´ıdeos anotados sem´anticamente. OS-6.: Desarrollo de una interfaz gr´afica que permita al usuario del sistema realizar consultas en lenguaje natural y obtener un v´ıdeo relevante que responda a dicha consulta. 1.3. ESTRUCTURA DE LA MEMORIA 5 1.3. Estructura de la memoria La memoria est´a dividida en cap´ıtulos que tratan aspectos diferentes del desarrollo del presente proyecto: En el cap´ıtulo 1 se expone la introducci´on al proyecto, describiendo las motivaciones para la realizaci´on del mismo, se definen los objetivos del mismo y se exponen conceptos clave para la comprensi´on de la memoria. En el cap´ıtulo 2 se describe el algoritmo pregunta-respuesta que da soporte a todo el trabajo de fin de grado. En el cap´ıtulo 3 se describen todos los aspectos relacionados con la gesti´on del proyecto: gesti´on de costes, del calendario, de riesgos, de la configuraci´on y del alcance. En el cap´ıtulo 4 se corresponde con la fase de an´alisis del proyecto. Se especifican los casos de uso, requisitos no funcionales y de informaci´on. En el cap´ıtulo 5 se describen las tecnolog´ıas utilizadas en el proyecto as´ı como las herramientas empleadas para desarrollar el proyecto. En el cap´ıtulo 6 se describe el dise˜no y la implementaci´on del software del proyecto. En el cap´ıtulo 7 se muestra el dise˜no del conjunto de pruebas al cual el sistema ser´a sometido y el resultado de las mismas. En el cap´ıtulo 8 se describen las conclusiones de la realizaci´on del proyecto y se reflexiona sobre posibles mejoras del proyecto. 6CAP´ ITULO 1. INTRODUCCI ´ ON Cap´ıtulo 2 El algoritmo pregunta-respuesta 2.1. Introducci´on Como se ha indicado en la introducci´on, el principal objetivo es la creaci´on de un sistema que permita responder mediante un v´ıdeo a consultas en lenguaje natural de un paciente. Para ello, lo m´as importante es saber en qu´e medida se relaciona la consulta del usuario con el contenido del v´ıdeo analizando, en primer lugar, la propia consulta en lenguaje natural del usuario. Este an´alisis se realiza mediante la anotaci´on sem´antica de la consulta del usuario, es decir, mediante la generaci´on del grafo conceptual asociado a la consulta en lenguaje natural. Este grafo interrelaciona tres elementos principalmente: Los t´erminos m´as relevantes extra´ıdos directamente del an´alisis del texto a analizar (en este caso la consulta del usuario) representados en un grafo mediante nodos. Los conceptos expandidos a partir de los t´erminos m´as relevantes directamente extra´ıdos. Esta expansi´on se realiza utilizando una ontolog´ıa concreta, dependiendo as´ı de ella. Estos conceptos no aparecen directamente en el texto, pero est´an directamente relacionados con ellos. Las relaciones entre los dos tipos de conceptos anteriores. Dichas relaciones dependen tambi´en de la ontolog´ıa e indican relaciones sem´anticas entre conceptos. Por ejemplo, entre un concepto Napole´on y un concepto Francia existe una relaci´on de emperador (entre otras). 7 8CAP´ ITULO 2. EL ALGORITMO PREGUNTA-RESPUESTA Por otra parte, se realiza el mismo an´alisis sobre los subt´ıtulos de cada uno de los v´ıdeos que manejar´a el sistema pregunta-respuesta. Se utilizan los subt´ıtulos puesto que es la forma m´as fiable de conocer el contenido sem´antico de un v´ıdeo ya que otros metadatos como el t´ıtulo, la descripci´on o las etiquetas son creados por terceras personas que pueden no entender de forma completa el v´ıdeo o introducir informaci´on que no tiene nada que ver con el v´ıdeo. Como resultado de estos an´alisis se obtiene un grafo similar al de la figura 2.1 (los tipos de relaciones entre conceptos aparecen omitidas en este grafo para facilitar la visualizaci´on del mismo). Dicho grafo corresponde a un v´ıdeo de tem´atica de enfermedades respiratorias. Como se puede observar, los conceptos aparecen interrelacionados entre s´ı. La expansi´on se realiza a partir del nodo denominado “pneumothorax”, obtenido directamente de los subt´ıtulos hasta alcanzar otras enfermedades respiratorias como “neumon´ıa” o “hemoptisis”. As´ı, una vez se tiene tanto el grafo del v´ıdeo como el grafo de la consulta del usuario, se procede a compararlos mediante un algoritmo de comparaci´on de grafos. La principal ventaja de dicha comparaci´on reside en que es muy precisa puesto que tiene en cuenta todos los nodos y relaciones sem´anticas tanto de la consulta del usuario como del contenido del v´ıdeo. Como el proceso de anotaci´on sem´antica es un proceso lento (para algunos v´ıdeos puede tardar hasta 40 segundos), resulta imperativo almacenar el resultado de todas las anotaciones en una base de datos. Por otra parte, el rendimiento del algoritmo de comparaci´on de grafos es, en ocasiones, lento para los prop´ositos de la aplicaci´on debido, principalmente, a que el grafo puede tener un n´umero de nodos muy elevado (del orden de centenas de nodos y miles de relaciones). Variar el primer elemento es posible mediante la variaci´on de la profundidad de los grafos devueltos por el anotador sem´antico. Sin embargo, no es deseable puesto que los grafos obtenidos ser´an m´as peque˜nos y, por ende, la comparaci´on de la consulta del usuario con los grafos de los v´ıdeos ser´a menos precisa. La soluci´on pasa por hacer que el algoritmo de comparaci´on de grafos tenga como entrada siempre un n´umero constante de grafos. As´ı, evitamos que el sistema se ralentice demasiado seg´un escala el n´umero de grafos almacenados en la base 2.1. INTRODUCCI ´ ON 9 Figura 2.1: Grafo asociado a los subt´ıtulos de un v´ıdeo. de datos. Por lo tanto, es imperativo realizar un filtrado inicial de los v´ıdeos, descartando el m´aximo posible de ellos. En resumen, el proceso de pregunta-respuesta consta de las siguientes fases: 1. Inicialmente, se almacena la anotaci´on sem´antica de un conjunto de v´ıdeos en una base de datos. Estos v´ıdeos ser´an los que el sistema devuelva como respuesta. 2. Posteriormente, se anota sem´anticamente la consulta del usuario, obteniendo un grafo. 3. A continuaci´on, se realiza un filtrado de todos los v´ıdeos almacenados, qued´andonos con un n´umero constante de ellos (que ser´an los m´as relevantes). 4. Para aquellos v´ıdeos no descartados del filtrado, aplicamos el algoritmo de comparaci´on entre el grafo de la consulta del usuario y los grafos de los v´ıdeos. Devolvemos los v´ıdeos m´as relevantes. 10 CAP´ ITULO 2. EL ALGORITMO PREGUNTA-RESPUESTA 2.2. Filtrado de v´ıdeos Como se ha indicado anteriormente, la comparativa de grafos es un proceso relativamente lento, por lo que es preciso hacer un filtrado inicial de los v´ıdeos almacenados en el sistema, en funci´on de su relevancia. Para ello, se utiliza una t´ecnica denominada “b´usqueda por palabras” (del ingl´es, keyword search) mediante un motor de b´usqueda “ElasticSearch” que almacena los nodos asociados a cada uno de los v´ıdeos de la base de datos. El tipo de consulta se denomina “Match Query” [5] y consiste en una consulta de texto completo, es decir, los t´erminos que se le suministran pasan por un analizador [6] que realiza algunas operaciones b´asicas de procesamiento de lenguaje natural: tokenizaci´on, eliminaci´on de “palabras vac´ıas” (del ingl´es, “stopwords”) y sustituci´on de letras may´usculas por min´usculas. Esto permite normalizar la consulta puesto que puede que los t´erminos suministrados no coincidan con los t´erminos del grafo (en caso de que se decida cambiar el algoritmo de b´usqueda y obtener los t´erminos sin utilizar ADEGA). La consulta anterior se aplica sobre el campo “label” de los datos exportados, es decir, sobre cada uno de los conceptos de los grafos de todos los v´ıdeos de la base de datos. Puesto que la consulta se realiza sobre un motor de b´usqueda optimizado para tal fin, se realiza m´as r´apido que aplicando el algoritmo de comparativa de grafos directamente. Para cada t´ermino consultado, se obtiene tanto el peso del nodo encontrado (este peso lo devuelve ADEGA como resultado de su anotaci´on) como el ´ındice de similaridad devuelto por ElasticSearch a la hora de realizar la consulta. Para calcular la relevancia del v´ıdeo se realiza el producto del peso del nodo recuperado por la relevancia obtenida mediante la consulta a ElasticSearch y se acumula para cada v´ıdeo por cada t´ermino encontrado. As´ı, si el peso del nodo es nulo, la relevancia para ese t´ermino es nula, puesto que el nodo no tiene importancia en el grafo del v´ıdeo. De la misma forma, si la relevancia obtenida de la consulta a ElasticSearch es nula, quiere decir que el t´ermino no se corresponde con el nodo. 2.3. COMPARATIVA DE GRAFOS 11 La lista obtenida anteriormente se ordena seg´un la relevancia calculada. De dicha lista se selecciona cierto n´umero de v´ıdeos que ser´an los que se comparen utilizando el algoritmo de comparaci´on de grafos. Mediante pruebas emp´ıricas se ha determinado que un n´umero 100 v´ıdeos permite, tanto agilizar en gran medida el procesado mediante la comparaci´on de grafos, como no despreciar v´ıdeos que s´ı puedan ser relevantes. 2.3. Comparativa de grafos Para realizar la comparativa de grafos se utiliza un algoritmo [12] que proporciona una medida de la similaridad precisa basada en una medida denominada coeficiente de Soresen-Dice. Dicha medida, aplicada al problema de comparativa de grafos, tiene en cuenta espec´ıficamente la naturaleza conceptual del grafo, es decir, los tipos de relaciones entre los conceptos que conforman el grafo. El algoritmo comienza computando la intersecci´on entre el par de grafos a comparar. Dicha intersecci´on est´a compuesta por dos elementos fundamentalmente: aquellos nodos que est´en en ambos grafos y aquellas relaciones que sean del mismo tipo en ambos grafos y relacionen los mismos nodos. En base a estos dos elementos se crea otro grafo, denominado grafo intersecci´on. A continuaci´on, se procede a calcular la similaridad entre el grafo intersecci´on y los dos grafos originales. Este componente se subdivide en dos componentes m´as b´asicos: Similaridad conceptual: indica el n´umero de nodos que ambos grafos tienen en com´un. Similaridad relacional: indica el n´umero de relaciones que ambos grafos tienen en com´un, es decir, el n´umero de relaciones del mismo tipo que relacionan nodos iguales. El c´alculo de ambas similaridades est´a basada en el coeficiente de similaridad de Soresen-Dice. Se escoge este coeficiente por ser muy sencillo de calcular y, por ende, r´apido de calcular. As´ı, la similaridad conceptual se calcula con la f´ormula 2.1. sc=2n(Gc) n(G1) + n(G2)(2.1) 12 CAP´ ITULO 2. EL ALGORITMO PREGUNTA-RESPUESTA Donde: scdenota la similaridad conceptual. n(G) es el n´umero de nodos del grafo G. G1yG2son los dos grafos originales a comparar. Gces el grafo intersecci´on de G1yG2, es decir, el grafo que tiene los nodos y relaciones comunes a dos grafos originales. Un ejemplo del anterior proceso se puede ver en la figura 2.2, cuyos grafos iniciales se denominan G1yG2, las relaciones y nodos comunes a ambos grafos se marcan con negrita y son A, B y C y el grafo intersecci´on, Gc, resulta de los nodos y relaciones comunes. De forma an´aloga, la similaridad relacional se calcula con la f´ormula 2.2. Figura 2.2: Ejemplo de intersecci´on de dos grafos. sr=2m(Gc) mGc(G1) + mGc(G2)(2.2) Donde: 2.3. COMPARATIVA DE GRAFOS 13 srdenota la similaridad relacional. m(Gc) el n´umero de relaciones del grafo intersecci´on. mGc(Gi) es el n´umero de relaciones en el vecindario del grafo Gi. Se define como vecidario al conjunto de nodos y relaciones del grafo que tienen por lo menos un extremo perteneciente al grafo intersecci´on. Un ejemplo de la anterior f´ormula aparece reflejado en la figura 2.3 cuyos grafos son los mismos que los mostrados en la figura 2.2. El vecindario inmediato aparece representado por un sombreado gris e identifica aquellas relaciones y nodos que est´an en contacto o forman parte del grafo intersecci´on. Las marcas sobre cada una de las relaciones corresponden al n´umero de relaciones que se cuentan de cada grafo que, en el caso del grafo intersecci´on, se cuentan doblemente (puesto que el numerador de la f´ormula est´a multiplicado por dos). Figura 2.3: Ejemplo de vecindario y c´alculo de la similaridad relacional. Una vez calculada la similaridad conceptual y la similaridad relacional, es preciso combinarlas en una puntuaci´on acumulativa. Para ello, una primera aproximaci´on ser´ıa, directamente, multiplicar ambos t´erminos (s=sc·sr), siendo la puntuaci´on acumulativa proporcional a las dos componentes. Sin embargo, la 20 CAP´ ITULO 3. GESTI ´ ON DEL PROYECTO Cuadro 3.5: Plantilla de an´alisis de riesgos Identificador R-XXX Nombre Descripci´on Probabilidad Alta, media o baja. Impacto Alto, medio o bajo. Exposici´on Alta, media o baja. Indicador Indica si el riesgo se ha manifestado. Identificador R-001 Nombre Planificaci´on optimista, “mejor caso” (en lugar de realista, “caso esperado”) Descripci´on En el momento de realizar la planificaci´on del proyecto, esta se realiza de forma demasiado optimista asumiendo que no existir´a ning´un problema de ejecuci´on del plan o que no existir´an vueltas a atr´as en la planificaci´on. Probabilidad Media Impacto Alta Exposici´on Alta Indicador Existen 5 retrasos consecutivos en todas las tareas una vez iniciado el proyecto Identificador R-002 Nombre Un retraso en una tarea produce retrasos en cascada en las tareas dependientes. Descripci´on Debido a la naturaleza de las dependencias entre tareas, es posible que se diera el caso de que el inicio de una tarea se ve retrasado debido a las dependencias de dicha tarea. Probabilidad Media Impacto Alta Exposici´on Alta Indicador El N´umero de dependencias en cascada es mayor que 4. Identificador R-003 3.2. GESTI ´ ON DE RIESGOS 21 Nombre El ciclo de revisi´on de los tutores es m´as lento de lo esperado. Descripci´on Debido a circunstancias ajenas al proyecto, los tutores no pueden revisar el estado del mismo justo a la finalizaci´on del incremento, produciendo retrasos en la planificaci´on del proyecto. Probabilidad Media Impacto Medio Exposici´on Media Indicador. El ciclo de revisi´on tarda un 50 % m´as de lo esperado. Identificador R-004 Nombre Las herramientas de desarrollo no funcionan como se esperaba. Descripci´on Puesto que el proyecto a realizar es un proyecto software que utiliza herramientas como IDE (entornos de desarrollo integrado) yframeworks, es posible que algunas de esas herramientas tengan errores que sea preciso sortear para permitir la finalizaci´on del proyecto. El sorteamiento de dichos errores provocar´ıa retrasos en la planificaci´on del proyecto. Probabilidad Baja Impacto Alto Exposici´on Medio Indicador La p´erdida de tiempo debida a herramientas defectuosas supera 4 horas. Identificador R-005 Nombre La curva de aprendizaje para las nuevas herramientas de desarrollo es m´as larga de lo esperado. Descripci´on Debido a la inexperiencia en las tecnolog´ıas a utilizar en el momento del desarrollo del proyecto, es posible que el tiempo estimado en la planificaci´on para su aprendizaje sea insuficiente con respecto a lo planificado. Probabilidad Media Impacto Medio Exposici´on Alta 22 CAP´ ITULO 3. GESTI ´ ON DEL PROYECTO Indicador La p´erdida de tiempo debida a herramientas complejas supera 20 horas. Identificador R-006 Nombre Se a˜naden requisitos extra Descripci´on En el inicio del proyecto se establecen los requisitos que se deben cumplir. Sin embargo, durante el transcurso del proyecto, dichos requisitos se ven afectados de tal manera que se a˜naden requisitos relevantes que deben ser tenidos en cuenta. Probabilidad Baja Impacto Alto Exposici´on Media Indicador El n´umero de requisitos extras que se a˜naden es mayor que 5. Identificador R-007 Nombre No se sigue la gesti´on de la configuraci´on Descripci´on No seguir la gesti´on de la configuraci´on expuesta en la presente memoria podr´ıa acarrear resultados desastrosos para el proyecto (como la p´erdida de todo el c´odigo fuente). Probabilidad Baja Impacto Alta Exposici´on Alta Indicador El tiempo entre “commits” en el repositorio es mayor que una semana. Identificador R-008 Nombre Reducci´on de las horas a dedicar al proyecto. Descripci´on Por motivos ajenos al proyecto, resulta imposible dedicar al proyecto las horas estipuladas en el presente documento durante cierto per´ıodo de tiempo. Probabilidad Media Impacto Alta Exposici´on Alta 3.2. GESTI ´ ON DE RIESGOS 23 Indicador El n´umero de horas que se dedican al proyecto se reduce en 2 o m´as. Identificador R-009 Nombre Las partes del proyecto que no se han especificado claramente consumen m´as tiempo de los esperado. Descripci´on Debido a la especificaci´on ambigua de alguna de las funcionalidades de un m´odulo del producto, es necesario realizar tareas de redise˜no o reimplementaci´on. Probabilidad Media Impacto Medio Exposici´on Media Indicador El tiempo perdido por reuniones de esclarecimiento de requisitos supera las 3 horas. Identificador R-010 Nombre Problemas de integraci´on de las distintas tecnolog´ıas. Descripci´on La integraci´on de las distintas tecnolog´ıas utilizadas en el proyecto consume m´as tiempo de lo estipulado en la planificaci´on del proyecto. Probabilidad Media Impacto Medio Exposici´on Media Indicador El tiempo perdido por problemas de integraci´on supera las 10 horas. Identificador R-011 Nombre El desarrollo de funciones software err´oneas requiere su redise˜no e reimplementaci´on. 24 CAP´ ITULO 3. GESTI ´ ON DEL PROYECTO Descripci´on Debido a un dise˜no o codificaci´on apresurados del producto, es preciso llevar a cabo un trabajo adicional para que estas cumplan correctamente con los requisitos del software. Si este problema no es detectado a tiempo, probablemente ser´a necesario realizar trabajo en cascada que afecte a otros m´odulos del sistema. Probabilidad Baja Impacto Medio Exposici´on Baja Indicador El n´umero de funcionalidades err´oneas supera la 1 unidad. Identificador R-012 Nombre Los servicios del anotador sem´antico ADEGA no est´an disponibles cuando se necesitan. Descripci´on El anotador sem´antico deja de funcionar debido a causas inespecificadas lo que evita que se pueda desarrollar utilizando el anotador, que es una base del proyecto. Probabilidad Alta Impacto Alto Exposici´on Alta Indicador El anotador ADEGA deja de funcionar dos d´ıas no consecutivos. Identificador R-013 Nombre Alguna de las API utilizadas en el proyecto cambia dr´asticamente. Descripci´on Alguna de las API utilizadas en el proyecto sufre cambios de forma dr´astica, lo que implica tener que reimplementar parte del c´odigo de la aplicaci´on. Probabilidad Baja Impacto Alto Exposici´on Media Indicador El cambio de API provoca errores de compilaci´on o ejecuci´on con la nueva versi´on. 3.2. GESTI ´ ON DE RIESGOS 25 Identificador R-014 Nombre Baja del desarrollador del proyecto. Descripci´on Debido a circunstancias f´ısicas o mentales ajenas al proyecto, el desarrollador no podr´a estar disponible durante un per´ıodo de tiempo no despreciable para el proyecto. Probabilidad Baja Impacto Alto Exposici´on Media Indicador El desarrollador no trabaja en el proyecto durante dos semanas consecutivas. Identificador R-015 Nombre Baja de los tutores Descripci´on Debido a circunstancias f´ısicas o mentales ajenas al proyecto, alguno de los tutores no puede estar disponible durante un per´ıodo no despreciable de tiempo. Probabilidad Baja Impacto Medio Exposici´on Baja Indicador El tutor comunica directamente al desarrollador su falta de disponibilidad. 3.2.4. Planificaci´on de riesgos Para aquellos riesgos con exposici´on alta mencionados anteriormente, se definir´an una serie de medidas que permitir´an evitarlos en la medida de lo posible, o, en caso de que ocurran, reducir sus efectos todo lo posible. Para realizar la planificaci´on de riesgos, se utilizar´a la plantilla definida en la tabla 3.7. Cuadro 3.7: Plantilla de planificaci´on de riesgos Identificador Nombre del riesgo Tipo de acci´on Acci´on a aplicar 26 CAP´ ITULO 3. GESTI ´ ON DEL PROYECTO R-001 Planificaci´on optimista, “mejor caso” (en lugar de realista, “caso esperado”) Prevenci´on Planificar teniendo en cuenta el peor caso posible siempre. As´ı, se mitiga tambi´en la inexperiencia del desarrollador a la hora de planificar proyectos. R-002 Un retraso en una tarea produce retrasos en cascada en las tareas dependientes. Minimizaci´on Utilizar un ciclo de vida en incrementos y evitar dependencias en la medida de lo posible R-007 No se sigue la gesti´on de la configuraci´on. Prevenci´on Realizar revisiones peri´odicas para comprobar que se est´e siguiendo la gesti´on de la configuraci´on. R-008 Reducci´on de las horas a dedicar al proyecto. Minimizaci´on Sobredimensionar ligeramente la planificaci´on de las tareas del proyecto para que la reducci´on de horas afecte lo m´ınimo posible. R-012 Los servicios del anotador sem´antico ADEGA no est´an disponibles cuando se necesitan. Contingencia Desplegar una versi´on local de ADEGA que permita no depender de la versi´on p´ublica accesible por todo el mundo. 3.2.5. Seguimiento y control Debe reanalizarse la lista de riesgos identificada al principio del proyecto para comprobar si se modifica la probabilidad e impacto de alguno de los riesgos identificados. En concreto, se har´a una revisi´on con frecuencia semanal para ver si existen cambios en la probabilidad e impacto o si alguno de los indicadores mostrados est´a a punto de manifestarse. Los riesgos manifestados en el proyecto se indican en el apartado “Planificaci´on’. 3.3. GESTI ´ ON DE COSTES 27 3.3. Gesti´on de Costes En este apartado se realizar´a una estimaci´on de los costes asociados a la realizaci´on del proyecto. Se dividen los costes en dos tipos: costes directos ycostes indirectos. 3.3.1. Costes directos Los costes de los equipos inform´aticos son calculados teniendo en cuenta la amortizaci´on y en base al precio total del elemento seg´un la siguiente f´ormula: Precio del producto adquirido 12 ·A˜nos de duraci´on del equipo ·Meses de duraci´on del proyecto (3.1) N´otese que el denominador de la fracci´on representa la conversi´on de a˜nos a meses. Tambi´en se supone que el proyecto comienza el 1 de Marzo de 2018 y termina el 1 de Julio de 2018. Se distinguen los siguientes tipos de costes directos: Equipamiento inform´atico: •Port´atil Dell XPS 13 con 16GB RAM, procesador i7-8550U y 512GB de disco SSD valorado en 1480 euros obtenido justo antes del inicio del proyecto. Utilizando la f´ormula 3.1 se obtiene un coste de 1480 12·4·6 = 185 euros 1. •Rat´on, teclado mec´anico y adaptadores varios necesarios para el port´atil, valorados ambos en 50 euros. El coste para el proyecto es de 50 12·4·7 = 7,30 euros. •Monitor de 23 pulgadas cedido por el Centro Singular de Investigaci´on en Tecnolog´ıas de la Informaci´on. No es de reciente adquisici´on as´ı que el coste se considera despreciable. Software y tecnolog´ıas: se han utilizado versiones gratuitas siempre que ha sido posible. Adem´as, se han utilizado versiones de prueba de “Microsoft Project” y de “Enterprise Architect”. Por lo tanto, el coste de este apartado es nulo. 1El coste de los equipos incluye IVA. 28 CAP´ ITULO 3. GESTI ´ ON DEL PROYECTO Sistema operativo: ´unicamente se ha utilizado Ubuntu 16.04, totalmente gratuito. Recursos humanos: consultando diversas fuentes [2] se ha estimado el sueldo bruto en 18.000 euros anuales. Para el c´alculo del coste real para la empresa se utiliza la calculadora de contratos de la Universidad de Santiago de Compostela [16]. En dicha calculadora suministramos los siguientes par´ametros: •18.000 euros distribuidos en 14 pagas. Adem´as, hay que tener en cuenta que se trata de un contrato a tiempo parcial por lo que el salario se divide a la mitad. En resumen: 18000 14∗2= 642,85 euros/mes. •Per´ıodo del contrato: del 1/3/2018 al 1/7/2018. •N´umero de pagas: 14. •Tipo de contrato: obra y servicio. •Jornada laboral: tiempo parcial. •Horas semanales: 30. •Categor´ıa cotizaci´on: Ingeniero. Investigador en formaci´on. As´ı, se obtienen los siguientes costes: Bruto 2.592,14e Pagas extras. 433,86e Liquidaci´on 99,71e Contrato 3.125,71e Seguridad Social 1.168e Total 4.294e Cuadro 3.8: Costes de personal 3.3.2. Costes indirectos Teniendo en cuenta que, seg´un la Universidad de Santiago de Compostela, es necesario aplicar un 20 % en “concepto de costes indirectos” [10], y que, el coste acumulado hasta el momento de costes directos asciende a un total de 4.486,3e, los costes indirectos del proyecto ascienden a un total de 4.486,3 ·0.20 = 897,26 e. 3.4. GESTI ´ ON DE LA CONFIGURACI ´ ON 29 3.3.3. Costes totales del proyecto El coste total del proyecto es la suma de los costes directos m´as los costes indirectos: 4.294 + 897,26 = 5.191,26 e 3.4. Gesti´on de la Configuraci´on El proceso de gesti´on de la configuraci´on tiene por objetivo controlar y gestionar los cambios sobre los elementos de configuraci´on que conforman el proyecto durante todo el ciclo de vida del mismo. As´ı, se asegura, por un lado, que siempre se est´e trabajando sobre una versi´on estable y coherente del proyecto y, por otro lado, que las entregas al cliente se realicen siempre sobre la ´ultima versi´on estable del producto. 3.4.1. Herramientas empleadas En la gesti´on de la configuraci´on se emplean las siguientes herramientas: Gitlab: Servicio web de control de versiones basado en Git. Bitbucket: Servicio web, an´alogo a Gitlab, basado en Git. Git: Sistema de control de versiones no centralizado. Su prop´osito es llevar el registro de cambios sobre cada uno de los ficheros sometidos bajo su supervisi´on. Maven: Herramienta para la gesti´on, compilaci´on y construcci´on de proyectos Java. 3.4.2. Definici´on del sistema de configuraci´on Para el manejo de los repositorios se utilizar´an dos opciones: Utilizaci´on de la interfaz web: en el caso que se desee realizar el clonado del repositorio o proponer nuevos cambios. Los motivos de realizar estas tareas por esta v´ıa es la facilidad de realizar dichas tareas mediante la interfaz web (en oposici´on de la l´ınea de comandos). 36 CAP´ ITULO 3. GESTI ´ ON DEL PROYECTO •Base de datos: creaci´on de la base de datos VoltDB y ElasticSearch y sincronizaci´on de las mismas. Implementaci´on de las operaciones requeridas sobre las bases de datos. •Interfaz de usuario: creaci´on de la interfaz de usuario que permite seleccionar los v´ıdeos y a˜nadirlos para su anotaci´on as´ı como mostrar los trabajos de anotaci´on en proceso. •Servidor web: creaci´on del API REST que permite a˜nadir v´ıdeos para su anotaci´on. Implementaci´on de las llamadas a ADEGA desde el servidor as´ı como del sistema de colas. Incremento 3: sistema gestor de los v´ıdeos anotados: •Base de datos: creaci´on de las consultas que permiten realizar las operaciones de borrado, actualizaci´on y consulta de los v´ıdeos anotados. •Interfaz de usuario: creaci´on de la interfaz de usuario que permite mostrar los v´ıdeos para su consulta, actualizaci´on y borrado. •Servidor web: creaci´on del API REST que permite realizar las operaciones sobre la base de datos. Incremento 4: sistema pregunta-respuesta: •Algoritmo pregunta-respuesta: dise˜no e implementaci´on del algoritmo pregunta-respuesta. •Interfaz de usuario: creaci´on de la interfaz que da soporte al algoritmo. •Servidor web: creaci´on del API REST que permite enviar consultas en lenguaje natural al algoritmo y recibir los v´ıdeos recomendados. Fin del proyecto: actividades realizadas al cierre del proyecto. •Memoria del proyecto: redacci´on de la presente memoria. •Manuales t´ecnicos y de usuario: redacci´on de los manuales de operaci´on y soporte del producto. 3.5. GESTI ´ ON DEL TIEMPO 37 3.5.3. Planificaci´on A continuaci´on se muestra la planficaci´on temporal del proyecto. Dicha planificaci´on se ha visto afectada por una serie de circunstancias, que son las siguientes: Materializaci´on del riesgo R-008 (“reducci´on de las horas a dedicar al proyecto”). As´ı, el n´umero de horas disponibles diarias se redujo de 5 horas a 4. Materializaci´on del riesgo R-012 (“Los servicios del anotador sem´antico ADEGa no est´an disponibles cuando se necesitan”). En este caso se ha aplicado la medida de contingencia descrita en el apartado “Planificaci´on de riesgos”: desplegar una versi´on local de ADEGA para realizar el desarrollo. La medida de sobredimensi´on de tareas ha ayudado a mitigar el impacto del riesgo R-008. El tiempo necesario para implementar el procesamiento de lenguaje natural se redujo dr´asticamente al utilizar directamente ADEGA para tal fin. Ese tiempo ahorrado se utiliza para compensar la reducci´on de horas a dedicar al proyecto. Estos dos factores anteriores permiten que la manifestaci´on del riesgo R-008 se vea aplacada por el ahorro de tiempo asociado al procesamiento de lenguaje natural mediante ADEGA. Adem´as, la medida de contingencia aplicada evita posibles p´erdidas de tiempo en esperar a que el anotador sem´antico est´e disponibles. Por lo tanto, se tiene la planificaci´on mostrada en la figura 3.4. En ella se muestran las distintas etapas en las que se desarrolla el proyecto. Teniendo estas consideraciones en cuenta, el proyecto comienza el 1 de Marzo de 2018 y finaliza el d´ıa 26 de Junio de 2018 habiendo dedicado cuatro horas diarias durante 19 semanas y realizando un ´ultimo esfuerzo de ocho horas diarias durante la ´ultima semana siendo as´ı un total de 20 semanas. El n´umero de horas total dedicado es de 420 horas. A continuaci´on se explican cada una de las fases de las que consta la planificaci´on, con su respectivo cronograma desplegado. 38 CAP´ ITULO 3. GESTI ´ ON DEL PROYECTO Figura 3.4: Diagrama de gantt resumen del proyecto. . 3.5. GESTI ´ ON DEL TIEMPO 39 Iniciaci´on del proyecto En la figura 3.5 se muestra el cronograma correspondiente a la fase de iniciaci´on del proyecto. Debido a que el proyecto abarca un campo nuevo para el desarrollador, el conocimiento de este sobre el ´ambito en el que va a trabajar es muy escaso. Por este motivo, es necesaria una fase de estudio de tecnolog´ıas a utilizar en el proyecto. Es especialmente relevante el tiempo necesario para el estudio de las bases de datos VoltDB y ElasticSearch, por ser tecnolog´ıas completamente nuevas para el desarrollador. Figura 3.5: Iniciaci´on del proyecto Como se puede apreciar en el cronograma, esta fase comienza con la extracci´on de requisitos del software que, a su vez comprende las fases de extracci´on, an´alisis, especificaci´on y validaci´on de los distintos requisitos. Posteriormente, se realizan distintas actividades relacionadas con la gesti´on del proyecto siendo estas el establecimiento de un plan de riesgos, de un sistema de gesti´on de la configuraci´on y 40 CAP´ ITULO 3. GESTI ´ ON DEL PROYECTO el estudio de una metodolog´ıa de desarrollo (en este caso, se opta por un ciclo de vida en incrementos). A continuaci´on, se procede a realizar el dise˜no preliminar el sistema, en forma de un diagrama de casos de uso y de un diagrama de arquitectura. Por ´ultimo, se procede a estudiar las distintas tecnolog´ıas necesarias para llevar a cabo el proyecto. Incremento 1: b´usqueda y almacenamiento de los metadatos de los v´ıdeos de Youtube Este incremento, mostrado en la figura 3.6, comprende el dise˜no, implementaci´on y validaci´on del m´odulo de almacenamiento de b´usqueda y almacenamiento de metadatos de la plataforma Youtube. N´otese que este incremento corresponde a la mitad del subsistema de anotaci´on, descrito en los casos de uso. En primer lugar, se procede a dise˜nar el diagrama de clases de la aplicaci´on y la interfaz de usuario mediante wireframes. Posteriormente, se procede a codificar la abstracci´on del API de Youtube y la interfaz que permite realizar las b´usquedas y almacenamiento de los datos de los v´ıdeos. En este incremento no se codifican los accesos a la base de datos, si no que se deja esa tarea para el siguiente incremento (puesto que es m´as pr´actico realizar todo junto). Por ´ultimo, se valida el sistema dise˜nando e implementando las pruebas y se redacta el manual de usuario concerniente a esta parte. Incremento 2: anotador de v´ıdeos seleccionados y almacenamiento de los mismos. En la figura 3.7 se muestra el cronograma correspondiente al segundo incremento del proyecto. En este incremento, se dise˜na, implementa y valida el proceso de anotaci´on de v´ıdeos, as´ı como el almacenamiento de los datos resultantes de la anotaci´on. En primer lugar, se dise˜na la interfaz de usuario, el modelo de datos y el diagrama de clases. A continuaci´on, se crea la base de datos (incluyendo el proceso de sincronizaci´on), se codifica el anotador, las interacciones con la base de datos para almacenar el resultado de la anotaci´on y se integra la interfaz de usuario de anotaci´on de los v´ıdeos para que soporte anotaci´on. Por ´ultimo, se crean y ejecutan las pruebas y se documenta el manual de usuario. 3.5. GESTI ´ ON DEL TIEMPO 41 Figura 3.6: Cronograma del incremento 1: b´usqueda y almacenamiento de los metadatos de los v´ıdeos de Youtube. Incremento 3: sistema gestor de los v´ıdeos almacenados. En la figura 3.8 se muestra el cronograma correspondiente al tercer incremento. En este incremento, se dise˜na, implementa y valida el m´odulo que permite gestionar los v´ıdeos que est´an almacenados en el sistema. De nuevo, se crea el diagrama de clases y el dise˜no de la interfaz de usuario de este m´odulo, se codifican los accesos a la base de datos y se crea la interfaz de usuario asociada con el sistema gestor de v´ıdeos almacenados. Por ´ultimo, se ejecutan las pruebas y se documentan los manuales de usuario. Incremento 4: sistema pregunta-respuesta. En la figura 3.9 se muestra el cronograma correspondiente al ´ultimo incremento. En ´el, se dise˜na, implementa y valida el sistema pregunta-respuesta. En primer lugar, se dise˜na tanto el algoritmo a utilizar para realizar la comparativa de la adecuaci´on entre el contenido de los v´ıdeos y la consulta en lenguaje natural del usuario como el diagrama de clases y la interfaz de usuario correspondiente a 42 CAP´ ITULO 3. GESTI ´ ON DEL PROYECTO Figura 3.7: Cronograma del incremento 2: anotador de v´ıdeos seleccionados y almacenamiento de los mismos. Figura 3.8: Cronograma del incremento 3: sistema gestor de los v´ıdeos anotados 3.5. GESTI ´ ON DEL TIEMPO 43 esta parte del sistema. Posteriormente, se codifica el sistema de procesamiento de lenguaje natural del usuario (mediante ADEGA), el sistema de b´usqueda por palabras con ElasticSearch, el propio algoritmo de comparaci´on de grafos y la interfaz de usuario. Por ´ultimo, se ejecutan las pruebas y se documentan los manuales de usuario. Figura 3.9: Cronograma del incremento 4: sistema pregunta-respuesta Documentaci´on. En la figura 3.10 se muestra el cronograma correspondiente a la etapa de cierre del proyecto. En esta etapa, se procede a la creaci´on de la memoria del TFG y la creaci´on del manual t´ecnico del sistema. Figura 3.10: Cronograma del cierre del proyecto. 44 CAP´ ITULO 3. GESTI ´ ON DEL PROYECTO Cap´ıtulo 4 An´alisis 4.1. Especificaci´on de requisitos Una especificaci´on de requisitos software es una descripci´on completa del sistema software a desarrollar en el proyecto. Una especificaci´on de requisitos contiene: Casos de uso: Conjunto de funcionalidades que realizar´a el sistema software. Requisitos no funcionales: Describen las caracter´ısticas del sistema a desarrollar desde el punto de vista de la seguridad, el rendimiento... Requisitos de informaci´on: Describe los datos que utilizar´a el sistema software. El principal motivo por el que no se incluyen los requisitos funcionales reside en que tanto casos de uso como requisitos funcionales representan funcionalidades del sistema, y, por lo tanto, pueden ser redundantes. En general, se recomienda utilizar casos de uso puesto que tienen un modelo m´as detallado que facilita una definici´on m´as precisa de una funci´on. S´olo es recomendable utilizar ambos cuando se necesita describir funcionalidades con distinto nivel de abstracci´on, es decir, funcionalidades muy complejas que, en la pr´actica, necesitar´an de varias clases colaborando y funcionalidades muy sencillas que pueden ser implementadas con el m´etodo de una clase pero que son importantes para entender lo que se pretende. En este caso, no existen tales funcionalidades por lo que se omite la descripci´on de requisitos funcionales. 45 52 CAP´ ITULO 4. AN ´ ALISIS Criterio de validaci´on El requisito se considera cumplido cuando sea posible ver los v´ıdeos dentro del canal y seleccionar v´ıdeos para su procesamiento. CU. 8 Ver subt´ıtulos. Descripci´on Permite ver los subt´ıtulos asociados a un v´ıdeo de Youtube. Pre–condiciones 1. Se ha realizado previamente una b´usqueda de v´ıdeos. Secuencia normal 1. El usuario pulsa sobre el bot´on “Ver subt´ıtulos” asociado a la ventana de metadatos de un v´ıdeo. 2. El sistema muestra una nueva ventana con los subt´ıtulos del v´ıdeo de Youtube seleccionado. Dichos subt´ıtulos se muestran tal y como los ense˜na la plataforma. 3. El usuario pulsa sobre el bot´on cerrar cuando haya finalizado de ver los subt´ıtulos. Importancia Vital Estabilidad Alta Criterio de validaci´on El requisito se considera cumplido cuando sea posible ver los subt´ıtulos asociados a un v´ıdeo de la plataforma Youtube. Subsistema de gesti´on de v´ıdeos anotados El subsistema de gesti´on de v´ıdeos anotados se encarga de permitir visualizar los v´ıdeos que ya han sido almacenados en el sistema. Sobre dichos v´ıdeos es posible eliminarlos completamente del sistema o actualizar los datos del v´ıdeo, incluyendo, en este caso, tanto los datos obtenidos directamente de Youtube como los resultados de la anotaci´on sem´antica. El diagrama de casos de uso que representa este subsistema se muestra en la figura 4.2. La descripci´on de los casos de uso que conforman este subsistema se describen a continuaci´on: 4.1. ESPECIFICACI ´ ON DE REQUISITOS 53 Figura 4.2: Subsistema de gesti´on de v´ıdeos anotados CU. 9 Mostrar v´ıdeos anotados Descripci´on Permite mostrar los v´ıdeos almacenados en las bases de datos del sistema Actores Administrador Pre–condiciones 1. No hay. Secuencia normal 1. El usuario selecciona la opci´on “Administrar v´ıdeos anotados”. 2. El sistema muestra un recuadro de texto que invita a buscar v´ıdeos. 3. El usuario introduce su consulta en el recuadro de texto. 4. El sistema muestra los v´ıdeos anotados en el sistema teniendo en cuenta la consulta del usuario. Importancia Vital Estabilidad Alta 54 CAP´ ITULO 4. AN ´ ALISIS Criterio de validaci´on Se considera el requisito cumplido si es posible mostrar todos los v´ıdeos anotados en el sistema y si es posible filtrar la lista de v´ıdeos anotados en funci´on de la consulta del usuario. CU. 10 Eliminar v´ıdeos anotados Descripci´on Permite eliminar un conjunto de v´ıdeos del sistema Actores Administrador Pre–condiciones 1. No hay. Secuencia normal 1. Se ejecuta el caso de uso “Mostrar v´ıdeos anotados”. 2. El usuario selecciona los v´ıdeos que desea eliminar de la lista mostrada y pulsa en “Eliminar v´ıdeos”. 3. El sistema elimina los v´ıdeos de la base de datos. Importancia Vital Estabilidad Alta Criterio de validaci´on Se considera el requisito cumplido si es posible eliminar los v´ıdeos seleccionados por el usuario. CU. 11 Actualizar v´ıdeos anotados Descripci´on Permite actualizar las anotaciones de un conjunto de v´ıdeos del sistema Actores Administrador Pre–condiciones 1. No hay. Secuencia normal 1. Se ejecuta el caso de uso “Mostrar v´ıdeos anotados”. 2. El usuario selecciona los v´ıdeos que desea eliminar de la lista mostrada y pulsa en “Actualizar v´ıdeos”. 3. El sistema actualiza los v´ıdeos realizando las operaciones necesarias (anotaci´on y modificaci´on de los datos). Importancia Vital Estabilidad Alta 4.1. ESPECIFICACI ´ ON DE REQUISITOS 55 Criterio de validaci´on Se considera el requisito cumplido si es posible actualizar los v´ıdeos seleccionados por el usuario. CU. 12 Mostrar grafo Descripci´on Permite mostrar el grafo de aquellos v´ıdeos que han sido anotados en el sistema Actores Administrador Pre–condiciones 1. No hay Secuencia normal 1. Se ejecuta el caso de uso “Mostrar v´ıdeos anotados”. 2. El usuario pulsa sobre el bot´on “Ver grafo” adjunto a un v´ıdeo de la lista de v´ıdeos. 3. El sistema muestra una pantalla con el grafo resultante de la anotaci´on de dicho v´ıdeo. 4. El usuario cierra la pantalla cuando haya terminado la operaci´on. Importancia Vital Estabilidad Alta Criterio de validaci´on Se considera el requisito cumplido si es posible mostrar el grafo asociado a cualquier v´ıdeo anotado del sistema. CU. 13 Mostrar estad´ısticas Descripci´on Permite mostrar las estad´ısticas y el estado del sistema en tiempo real. Actores Administrador Pre–condiciones 1. No hay Secuencia normal 1. El administrador pulsa sobre la opci´on del men´u “dashboard”. 2. El sistema muestra el n´umero de v´ıdeos anotados, unos gr´aficos que muestran el uso de recursos de los servidores de la base de datos y si las m´aquinas de las bases de datos est´an funcionando o no. Importancia Quedar´ıa bien 56 CAP´ ITULO 4. AN ´ ALISIS Estabilidad Alta Criterio de validaci´on Se considera el requisito cumplido si es posible mostrar el grafo asociado a cualquier v´ıdeo anotado del sistema. Subsistema de pregunta-respuesta El subsistema de pregunta-respuesta se encarga de responder a las preguntas en lenguaje natural del usuario mediante un v´ıdeo. Pese a que est´a conformado por un ´unico caso de uso, no tiene nada que ver con los casos de uso anteriores por lo que debe especificarse aparte. El diagrama de casos de uso que representa este subsistema se muestra en la figura 4.3. La descripci´on del caso de uso que conforma este subsistema se describe a continuaci´on: Figura 4.3: Subsistema de pregunta-respuesta CU. 14 Introducir consulta. Descripci´on Permite introducir una consulta al sistema pregunta-respuesta para su procesamiento. Actores Paciente, Administrador Pre–condiciones 1. No hay Secuencia normal 1. El usuario introduce en el cuadro de texto su consulta en lenguaje natural. 4.1. ESPECIFICACI ´ ON DE REQUISITOS 57 2. El sistema captura la consulta y ejecuta el algoritmo sobre la misma. Importancia Vital Estabilidad Alta Criterio de validaci´on El requisito se considera cumplido si es posible enviar y procesar la consulta del usuario en lenguaje natural y obtener un conjunto de v´ıdeos relevantes para el usuario. CU. 15 Visualizar resultados Descripci´on Permite ver los resultados del procesamiento de la consulta del usuario. Actores Paciente, Administrador Pre– condiciones 1. Se ha capturado previamente una consulta del usuario. Secuencia normal 1. El sistema devuelve una lista de v´ıdeos como resultado de procesar la consulta del usuario. 2. El usuario visualiza los resultados devueltos por el sistema. Importancia Vital Estabilidad Alta Criterio de validaci´on Se considera el requisito validado cuando sea posible ver los resultados devueltos por el sistema pregunta-respuesta. 4.1.3. Requisitos no funcionales Para la descripci´on de los requisitos no funcionales se utiliza la siguiente plantilla: Requisito RQNF-X T´ıtulo: Nombre del requisito Descripci´on: Descripci´on del requisito Importancia: Importancia del requisito (alta, media o baja) Urgencia: Urgencia de la implementaci´on del requisito (alta, media o baja) 58 CAP´ ITULO 4. AN ´ ALISIS Criterio de validaci´on: Criterio de validaci´on del requisito La cabecera de la tabla representa el identificador del requisito, que es un´ıvoco a lo largo del documento. A continuaci´on se especifica el cat´alogo de requisitos no funcionales del sistema software: Requisito RQNF-1 T´ıtulo: Rendimiento del sistema de consultas Descripci´on: El sistema de pregunta respuesta no debe tardar m´as de 10 segundos en responder a una consulta del usuario. El motivo de este requisito reside en que el sistema debe responder a preguntas en tiempo real. Importancia: Alta Urgencia: Media Criterio Las consultas que se realicen tardan todas menos de 10 segundos en ser procesadas. Requisito RQNF-2 T´ıtulo: Idioma utilizado por el usuario Descripci´on: El idioma utilizado por el usuario para realizar consultas al sistema pregunta-respuesta ser´a el ingl´es. Importancia: Alta Urgencia: Media Criterio de Validaci´on Las consultas que se realicen responden correctamente al idioma ingl´es. Requisito RQNF-3 T´ıtulo: Interfaz usable 4.1. ESPECIFICACI ´ ON DE REQUISITOS 59 Descripci´on: La interfaz de usuario dise˜nada deber´a ser usable para facilitar la adaptaci´on de los usuario, cumpliendo con el mayor n´umero de heur´ısticos de Nielsen posibles y obteniendo la mejor nota posible en los tests de usabilidad. Importancia: Alta Urgencia: Media Criterio de Validaci´on La evaluaci´on de usabilidad supera la evaluaci´on heur´ıstica mediante los principios de Nielsen y los tests de usabilidad tienen una nota media mayor que 8. Requisito RQNF-4 T´ıtulo: Interfaz gr´afica independiente de motor. Descripci´on: El sistema pregunta-respuesta debe ser implementado de forma separada a la interfaz, puesto que es posible que en un futuro se cambie la interacci´on con el paciente. Importancia: Alta Urgencia: Alta Criterio de Validaci´on Se considerar´a validado este requisito si el sistema preguntarespuesta se desarrolla independientemente de la interfaz pudiendo ser llamado sin la necesidad de esta ´ultima, es decir, si el sistema pregunta-respuesta se expone como un servicio REST. Requisito RQNF-5 T´ıtulo: Extensiblidad Descripci´on: El c´odigo debe estar dise˜nado de forma que sea posible efectuar, de forma simple, un cambio del sistema pregunta-respuesta sin afectar de forma significativa al resto del c´odigo. Importancia: Alta Urgencia: Alta 60 CAP´ ITULO 4. AN ´ ALISIS 4.1.4. Requisitos de informaci´on Para la descripci´on de los requisitos de informaci´on se utiliza la siguiente plantilla: Requisito RQI-X T´ıtulo: Nombre del requisito Descripci´on: Descripci´on del requisito Importancia: Importancia del requisito (alta, media o baja) Estabilidad Alta, media o baja. Datos espec´ıficos Datos espec´ıficos que maneja el requisito de informaci´on. A continuaci´on se especifica el cat´alogo de requisitos de informaci´on del sistema. Requisito RQI-1 T´ıtulo: V´ıdeo Descripci´on: Cada uno de los v´ıdeos recuperados de la plataforma Youtube. Importancia: Alta Estabilidad Alta Datos espec´ıficos Identificador. T´ıtulo. Descripci´on. Etiquetas (“tags”). N´umero de visitas. N´umero de “me gustas” (“likes”). N´umero de “no me gustas” (“dislikes”). N´umero de favoritos. N´umero de comentarios. Requisito RQI-2 T´ıtulo: T´ermino del contexto Descripci´on: Cada uno de los elementos del contexto que se recuperan del proceso de anotaci´on sem´antica 4.1. ESPECIFICACI ´ ON DE REQUISITOS 61 Importancia: Alta Estabilidad Alta Datos espec´ıficos T´ermino. URI. Relevancia. Lista de sin´onimos. Posici´on. Longitud. Tipo de entidad (posTag). Requisito RQI-3 T´ıtulo: Nodo Descripci´on: Cada uno de los nodos que se recuperan del algoritmo de anotaci´on sem´antica Importancia: Alta Estabilidad Alta Datos espec´ıficos Identificador. Etiqueta. Recurso. Es categor´ıa. Es desambiguaci´on. T´ermino del contexto asociado. Requisito RQI-4 T´ıtulo: Relaci´on Descripci´on: Cada una de las relaciones que se generan a partir del grafo. Importancia: Alta Estabilidad Alta Datos espec´ıficos Identificador de nodo origen. Nombre de la relaci´on que une los nodos. 68 CAP´ ITULO 5. AN ´ ALISIS DE TECNOLOG´ IAS Y HERRAMIENTAS El dise˜no se controla mediante variables SASS, lo que permite, mediante la modificaci´on un ´unico fichero de variables, personalizar el estilo de toda la p´agina de forma r´apida y sin problemas. JUnit y MockMVC JUnit [19] es una librer´ıa que habilita la creaci´on de pruebas unitarias para el lenguaje Java. Se complementa con MockMVC, que permite realizar pruebas unitarias sobre servicios REST. 5.1.3. APIs Youtube V3 El API de Youtube [15] consiste en un conjunto de servicios REST que se consumen para acceder a funcionalidades de b´usqueda de canales, v´ıdeos, obtenci´on de metadatos asociados a los v´ıdeos, etc. El acceso a esta API se realiza mediante un API Java que permite evitar el tener que utilizar funciones HTTP para llamar a los servicios directamente. As´ı, simplemente se utilizan clases Java que abstraen dichas llamadas. Para utilizar esta API es necesario realizar un proceso de autorizaci´on mediante alguna de las dos formas siguientes: mediante un sistema denominado “OAuth2” o mediante una llave API. Se escoge la segunda forma puesto que es totalmente transparente al usuario (la primera requiere pulsar un bot´on que confirme el acceso a la API). 5.1.4. ADEGA ADEGA [9] es un anotador sem´antico que, a partir de un documento de texto realiza las siguientes operaciones: Identifica los t´erminos relevantes del texto (tambi´en denominados menciones). Es preciso destacar que estas menciones pueden ser ambiguas, es decir, una misma menci´on puede hacer referencia a conceptos distintos. Selecciona dentro de una ontolog´ıa un conjunto de entidades (denominadas entidades candidatas) para anotar cada una de las menciones. 5.1. TECNOLOG´ IAS DE DESARROLLO 69 Crea un grafo sem´antico que interconecta estas entidades candidatas. Utiliza el grafo anterior para desambiguar colectivamente cu´al de las entidades candidatas es la m´as adecuada para anotar cada una de las menciones. ADEGA no est´a ligado a una ontolog´ıa determinada y, por ello, puede anotar textos de cualquier dominio. La calidad de su anotaci´on depende, en gran medida, de la ontolog´ıa utilizada para seleccionar las entidades m´as adecuadas para el proceso de anotaci´on. Dos ejemplos de ontolog´ıas muy conocidas son: DBpedia: es una formalizaci´on de la Wikipedia y, por lo tanto, tiene un car´acter gen´erico y multidominio. MeSH: contiene terminolog´ıa m´edica especializada. Es la ontolog´ıa utilizada en el presente proyecto. En concreto, las operaciones que es posible realizar mediante la API proporcionada por esta herramienta se describen a continuaci´on. Autorizaci´on Todas las operaciones del API REST requieren autorizaci´on. Para ello, ´unicamente se precisa el correo electr´onico del individuo que est´a utilizando el API. Si el correo es v´alido se devuelve un token que identifica al usuario en todas las llamadas al API para esa sesi´on. Extracci´on del contexto Esta operaci´on permite extraer los t´erminos m´as relevantes del texto. En primer lugar, se extraen las entidades nombradas del texto en cuesti´on (principalmente sustantivos) y, a partir de dichos entidades, se extraen los t´erminos compuestos (como, por ejemplo, Banco de Espa˜na). La extracci´on de t´erminos compuestos se realiza “probando” todas las combinaciones de hasta longitud 5 de las entidades nombradas del contexto. La “prueba” consiste en buscar el t´ermino combinado en un ´ındice Lucene de t´erminos obtenido directamente de MeSH. En caso de que la b´usqueda sea fruct´ıfera, el t´ermino 70 CAP´ ITULO 5. AN ´ ALISIS DE TECNOLOG´ IAS Y HERRAMIENTAS es compuesto; en otro caso, se descarta la combinaci´on y se prueba la siguiente. As´ı, esta operaci´on tiene los siguientes par´ametros configurables: Texto: texto a analizar. Ontolog´ıa: indica la ontolog´ıa que se va a utilizar para realizar la b´usqueda de los t´erminos compuestos. Las ontolog´ıas soportadas actualmente por ADEGA son DBPedia (en ingl´es) y MeSH. Extractor de t´erminos compuestos: indica qu´e extractor de t´erminos compuestos se va a utilizar. N´umero de elementos del contexto a extraer: indica el n´umero de elementos del contexto que se devuelven de la llamada al API. En caso de que no se especifique, se devuelven todos los t´erminos encontrados. Extracci´on de los nodos ra´ız Esta operaci´on permite asignar a cada t´ermino del contexto la URI del recurso que lo representa en una ontolog´ıa determinada. Para ello, de nuevo, se realiza una b´usqueda en el ´ındice para comprobar la URI correspondiente a cada t´ermino. La URI que m´as relevancia tenga, es decir, la que “m´as se parezca”, es la URI que se asigna. Hay que tener en cuenta que la relevancia la proporciona directamente Lucene. En este paso se realiza la desambiguaci´on de los t´erminos del contexto. Se conoce por “desambiguaci´on” al proceso de obtener los nodos a los que se refiere un nodo ambiguo. Por ejemplo, dado el nodo “DBA”, que es ambiguo, los nodos de la desambiguaci´on ser´ıan: “Database Administrator”, “Doctor in Business Administration”, etc. As´ı, los par´ametros configurables en esta operaci´on son los siguientes: Contexto: contexto extra´ıdo del paso anterior en formato JSON. Ontolog´ıa: ontolog´ıa que se va a utilizar para realizar la extracci´on, de forma an´aloga al paso anterior. 5.1. TECNOLOG´ IAS DE DESARROLLO 71 Extractor de nodos ra´ız: permite cambiar la estrategia de extracci´on de los nodos. Se distinguen dos estrategias: •Extractor de nodos simple: este extractor simplemente realiza la asignaci´on de t´ermino a recurso sin intentar desambiguar. •Extractor de nodos con desambiguaci´on: este extractor intenta desambiguar a˜nadiendo todos los nodos relacionados con el nodo ambiguo. Generaci´on del grafo Esta operaci´on permite generar el grafo a partir de los nodos ra´ız extra´ıdos en el paso anterior. El algoritmo a seguir es el siguiente: Inicialmente, es preciso localizar los nodos que se pretende alcanzar desde la ra´ız. Dichos nodos se denominan “nodos hoja”. Estos nodos se obtienen consultando al ´ındice Lucene usando el contexto extra´ıdo en la operaci´on correspondiente. Se obtiene como resultado los 100 nodos hoja m´as relevantes. Se explora desde los nodos ra´ız hasta cierta profundidad pesado los nuevos nodos obtenidos del proceso de exploraci´on, se crea el subgrafo los nodos explorados de este paso y se realiza el pesado del grafo completo. Se realiza el mismo procedimiento anterior pero esta vez utilizando los nodos hoja. Se realiza la intersecci´on de los dos grafos anteriores para obtener el grafo de exploraci´on completo. Este algoritmo de b´usqueda se denomina “b´usqueda bidireccional”. As´ı, los par´ametros que se pueden configurar en esta operaci´on son los siguientes: Contexto: contexto obtenido de su correspondiente operaci´on en formato JSON. Nodos ra´ız: nodos ra´ız obtenidos de su correspondiente operaci´on en formato JSON. 72 CAP´ ITULO 5. AN ´ ALISIS DE TECNOLOG´ IAS Y HERRAMIENTAS Profundidad: profundidad m´axima a la que se va a explorar. Ontolog´ıa: ontolog´ıa a utilizar para la exploraci´on (de forma an´aloga a las operaciones anteriores). M´etodo de pesado de los nodos: algoritmo a utilizar para realizar el pesado de los nodos. M´etodo de pesado del grafo: algoritmo a utilizar para realizar el pesado del grafo. Extractor de nodos hoja: indica el algoritmo que se utiliza para extraer los nodos hoja para realizar la exploraci´on. 5.1.5. Bases de datos ElasticSearch ElasticSearch es un motor de b´usqueda basado en Lucene que se puede utilizar como base de datos NoSQL. Provee las siguientes funcionalidades: Capacidad de b´usquedas de textos completos. A partir de un texto en lenguaje natural es capaz de identificar las palabras de la b´usqueda as´ı como la relevancia de las mismas en el texto. Procesamiento de lenguaje natural. Proporciona herramientas para ejecutar algunas de las operaciones t´ıpicas de procesamiento de lenguaje natural como es la tokenizaci´on de palabras, divisi´on de frases, normalizaci´on, etc. Potencia de consultas. ElasticSearch proporciona un lenguaje de consultas propio denominado Query DSL. Este lenguaje permite realizar consultas como b´usqueda por t´erminos, b´usqueda por t´erminos priorizando unos campos m´as que otros, b´usquedas a texto completo... VoltDB Pese a que es posible utilizar ElasticSearch como un sistema de almacenamiento NoSQL, existen problemas derivados de la inserci´on de datos en dicho motor de 5.1. TECNOLOG´ IAS DE DESARROLLO 73 b´usqueda [4]. Por lo tanto, se recomienda utilizar un sistema de almacenamiento secundario que permita, por un lado tener un almacenamiento estable y r´apido de los datos y, por otro lado, exportar dichos datos para poder consultarlos en ElasticSearch. La base de datos elegida para tal fin se denomina VoltDB. Esta base de datos pertenece a una nueva generaci´on de sistemas de almacenamiento denominados como NewSQL [22], combinando, por un lado, las capacidades ACID de las bases de datos relacionales (as´ı como el lenguaje de consultas SQL) y, por otro lado, la escalabilidad de los sistemas NoSQL. En concreto, las caracter´ısticas m´as relevantes de dicha base de datos son las siguientes [35]: Lenguaje de consultas SQL: utiliza como lenguaje de consultas SQL de forma pr´acticamente completa. Esto permite agilizar el desarrollo al evitar el aprendizaje de un lenguaje de consultas espec´ıfico, como, por ejemplo, MongoDB, o al utilizar lenguajes parecidos a SQL, que no soportan todas las funcionalidades, como, por ejemplo, Cassandra. Escalabilidad horizontal: es posible a˜nadir nodos a una instalaci´on existente para incrementar su capacidad de almacenamiento. Almacenamiento en memoria: en lugar de almacenar los datos ´ıntegramente en disco, se almacenan en memoria RAM. Esto permite mayores velocidades de acceso y escritura, con la salvedad de que los datos no ser´ıan persistentes. Este problema se soluciona mediante snapshots peri´odicas a disco. M´odulo de exportaci´on a ElasticSearch: permite crear una tabla virtual en la cual los datos insertados en ella se env´ıan autom´aticamente a ElasticSearch. Esto evita los problemas de escritura relacionados con ElasticSearch (al realizar las comprobaciones de la escritura el propio m´odulo) y facilita la manipulaci´on de los ´ındices ElasticSearch al ser creados y manipulados autom´aticamente. 74 CAP´ ITULO 5. AN ´ ALISIS DE TECNOLOG´ IAS Y HERRAMIENTAS 5.1.6. Entornos de desarrollo integrado Intellij IDEA Se utiliza este editor [18] para la edici´on del c´odigo Java correspondiente a los servicios web. Tambi´en se utiliza para la programaci´on del cliente web mediante Javascript. 5.1.7. Lenguajes de programaci´on Se han utilizado los siguientes lenguajes de programaci´on: Java. Javascript. SQL. Shell Script. 5.2. Tecnolog´ıas de documentaci´on 5.2.1. Emacs + L A T EX Emacs [27] es un editor de texto de prop´osito general altamente extensible mediante plugins. Uno de esos plugins se denomina auctex [11] y permite convertir el editor en un IDE de desarrollo de LaTeX potente y liviano. Tambi´en se ha utilizado un modo del editor denominado flyspell que permite incorporar correcci´on de errores ortogr´aficos al vuelo. 5.2.2. Git Se ha utilizado Git [31] para almacenar la memoria en un repositorio as´ı como para controlar los cambios sobre la misma. 5.2.3. WBSTool WBSTool [29] es un editor online gratu´ıto de Estructuras de Descomposici´on del Trabajo. Permite visualizar el EDT mientras se est´a realizando, su exportaci´on 5.2. TECNOLOG´ IAS DE DOCUMENTACI ´ ON 75 a distintos formatos y la edici´on del mismo de forma visual. Se ha utilizado para generar la EDT del presente proyecto. 5.2.4. Microsoft Project Microsoft Project [21] es un software de ofim´atica enfocado en la gesti´on de proyectos. Sirve para gestionar la calendarizaci´on del proyecto mediante la generaci´on de diagramas de Gantt, gesti´on de recursos, etc. Permitiendo as´ı administrar de forma completa la planificaci´on del proyecto. 5.2.5. Enterprise Architect Enterpise Architect [28] es un software de modelado UML que permite gestionar todo tipo de diagramas: de clases, secuencia, de arquitectura, etc. Se utiliza para gestionar todos los diagramas concernientes al dise˜no del proyecto as´ı como para la generaci´on de los diagramas de casos de uso. 5.2.6. Draw.io Draw.io [3] es una aplicaci´on web de dibujo de prop´osito general. Se utiliza para representar todos aquellos diagramas que no es posible representar mediante el “Enterprise Architect”. 5.2.7. Lumzy Lumzy [20] es una herramienta para la creaci´on de prototipos navegables de interfaces de usuario. 76 CAP´ ITULO 5. AN ´ ALISIS DE TECNOLOG´ IAS Y HERRAMIENTAS Cap´ıtulo 6 Dise˜no e Implementaci´on 6.1. Arquitectura del sistema La arquitectura del sistema permite ver a alto nivel como interacciona el sistema software con los distintos componentes externos al mismo. La figura 6.1 muestra un diagrama que representa la arquitectura de forma simplificada. En dicho diagrama se distinguen dos partes claramente diferenciadas; por una parte, aquellos elementos externos al software a desarrollar y sobre los que no tenemos control (denominados “sistemas externos”) y, por otra parte, aquellos elementos desarrollados en el proyecto sobre los que s´ı se tiene control (denominados “elementos internos”). As´ı, los dos ´unicos elementos externos son el anotador sem´antico ADEGA y la API de Youtube y ambos son accedidos a trav´es del servidor web. Dicho servidor alberga los servicios REST que son consumidos por el cliente y sirve de interfaz para realizar las peticiones a estos servicios externos, teniendo as´ı todo centralizado en el servidor. Los clientes web (representados en el diagrama como interfaces gr´aficas) ´unicamente consumen los servicios proporcionados por el servidor. Por otra parte, los accesos a las bases de datos tambi´en se realizan a trav´es del servidor y existe un proceso de sincronizaci´on entre la base de datos VoltDB y el motor de b´usqueda ElasticSearch mediante los mecanismos de exportaci´on proporcionados por VoltDB. El principal motivo por el que existen dos bases de datos reside, principalmente, en que ElasticSearch tiene varios problemas si se utiliza como almacenamiento de datos primario [4], tal y como se ha comenta77 84 CAP´ ITULO 6. DISE ˜ NO E IMPLEMENTACI ´ ON incluye las siguientes tablas: YoutubeVideo: almacena los metadatos del v´ıdeo. VideoTags: almacena las etiquetas de un v´ıdeo. ContextNode: almacena los nodos del contexto. RootNodes: almacena los nodos ra´ız del v´ıdeo. Relations: almacena las relaciones entre los nodos. Se almacena tanto el v´ıdeo que los relaciona como los identificadores de los nodos involucrados (que son los mismos que los obtenidos en ADEGA). Tambi´en se almacena el tipo de relaci´on que une a los nodos (persona, lugar de nacimiento, etc.). Implementaci´on de la exportaci´on en ElasticSearch ElasticSearch trabaja con una notaci´on similar a las bases de datos relacionales. Para ElasticSearch, un´ındice tiene la misma consideraci´on que una base de datos. Dentro de un ´ındice, es posible definir distintos “tipos” que, utilizando el simil con una base de datos relacional, se corresponder´ıan con una tabla. Dentro de un tipo existen documentos que, de nuevo, se corresponder´ıan con las distintas filas de una tabla en una base de datos relacional. A diferencia de la mayor´ıa de las bases de datos NoSQL, la definici´on de un tipo es est´atica, es decir, una vez definido un tipo no es posible que dos documentos tengan campos distintos. Por lo tanto, aquellos campos que no existan deber´an estar a NULL. Para simplificar la implementaci´on, solo se exportar´an los nodos relativos a los nodos ra´ız y los t´ıtulos de los v´ıdeos. Los primeros son necesarios para poder obtener los grafos a la hora de implementar el sistema. Los segundos son necesarios para obtener los v´ıdeos a la hora de administrar la base de datos de v´ıdeos (en la que se realiza una b´usqueda por t´ıtulo). Para habilitar la exportaci´on desde VoltDB, es preciso modificar el XML de configuraci´on para a˜nadir la url de acceso de ElasticSearch (endpoint). Dicha configuraci´on se modifica en el fichero “deployment.xml” de la ra´ız de la base de datos. Es preciso agregar el siguiente fragmento de XML: 6.3. MODELO DE DATOS 85 1<export> <configuration tar get=”elasticsearch” enabled=” true ” type=” elasticsearch”> 3<property name=” endpoint ”> http : // 1 0. 10 . 0. 16 0: 92 00 / voltdb /adega 5</property> </configuration > 7</export> En el anterior fragmento de c´odigo, especificamos el´ındice ElasticSearch (voltdb) y el tipo de documento (ADEGA). En caso de que no exista cualquiera de los dos elementos anteriores, este ser´a creado autom´aticamente por VoltDB. Asimismo, tambi´en especificamos el nombre de la exportaci´on, necesario para crear la tabla virtual de inserci´on. Para crear la tabla virtual de inserci´on se utiliza el siguiente c´odigo1: 1CREATE STREAM ROOTNODES EXPORTED EXPORT TO TARGET e l a s t i c s e a r c h ( VIDEOID varchar(2048) NOT NULL, 3VIDEOTITLE varchar(2048) NOT NULL, NODEID i n t e g e r NOT NULL, 5LABEL varchar(2048) , RESOURCE varchar(2048) , 7WEIGHT float , ISCATEGORY integer 9) ; As´ı, cada documento del ´ındice est´a compuesto por el identificador del v´ıdeo y uno de los nodos asociados al grafo obtenido del v´ıdeo. Implementaci´on de la persistencia en VoltDB Como se ha comentado en apartados anteriores, VoltDB es una base de datos fundamentalmente en memoria, por lo que en caso de que la base de datos se 1El nombre “elasticsearch” se corresponde con el identificador definido en el XML 86 CAP´ ITULO 6. DISE ˜ NO E IMPLEMENTACI ´ ON apague los datos se perder´ıan. Sin embargo, es posible conseguir persistencia mediante varias v´ıas [33]: Snapshots: mediante esta caracter´ıstica, se tiene un volcado completo de la base de datos en un momento temporal. Estos volcados se pueden programar para ocurrir a ciertos intervalos. Command Logging: mediante esta caracter´ıstica, se tiene un log de las operaciones de cada transacci´on. Cuando la base de datos se apaga, se recuperan los datos primero del volcado de la base de datos y, posteriormente, del registro de operaciones hasta alcanzar un estado consistente. K-safety: en un sistema distribuido, se refiere al n´umero de duplicaciones de las particiones de una base de datos (siendo una partici´on un fragmento de los datos totales almacenados en la base de datos), de tal manera que la p´erdida de un servidor no ocasione una interrupci´on del servicio. As´ı, por ejemplo, un valor de K-safety de 2 indica que existen dos copias de una partici´on distribuidas en el sistema. Database replication: es similar a K-safety solo que, en lugar de copiar una partici´on, se copia la base de datos entera. Esta funcionalidad est´a pensada para tener copias de una misma base de datos en lugares geogr´aficos distintos. Desafortunadamente, las caracter´ısticas Command Logging yK-safety no est´an disponible en la versi´on gratu´ıta de VoltDB (Community). Adem´as, no tiene ning´un sentido realizar replicaci´on de la base de datos en un sistema que no es distribuido (tal y como se indic´o en las restricciones del proyecto). Por lo tanto, la ´unica estrategia a utilizar es la utilizaci´on de Snapshots. Configurar esta caracter´ıstica es muy sencillo: basta con agregar la siguiente l´ınea al fichero deployment.xml: 1<snapshot frequency=”10m” retain=”4” p r e f i x=”adegaVideoDB”/> 6.4. SERVIDOR WEB (BACKEND) 87 La anterior l´ınea permite configurar Snapshots con una periodicidad de 10 minutos. Para evitar que las copias llenen el disco duro, instru´ımos a VoltDB para que ´unicamente conserve las 4 m´as recientes. Dichas copias estar´an prefijadas con el nombre “adegaVideoDB”. 6.4. Servidor Web (backend) 6.4.1. Diagrama de paquetes El servidor web es el elemento del sistema m´as complejo. Por ello, es preciso una organizaci´on de las clases del c´odigo en paquetes que faciliten la programaci´on y permitan una mayor extensibilidad en un futuro. Dichos paquetes no se corresponden con un m´odulo en concreto del sistema, sino que agrupan clases con funcionalidades comunes. As´ı, el diagrama de paquetes que representa al servidor web es el que se muestra en la figura 6.4. Se distingue la siguiente divisi´on en paquetes: Controller: contiene todos los controladores Spring, es decir, todos los m´etodos Java que se traducen a servicios REST. QuestionAnswering: contiene todas las clases relativas a la implementaci´on del sistema pregunta-respuesta. Youtube: contiene todas las clases que permiten acceder al API de Youtube y obtener los datos necesarios de la misma. Management: contiene todas las clases que permiten administrar los v´ıdeos del sistema. DAO: contiene todos las clases DAO que permiten acceder a las distintas bases de datos. Tambi´en incluye la factor´ıa abstracta que permite instanciar los DAOs. JobQueue: contiene las clases relativas a crear y manejar la cola de procesamiento de anotaciones de v´ıdeos. Adega: contiene todas aquellas clases que permiten interaccionar con ADEGA. 88 CAP´ ITULO 6. DISE ˜ NO E IMPLEMENTACI ´ ON Figura 6.4: Diagrama de paquetes del backend Las dependencias entre paquetes se derivan de los detalles de implementaci´on de las funcionalidades. En concreto son salientables las dependencias siguientes: Se puede observar que el prop´osito del controlador es delegar la responsabilidad de las llamadas a los servicios al paquete que se encargue de ello. Los servicios que ´unicamente consultan a Youtube (b´usqueda de canales y v´ıdeos del canal) se redirigen directamente al paquete “Youtube”. 6.4. SERVIDOR WEB (BACKEND) 89 El paquete “JobQueue” necesita del paquete Youtube. Esto se debe a que, lo ´unico que se necesita para encolar un v´ıdeo es el identificador del mismo. Esto permite utilizar el mismo m´etodo tanto para procesar los v´ıdeos seleccionados por un usuario como procesar los v´ıdeos en lote (que simplemente son cadenas de texto). El paquete “QuestionAnswering” precisa del paquete “Adega” debido a que se utiliza en las primeras fases para procesar el lenguaje natural del usuario. A continuaci´on se proceder´an a describir los patrones de dise˜no utilizados y el contenido de los paquetes anteriormente descritos. 6.4.2. Patrones de dise˜no software Un patr´on de dise˜no es una t´ecnica utilizada para resolver problemas comunes de dise˜no de software. Los patrones aqu´ı listados hacen referencia a los patrones GoF (Gang Of Four) creados por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides [8]. En concreto, los patrones utilizados en este proyecto son los siguientes: DAO/DTO: no encajan directamente en la categor´ıa de patrones de dise˜no puesto que son una forma de estructurar los accesos a los datos. Por una parte un DAO es un objeto que suministra una interfaz com´un entre la aplicaci´on y los accesos a una fuente de datos (habitualmente una base de datos). Por otra parte, DTO constituye un objeto que permite transportar datos entre distintas partes de la aplicaci´on sin poseer en s´ı mismo nada m´as que capacidad para almacenar datos. As´ı, un DAO realiza consultas a la fuente de datos devolviendo DTOs como resultado. Estos dos tipos de objeto son la base para el patr´on Abstract Factory. Abstract Factory: permite controlar la instanciaci´on de clases. En concreto, se utiliza para controlar la creaci´on de los objetos DAO de tal manera que sea posible modificar la base de datos que se est´e utilizando de forma sencilla. As´ı, a˜nadir una nueva base de datos al sistema implica ´unicamente implementar las interfaces correspondientes al DAO y modificar la factor´ıa para que tenga en cuenta la nueva base de datos a la hora de obtener los correspondientes DAOs. 90 CAP´ ITULO 6. DISE ˜ NO E IMPLEMENTACI ´ ON Singleton: este patr´on de dise˜no permite restringir la instanciaci´on de objetos de una clase. En concreto, se utiliza este patr´on para que haya un ´unico objeto DAO instanciado a lo largo del programa, es decir, todos los accesos a los datos pasan por un ´unico objeto. Este patr´on se utiliza en combinaci´on con el patr´on Abstract Factory de tal manera que la factor´ıa controla la instanciaci´on de objetos asegur´andose que solo hay un DAO instanciado a la vez. Strategy: permite mantener un conjunto de algoritmos de tal manera que se pueda elegir el algoritmo m´as conveniente para cada ocasi´on. Se utiliza en el sistema pregunta-respuesta para dividir los algoritmos de b´usqueda por palabras y comparaci´on de grafos conceptuales en algoritmos distintos, permitiendo as´ı el uso de uno u otro de forma independiente. Facade: permite reducir la complejidad de un subsistema mediante una interfaz simple a un sistema complejo. Se utiliza en el sistema de anotaci´on para abstraer la complejidad del API de Youtube mediante la ocultaci´on de los tipos devueltos por el API de Youtube as´ı como mediante una simplificaci´on de las operaciones que se pueden realizar a trav´es del API con la definici´on de m´etodos claros y sencillos. 6.4.3. Diagramas de clases Un diagrama de clases es una estructura que permite mostrar las distintas clases que conforman un sistema software as´ı como sus relaciones, atributos y m´etodos. Los diagramas de clases aqu´ı mostrados no pretenden ser una descripci´on exhaustiva de las clases del sistema si no que solo muestran los aspectos m´as importantes de las clases que conforman los distintos paquetes as´ı como las relaciones entre las clases de un mismo paquete. Paquete “Youtube” Como ya se ha comentado anteriormente, este paquete se encarga de acceder a la API de Youtube para obtener la informaci´on relevante sobre los v´ıdeos y canales. La estructura del paquete se detalla en el diagrama de clases de la figura 6.5. 6.4. SERVIDOR WEB (BACKEND) 91 Figura 6.5: Diagrama de clases del paquete Youtube. 92 CAP´ ITULO 6. DISE ˜ NO E IMPLEMENTACI ´ ON En primer lugar, existen tres clases (YoutubeVideo,YoutubeVideoStatistics yYoutubeChannel) que son simplemente contenedores de datos de los v´ıdeos de Youtube, las estad´ısticas de cada v´ıdeo y los canales de Youtube respectivamente. Se utilizan estas clases en lugar de las proporcionadas por el API de Youtube para simplificar la transmisi´on de datos entre el cliente web y el servidor. As´ı, no se transmiten datos que no sean necesarios para el cliente ni para el servidor web. Como se puede observar, existe una fachada (YoutubeFacade) que permite abstraer la complejidad de utilizaci´on de la API de Youtube mediante la ejecuci´on de m´etodos que no devuelvan ni reciban como par´ametro clases internas del API. Dicha clase tiene como m´etodos las funcionalidades principales del paquete que son las siguientes: downloadSubtitles: Se encarga de descargar los subtitulos. Requiere de los datos del v´ıdeo (para saber que lenguaje debe descargarse y de que v´ıdeo), el nombre del fichero donde se guardar´an los subt´ıtulos y, por ´ultimo, el modo de descarga de los subt´ıtulos. Este ´ultimo par´ametro controla si los subtitulos se descargan de forma “limpia” o “no limpia”, es decir, si se purgan los elementos que no sean puramente subt´ıtulos textuales o no (puesto que los subt´ıtulos se descargan en formato XML y es preciso eliminar las etiquetas). getChannelsByDisplayName: Obtiene una lista de canales seg´un el nombre que se muestre al p´ublico. Estos nombres pueden no ser un´ıvocos por lo que se devuelve una lista de canales en funci´on de la aproximaci´on de la consulta. getVideoFromId: a partir de un identificador de un v´ıdeo (que es posible obtener directamente desde la URL del mismo) se obtienen los datos relacionados con ese v´ıdeo. getVideosFromChannel: obtiene los v´ıdeos de un canal. Recibe como par´ametro el identificador del canal y el token del canal. Dicho token permite obtener la lista de v´ıdeos del canal de forma paginada, es decir, en fragmentos de N v´ıdeos de cada vez (en lugar de todos a la vez, que podr´ıa ser una operaci´on que tarde mucho tiempo). Se utiliza la clase Java String- 6.4. SERVIDOR WEB (BACKEND) 93 Builder en lugar de la clase String para permitir simular un paso por referencia del token: cada vez que se pida una nueva lista de v´ıdeos con un determinado token, se devuelve el siguiente token a trav´es de este par´ametro del m´etodo (utilizando los m´etodos internos para modificar la cadena que contiene el StringBuilder). Esto permite sortear la limitaci´on de Java de devolver un ´unico elemento en una funci´on y tener que crear una clase que albergue tanto la lista de v´ıdeos como el siguiente token de cada vez. Existe una clase que se encarga espec´ıficamente de facilitar las operaciones necesarias para la descarga de los subt´ıtulos (SubtitleDownloader). Dicha clase est´a compuesta de los siguientes m´etodos: getSubtitleInfo: consulta el API de Youtube sobre los subt´ıtulos disponibles para un v´ıdeo en concreto. Es preciso mencionar que el API de Youtube no permite descargar cualquier subt´ıtulo: solo permite descargar aquellos que han sido creados por un humano y no aquellos que son autogenerados por el sistema de generaci´on de subt´ıtulos de Youtube. findDownloadUrl: Este m´etodo se encarga de obtener la URL interna de descarga de los subt´ıtulos. El c´odigo correspondiente a este m´etodo se presenta en el siguiente extracto de c´odigo: 1String magicUrl = v . retrieveMagicURL ( videoUrl ) ; magicUrl += ”&” ; 3magicUrl += ”name=” + capti on Info . getSnippet () . getName ( ) + ”&” ; magicUrl += ” lang=” + c aptio nI nfo . getSnippet ( ) . getLanguage () + ”&” ; 5magicUrl += ” type=track&” ; String kind = capt ionIn fo . getSnippet ( ) . getTrackKind () . toLowerCase ( ) ; 7i f ( ! kind . eq uals ( ” standard ” ) ) magicUrl += ” kind=” + capti on Info . getSnippet ( ) . getTrackKind () . toLowerCase () ; 9 return magicUrl ; 100 CAP´ ITULO 6. DISE ˜ NO E IMPLEMENTACI ´ ON la consulta, los t´erminos asociados a la consulta (que realmente se obtienen del grafo, pero as´ı es m´as sencillo) y el hist´orico del paciente2. Figura 6.10: Diagrama de clases del paquete “QuestionAnswering” Paquete “Controller” El diagrama de clases para este paquete se muestra en la figura 6.11. Este paquete contiene la implementaci´on de todos los servicios REST de la aplicaci´on. Como se puede observar en el diagrama de paquetes, simplemente delega la responsabilidad de resolver la llamada en el paquete correspondiente al servicio. Los controladores existentes en la aplicaci´on y su funcionalidad son los siguientes: VideoController: controlador asociado a la recuperaci´on de v´ıdeos y canales. As´ı, este controlador invoca a los siguientes servicios REST: Controlador: VideoController Servicio: [GET]/searchChannels Descripci´on: Busca los canales de Youtube que se correspondan con la consulta del usuario Par´ametros: displayName: consulta del usuario a buscar Respuesta: 2En el caso del estado actual del proyecto no se tiene en cuenta. Se a˜nade con previsi´on de una posible ampliaci´on. 6.4. SERVIDOR WEB (BACKEND) 101 200 (OK): c´odigo de respuesta est´andar HTTP que indica que la operaci´on se ha llevado a cabo con ´exito. se devuelve un resultado en formato json 500 (INTERNAL SERVER ERROR): c´odigo de respuesta est´andar HTTP que indica que ha habido un fallo al procesar la petici´on. Controlador: VideoController Servicio: [GET]/searchVideos Descripci´on: Busca los v´ıdeos asociados a un canal. Par´ametros: channelID: identificador del canal. token: token que permite paginar la recuperaci´on de los v´ıdeos Respuesta: 200 (OK): c´odigo de respuesta est´andar HTTP que indica que la operaci´on se ha llevado a cabo con ´exito. se devuelve un resultado en formato json 500 (INTERNAL SERVER ERROR): c´odigo de respuesta est´andar HTTP que indica que ha habido un fallo al procesar la petici´on. AnotationController: controlador asociado a la anotaci´on de v´ıdeos, es decir, a la creaci´on de trabajos en cola. As´ı, este controlador invoca a los siguientes servicios REST: Controlador: AnotationController Servicio: [POST]/anotate Descripci´on: A˜nade tantos trabajos en cola como v´ıdeos se le pasen como par´ametro. Par´ametros: listVideo: lista de v´ıdeos a anotar separados por una coma cada uno. Respuesta: 200 (OK): c´odigo de respuesta est´andar HTTP que indica que la operaci´on se ha llevado a cabo con ´exito. se devuelve un resultado en formato json 500 (INTERNAL SERVER ERROR): c´odigo de respuesta est´andar HTTP que indica que ha habido un fallo al procesar la petici´on. 102 CAP´ ITULO 6. DISE ˜ NO E IMPLEMENTACI ´ ON Controlador: AnotationController Servicio: [GET]/getJobs Descripci´on: Obt´en la lista de trabajos actuales del sistema junto con el estado de los mismos. No tiene par´ametros. Respuesta: 200 (OK): c´odigo de respuesta est´andar HTTP que indica que la operaci´on se ha llevado a cabo con ´exito. se devuelve un resultado en formato json 500 (INTERNAL SERVER ERROR): c´odigo de respuesta est´andar HTTP que indica que ha habido un fallo al procesar la petici´on. ManagementController: controlador asociado a la administraci´on de los v´ıdeos anotados en el sistema. As´ı, este controlador invoca a los siguientes servicios REST: Controlador: ManagementController Servicio: [GET]/getVideoCount Descripci´on: Permite obtener estad´ısticas de los v´ıdeos almacenados en la base de datos. No tiene par´ametros. Respuesta: 200 (OK): c´odigo de respuesta est´andar HTTP que indica que la operaci´on se ha llevado a cabo con ´exito. se devuelve un resultado en formato json 500 (INTERNAL SERVER ERROR): c´odigo de respuesta est´andar HTTP que indica que ha habido un fallo al procesar la petici´on. Controlador: ManagementController Servicio: [GET]/getAllVideos Descripci´on: Obt´en todos los v´ıdeos de la base de datos relacionados con la consulta del usuario. Par´ametros: query: consulta del usuario para obtener los v´ıdeos de la base de datos Respuesta: 200 (OK): c´odigo de respuesta est´andar HTTP que indica que la operaci´on se ha llevado a cabo con ´exito. se devuelve un resultado en formato json 6.4. SERVIDOR WEB (BACKEND) 103 500 (INTERNAL SERVER ERROR): c´odigo de respuesta est´andar HTTP que indica que ha habido un fallo al procesar la petici´on. Controlador: ManagementController Servicio: [GET]/delete Descripci´on: Elimina un conjunto de v´ıdeos del sistema. Par´ametros: videoList: lista de identificadores de los v´ıdeos a eliminar del sistema (separados por una coma cada uno). Respuesta: 200 (OK): c´odigo de respuesta est´andar HTTP que indica que la operaci´on se ha llevado a cabo con ´exito. se devuelve un resultado en formato json 500 (INTERNAL SERVER ERROR): c´odigo de respuesta est´andar HTTP que indica que ha habido un fallo al procesar la petici´on. Controlador: ManagementController Servicio: [GET]/update Descripci´on: Actualiza un conjunto de v´ıdeos del sistema. Par´ametros: videoList: lista de identificadores de los v´ıdeos a actualizar del sistema (separados por una coma cada uno. Respuesta: 200 (OK): c´odigo de respuesta est´andar HTTP que indica que la operaci´on se ha llevado a cabo con ´exito. se devuelve un resultado en formato json 500 (INTERNAL SERVER ERROR): c´odigo de respuesta est´andar HTTP que indica que ha habido un fallo al procesar la petici´on. Controlador: ManagementController Servicio: [GET]/getGraph Descripci´on: Obtiene un grafo asociado a un v´ıdeo en concreto. Par´ametros: videoId: identificador del v´ıdeo del cual se debe recuperar el grafo. Respuesta: 104 CAP´ ITULO 6. DISE ˜ NO E IMPLEMENTACI ´ ON 200 (OK): c´odigo de respuesta est´andar HTTP que indica que la operaci´on se ha llevado a cabo con ´exito. se devuelve un resultado en formato json 500 (INTERNAL SERVER ERROR): c´odigo de respuesta est´andar HTTP que indica que ha habido un fallo al procesar la petici´on. UserQueryController: controlador encargado de procesar las consultas del usuario del sistema pregunta-respuesta. As´ı, este controlador invoca a los siguientes servicios REST: Controlador: UserQueryController Servicio: [POST]/processQuery Descripci´on: A partir de una consulta en lenguaje natural del usuario se obtiene una lista de v´ıdeo relevantes. Se diferencia del servicio de obtenci´on de v´ıdeos de “ManagementController” en que la b´usqueda que se realiza aqu´ı es mucho m´as precisa (puesto que utiliza el algoritmo pregunta-respuesta). Par´ametros: query: consulta en lenguaje natural del paciente Respuesta: 200 (OK): c´odigo de respuesta est´andar HTTP que indica que la operaci´on se ha llevado a cabo con ´exito. se devuelve un resultado en formato json 500 (INTERNAL SERVER ERROR): c´odigo de respuesta est´andar HTTP que indica que ha habido un fallo al procesar la petici´on. 6.5. Diagramas de secuencia Los diagramas de secuencia permiten mostrar las interacciones entre las distintas instancias de clases y los actores. Se omiten aquellos diagramas de secuencia que sean demasiado sencillos como para aportar informaci´on relevante. En concreto, se omiten los diagramas de secuencia de los casos de uso CU. 7 (“Ver metadatos”), CU. 8 (“Ver subt´ıtulos”), CU. 12 (“Mostrar grafo”), CU. 13 6.5. DIAGRAMAS DE SECUENCIA 105 Figura 6.11: Diagrama de clases para el paquete “Controller” (“Mostrar estad´ısticas”). 6.5.1. Anotaci´on de v´ıdeos. El diagrama de secuencia de la figura 6.12 muestra las interacciones del administrador con el sistema para realizar la anotaci´on de los v´ıdeos, es decir, obtener el grafo asociado a un conjunto de v´ıdeos de la plataforma Youtube y almacenarlos en el sistema. Este diagrama corresponde al caso de uso CU. 1 (“Anotar v´ıdeo sem´anticamente”) y CU. 3 (“A˜nadir v´ıdeo en cola”). 106 CAP´ ITULO 6. DISE ˜ NO E IMPLEMENTACI ´ ON Figura 6.12: Diagrama de secuencia: “anotaci´on de v´ıdeos” 6.5. DIAGRAMAS DE SECUENCIA 107 La interacci´on se inicia con la llamada al servicio de anotaci´on pasando una lista de identificadores de v´ıdeo como par´ametros. Por cada v´ıdeo, se env´ıa un nuevo trabajo en cola, identificado por la instanciaci´on de la l´ınea de vida “Job”. Cada trabajo realiza las siguientes operaciones: Descarga los subt´ıtulos asociados a un v´ıdeo. No se entra en las interioridades de la descarga de subt´ıtulos puesto que depende enormemente del modo de descarga de los mismos. Realiza una llamada a ADEGA para obtener el contexto asociado a los subtitulos descargados. Realiza una llamada a ADEGA para obtener los nodos ra´ız del contexto obtenido anteriormente. Realiza otra llamada a ADEGA para obtener el grafo asociado al contexto y a los nodos ra´ız obtenidos en los dos pasos anteriores. Toda esta informaci´on (la obtenida de las llamadas a ADEGA junto con la informaci´on de los v´ıdeos) se almacena en las bases de datos. El mismo m´etodo de almacenamiento realiza la sincronizaci´on entre las bases de datos. Se notifica al administrador de que el trabajo ha finalizado exitosamente. 6.5.2. B´usqueda de canales y v´ıdeos. El diagrama de secuencia de la figura 6.13 muestra las interacciones del administrador con el sistema cuando desea realizar una b´usqueda de canales y v´ıdeos de la plataforma Youtube. Este diagrama corresponde a los casos de uso CU. 5 (“Buscar canales”) y CU.6 (“Buscar v´ıdeos”). En primer lugar, la interacci´on se inicia con la b´usqueda de un canal en funci´on de su nombre. De ah´ı, se devuelve una lista de canales, junto con el identificador de cada canal (representado por la clase “YoutubeChannel”). Posteriormente, se obtienen los v´ıdeos asociados a un canal en concreto mediante su identificador. Para cada v´ıdeo (representado por un PlayListItem) se obtienen los metadatos del v´ıdeo asociado (representado por el bucle). Se devuelve al usuario una lista de v´ıdeos del canal seleccionado. 108 CAP´ ITULO 6. DISE ˜ NO E IMPLEMENTACI ´ ON Figura 6.13: Diagrama de secuencia: “b´usqueda de canales y v´ıdeos” 6.5. DIAGRAMAS DE SECUENCIA 109 6.5.3. Mostrar v´ıdeos anotados El diagrama de secuencia de la figura 6.14 muestra las interacciones del administrador con el sistema cuando desea ver los v´ıdeos que hay anotados en el sistema. Este diagrama se corresponde con el caso de uso CU. 9 (“Mostrar v´ıdeos anotados”). Figura 6.14: Diagrama de secuencia: “Mostrar v´ıdeos anotados” La interacci´on se inicia con la llamada al servicio de obtenci´on de v´ıdeos en funci´on de una consulta. Primeramente, se consulta a ElasticSearch acerca de los v´ıdeos disponibles en el sistema. Esto se realiza as´ı debido a que ElasticSearch permite una mayor flexibilidad a la hora de realizar b´usquedas en funci´on de campos de texto. De la consulta se obtiene una lista de v´ıdeos asociados, y, a su vez, para cada v´ıdeo de la lista se obtienen los metadatos m´as relevantes (t´ıtulo y descripci´on, principalmente) de VoltDB. Estos datos se devuelven al administrador para su visualizaci´on. 116 CAP´ ITULO 6. DISE ˜ NO E IMPLEMENTACI ´ ON b´usquedas. Los resultados se devuelven justo debajo por orden de relevancia de la misma manera que en el prototipo de la figura 6.19. Figura 6.20: Prototipo de la p´agina de pregunta respuesta. 6.6.2. Implementaci´on de la interfaz de usuario Para la implementaci´on de la interfaz de usuario se ha decidido por implementar una Single Page Application (SPA) utilizando AngularJS yBulma. As´ı, el esqueleto de la aplicaci´on consiste tanto en la barra de navegaci´on izquierda como en la barra de t´ıtulo y en la parte derecha se intercambian las distintas p´aginas de la aplicaci´on: mostrar v´ıdeos, buscar canales, mostrar resultados de las anotaciones... Cada una de estas p´aginas se corresponde con un controlador en AngularJS. As´ı, la p´agina principal de la aplicaci´on tiene el aspecto mostrado en la figura 6.21. Como se puede observar, en la parte izquierda de la p´agina existe una barra de navegaci´on que permite acceder a las principales funcionalidades de la aplicaci´on. La parte central alberga el contenido en cuesti´on de cada funcionalidad que, en este caso, muestra estad´ısticas del sistema (“dashboard”). Por otra parte, la p´agina que muestra los v´ıdeos de un canal tiene el aspecto mostrado en la figura 6.22. Como se puede ver, se permite visualizar el v´ıdeo 6.6. INTERFACES DE USUARIO (FRONTEND)117 Figura 6.21: Implementaci´on de la pantalla principal de la aplicaci´on. directamente (pulsando sobre la miniatura), se muestran algunos datos b´asicos y se permite a˜nadir para selecci´on en el “checkbox” adjunto a cada v´ıdeo. Adem´as, se permite ver los metadatos espec´ıficos de cada v´ıdeo pulsando sobre el bot´on “Ver metadatos”. Los v´ıdeos seleccionados pueden ser enviados para su anotaci´on pulsando sobre el bot´on inferior derecho “Anotar seleccionados”. Por ´ultimo, la interfaz pregunta respuesta tiene el aspecto mostrado en la figura 6.23. Esta interfaz simplemente consiste en un buscador que muestra la respuesta al usuario inmediatamente debajo. Figura 6.22: Implementaci´on de la visualizaci´on de v´ıdeos de un canal. 118 CAP´ ITULO 6. DISE ˜ NO E IMPLEMENTACI ´ ON Figura 6.23: Implementaci´on de la interfaz del sistema pregunta-respuesta. Cap´ıtulo 7 Pruebas y validaci´on 7.1. Pruebas unitarias Las pruebas unitarias sirven para asegurar el correcto funcionamiento de un fragmento o m´odulo de c´odigo. Para la implementaci´on de estas pruebas unitarias se ha utilizado JUnit, un framework Java para la creaci´on de pruebas unitarias. Las pruebas que se implementen ser´an pruebas de caja negra, por simplicidad. Para la especificaci´on de las pruebas unitarias, se definir´a el m´etodo a probar as´ı como los par´ametros que se le suministran, tal y como especifica la siguiente plantilla: Identificador: PU-X M´etodo a probar: M´etodo a probar Par´ametros: Par´ametros que se le suministran al m´etodo Resultado esperado: Resultado esperado de la prueba unitaria Precondiciones: Precondiciones de la prueba Ejemplo de llamada Ejemplo de una llamada As´ı, el cat´alogo de pruebas realizado es el siguiente: 119 120 CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON Identificador: PU-1 M´etodo a probar: YoutubeFacade.getVideoFromId Par´ametros: “lIqT3WX SUc” Resultado esperado: Ejecuci´on correcta. Se obtiene un objeto con los datos del v´ıdeo. El t´ıtulo del v´ıdeo es “Turning the Page to a New Decade” Precondiciones: No hay Ejemplo de llamada new YoutubeFacade().getVideoFromId(“lIqT3WX SUc”) Identificador: PU-2 M´etodo a probar: SubtitleDownloader.getvideoSubtitle Par´ametros: “lIqT3WX SUc” Resultado esperado: Se obtiene un objeto con los subtitulos del v´ıdeo. Los ´unicos subt´ıtulos disponibles son de tipo ASR y EN, es decir, autogenerados y en ingl´es. Precondiciones: No hay Ejemplo de llamada new SubtitleDownloader().getVideoSubtitles(“lIqT3WX SUc”) Identificador: PU-3 M´etodo a probar: SubtitleDownloader.findDownloadUrl Par´ametros: s.getvideoSubtitles(“lIqT3WX SUc”).get(0) “lIqT3WX SUc” Resultado esperado: Se obtiene una URL que corresponde con los subt´ıtulos autogenerados del v´ıdeo (en formato XML) Precondiciones: No hay Ejemplo de llamada SubtitleDownloader s = new SubtitleDownloader(); s.findDownloadUrl(s.getVideoSubtitles(“lIqT3WX SUc”).get(0), “lIqT3WX SUc”) 7.1. PRUEBAS UNITARIAS 121 Identificador: PU-4 M´etodo a probar: SubtitleDownloader.downloadSubtitle Par´ametros: s.findDownloadUrl(s.getVideoSubtitles(“lIqT3WX SUc”).get(0)), “subtitulos.txt”, DownloadMode.NOT CLEAN Resultado esperado: Se obtiene un fichero denominado “subt´ıtulos.txt” que contiene los subt´ıtulos descargados de Youtube. Los subt´ıtulos contienen etiquetas XML. Precondiciones: No hay Ejemplo de llamada s.downloadSubtitle( s.findDownloadUrl(s.getVideoSubtitles(“lIqT3WX SUc”).get(0)), “subtitulos.txt”, DownloadMode.NOT CLEAN ) Identificador: PU-5 M´etodo a probar: SubtitleDownloader.downloadSubtitle Par´ametros: s.findDownloadUrl(s.getVideoSubtitles(“lIqT3WX SUc”).get(0)), “subtitulos.txt”, DownloadMode.CLEAN Resultado esperado: Se obtiene un fichero denominado “subt´ıtulos.txt” que contiene los subt´ıtulos descargados de Youtube. Los subt´ıtulos no contienen etiquetas XML. Precondiciones: No hay Ejemplo de llamada s.downloadSubtitle( s.findDownloadUrl(s.getVideoSubtitles(“lIqT3WX SUc”).get(0)), “subtitulos.txt”, DownloadMode.CLEAN ) Identificador: PU-5 M´etodo a probar: SubtitleDownloader.downloadSubtitle Par´ametros: s.findDownloadUrl(s.getVideoSubtitles(“aaaa”).get(0)), “subtitulos.txt”, DownloadMode.CLEAN Resultado esperado: Se devuelve un error asociado a que el v´ıdeo no existe en la base de datos de Youtube. Precondiciones: No hay Ejemplo de llamada s.downloadSubtitle( s.findDownloadUrl(s.getVideoSubtitles(“aaaa”).get(0)), “subtitulos.txt”, DownloadMode.CLEAN ) 122 CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON Identificador: PU-6 M´etodo a probar: SubtitleDownloader.dowloadSubtitle Par´ametros: s.findDownloadUrl(s.getVideoSubtitles(“GRxofEmo3HA”).get(0)), “subtitulos.txt”, DownloadMode.CLEAN Resultado esperado: Se devuelve un error asociado a que el v´ıdeo no posee subt´ıtulos. Precondiciones: No hay Ejemplo de llamada s.downloadSubtitle( s.findDownloadUrl(s.getVideoSubtitles(“GRxofEmo3HA”).get(0)), “subtitulos.txt”, DownloadMode.CLEAN ) Identificador: PU-7 M´etodo a probar: Mangement.update Par´ametros: “lIqT3WX SUc” Resultado esperado: Se actualiza el contenido tanto de la anotaci´on del v´ıdeo como de los metadatos de Youtube Precondiciones: El v´ıdeo debe estar anotado previamente en la base de datos. Preferentemente, su contenido en la base de datos debe estar a “null” (para que sea m´as f´acil de comprobar) Ejemplo de llamada new Management().update(“lIqT3WX SUc”) Identificador: PU-8 M´etodo a probar: Management.update Par´ametros: “aaaaaa” Resultado esperado: El sistema devuelve un error asociado a que no se puede actualizar el v´ıdeo. Precondiciones: El v´ıdeo no debe estar anotado en las bases de datos Ejemplo de llamada new Management().update(“aaaaaaa”) 7.1. PRUEBAS UNITARIAS 123 Identificador: PU-9 M´etodo a probar: Management.delete Par´ametros: “lIqT3WX SUc” Resultado esperado: El v´ıdeo es eliminado de la base de datos. Precondiciones: El v´ıdeo debe estar anotado previamente en la base de datos. Ejemplo de llamada new Management().delete(“lIqT3WX SUc”) Identificador: PU-10 M´etodo a probar: Management.delete Par´ametros: “aaaaaa” Resultado esperado: El sistema devuelve un error asociado a que no se puede eliminar el v´ıdeo. Precondiciones: El v´ıdeo no debe estar anotado en las bases de datos Ejemplo de llamada new Management().update(“aaaaaaa”) Identificador: PU-11 M´etodo a probar: Management.delete Par´ametros: null Resultado esperado: El sistema devuelve un error asociado a que no se puede eliminar el v´ıdeo. Precondiciones: El v´ıdeo no debe estar anotado en las bases de datos Ejemplo de llamada new Management().update(null) Identificador: PU-12 M´etodo a probar: Management.getGraph Par´ametros: “lIqT3WX SUc” Resultado esperado: Se obtiene el grafo asociado al v´ıdeo. Precondiciones: El v´ıdeo debe estar anotado previamente en la base de datos. Ejemplo de llamada new Management().getGraph(“lIqT3WX SUc”) 124 CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON Identificador: PU-13 M´etodo a probar: YoutubeFunctionalities.getAllVideosFromChannel Par´ametros: “lIqT3WX SUc” Resultado esperado: Se obtiene una lista de “PlayListItems” con los v´ıdeos asociados al canal Precondiciones: No hay Ejemplo de llamada new YoutubeFunctionalities.getAllVideosFromChannel(“lIqT3WX SUc”) 7.2. Pruebas de integraci´on Las pruebas de integraci´on se realizan una vez se han superado las pruebas unitarias sobre el software. El prop´osito principal de las mismas es probar que los distintos m´odulos que conforman el software funcionen bien en su conjunto. De nuevo, para la codificaci´on de las pruebas se utiliza JUnit. Para la realizaci´on de estas pruebas, lo m´as sencillo es llamar a los distintos servicios expuestos en la aplicaci´on. Para ello, se utiliza una librer´ıa denominada “MockMVC” que permite realizar llamadas a los distintos servicios, configurando distintos par´ametros sobre dichas llamadas y comprobar las respuestas a las llamadas a los servicios. La plantilla para este tipo de pruebas es muy similar que la utilizada para las pruebas unitarias. El cat´alogo de pruebas de integraci´on es el siguiente: Identificador: PI-1 Servicio a probar: /anotate Par´ametros: “lIqT3WX SUc” Resultado esperado: El sistema a˜nade el trabajo a la cola de anotaciones. Se anota el v´ıdeo en las bases de datos. Precondiciones: Las bases de datos est´an desplegadas y el v´ıdeo no est´a anotado en la base de datos. Ejemplo de llamada this.mock.perform(post(/anotate”) .param(.anotation”,”lIqT3WX SUc”)) .andExpect(status().isOk()) .andExpect(content() .contentType(MediaType.APPLICATION JSON UTF8)); 7.2. PRUEBAS DE INTEGRACI ´ ON 125 Identificador: PI-2 Servicio a probar: /anotate Par´ametros: “qwertyuiop” Resultado esperado: El sistema devuelve un error indicando que el v´ıdeo no existe Precondiciones: Las bases de datos est´an desplegadas. Ejemplo de llamada this.mock.perform(post(/processQuery”) .param(.anotation”, ”qwertyuiop”)) .andExpect(status().isInternalServerError()) .andExpect(content().contentType(MediaType.APPLICATION JSON UTF8)); Identificador: PI-3 Servicio a probar: /anotate Par´ametros: “lIqT3WX SUc”, “FukBZp9gyQQ” Resultado esperado: El sistema a˜nade un trabajo por cada v´ıdeo a la cola de anotaciones. Se anota cada v´ıdeo en las bases de datos. Precondiciones: Las bases de datos est´an desplegadas y los v´ıdeos no est´an anotados en las base de datos. Ejemplo de llamada this.mock.perform(post(/anotate”) .param(.anotation”,”lIqT3WX SUc”)) .param(“anotation”, “FukBZp9gyQQ”) .andExpect(status().isOk()).andExpect(content() .contentType(MediaType.APPLICATION JSON UTF8)); Identificador: PI-4 Servicio a probar: /processQuery Par´ametros: “I have diabetes and hypertension.” Resultado esperado: El sistema devuelve un conjunto de v´ıdeos relevantes en funci´on de la consulta del usuario. Precondiciones: Las bases de datos est´an desplegadas y contienen v´ıdeos que traten diabetes e hipertensi´on. Ejemplo de llamada this.mock.perform(post(“anotate”) .param(“query”, “I have diabetes and hypertension”)) .andExpect(status().isOk()) 132 CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON 7.3.3. Matrices de trazabilidad En la figura 7.1 se muestra la matriz de trazabilidad entre los casos de uso y las pruebas de validaci´on del software. As´ı, se puede comprobar que los requisitos del proyecto han sido todos validados correctamente. As´ı, se puede comprobar que los requisitos del proyecto han sido todos validados correctamente. 7.3. PRUEBAS DE VALIDACI ´ ON DE REQUISITOS 133 Cuadro 7.1: Matriz: casos de uso - pruebas de validaci´on. P. 001 P. 002 P. 003 P. 004 P. 005 P. 006 P. 007 P. 008 P. 009 P. 010 P. 011 P. 012 P. 013 P. 014 P. 015 P. 016 P. 017 P. 018 P. 019 CU. 01              CU. 02          CU. 03               CU. 04        CU. 05         CU. 06        CU. 07  CU. 08  CU. 09     CU. 10   CU. 11  CU. 12  CU. 13   CU. 14   CU. 15   134 CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON 7.4. Validaci´on de la interfaz de usuario. Tras la realizaci´on de cada incremento, se ha evaluado de forma progresiva la interfaz gr´afica de la aplicaci´on. La evaluaci´on se realiza mediante dos formas: mediante los heur´ısticos creados por Jacob Nielsen [23] y mediante pruebas del sistema con usuarios reales. 7.4.1. Heur´ısticos de Nielsen Los resultados de la evaluaci´on para cada heur´ıstico son los siguientes: Visibilidad del estado del sistema: se debe mantener a los usuarios informados del estado del sistema, dando una retroalimentaci´on adecuada en un tiempo razonable. •La interfaz muestra tanto el estado del sistema como las operaciones que se est´an realizando en el mismo en tiempo razonable. En concreto, se muestran los distintos estados de anotaci´on de un v´ıdeo sabiendo cuando comienza y cuando termina. Utilizar el lenguaje de los usuarios: el sistema debe utilizar el lenguaje natural de los usuarios, con palabras o frases que le sean conocidas, evitando vocabulario t´ecnico propio del sistema y desconocido por el usuario. •Los t´erminos que se utilizan en la aplicaci´on son adecuados para los usuarios que van a utilizar el sistema. Control y libertad para el usuario: los usuarios deben tener una forma f´acil de salir de funciones del sistema en las que han entrado por error. •Es posible salir de cualquier funci´on utilizando la barra de navegaci´on izquierda de la interfaz. Consistencia y est´andares: el lenguaje utilizado por el sistema debe ser el acorde al de la plataforma y ´ambito en que est´a implementado de modo que el usuario no tenga que preguntarse el significado de las palabras y acciones del sistema. 7.4. VALIDACI ´ ON DE LA INTERFAZ DE USUARIO. 135 •Se utiliza un lenguaje adecuado que permite al usuario reconocer los mensajes del sistema. Prevenci´on de errores: se deben eliminar acciones que puedan llevar al usuario a cometer errores, o advertir sobre el peligro de una acci´on y preguntar si desea ejecutarla. •La ´unica peligrosidad del sistema reside en las acciones de actualizaci´on y borrado, ambas remarcadas adecuadamente. Minimizar la carga de memoria del usuario: el sistema debe evitar que el usuario deba memorizar informaci´on, mostrando lo que necesite para realizar las acciones. •Toda la informaci´on se muestra en la interfaz mediante un lenguaje sencillo y permitiendo consultar toda la informaci´on necesaria a la vez. Flexibilidad y eficiencia de uso: el uso de atajos permiten mejorar la eficiencia de usuarios experimentados sin necesidad de dificultar el uso de usuarios inexpertos. •No existen atajos. Sin embargo, las funcionalidades exigen poco esfuerzo en ser ejecutadas, por lo que se realizan r´apidamente. Di´alogos est´eticos y dise˜no minimalista: la interfaz no debe contener informaci´on irrelevante, ya que cada unidad de informaci´on disminuye la visibilidad relativa de la informaci´on importante. •La interfaz es lo m´as minimalista posible, por lo que no hay informaci´on superflua. Ayudar a los usuarios a conocer, diagnosticar y recuperarse de los errores: los mensajes de error deben ser claros y sin c´odigos extra˜nos, permitiendo al usuario identificar perfectamente el error. •Siempre que se produce un error se notifica al usuario de forma clara y sencilla, sin utilizar c´odigos de error. 136 CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON Ayuda y documentaci´on: lo ideal es que un sistema sea usable sin documentaci´on, no obstante, es posible necesitarla. En ese caso, la documentaci´on debe ser f´acil de encontrar, clara y concreta. •Existen los manuales de usuarios anexos a este documento. Adem´as, las funcionalidades del sistema son autodescriptivas. 7.4.2. Pruebas de usabilidad Las pruebas de usabilidad tienen por objetivo comprobar que el software desarrollado resulta f´acil de utilizar para los tipos de usuarios objetivo, es decir, para aquellos usuarios para los cuales se ha desarrollado el software. En el caso de este proyecto, se ha realizado una evaluaci´on2con tres usuarios a los cuales se les ha pedido que cubran el cuestionario SUS [1]. El principal prop´osito de este cuestionario es proporcionar un “test f´acil de completar, f´acil de puntuar y que permitiera establecer comparaciones cruzadas entre productos”[24]. La plantilla de la tabla 7.2 indica las preguntas que conforman el cuestionario y el m´etodo de c´alculo del mismo. Sin embargo, la puntuaci´on obtenida se multiplica por 0.25 para obtener as´ı una puntuaci´on sobre 10 (m´as f´acil de ponderar). Por otra parte, se ha preguntado a los usuarios posibles mejoras de la interfaz gr´afica. Teniendo en cuenta dicha plantilla, las puntuaciones obtenidas por los usuarios para cada pregunta en orden de aparici´on, son las siguientes: Primer usuario: 4, 2, 5, 1, 3, 3, 4, 5, 1, 5. Puntuaci´on total: 8.25 Segundo usuario: 5, 1, 4, 1, 5, 1, 5, 1, 5, 1. Puntuaci´on total: 9.75 Tercer usuario: 4, 2, 5, 1, 4, 3, 3, 2, 5, 1. Puntuaci´on total: 8 Cuarto usuario: 5, 1, 5, 1, 5, 1, 5, 1, 4, 1. Puntuaci´on total: 9.75 Quinto usuario: 3, 1, 5, 1, 4, 2, 5, 1, 4, 1. Puntuaci´on total: 8.25 2Los cuestionarios se refieren ´unicamente a la interfaz del sistema anotador 7.4. VALIDACI ´ ON DE LA INTERFAZ DE USUARIO. 137 Escala de usabilidad (SUS) 12345 Creo que me gustar´a visitar con frecuencia este sitio web. Encontr´e el sitio innecesariamente complejo. Pienso que el sitio web es f´acil de usar. Creo que necesitar´ıa apoyo de un experto para utilizar el sitio web. Encontr´e las diversas posibilidades del sitio web bastante bien integradas. Pienso que hay demasiada inconsistencia en el sitio web. Creo que la mayor´ıa de la gente podr´ıa hacer uso del sitio web r´apidamente. He encontrado el sitio web bastante inc´omodo de utilizar. Me he sentido muy seguro haciendo uso del sitio web. Necesitar´ıa aprender muchas cosas antes de poder manejarme con el sitio web. Evaluaci´on 12345 678910TOTAL - 1 5 - - 1 5 - - 1 5 - - 1 5 - - 1 5 - Cuadro 7.2: Plantilla de evaluaci´on de usabilidad. As´ı, a partir de los cuestionarios de usabilidad, se mejora la interfaz gr´afica desde una interfaz como de la figura 7.1 a una interfaz como la mostrada en la figura 7.2 que es la interfaz que se utiliza actualmente. Los principales cambios residen, principalmente, en mejorar el men´u lateral permitiendo acceder a las funcionalidades principales directamente. Tambi´en se ha producido una mejora de la visualizaci´on, modificando los colores oscuros por unos m´as claros (dando un aspecto minimalista). Por ´ultimo, se mejora la nomenclatura de las funcionalidades, para que sean m´as claras. 138 CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON Figura 7.1: Interfaz antigua, antes de las pruebas de usabilidad. 7.4. VALIDACI ´ ON DE LA INTERFAZ DE USUARIO. 139 Figura 7.2: Interfaz nueva, despu´es de las pruebas de usabilidad. 140 CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON Cap´ıtulo 8 Conclusiones y trabajo futuro 8.1. Conclusiones En el presente proyecto se ha desarrollado un sistema pregunta-respuesta (Enterprise Search) que permite responder a preguntas del usuario relacionadas con tem´atica m´edica. Adem´as, se ha desarrollado una aplicaci´on que da soporte al sistema pregunta-respuesta permitiendo la anotaci´on de v´ıdeos y la administraci´on de los mismos (Adega Enterprise Manager). Ambos sistemas utilizan el anotador sem´antico ADEGA que, en su versi´on actual, utiliza ´unicamente la ontolog´ıa MeSH. Por un lado, se ha implementado un sistema anotador que permite descargar los subt´ıtulos de cualquier v´ıdeo de Youtube siempre que existan, pese a las restricciones impuestas por la propia API de Youtube. Adem´as, se ha implementado un sistema de almacenamiento eficiente y escalable que permite ampliar las capacidades de almacenamiento del sistema simplemente a˜nadiendo nuevos nodos. Por otra parte, se ha implementado un sistema pregunta-respuesta que, utilizando los grafos devueltos por el anotador sem´antico ADEGA, permite recomendar v´ıdeos a preguntas abiertas del paciente en cuesti´on. Para la recomendaci´on se ha utilizado un algoritmo compuesto de dos pasos: un primer filtrado mediante una b´usqueda de palabras clave y un refinamiento de los v´ıdeos a recomendar mediante una comparativa de grafos. 141