PROTOTIPO DE HERRAMIENTA QUE PERMITA IDENTIFICAR...
138
1 PROTOTIPO DE HERRAMIENTA QUE PERMITA IDENTIFICAR RELACIONES DE PERTENENCIA EN EL ENTORNO PÚBLICO UTILIZANDO UN MOTOR DE BASES DE DATOS NOSQL JUAN MANUEL PÉREZ TRUJILLO ROMARIO ALBEIRO SÁNCHEZ MONTERO UNIVERSIDAD DISTRITAL “FRANCISCO JOSÉ DE CALDAS” FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS BOGOTÁ D.C. 2018
Transcript of PROTOTIPO DE HERRAMIENTA QUE PERMITA IDENTIFICAR...
1
PROTOTIPO DE HERRAMIENTA QUE PERMITA IDENTIFICAR RELACIONES
DE PERTENENCIA EN EL ENTORNO PÚBLICO UTILIZANDO UN MOTOR DE
BASES DE DATOS NOSQL
JUAN MANUEL PÉREZ TRUJILLO
ROMARIO ALBEIRO SÁNCHEZ MONTERO
UNIVERSIDAD DISTRITAL “FRANCISCO JOSÉ DE CALDAS”
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
BOGOTÁ D.C.
2018
2
PROTOTIPO DE HERRAMIENTA QUE PERMITA IDENTIFICAR RELACIONES
DE PERTENENCIA EN EL ENTORNO PÚBLICO UTILIZANDO UN MOTOR DE
BASES DE DATOS NOSQL
JUAN MANUEL PÉREZ TRUJILLO
ROMARIO ALBEIRO SÁNCHEZ MONTERO
Trabajo de grado presentado como requisito para optar al título de
INGENIERO DE SISTEMAS
Directora:
SONIA ORDOÑEZ SALINAS, Ph.D.
UNIVERSIDAD DISTRITAL “FRANCISCO JOSÉ DE CALDAS”
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
BOGOTÁ D.C.
2018
3
AGRADECIMIENTOS
A nuestra directora de proyecto de grado la profesora Sonia Ordoñez Salinas por la
toda la dedicación, paciencia, enseñanzas y herramientas b rindadas durante todo
este proceso para completar este trabajo satisfactoriamente.
A nuestra familia y amigos por sus consejos, comprensión y estar con nosotros
cuando más lo necesitábamos b rindándonos todo su apoyo.
A la profesora Alba Consuelo Nieto Lemus, quien siempre estuvo dispuesta a
colaborarnos, orientarnos y compartir sus conocimientos.
A los compañeros del grupo de investigación GESDATOS por compartir sus
conocimientos con nosotros.
4
TABLA DE CONTENIDO
1 INTRODUCCIÓN ....................................................................................................... 10
2 PLANTEAMIENTO DEL PROBLEMA .................................................................... 11
3. ESTADO DEL ARTE................................................................................................. 12
4. MARCO TEÓRICO Y REFERENCIAL................................................................... 15
4.1. MARCO TEÓRICO ............................................................................................. 15
4.1.1. Bases de datos NoSQL .............................................................................. 15
4.1.2. Redes sociales............................................................................................. 17
4.1.3. Procesamiento de Lenguaje Natural (PLN) ............................................ 17
4.2. MARCO METODOLÓGICO .............................................................................. 18
4.2.1. Rational Unified Process (RUP) ................................................................ 18
4.2.2. Agile Unified Process (AUP) ...................................................................... 19
4.2.3. Scrum ............................................................................................................ 20
4.2.4. Metodología ágil XP (Extreme Programming) ........................................... 21
4.3. MARCO TECNOLÓGICO.................................................................................. 23
4.3.1. Herramientas De Bases De Datos NoSQL ............................................. 23
4.3.2. Herramientas para el análisis de redes sociales .................................... 24
4.3.3. Crawlers ........................................................................................................ 26
5. OBJETIVOS ............................................................................................................... 28
5.1. OBJETIVO GENERAL ....................................................................................... 28
5.2. OBJETIVOS ESPECÍFICOS............................................................................. 28
6. DESARROLLO DE LA METODOLOGÍA ............................................................... 29
6.1. ARTEFACTOS DEFINIDOS ............................................................................. 29
7. DESARROLLO DE LA PROPUESTA .................................................................... 31
7.1. ARQUITECTURA DEL SISTEMA .................................................................... 31
7.2. DESARROLLO METODOLÓGICO.................................................................. 32
7.2.1. Primera iteración.......................................................................................... 34
5
7.2.2. Segunda iteración........................................................................................ 42
7.2.3. Tercera iteración .......................................................................................... 53
7.2.4. Cuarta iteración............................................................................................ 58
7.2.5. Quinta iteración ............................................................................................ 67
7.2.6. Sexta iteración ............................................................................................. 77
8. EXPERIMENTACIÓN ............................................................................................... 90
8.2. COLECCIÓN DE PRUEBA ............................................................................... 90
8.3. PRUEBAS DE RENDIMIENTO ........................................................................ 91
8.4. PRUEBAS DE EXTRACCIÓN DE LA INFORMACIÓN................................ 91
8.5. PRUEBAS DE USUARIO FINAL...................................................................... 93
9. TRABAJO FUTURO.................................................................................................. 96
10. CONCLUSIONES .................................................................................................. 97
11. REFERENCIAS ..................................................................................................... 98
12. ANEXOS ............................................................................................................... 104
6
Tabla de ilustraciones
Ilustración 1 Arquitectura cliente-servidor de 3 capas (Ilustración tomada de [38])31
Ilustración 2 Arquitectura del aplicativo web (Diseño propio). ................................... 32
Ilustración 3 Fragmento de información extractada por el crawler (Diseño propio).
.............................................................................................................................................. 37
Ilustración 4 Modelo de datos colección de MongoDB (Diseño propio). .................. 38
Ilustración 5 Diagrama de componentes integración del crawler de Uru (Diseño
propio). ................................................................................................................................ 40
Ilustración 6 Estructura del servicio socket (Diseño propio)....................................... 41
Ilustración 7 Porción del grafo de categorías de Wikipedia (Diseño propio). .......... 44
Ilustración 8 Pseudocódigo de componente que extrae categorías (Diseño propio).
.............................................................................................................................................. 44
Ilustración 9 Proceso de generalización de términos a nodos (Diseño propio) ...... 45
Ilustración 10 Pseudocódigo de componente que extrae sinónimos (Diseño propio)
.............................................................................................................................................. 46
Ilustración 11 Categorías de Wikipedia (Diseño propio). ............................................ 47
Ilustración 12 Diagrama de actividades de la validación de categorías (Diseño
propio). ................................................................................................................................ 48
Ilustración 13 Ejemplo de segmento del archivo de sinónimos (Diseño propio). .... 49
Ilustración 14 Definición de la estructura de datos (Diseño propio) .......................... 49
Ilustración 15 Pseudocódigo Obtener sniónimo por nodo o relación (Diseño propio)
.............................................................................................................................................. 52
Ilustración 16 Archivo de configuración de directorios (Diseño propio).................... 55
Ilustración 17 Pseudocódigo métodos manejadores de archivos (Diseño propio) . 56
Ilustración 18 Componente para la carga de la ontología en la base de datos (Diseño
propio). ................................................................................................................................ 57
Ilustración 19 Página principal UMA UD (Diseño propio). .......................................... 57
Ilustración 20 Sugerencia de personajes en la barra de búsquedas (Diseño propio).
.............................................................................................................................................. 58
Ilustración 21 Estructura de datos de la ontología (Parte 1) (Diseño propio) .......... 60
Ilustración 22 Estructura de datos de la ontología (Parte 2) (Diseño propio). ......... 61
Ilustración 23 Pseudocódigo para la construcción de la estructura de información
del personaje (Diseño propio). ........................................................................................ 61
Ilustración 24 Información obtenida de la página procesada en la estructura (Diseño
propio) ................................................................................................................................. 62
Ilustración 25 Proceso de creación de nodos y relaciones (Diseño propio). ........... 63
7
Ilustración 26 Evento de envío y recepción de personajes sugeridos por Wikipedia
(Diseño propio). ................................................................................................................. 68
Ilustración 27 Servicio de consulta del grafo de los personajes (Diseño propio). .. 69
Ilustración 28 Servicio de sugerencia de personajes (Diseño propio). ..................... 71
Ilustración 29 pseudocódigo del servicio de consulta de configuraciones del grafo
.............................................................................................................................................. 71
Ilustración 30 Interfaz web lista de personajes (Diseño propio). ............................... 72
Ilustración 31 Lista de sugerencias (Diseño propio).................................................... 73
Ilustración 32 Componente buscador de personajes simplificado (Diseño propio) 73
Ilustración 33 Integración buscador de personajes simplificado (Diseño propio) ... 74
Ilustración 34 Visualización del grafo (Diseño propio). ............................................... 75
Ilustración 35 Estructura del grafo para D3 (Diseño propio) ...................................... 76
Ilustración 36 Interfaz web visualización del grafo (Diseño propio). ......................... 76
Ilustración 37 Página web de contacto (Diseño propio).............................................. 79
Ilustración 38 Reseña del grupo de investigación (Diseño propio) ........................... 80
Ilustración 39 Áreas de conocimiento del grupo de investigación (Diseño propio).80
Ilustración 40 Miembros participantes del proyecto (Diseño propio). ....................... 81
Ilustración 41 Pagina web de funcionamiento del aplicativo (Diseño propio). ........ 81
Ilustración 42 Panel de navegación del aplicativo (Diseño propio) ........................... 82
Ilustración 43 Filtros del grafo del personaje (Diseño propio). ................................... 83
Ilustración 44 Configuraciones de fi ltro por tipo de nodo (Diseño propio) ............... 84
Ilustración 45 Interfaz web visualización del grafo integrada con el filtro (Diseño
propio) ................................................................................................................................. 84
Ilustración 46 Nodos seleccionados por el usuario (Diseño propio). ........................ 85
Ilustración 47 Caminos encontrados con los nodos seleccionados en Ilustración 46
(Diseño propio). ................................................................................................................. 86
Ilustración 48 Información básica por nodo (Diseño propio). ..................................... 87
Ilustración 49 Información básica por relación (Diseño propio) ................................. 88
Ilustración 50 Cantidad de páginas con la información esperada (Diseño propio) 94
Ilustración 51 Utilidad de la herramienta (Diseño propio). .......................................... 95
8
Índice de tablas
Tabla 1 Plantilla historias de usuario (Diseño basado en [63]). ................................. 29
Tabla 2 Plantilla tareas de ingeniería (Diseño basado en [63]) ................................. 30
Tabla 3 Plantilla pruebas de aceptación ((Diseño basado en [63]) ........................... 30
Tabla 4 Participantes en la construcción de la aplicación web (Diseño Propio) ..... 33
Tabla 5 Historias de usuario (Diseño propio). .............................................................. 33
Tabla 6 Historias de usuario de la primera iteración. .................................................. 34
Tabla 7 Comparación de crawlers (Diseño propio). .................................................... 36
Tabla 8 Tareas de ingeniería de la primera iteración. ................................................. 39
Tabla 9 Pruebas de aceptación de la primera iteración .............................................. 42
Tabla 10 Historias de usuario de la segunda iteración. .............................................. 43
Tabla 11 Tareas de ingeniería de la segunda iteración. ............................................. 47
Tabla 12 Relación de cargos con entidades gubernamentales de Colombia (Diseño
propio). ................................................................................................................................ 52
Tabla 13 Pruebas de aceptación de la segunda iteración .......................................... 52
Tabla 14 Historias de usuario tercera iteración. .......................................................... 53
Tabla 15 Asignación tipos de datos en la ontología (Diseño propio). ....................... 54
Tabla 16 Tareas de ingeniería de la tercera iteración. ................................................ 55
Tabla 17 Pruebas de aceptación tercera iteración. ..................................................... 58
Tabla 18 Historias de usuario cuarta iteración. ............................................................ 59
Tabla 19 Tareas de ingeniería cuarta iteración. ........................................................... 64
Tabla 20 Relaciones en Neo4J (Diseño propio). ........................................................ 65
Tabla 21 Tipos de nodo (Diseño propio) ....................................................................... 65
Tabla 22 Registro de la información abstraída (Diseño propio) ................................ 66
Tabla 23 Pruebas de aceptación cuarta iteración........................................................ 67
Tabla 24 Historias de usuario de la quinta iteración .................................................... 67
Tabla 25 Tareas de ingeniería de la quinta iteración. ................................................. 70
Tabla 26 Esquema de la interfaz web lista de personajes (Diseño propio). ............ 72
Tabla 27 Esquema lista de sugerencias (Diseño propio) ........................................... 73
Tabla 28 Esquema buscador de personajes simplificado (Diseño propio) .............. 73
Tabla 29 Esquema de la integración del buscador de personajes simplificado
(Diseño propio)................................................................................................................... 74
Tabla 30 Esquema del grafo (Diseño propio) ............................................................... 75
Tabla 31 Esquema interfaz web visualización del grafo (Diseño propio) ................. 76
Tabla 32 Pruebas de aceptación de la quinta iteración .............................................. 77
Tabla 33 Historias de usuario de la sexta iteración. ................................................... 77
9
Tabla 34 Tareas de ingeniería de la sexta iteración .................................................... 79
Tabla 35 Esquema página web de contacto (Diseño propio) .................................... 79
Tabla 36 Esquema de página web de funcionamiento del aplicativo ....................... 82
Tabla 37 Esquema del panel de navegación del aplicativo (Diseño propio). ......... 82
Tabla 38 Esquema filtros del grafo del personaje (Diseño propio) ........................... 83
Tabla 39 Esquema de la integración de los filtros con interfaz web de visualización
del grafo (Diseño propio) .................................................................................................. 84
Tabla 40 Esquema para de selección de nodos (Diseño propio) .............................. 85
Tabla 41 Esquema visualización información básica por nodo (Diseño propio). .... 87
Tabla 42 Esquema visualización de información básica por relación (Diseño propio)
.............................................................................................................................................. 88
Tabla 43 Pruebas de aceptación de la sexta iteración................................................ 89
Tabla 44 Categorías con mayor número de páginas encontradas (Diseño propio).
.............................................................................................................................................. 90
Tabla 45 Cantidad de nodos obtenidos (Diseño propio)............................................. 91
Tabla 46 Cantidad de atributos por cada tipo de nodo (Diseño propio) ................... 92
Tabla 47 Cantidad de relaciones por cada tipo (Diseño propio). .............................. 93
Tabla 48 Cantidad de atributos por cada tipo de relación (Diseño propio).............. 93
Tabla 49 Personajes más buscados por los usuarios (Diseño propio). ................... 94
10
1 INTRODUCCIÓN
El análisis de redes sociales virtuales, es una tarea que ha permitido a la industria y a la academia determinar patrones de comportamiento no solo de las personas
sino del mercado y de áreas específicas como las pandemias y ayudas frente a catástrofes.
Si bien aparecen en la literatura una gran cantidad de investigaciones y herramientas relacionadas con el área, generalmente estas incluyen temáticas
comerciales, relacionan un solo personaje, el idioma de presentación es el inglés o requieren de sofisticados conocimientos para entenderlas.
Este proyecto trata del desarrollo de un prototipo de software que permite identificar
relaciones de pertenencia mediante el análisis de la información de Wikipedia, motores de base de datos NoSQL como neo4J, Redis y MongoDB, algoritmos que permitan identificar relaciones, así como el procesamiento del lenguaje natural.
Con respecto al desarrollo del aplicativo se utilizó la metodología ágil conocida como “XP” la cual tiene ventajas frente a otras metodologías por su dinamismo, facilidad de resolver problemas inesperados y gestionar el cambio durante todo el proceso
de desarrollo de la herramienta, además de brindar instrumentos que permiten la retroalimentación y el seguimiento de los progresos para cumplir los objetivos.
A continuación, se describen los diversos componentes que harán parte del
proyecto, así como los que justifican el mismo.
11
2 PLANTEAMIENTO DEL PROBLEMA
Las redes sociales se han caracterizado por permitir conocer el círculo social,
familiar y laboral de una persona, así como otras características y patrones de
comportamiento. Dicho conocimiento se logra a través de análisis especializados
que involucran conceptos avanzados de la estadística y de la inteligencia artificial,
limitando el análisis generalmente a empresas y quedándose cortas a la hora de
permitir de manera fácil y directa al usuario final mostrar las posibles interrelaciones.
Redes sociales como a)LinkedIn tienen como objeto almacenar información
relacionada con el perfil profesional y laboral, así como sugerir a los usuarios
posibles contactos u organizaciones desde el punto de vista profesional;
b) Facebook permite a los usuarios crear su círculo social, familiar y laboral;
c) Twitter tiene como objetivo que una persona pueda publicar mensajes con
multimedia de 140 caracteres donde el círculo social que sigue a dicho usuario los
puede visualizar y d) Instagram se encarga de que los usuarios puedan compartir
a sus seguidores videos e imágenes con efectos fotográficos, filtros, marcos, entre
otras. Sin embargo, ninguna de estas redes no permiten que un usuario cualquiera
pueda hacer análisis de sus propios patrones de comportamientos.
Si bien existen Apis y herramientas libres y licenciadas que permiten extractar
patrones de comportamiento a partir de redes sociales, alguna que permita
identificar patrones en personajes de la política, son escasos por no decir que nulos.
Por lo anterior en el presente proyecto se plantea la siguiente pregunta: ¿Es posible
a través de una herramienta libre presentar de forma clara patrones de
comportamiento de personajes de la política pública mediante el uso áreas tales
como la inteligencia artificial, el procesamiento de lenguaje natural y bases NoSQL?
12
3. ESTADO DEL ARTE
En el presente estado del arte se encuentran algunos ejemplos de trabajos
relacionados con el proyecto que sirven de guía para contextualizar la investigación
y desarrollo que se ha llevado a cabo con Wikipedia. En primera instancia se
encuentra a Lizorkin y Grineva [1] los cuales utilizan un algoritmo de detección de
comunidades con Wikipedia y la representan a través de un grafo con estructura
jerárquica. Por otro lado, hay trabajos donde se busca crear redes o grafos basados
en los artículos que referencia Wikipedia; algunos autores como Zhang y Asano [2]
crean métodos para realizar mediciones de las relaciones de los artículos en la red
y así mismo determinar la semántica de dichas relaciones, al igual que el trabajo
realizado por Hardik, Anirudh y Balaji [3]. Similarmente Nguyen [4] utiliza un
algoritmo denominado NER el cual clasifica y analiza la estructura sintáctica de las
relaciones entre los artículos de Wikipedia.
Algunos autores como Zhou, Luo y Xiong [5] buscan medir el rango de propagación
de los artículos de acuerdo con las temáticas que van relacionadas con las
empresas más importantes del mundo. En relación con los trabajos anteriores Biuk-
aghai y Ng [6] proponen un método para clasificar y analizar automáticamente
artículos utilizando la jerarquía de grupos de Wikipedia a la cual se hizo un pre-
procesamiento y simplificación, obteniendo un grafo dirigido. También Bloom,
Pagelink y Jong [7] realizan una red asociativa multilenguaje de artículos de
Wikipedia para analizar las ventajas de asociar las temáticas de los artículos en
varios idiomas.
Conforme a las investigaciones realizadas, otros autores hacen énfasis en las redes
sociales que se pueden construir con base a la enciclopedia de Wikipedia, tal como
lo exponen Wu, Harrigan y Cunningham [8] y que además tienen la capacidad de
predecir la calidad del contenido de los artículos, Geiß [9] crea un sistema con la
capacidad de relacionar personas con características similares que son
mencionadas en documentos de Wikipedia con el fin de desambiguar los nombres,
adicionalmente Geiß, Spitz y Gertz [10] crean una red social donde enlazan
categorías, artículos e información de las personas basado en una ponderación de
las relaciones donde se mide la distancia entre las menciones de un texto.
Similarmente sucede con un trabajo de Nazir y Takeda [11], sin embargo la red
social de este sistema está representada por grafos tripartitos.
13
Otros trabajos más globales como el de Sinclair, Lewis y Martínez [12] desarrollan
un sistema que extrae e identifica entidades, nombres, lugares, organizaciones,
etcétera, por medio del API de Yahoo REST, Wikipedia PHP y un algoritmo llamado
Gate. Por otra parte la investigación realizada por Pei [13] describe la construcción
de ontologías usando diccionarios de Wikipedia como intermediarios, donde se
propone un punto de vista de mapas conceptuales además Torres, Molli, Skaf-Molli
y Díaz [14] plantean cubrir las relaciones que se presentan en DBpedia pero no en
Wikipedia, que generan un vacío entre la web semántica y la red social. El trabajo
Nadamoto [15] propone un sistema que presente la esencia de un tema y su
información básica, con el fin de mantener una vista acerca de este y evitar que los
usuarios de redes sociales en el momento de entrar en alguna discusión se
dispersen del tema original.
Con respecto a trabajos realizados con ontologías encontramos a Yong-Jin, Se-
Young, Seong-Bae, Young-Hwa y Kwon-Yang [16] proponen un sistema que
recopila información variable de personas y la representan a través de una ontología
basada en eventos (Reconstruction of People Information based on an Event
Ontology). Ahmed, Tebourski y Abdessalem crean una red social científica definida
con una ontología en lenguaje OWL con el objetivo de identificar y compartir un
lenguaje común en los distintos campos académicos existentes (ONTOSSN:
Scientific Social Network ONTOlogy) [17].
La utilización de crawlers se encuentra presente en el trabajo de Surja Rajayuda y
Linda Santuari que investiga sobre el contenido web y contenido profundo,
buscando obtener diversos tipos de datos que son almacenados en una base de
datos y analizados mediante el método K-Nearest Neighbors (KNN) difuso [18].
Qiusheng Zhang, Jianping Jun, Mingyu Lin y Xingyung Zhang proponen un algoritmo
de minería de textos basado en un crawler que clasifica e integra páginas web
enteras por tema tanto como sea posible, buscando mejorar su capacidad de
recuperación [19]. Zhang Zheng y Du Qian proponen un método de rastreo
enfocado, generando una colección de palabras del texto a través del algoritmo TF-
IDF y una colección de frases por medio del análisis de dependencia sintáctica con
el fin de seleccionar el conjunto de palabras clave del texto que serán utilizadas en
el motor de búsqueda y de esta manera parte del resultado de la búsqueda se usará
como enlaces iniciales en el crawler enfocado [20]. Xiaotian Diao plantea un crawler
para recolectar páginas en redes sociales con temática financiera utilizando un
algoritmo para definir la relevancia de la página captada, de predicción de enlace y
una programación de enlace para mejorar la eficiencia del crawler [21]. Amalia
14
Amalia, Dani Gunawan y Atras Najwan implementan un crawler con programación
multiproceso con el objetivo de recopilar artículos relacionados con la salud usando
el algoritmo de sitios más grandes primero y clasificador Naïve Bayes [22].
15
4. MARCO TEÓRICO Y REFERENCIAL
El proyecto cuenta con elementos conceptuales del área de las bases de datos y la
inteligencia artificial, y aprovecha la gran cantidad de información que se almacena
a través de las redes sociales como Wikipedia.
4.1. MARCO TEÓRICO
En el marco teórico se encuentran conceptos, características y diferentes modelos
de las bases de datos NoSQL. Por otro lado, se encuentra tópicos como el
procesamiento del lenguaje natural, redes sociales y algunas de metodologías de
desarrollo de software que tiene mayor relevancia en la actualidad.
4.1.1. Bases de datos NoSQL
El procesamiento de datos heterogéneos se debe realizar de una manera flexible
que permita almacenarlos de una manera natural y que sea flexible al cambio. Las
bases de datos NoSQL (Not Only SQL) permiten el uso tanto de lenguajes de
consulta estándar como lenguajes de consulta no estándar llamados NoSQL, donde
solucionan problemas para almacenar datos no estructurados, semiestructurados y
estructurados, escalar horizontalmente añadiendo más equipos y aumentando la
memoria RAM, CPU, entre otros recursos; a diferencia de los sistemas gestores de
bases de datos relacionales que solo permiten hacerlo verticalmente [23].
Las RDBMS aseguran una alta confiabilidad, debido a que las transacciones
cumplen con los principios ACID (Atomicidad (Atomicity), Consistencia
(Consistency), Aislamiento (Insolation) y Durabilidad (Durability)) a diferencia de las
bases de datos NoSQL que están entre el espectro de las ACID y las BASE
(Disponibilidad como prioridad (Basic Availability), priorizan la propagación de datos
(Soft state) y eventual consistencia (Eventually consistency)). Pero la principal
diferencia se encuentra en la manera en que se modelan los datos y la posibilidad
de gestionar información no estructurada, las bases datos NoSQL utilizan
estructuras de almacenamiento diferentes a las tablas como tablas hash, grafos,
columnas, entre otros [24] [25].
4.1.1.1. Bases de datos orientadas a grafos
Las bases de datos orientadas a grafos fueron muy famosas en 1990 pero luego de
la llegada de modelos semiestructurados como XML y modelos de bases de datos
16
geográficas su uso no tuvo mayor auge. Sin embargo, en la actualidad con el
aumento de recursos computacionales y la aparición de las redes sociales han
tomado importancia y aparecen en áreas como las comunicaciones, salud,
comercio, soluciones de negocio en línea y medios de comunicación en línea [26].
Las bases de datos NoSQL orientadas a grafos utilizan la teoría matemática de
grafos, abstrayendo los datos en nodos, aristas y propiedades [27]. Guardan
información en tuplas (nodos) de multiatributos que reflejan las relaciones de
manera diferente. Las bases de datos orientadas a objetos son útiles para el manejo
de datos altamente interconectados y por lo tanto son eficientes al atravesar las
relaciones entre diferentes entidades [23]. Es decir, proporcionan un mecanismo
efectivo y flexible de administración de información interconectada, debido a que la
relación entre los datos es explícitamente representada, donde las consultas se
basan en las relaciones existentes en los nodos [28].
4.1.1.2. Bases de datos clave valor
Las bases de datos Clave-Valor usan tablas hash y un apuntador el cual dirige a un
conjunto de datos, sus registros sólo pueden ser accedidos por medio de la clave
que lo identifica. Su escalabilidad para la recuperación de información hace que sea
usada por redes sociales como Facebook y el “El carrito de compras” de Amazon,
estas bases de datos no estructuradas tienen conjuntos de datos no relacionados
[25]. Dentro de las grandes ventajas que ofrece este tipo de bases de datos es su
capacidad de gestionar datos a grandes escalas, otra ventaja es el escalamiento
dinámico, el cual permite ajustar el tamaño del sistema de acuerdo con la carga de
datos a partir de la cantidad de accesos que se tengan tanto en el día como en la
noche dentro de la base de datos [29].
4.1.1.3. Bases de datos orientadas a documentos
Las bases de datos orientadas a documentos gestionan datos de archivos con datos
estructurados y semiestructurados como XML o JSON a modo de conjuntos de
datos. Por lo general cada registro es almacenado en un solo documento basándose
en que este encapsula y codifica la información de una manera estándar, lo que
hace que se simplifiquen el acceso a los datos y reduce la complejidad de las
transacciones [25]. De esta forma un documento tiene información estructurada que
representa las propiedades del documento que pueden ser utilizadas para las
búsquedas, algunos ejemplos son: las palabras claves, nombres, títulos,
17
referencias, direcciones URL, entre otros. Aun así, cuando se utilizan bases de
datos orientadas a documentos no es simplemente un repositorio de documentos
estructurados o semiestructurados, la gestión de este tipo de almacenamiento de
datos requiere la capacidad de enfrentarse con la independencia de datos, la
integración, el acceso a dichos datos, las versiones, la redundancia, la coherencia
y la recuperación de la información [30].
4.1.2. Redes sociales
Una red social es un sistema complejo e interdisciplinar, visto de una manera
general como una estructura de nodos (individuos u organizaciones) vinculados por
diversas relaciones de amistad, parentesco, intercambio financiero, entre otras [31].
El análisis de las redes sociales se centra en los diversos tipos de relaciones que
se pueden dar igual que su asociación y medida, su estudio es aplicable a múltiples
campos obteniendo herramientas visuales como modelos matemáticos que en su
mayoría se fundamentan en las medidas de centralidad de las estructuras de los
agentes a estudiar con lo que se pueden detectar comunidades así como relaciones
de poder, confianza, coautoría, etcétera [32] [33] Este análisis abarca modelos de
redes sociales, topología, teoría y software analítico de redes, small world y demás
temas que involucran interacción social [31].
4.1.3. Procesamiento de Lenguaje Natural (PLN)
El análisis de lenguaje natural de manera automática se ha logrado a través de
técnicas de lo que hoy se conoce como PLN; dichas técnicas aparecerán
inicialmente en trabajos de recuperación de información de Salton y Buckley [34].
Entre sus principales objetivos se encuentran la implementación de interfaces de
lenguaje natural que permitan que el usuario interactúe con las aplicaciones usando
su propio lenguaje, el procesamiento de textos con el fin de recuperar información,
extraer datos significativos e incluso elaborar resúmenes y la traducción automática
[35].
Dado que el PLN se basa generalmente en el análisis de las palabras que hacen
parte de un texto, es necesario en primera instancia realizar un pre-procesamiento
que permitan reducir la cantidad de variables que se tienen en cuenta “reducción de
la dimensionalidad”. Entre las actividades más comunes están la eliminación de
palabras irrelevantes, la lematización o stemming (identificación de la raíz de cada
18
palabra) y la tokenización (segmentación del texto en párrafos, frases o palabras)
[36].
Los sistemas de procesamiento de lenguaje natural requieren de componentes tales
como el análisis gramatical, morfológico, sintáctico, semántico y pragmático, la
planificación de frases (decisión acerca de la estructura de la frase) [36] [37].
Para el PLN se presentan formalismos que permiten representar el comportamiento
de las palabras en un documento, cuya complejidad depende de la cantidad de
elementos capturados que llevan a la interpretación y su procesamiento. Entre los
formalismos más simples se encuentran el modelo de espacio vectorial que
representa al documento como un vector de frecuencia, donde las entradas del
vector son la frecuencia de cada palabra, las listas dentro de las cuales se pueden
usar índices invertidos (lista de términos junto con el índice de los documentos en
los cuales aparece dicho término), grafos en los cuales se representan los términos
y la adyacencia entre estos, estructuras estadísticas basadas en la teoría de la
información que analizan el comportamiento de las palabras y la información que
estas aportan usando funciones probabilísticas y estructuras más avanzadas que
permiten incluir términos de la lingüística o métodos heurísticos como el aprendizaje
estadístico, la inteligencia artificial, entre otros que permiten encontrar relaciones y
patrones de comportamiento [34].
4.2. MARCO METODOLÓGICO
Las metodologías de desarrollo de software como su nombre lo indica son una guía
para documentar, diseñar, implementar, probar y desplegar un proyecto de
software. Por lo tanto, su uso facilita y evita caer en errores comunes que pueden
llevar al fracaso cuando se está desarrollando un proyecto. A continuación, se
describirán tres metodologías de las cuales dos son ágiles (AUP, SCRUM) y la otra
es mucho más robusta (RUP).
4.2.1. Rational Unified Process (RUP)
RUP es un modelo en fases que tiene cuatro fases dentro de su metodología: inicio,
elaboración, construcción y transición. Proporciona la asignación de tareas y
responsabilidades dentro de una organización para la producción de software de
calidad cumpliendo todos los requerimientos de los usuarios. A diferencia de otros
modelos este se encuentra enfocado en los asuntos de negocio en lugar de
cuestiones técnicas [38] [39].
19
En general cada una de las fases se resume de Pressman [40] de la siguiente forma:
● Fase de inicio: En esta fase agrupa actividades tanto de comunicación con el
cliente como de planeación. Principalmente se identifican los requerimientos del
negocio a través de un conjunto de casos de uso. Finalmente se crea un plan
donde identifica los recursos, evalúa los riesgos principales, define un programa
de actividades para las fases que se van a aplicar a medida que avanza el
incremento del software.
● Fase de elaboración: En esta etapa se añaden las actividades de
comunicación y aproximación del modelo general. La fase de elaboración
mejora y amplía los casos de uso que fueron documentados como parte de la
fase de inicio. Sin embargo, es importante tener en cuenta que al terminar la
fase de elaboración se debe revisar el alcance, riesgos y fechas de entrega
siguen coherentes. Algunas veces es necesario en esta etapa modificar el plan.
● Fase de Construcción: Para esta fase se completan los modelos de
requerimientos y diseño que se comenzaron durante la fase de elaboración, con
el fin de que se reflejen las iteraciones realizadas en las etapas anteriores.
Después se implementan en código fuente todas las características y funciones
necesarias que se estipulan en los requerimientos. Es importante tener en
cuenta que medida de que se implementan los componentes, se diseñan y
efectúan pruebas unitarias para cada uno (Es una forma de asegurar calidad
del producto). Finalmente, el ensamble de los componentes y las pruebas
conjuntas son necesarias para seguir con la siguiente fase.
● Fase de Transición: En general se da el software a los usuarios finales para
las pruebas beta, quienes reportan tanto los errores como los cambios de
componentes que no cumplen la función correctamente. Además, el equipo de
desarrollo genera los manuales de usuario, guías de solución de problemas,
procedimientos de instalación que se necesitan para el despliegue.
4.2.2. Agile Unified Process (AUP)
Es una metodología ágil que busca aligerar la documentación excesiva que se
puede generar usando RUP sin perder las características de este. Aplica técnicas
como modelamiento ágil (AM, concepto clave de AUP que permite realizar varios
modelos en paralelo e incluye principios tales como la rápida retroalimentación,
cambio incremental, aceptación al cambio y la suposición de simplicidad), diseño
basado en pruebas (TDD), gestión ágil al cambio y refactorización de bases de
datos [41].
20
AUP se basa en las mismas 4 fases de RUP (inicio, elaboración, construcción y
transición), aunque es guiado por siete principios, resumidos a continuación de [41]:
● Comprensión: Entender el negocio y dominio del problema relacionado con el
proyecto e identificar una solución viable.
● Implementación: Transformar los modelos en código ejecutable, y llevar a cabo
un nivel básico de pruebas (en su mayoría unitarias).
● Pruebas: Comprobar que se cumplan los requerimientos tal como se habían
diseñado.
● Despliegue: Planificar y ejecutar la entrega del sistema a los usuarios finales.
● Gestión de la configuración: Administrar el acceso a los componentes del
sistema, además de la gestión, control y mantenimiento de sus versiones.
● Gestión de proyectos: Coordinar las actividades relacionadas el proyecto como
la gestión de los riesgos, personas y sistemas fuera del alcance del proyecto,
para asegurar que es entregado a tiempo y dentro del presupuesto.
● Ambiente: Asegurarse que el equipo de trabajo cuenta con orientación (normas
y directrices) y herramientas (hardware, software, etc.).
4.2.3. Scrum
Scrum es una metodología ágil que se basa en la experiencia o el conocimiento
empírico de las actividades que acometen el desarrollo de software, a través de un
método iterativo para organizar un proceso en estado exploratorio. Es decir, mejora
iteración por iteración para encontrar la mejor forma de resolver un problema [42].
4.2.3.1. Pilares fundamentales de la metodología SCRUM
Scrum al aplicar un modelo incremental e iterativo para mejorar la predictibilidad y
el riesgo expones 3 pilares fundamentales [43]:
● Transparencia: Cada aspecto que se desarrolla en el proyecto de software debe
ser visible y estandarizado para que los involucrados tengan la capacidad de
comprender el trabajo que se está realizando.
● Inspección: Los involucrados deben realizar revisiones de los módulos,
componentes y artefactos que se han realizado a lo largo del proyecto para
detectar posibles variaciones que no van de acuerdo con los objetivos o
requerimientos del desarrollo.
● Adaptación: Cuando el proceso se ha desviado de los objetivos que se
estipulan antes de empezar un proyecto, cada uno de los aspectos deben ser
21
ajustados o corregidos de acuerdo con los requerimientos por medio de 4
eventos formales que se encuentran dentro del sprint:
o Reunión de planificación del sprint.
o Scrum diario.
o Revisión del sprint.
o Retrospectiva del sprint.
4.2.4. Metodología ágil XP (Extreme Programming)
Extreme programming (XP) es una metodología de desarrollo ágil inspirada por Kent
Beck en 1996 cuando trabajaba para Chrysler Corporation [44]. XP se enfoca en el
uso de buenas técnicas de programación, comunicación y trabajo en equipo [45].
Asimismo, se distingue de otras metodologías por:
● Ciclos de desarrollo cortos, resultados rápidos, concretos y retroalimentación
constante.
● Tiene un enfoque de planificación incremental, donde se espera un plan de
trabajo general que evoluciona y crece a medida que se desarrolla el proyecto.
● Tiene una alta flexibilidad en la planeación y responde a los cambios según las
necesidades del negocio.
● Se basa en pruebas automatizadas escritas por programadores. Los clientes y
analistas de calidad supervisan el progreso del desarrollo, el cual permite que
el sistema evolucione para detectar los defectos de forma temprana.
● Depende de la comunicación, las pruebas y código fuente para comunicar la
estructura e intención del sistema.
4.2.4.1. Prácticas de la programación extrema
XP es una metodología ágil que abarca una gran cantidad de prácticas que a
continuación serán descritas rápidamente:
● Planeación: Los clientes deciden las historias de usuario a desarrollar, de
acuerdo con las estimaciones realizadas por los programadores.
● Despliegues pequeños: Los despliegues se realizan en periodos de tiempo
relativamente cortos. Con el paso tiempo se van creando e incluyendo nuevas
funcionalidades al software.
● Metáforas: Básicamente define la forma y estructura del software que será
discutida con los programadores y clientes.
22
● Diseño simple: Consiste en crear un diseño del software sencillo aplicando
prácticas de programación como la reutilización del código y la simplificación de
clases, componentes, métodos, entre otros.
● Pruebas: Los programadores deben crear pruebas unitarias para cada
funcionalidad de software y los clientes escriben pruebas funcionales por cada
iteración.
● Mejora continua: Los componentes pueden ser mejorados a medida que van
transcurriendo las iteraciones del proyecto.
● Integración continua: Cada funcionalidad o cambio nuevo en el software debe
ser integrado en la menor cantidad de tiempo posible.
● Propiedad colectiva: Los programadores deben mejorar los componentes de
software cada vez que tenga la oportunidad de realizar dichos cambios.
4.2.4.2. Herramientas de XP
La programación extrema utiliza varias herramientas que convierte el desarrollo de
la metodología más simple y flexible. Algunas de las herramientas que se pueden
encontrar son:
● Historias de Usuarios: Representan una descripción simple y concreta del
comportamiento de sistema. Esta descripción debe ser lo más corta posible con
el fin de que los programadores puedan desarrollar la funcionalidad en poco
tiempo y sea sencilla la fase de pruebas
● Despliegue: XP busca es implementar un conjunto de historias relevantes para
el proyecto y de forma gradual ir desarrollando e implementando nuevas
historias de usuario.
● Iteración: La meta de cada iteración es desplegar un conjunto de historias de
usuario previamente desarrolladas y probadas por los desarrolladores con
pruebas unitarias.
● Tarea de Ingeniería: Una tarea es una actividad de duración muy corta que
hace parte de una historia de usuario. Un conjunto de tareas de ingeniería
constituye una historia de usuario. En cada tarea pueden participar uno o varios
programadores.
● Pruebas: Una de las características principales de XP son las pruebas unitarias
hechas por los programadores. Dichas pruebas permiten comprobar de forma
efectiva si se están cumpliendo las funcionalidades especificadas en las
historias de usuario y permite probar el software de forma continua.
23
4.3. MARCO TECNOLÓGICO
En el marco referencia se encuentran algunas herramientas respecto a las bases
de datos NoSQL, análisis y visualización de redes sociales online.
4.3.1. Herramientas De Bases De Datos NoSQL
Es necesaria una revisión de herramientas o gestores de bases de datos NoSQL
con el fin de seleccionar aquella que cumplan los requerimientos que dan
persistencia a la información del proyecto planteado.
4.3.1.1. NEO4J
Desarrollado por Neo Technology, publicada su primera versión en febrero de 2010,
su segunda y más reciente versión en diciembre del 2013 [46], es un sistema
manejador de bases de datos orientado a grafos que cuenta con licencia dual (Affero
General Public License (AGPL) v3 y licencia comercial) [47].
Entre sus principales características se encuentran [47] [48]:
● Presenta casos de uso web tales como etiquetado de metadatos, anotaciones,
redes sociales, wikis, entre otros.
● Usa un intuitivo modelo de representación de datos orientado a grafos.
● Tiene enlaces para diferentes lenguajes (Python, Jython, Ruby y Clojure)
● La gestión de almacenamiento busca la eficiencia respecto a rendimiento y
escalabilidad.
● Puede manejar millones de nodos, relaciones y propiedades en un solo equipo.
● Maneja una API orientada a objetos.
● El almacenamiento es totalmente persistente.
● No usa disparadores o Triggers.
● Usa una representación más “natural” con el fin de separar los datos y la lógica
Como lenguaje de consulta utiliza Cypher Query Language un lenguaje declarativo,
inspirado en SQL que permite manipular las estructuras de los grafos (seleccionar,
insertar, actualizar o eliminar) y utiliza ASCII-Art para representar los patrones [49].
4.3.1.2. Redis
Es un motor de bases de datos de código abierto desarrollado ANSI C en el 2009
por Salvatore Sanfilippo basado en el uso de tablas tipo clave-valor o tablas hashes.
24
Soporta estructuras de datos como string, hashes (clave y valor son string), lists,
sets (colección de datos), mapas de bits, hyperlogs e índices geoespaciales
además soporta operaciones atómicas como inserciones, unions y ejecución de
scripts desarrollados en lenguaje Lua [50].
Alguna de las características más comunes de Redis son [50]:
● Soporte a la mayoría de los lenguajes de programación que se utilizan en la
actualidad.
● Transacciones.
● Scripts en LUA
● Llaves con un tiempo de vida.
● Tiene soporte para la mayoría de las versiones del sistema operativo de Linux.
4.3.1.3. MongoDB
Es un motor de bases de datos de código abierto orientado a documentos lanzado
en el 2009 por la compañía MongoDB Inc [51], guarda sus registros en unas
estructuras de datos basadas en archivos Json llamadas Bson (Json Binario).
MongoDB proporciona un alto rendimiento, alta disponibilidad y la escala
automática. Un registro es un documento, su estructura de datos está compuesta
por pares de campos y de valor. Los documentos de MongoDB son similares a las
estructuras de JSON donde los valores de los campos pueden incluir otros
documentos, matrices y conjuntos de documentos [52].
Sus características principales son [52]:
● Admite índices para consultas más rápidas que pueden incluir documentos y
matrices embebidas.
● Tiene un lenguaje de consulta de lectura y escritura de los datos que se
encuentran almacenados, además de consultas de datos geoespaciales.
● Soporte para la redundancia de datos.
● Escalabilidad horizontal a través de la distribución de información en varias
máquinas.
● Soporta múltiples motores de almacenamiento como: WiredTiger y MMAPv1.
4.3.2. Herramientas para el análisis de redes sociales
Se presenta un pequeño listado de herramientas para el análisis de redes sociales
más conocidas:
25
4.3.2.1. Social Mention
Es un motor de búsqueda y análisis de contenido gratuito generado por los usuarios
en blogs, foros, noticias, comentarios, eventos y diversas publicaciones en un solo
flujo de información en tiempo real trabajando directamente con más de 100 medios
sociales como Twitter, Facebook, FriendFeed, YouTube, Digg, Google, etcétera.
Además de ofrecer alertas diarias de actividad y APIs [53].
4.3.2.2. Automap
Elaborada por CASOS, es una herramienta de minería de texto para conseguir
información a partir de textos no estructurados utilizando métodos análisis de texto
en red. La información obtenida puede ser datos de contenido analítico (palabras y
frecuencias), datos de meta-red (la clasificación cruzada de los conceptos en su
categoría ontológica como personas, lugares, cosas y las conexiones entre estos
conceptos) datos de red semántica, y datos de confianza (actitudes, creencias) [54].
4.3.2.3. Google Trends
Brindada por Google es una herramienta de acceso que permite hacer una
comparación de la popularidad de búsqueda de varias palabras o frases durante
cierto tiempo mostrando la variación en una escala de 0 a 100 (entre más próximo
a 100 más alta son los niveles de búsqueda de dicho término) además permite ver
patrones, cambios en el tiempo o variación por zona geográfica (mediante un mapa
de calor global) y la posibilidad de comparar hasta 5 términos a la misma vez [55].
4.3.2.4. Tableau
Creado por una compañía con el mismo nombre es una herramienta paga para la
visualización de datos e información, permitiendo la creación de visualizaciones de
alto nivel, tableros de control, informes, y ver cambios en tiempo real. Da la
posibilidad de diferentes representaciones de datos en un mismo dashboard y
añadir información extra como documentos o páginas web [56].
4.3.2.5. CitNetExplorer
Es una herramienta para la visualización y análisis de redes de referencias de
publicaciones científicas, permite a las redes de citación ser importadas
directamente desde la base de datos Science y ser exploradas de forma interactiva,
26
entre sus aplicaciones se incluyen el análisis del desarrollo de un campo de
investigación en el tiempo, identificación de la literatura sobre un tema de
investigación, trabajo de cierto investigador y revisión de literatura [57].
Para desarrollo del aplicativo se decidió manejar Neo4J debido a su uso intuitivo
para el manejo de base de datos orientadas a grafos, posibilidad de enlazar con
lenguajes ya conocidos por nosotros como Python, la separación entre los datos y
la lógica que permite una mayor visualización de la arquitectura, además de que
presenta soporte de aplicaciones en entorno web tales como etiquetado de
metadatos y redes sociales.
4.3.3. Crawlers
Se presenta un pequeño listado de los crawlers más conocidos:
4.3.3.1. Website Crawler and Xml Sitemap Generator
Find b roken Links, Redirects & Site Crawl Tool permiten revisar el estado de enlaces
externos e internos en un sitio web, presentando un informe que proporciona
información sobre cada enlace recorrido, identificando re direccionamientos y
errores de enlace. La herramienta es totalmente gratuita y cuenta con resultados
descargables y una función de mapa del sitio [58].
4.3.3.2. Web fountain
Rastrea una serie de páginas web repetidamente, manteniendo una copia local de
hasta 1 MB del texto de cada página con sus respectivos metadatos en un
repositorio. Este rastreador es incremental dado que la copia del repositorio de cada
página se actualiza tan pronto como se rastrea la página web actual mediante una
colección de colas de direcciones web, junto a parámetros que determinan cómo se
deben seleccionar las URL a actualizar mediante un algoritmo de optimización [59].
4.3.3.3. Sphider
Es un crawler y buscador web implementado en PHP que emplea el sistema
manejador de base de datos MySql e incluye funcionalidades como autocompletado
de palabras, sugerencias de ortografía, indexación de texto completo, páginas
estáticas y dinámicas, utiliza el protocolo robots.txt el cual evita que ciertos bots
27
analicen todo o una parte privada del sitio web. Finalmente, sigue las redirecciones
del lado del servidor y permite reanudar procesos de búsqueda en pausa [60].
4.3.3.4. HTTrack
Permite descargar recursivamente archivos HTML incluyendo imágenes a un
directorio local permitiendo actualizar sitios duplicados y reanudar las descargas
interrumpidas, es completamente configurable y tiene un sistema de ayuda
integrado [61].
4.3.3.5. Uru
El aplicativo web Uru es un Crawler que se encarga de recolectar información
personal, y contenido en general a partir de páginas en español de Wikipedia
relacionadas con personajes [62].
Dentro de la información general que extrae el crawler está: nombres, fecha de
nacimiento, religión, residencia, ocupación, partido político, entre otros. Uru extrae
todo el contenido de la página de Wikipedia que generalmente contiene información
más detallada de la persona como su biografía, familia, logros alcanzados en su
ocupación, obras, entre otros [62].
Asimismo, Uru obtiene las “URL” o localizador uniforme de recursos (URL por la
sigla inglés Uniform Resource Locator), de personas e instituciones de Wikipedia
relacionadas [62].
El aplicativo funciona de manera recursiva e incremental ya que a partir de la URL
definida por el usuario, explora no solo la información sino las URL´s encontradas.
Las nuevas URL ´s son procesadas por el Crawler para obtener información y del
mismo modo obtener nuevas URL´s. Pese a que durante el recorrido puede
encontrar URL´s ya procesadas el aplicativo asegura, que las páginas web no se
repitan ni sean exploradas nuevamente. Cuando Uru no encuentra nuevas URL´s y
ha terminado de procesar todas las páginas web, se da por finalizado el flujo de
datos donde retorna un archivo extensión JSON con la información extractada en
Wikipedia [62].
28
5. OBJETIVOS
5.1. OBJETIVO GENERAL
Desarrollar un prototipo de software que permita identificar relaciones de
pertenencia de personajes vinculados con la política colombiana utilizando un
motor de bases de datos NoSQL, información pública en enciclopedias libres en
el idioma español y procesamiento de lenguaje natural.
5.2. OBJETIVOS ESPECÍFICOS
● Definir los requerimientos funcionales y no funcionales para el desarrollo del
prototipo que permita el desarrollo de la herramienta para analizar y verificar
las necesidades del prototipo.
● Definir y desarrollar el algoritmo de procesamiento de lenguaje natural que
permita identificar las relaciones familiares, laborales y profesionales de
personajes de la política pública para el almacenamiento de dichas
relaciones en una base de datos NoSQL.
● Definir, diseñar e implementar todos los componentes que hacen parte de la
arquitectura, modelos de datos y en general los artefactos para el desarrollo
de la herramienta.
● Desarrollar y probar el código necesario para la implementación de la
herramienta a través lenguajes de programación o validar componentes de
software.
29
6. DESARROLLO DE LA METODOLOGÍA
Dentro del desarrollo del aplicativo se utilizó la metodología ágil XP (Extreme
Programming) que se diferencia de las metodologías tradicionales por su
practicidad y énfasis a la adaptabilidad en los desarrollos de software de tipo
investigativo y experimental en donde los requerimientos no se encuentran definidos
en su totalidad desde el inicio; algunos pueden cambiar o ampliarse con el tiempo
u otros pueden rechazarse. XP nos brinda herramientas y prácticas que se adaptan
al proyecto.
6.1. ARTEFACTOS DEFINIDOS
El proyecto de investigación se estructuró de acuerdo con un conjunto de artefactos
y entregables relacionados con la metodología de desarrollo XP. A continuación, se
menciona de manera breve los distintos entregables que se utilizaron en el proyecto.
● Historias de usuario: Representan una descripción simple y concreta del
comportamiento de sistema. En la tabla 1 encuentra una plantilla de una historia
de usuario.
Historia de Usuario
Número
Identif icador único Usuario
Individuo que va interactuar con la f uncionalidad
Nombre de Historia Nombre de la historia de usuario
Prioridad en Negocio Grado de importancia de la historia
Puntos estimados
Número de días estimados
Iteración asignada
Número de iteración a la que pertenece la historia
Responsables Persona encargada de desarrollar la historia
Descripción Descripción corta y detallada de la f uncionalidad
Observaciones Notas o recomendaciones para la persona responsable
Tab la 1 Plantilla historias de usuario (Diseño basado en [63]).
● Tareas de ingeniería: Una tarea de ingeniería es una actividad de duración muy
corta que hace parte de una historia de usuario. En la Tabla 2 se encuentra una
plantilla de una tarea de ingeniería.
30
Tarea de Ingeniería
Número de Tarea identificador único
Número de historia
Número de historia a la que pertenece la tarea
Nombre de Tarea Nombre de la tarea o activ idad
Tipo de Tarea
clasificación para la tarea Puntos Estimados
número de días estimados
Responsable Persona encargada de desarrollar la actividad
Descripción Descripción detallada de la actividad que va ser desarrollada por la persona.
Tab la 2 Plantilla tareas de ingeniería (Diseño basado en [63])
● Pruebas de aceptación: Las pruebas de aceptación permiten comprobar de
forma efectiva si se están cumpliendo las funcionalidades especificadas en las
historias de usuario. En la Tabla 3 se encuentra la plantilla de una prueba de
aceptación utilizada en la metodología de desarrollo.
Prueba de Aceptación
Número de prueba
Identif icador único Número de historia
Número de historia a la que pertenece la prueba
Nombre de la prueba Nombre de la tarea o activ idad
Condiciones de ejecución Condiciones antes de ejecutarse la prueba
Entradas
Condiciones de entrada y pasos a seguir para ejecutar la prueba
Resultado Esperado Resultado esperado de la prueba
Evaluación Análisis de aceptación o rechazo de la prueba.
Tab la 3 Plantilla pruebas de aceptación ((Diseño basado en [63])
● Diagramas de actividades: Los diagramas de actividades describen el flujo que
trabajo de una funcionalidad del sistema.
● Diagrama de componentes: Los diagramas de componentes muestran las
dependencias entre todos los componentes desarrollados o utilizados en un
sistema.
● Manual de usuario: Es un instructivo que describe y explica las funcionalidades
de un sistema de forma clara y concreta.
● Producto: Es resultado de toda la especificación, desarrollo, análisis y pruebas
del sistema de software.
31
7. DESARROLLO DE LA PROPUESTA
En esta sección se describen aspectos relacionados con la arquitectura diseñada
para el sistema, así como el desarrollo metodológico que se llevó a cabo para la
implementación del prototipo.
7.1. ARQUITECTURA DEL SISTEMA
La arquitectura definida corresponde a cliente-servidor en 3 capas, dado que trata
de un sistema con un conjunto de servicios accedidos mediante el protocolo HTTP
a los servidores, donde los procesos lógicos están separados y por tanto se ejecuta n
sobre procesadores diferentes. Dichas capas son conocidas como: presentación,
procesamiento de la aplicación y gestión de datos. Una de las grandes ventajas
que ofrece esta arquitectura es la optimización en la transferencia de información
entre servidores web y la base de datos. La ilustración 1 presenta una gráfica
general de la arquitectura cliente servidor en 3 capas [38].
Ilustración 1 Arquitectura cliente-servidor de 3 capas (Ilustración tomada de [38])
La ilustración 2 incluye la arquitectura de la aplicación Uma (Dirigente en Quechua)
como resultado del desarrollo del proyecto. La arquitectura consta de:
● La capa de datos donde se encuentran implementadas las bases de datos: a)
MongoDB la cual se encarga de almacenar toda la información que extrae el
aplicativo web de Wikipedia y b) la base de datos Neo4j donde se guardadas
todas las entidades y relaciones que fueron extraídas, luego de haber pasado
por fases de procesamientos.
● La capa de proceso que consta de: a) La integración del crawler Uru y la
ontología. El crawler Uru extrae información personal, académica laboral y
familiar de un determinado personaje de la política colombiana de Wikipedia. La
ontología permite solucionar aspectos como el de sinonimia, modelo de datos
dinámico, consultas a base de datos e información relacionada con la
visualización de grafos. Dicha ontología fue implementada en REDIS, con el fin
de optimizar los tiempos de respuesta y b) Implementar un servicio de socket
que permite comunicar los procesos del sistema entre Python y Node.js.
32
● La capa de presentación contiene los flujos de trabajo entre el usuario y el
aplicativo web por medio de las interfaces de usuario.
Ilustración 2 Arquitectura del aplicativo web (Diseño propio).
7.2. DESARROLLO METODOLÓGICO
Para la construcción del aplicativo web se realizaron seis iteraciones donde cada
una contiene sus respectivas historias de usuarios, tareas de ingeniería y prueba de
aceptación. Asimismo, definen las funciones del software y sus componentes con el
fin de identificar el flujo de trabajo, entradas y salidas del aplicativo web.
La tabla 4 describe los roles de los participantes en la construcción de la aplicación
web. Dos de los participantes se encargan del desarrollo y pruebas del producto, el
33
otro participante gestiona y define las tareas de acuerdo con las necesidades del
aplicativo.
Roles Responsable
Desarrollador Romario Sánchez, Juan Manuel Pérez
Analista de Calidad Romario Sánchez, Juan Manuel Pérez
Consultor Sonia Ordoñez
Gestor Sonia Ordoñez
Tab la 4 Participantes en la construcción de la aplicación web (Diseño Propio)
Las estimaciones y prioridad de las historias de usuario se visualizan en la tabla 5,
allí describe cuales son las historias de usuario con mayor prioridad y mayor
esfuerzo.
Historias Nombre Iteración Prioridad Esfuerzo
1 Extraer información de Wikipedia 1 Medio 10
2 Def inición o desarrollo del crawler a utilizar 1 Alto 10
3 Integrar crawler en el aplicativo 1 Medio 10
4 Cargar inf ormación del crawler 1 Medio 5
5 Construir servicio socket 1,5 Alto 15
6 Control de categorías en la búsqueda de personajes 2 Bajo 5
7 Cargar sinónimos de términos generales 2 Alto 12
8 Def inir estructura de datos 2 Medio 8
9 Carga de conocimiento en la ontología 2 Alto 9
10 Componente ejecutable para la carga de la ontología 3 Alto 9
11 Interfaz gráfica buscador de personajes 3 Medio 12
12 Lógica de carga de nodos y relaciones 4 Alto 9
13 Construcción de nodos 4 Medio 8
14 Construcción de relaciones 4 Alto 7
15 Consultar lista de personajes 5 Alto 16
16 Consultar lista de personajes sugeridos por Wikipedia 5 Alto 10
17 Visualizar grafo de personajes 5 Alto 14
18 Interfaces gráficas informativas 6 Medio 12
19 Filtro de nodos 6 Medio 8
20 Filtro de camino entre nodos 6 Medio 10
21 Visualizar información básica del nodo y relación 6 Medio 8
Tab la 5 Historias de usuario (Diseño propio).
34
7.2.1. Primera iteración
En la primera iteración se desarrollaron actividades conjuntas entre todo el equipo
referentes a la planeación del desarrollo, así como el planteamiento de las historias
de usuario, tareas de ingeniería y pruebas de aceptación. Las descripciones y
especificaciones de las historias de usuario definidas en la primera iteración se
encuentran en el Anexo No 1.
7.2.1.1. Historias de Usuario
Esta iteración tuvo como objetivo, por un lado, la identificación o implementación del
crawler que permitiera obtener la información de los personajes de la política
colombiana a través de la enciclopedia libre en línea Wikipedia y por el otro la
integración del crawler al sistema.
Las historias de usuario definidas para la primera iteración se encuentran en la tabla
6. Allí se encuentra el nombre de la historia, su descripción y el estado con el que
finalizó dicha historia de usuario.
Historias Nombre Descripción Estado
1
Extraer información
de Wikipedia
El sistema debe extraer la información de Wikipedia en
español de los personajes que sean solicitados por el
usuario Rechazada
2
Def inición o desarrollo
del crawler a utilizar
Se debe realizar un análisis de crawlers de código abierto
que se puedan integrar al sistema y de los cuales se pueda
obtener información relacionada con personajes de la
política colombiana. Luego de revisar y probar las distintas
opciones encontradas se elige el crawler Uru Aceptada
3
Integrar crawler en el
aplicativo
Realizar la integración del crawler Uru al aplicativo web por medio del montaje de sus componentes de sof tware e instalación de sus dependencias. Aceptada
4
Cargar inf ormación
del crawler
Construir un componente de software que permita
almacenar toda la información extractada por el crawler en
una base de datos que pudiese almacenar información
semiestructurada. Para lo cual después de revisar varias
opciones se determinó que la mejor era MongoDB. Aceptada
5
Construir servicio
socket
Realizar un servicio socket de tipo bidireccional que permita
env iar y recibir información entre Python y Node.js. Extendida
Tab la 6 Historias de usuario de la primera iteración.
El énfasis de la primera iteración fue realizar la búsqueda de componentes de
software, librerías o APIS con la funcionalidad de extraer información de las páginas
de Wikipedia para obtener la mayor cantidad de información relacionada a los
personajes.
35
7.2.1.1.1. Extraer información de Wikipedia
Como resultado de la búsqueda de librerías que permitieran extraer información de
las páginas de Wikipedia, se buscó la integración de las librerías “Wikipedia API” y
“WPTools” sin embargo, los componentes probados e integrados al sistema extraen
información de forma parcial o incompleta, sus tiempos de respuesta son lentos con
grandes cantidades de datos y los componentes no respondieron a la cantidad de
peticiones necesarias para el sistema. Dados los resultados anteriores se consideró
necesario obtener la información de las páginas web que se encontraban enlazadas
por lo que se contempló la utilización de un crawler.
7.2.1.1.2. Definición o desarrollo del crawler a utilizar
La función básica de un crawler es la exploración y extracción de información de un
sitio web. En este caso fue la extracción de toda la información de un personaje y la
información de otros enlaces que tengan relación con dicho personaje.
Para identificar cuál crawler ofrecía mayor información acorde a las necesidades del
aplicativo, se realizaron pruebas con los incluidos en la tabla 7, identificando las
características principales. Como resultado de esta exploración se determinó que el
componente de software “Uru”, presentaba las funcionalidades necesarias para la
integración con el aplicativo.
Nombre Descripción Código libre
Cumple Lenguaje
wikipedia-crawler
Únicamente realiza la extracción de enlaces
relacionados a una página inicial ingresada por el
usuario de Wikipedia [64].
Si No Py thon
wiki-crawler Realiza una búsqueda en Wikipedia a partir de un
término y descarga todas las páginas relacionadas
con el término ingresado. Solo descarga el título y
descripción de cada página encontrada [65].
Si No Jav ascript
Wiki_crawler Únicamente busca otros términos relacionados con
una palabra ingresada por el usuario [66].
Si No Py thon
web crawler Solo busca enlaces relacionados con un criterio
según términos de búsqueda ingresados por el
usuario, no muestra relación cuáles f ueron los
Si No Jav a
Script
36
enlaces “semilla” (donde se comienza la iteración)
[67]
Httrack Descarga todo el contenido HTML de la página web,
sin embargo para obtener cierto dato de la página es
necesario la implementación de un Scrapy [61]
Si No .Net
Uru Extrae nombres, f echa de nacimiento, religión,
residencia, ocupación, partido político, entre otros.
Uru extrae todo el contenido de la página de
Wikipedia que generalmente contiene inf ormación
más detallada de la persona como su biografía,
f amilia, logros alcanzados en su ocupación, obras,
entre otros [62].
Si Si Py thon
Tab la 7 Comparación de crawlers (Diseño propio).
Uru es un componente de software construido en Python que se encarga de
recolectar información personal, y contenido en general a partir de páginas en
español de Wikipedia relacionadas con personas. Dentro de la información general
que extrae el crawler está: nombres, fecha de nacimiento, religión, residencia,
ocupación, partido político, entre otros [62].
7.2.1.1.3. Integración del crawler en el aplicativo
Luego de definir el crawler se realiza el proceso de integración de dicho componente
al aplicativo web. Uru extrae todo el contenido de la página de Wikipedia que
generalmente contiene información detallada de la persona como su biografía,
familia, logros alcanzados en su ocupación, obras, entre otros. En la ilustración 3 se
encuentra un ejemplo de la información que puede ser extraída por el crawler Uru y
del personaje “Juan Manuel Santos Calderón” presidente de Colombia para el
periodo 2014-2018, en dicha figura aparece un fragmento de información básica del
personaje.
"URL": "https://es.wikipedia.org/wiki/Juan_Manuel_Santos", "Información personal": {
"URL": "https://es.wikipedia.org/wiki/Iglesia_cat%C3%B3lica", "title": "Iglesia católica" },
"Partido político": [ { "URL": "https://es.wikipedia.org/wiki/Partido_Social_de_Unidad_Nacional", "title": " Partido Social de Unidad Nacional"
37
} ],
"Residencia": [ { "URL": " https://es.wikipedia.org/wiki/Casa_de_Nari%C3%B1o", "title": " Casa de Nariño"
} ]
Ilustración 3 Fragmento de información extractada por el crawler (Diseño propio).
7.2.1.1.4. Cargue de información del crawler
La información que se extrae del crawler es semiestructurada en formato JSON, por
lo que fue necesario incluir un motor de bases de datos compatible con este tipo
información. MongoDB es una base de datos NoSQL orientada a documentos de
tipo BSON (JSON Binario) la cual proporciona alto rendimiento, alta disponibilidad
y escalabilidad. Con el fin de guardar toda la información en bruto obtenida por el
crawler, se determinó el uso de esta base de datos para llevar registro de los
personajes que han sido procesados.
El crawler siempre extrae el nombre y la URL de la página como identificador del
personaje. El resto de la información es opcional, es decir que no siempre se
encuentra en todos los personajes extractados por el crawler. En la ilustración 4 se
encuentra un modelo general de la colección de MongoDB implementada para el
aplicativo.
38
Ilustración 4 Modelo de datos colección de MongoDB (Diseño propio).
7.2.1.1.5. Construcción servicio socket
Para la comunicación entre Python y Node.js se implementó un servicio creado en
Python a través del socket que permite enviar y recibir información en tiempo real.
Para la implementación del socket se utilizó SocketIO [68] que es una tecnología
implementada en JavaScript la cual crea canales bidireccionales en tiempo real
basados en eventos de emisión y recepción brindando rapidez y confiabilidad de
transmisión de información. Por otro lado flask-socketio [69] es un componente que
permite el montaje del socket en Python donde una aplicación del lado cliente
(JavaScript, Java, C++, Swift o cualquier cliente compatible) puede establecer una
conexión al socket web.
7.2.1.2. Tareas de ingeniería
En la tabla 8 se encuentra la lista de tareas de ingeniería que se realizaron para la
primera iteración. La descripción de cada tarea de ingeniería se puede encontrar en
el Anexo No 1.
39
Tarea
Historia de
usuario Nombre Estado
1 1 Integrar librería “Wikipedia API” Rechazada
2 1 Integrar librería “WPTools” Rechazada
3 2 Búsqueda de crawlers Aceptada
4 3 Integración del crawler Aceptada
5 3 Adaptación de la información obtenida del crawler Aceptada
6 4 Insertar información de personajes Aceptada
7 4 Consultar información de personajes Aceptada
8 5 Construir servicio básico del socket Aceptada
Tab la 8 Tareas de ingeniería de la primera iteración.
El desarrollo de las tareas de ingeniería para la primera iteración dio como resultado:
7.2.1.2.1. Integración librería “Wikipedia API” y “WPTools”
Aunque las dos primeras integraciones de las librerías de Python fueron
rechazadas, estas tareas de ingeniería sirvieron para explorar e identificar los datos,
el tiempo de respuesta y la disponibilidad de la información solicitados por el
sistema. Igualmente, sirvieron para identificar que era necesario extraer información
de las personas relacionadas en la página de Wikipedia del personaje, por lo que
se decidió que era necesario la integración de un crawler.
7.2.1.2.2. Búsqueda de crawlers
La definición del crawler implicó la búsqueda de varios componentes de software
disponibles que permitieran las extracciones de información de Wikipedia. Uru es el
componente de software seleccionado para la integración con el aplicativo web que
cumple con una de las especificaciones necesarias para el desarrollo del sistema.
7.2.1.2.3. Integración del Crawler
La integración del crawler implicó el montaje de los componentes de software del
crawler Uru en el aplicativo web que se ve reflejados en el diagrama de
componentes de la Ilustración 5, donde se describe los distintos componentes del
crawler presentes en el aplicativo web. En la capa de negocio se encuentra el
componente que se encarga de extraer la información de Wikipedia y el componente
que envía la información extraída a la capa de presentación. El componente de la
capa de presentación se encarga de visualizar los personajes que han sido
procesados.
40
Ilustración 5 Diagrama de componentes integración del crawler de Uru (Diseño
propio).
7.2.1.2.4. Adaptación de la información obtenida del crawler
Para obtener la información relacionada al personaje al crawler Uru se le debe
ingresar como parámetro una URL con la que se obtiene un conjunto de datos de la
página de Wikipedia en la que se encuentran:
Nombres.
Cónyuge(s)
Padre(s)
Hijo(s)
Cargo(s)
Educación
Religión.
Fecha y lugar de nacimiento
Residencia
Ocupación
Redes sociales
41
7.2.1.2.5. Inserción y consulta de información de los personajes
Cuando el aplicativo obtiene la información del personaje inserta un documento en
una colección en MongoDB. La información almacenada en MongoDB se puede
gestionar a través de un componente en software construido en el aplicativo web.
Dicho componente permite entre otras funciones filtrar a través de la URL y el
nombre.
7.2.1.2.6. Construcción servicio básico del socket
El socket se implementa con una dirección IP y un puerto por donde se comunicará
Python y Node.js. Este montaje permite que en las siguientes iteraciones se pueda
construir los servicios que requiere el sistema. El montaje del servicio crea canales
los cuales envían información entre el lado cliente y el lado servidor. En la ilustración
6 se incluye un diagrama de la estructura del socket implementado. En este caso el
lado cliente es Node.js y el lado servidor es Python donde ambos pueden enviar y
recibir información de acuerdo con sus respectivos flujos de trabajo.
Ilustración 6 Estructura del servicio socket (Diseño propio)
42
7.2.1.3. Pruebas de aceptación
La lista de pruebas de aceptación que se realizaron para cada una de las historias
de usuario se encuentra en la Tabla 9. Cada prueba de aceptación se realiza de
acuerdo con las diferentes condiciones y pasos descritos en el Anexo No 1.
Prueba
Historia de
usuario Nombre Estado
1 1 Extraer información de Wikipedia. Rechazada
2 2 Extraer información a través crawler URU Aceptada
3 3
Registrar información de personajes en la base de datos
MongoDB Aceptada
4 4 Consultar información de personajes Aceptada
5 5 Env ío de información a través del socket Aceptada
Tab la 9 Pruebas de aceptación de la primera iteración
7.2.2. Segunda iteración
El objetivo para esta iteración es la recolección de ayudas léxicas para alimentar la
ontología. Algunas de las tareas que se realizan son: la recolección de categorías y
sinónimos almacenados en archivos de extensión JSON. Para la segunda iteración
aparecen 3 nuevas historias usuario y una historia que se extendió de la primera
iteración.
7.2.2.1. Historias de usuario
El resumen de las historias de usuario definidas para la segunda iteración se
encuentra en la tabla 10. Toda la especificación de cada una de las historias de
usuario se encuentra en el Anexo No 1.
43
Historias Nombre Descripción Estado
6
Controlar las categorías de
búsqueda de personajes
Con el f in de delimitar los resultados de búsqueda que se presentaran al usuario se deben cargar las categorías de Wikipedia que tenga relación con el gobierno colombiano Aceptada
7
Cargar sinónimos de términos
generales
Wikipedia al ser una enciclopedia libre en la que múltiples usuarios interactúan, existen una gran multiplicidad de términos que hacen referencia a la misma inf ormación, de esta manera debe existir un mecanismo que identif ique sinónimos. Aceptada
8 Def inir estructura de datos
La inf ormación almacenada en la base de datos orientada a grafos debe estar estructurada según un modelo de datos previamente diseñado, esto tiene el f in de que independiente de la fuente de información el almacenamiento se realizará sobre los nodos y relaciones prev iamente diseñados. Aceptada
9
Carga de conocimiento en la
ontología
Para mejorar la búsqueda de relaciones entre personajes es necesario ingresar conocimiento acerca de la estructura política colombiana. Aprobada
Tab la 10 Historias de usuario de la segunda iteración.
7.2.2.1.1. Control de categorías de búsqueda de personajes
Para la búsqueda de los personajes disponibles en Wikipedia se utilizó la librería de
Python Wikipedia 1.4.0 [70], la cual tiene un método que permite obtener los enlaces
de las páginas que estén relacionados con un criterio de búsqueda. Al realizar un
análisis de los resultados se notó que no todos los enlaces corresponden a páginas
de personas y no todas las páginas de personas se deberían dar como sugerencia
al usuario dado que se busca que la información de la página este enfocada a
personajes del entorno público de la política colombiana. Sin embargo, cada página
de Wikipedia se encuentra asociada a un conjunto de categorías o subcategorías.
Por lo tanto, el aplicativo selecciona las categorías de Wikipedia para realizar filtros
y mostrar al usuario solamente los resultados de búsqueda que cumplan con el
objetivo del prototipo.
Para la historia de usuario 5 se realiza una búsqueda de las categorías de Wikipedia
donde se encontraron 134 categorías y subcategorías que hacen parte del campo
de la política en Colombia en el idioma en español. Las categorías permiten al
sistema delimitar la búsqueda de personajes de Wikipedia y restringen los tipos de
páginas y contenido no hacen parte de dichas categorías. Para la extracción de las
categorías que van a ser incluidas posteriormente dentro del sistema se utiliza un
componente de software construido en Python que se encarga de buscar todas las
categorías hijas o subcategorías de una categoría general. En la ilustración 7 se
44
encuentra una porción muy pequeña de la estructura en forma de grafo de las
categorías de Wikipedia, los óvalos son las categorías y los rectángulos las páginas.
Ilustración 7 Porción del grafo de categorías de Wikipedia (Diseño propio).
En la ilustración 8 se encuentra el pseudocódigo del componente que extrae las
categorías de Wikipedia. Su función principal es ingresar una categoría padre y por
medio de una solicitud al API de wikimedia [71] busca las categorías hijas o
subcategorías, las añade a una lista con la que realiza la búsqueda recursiva y
controla las categorías ya iteradas. Cuando el proceso ha finalizado el componente
de software crea un archivo de extensión JSON con las categorías que fueron
encontradas.
Ilustración 8 Pseudocódigo de componente que extrae categorías (Diseño propio).
7.2.2.1.2. Cargar sinónimos de términos generales
Para esta historia de usuario se identificó que Wikipedia no tiene un estándar en la
información de los personajes. Es decir, los datos se pueden referir a una misma
45
información para todos los personajes, pero puede encontrarse esta información
con distintos términos. Por ejemplo, cuando se quiere obtener la información con
respecto a la educación obtenida por el personaje podemos encontrar términos tales
como: educación, alma mater, universidad, institución, facultad, escuela, etc. En
general, estas palabras o frases se pueden encerrar en un solo concepto que puede
ser llamado “Educación” donde permite identificar el tipo de información que está
procesando el sistema. El proceso anterior permitió crear un compendio de
conceptos con sus sinónimos en español para lograr estandarizar la información
recolectada de Wikipedia.
El ejemplo anterior de la educación cursada por un personaje, se puede suponer
que un personaje estudia o estudió en una institución por un periodo de tiempo para
obtener un pregrado, posgrado, curso, diplomado, etc. El personaje es un nodo de
tipo persona y la institución educativa se puede definir como un nodo de tipo
institución u organización. Para conectar los dos nodos se define la relación con la
información que une ambos nodos, en este caso la información de la relación es el
periodo de tiempo y la actividad que realizó el personaje en dicha institución. En
resumen, todos los términos relacionados a los personajes se pueden generalizar
en conceptos propios del sistema y asociar a nodos y relaciones que se encargan
de unir toda la información que se pueda extraer de Wikipedia. En la Ilustración 9
se encuentra un ejemplo de cómo funciona todo el proceso de asociación de
términos con los nodos y relaciones.
Ilustración 9 Proceso de generalización de términos a nodos (Diseño propio)
Para la recolección de sinónimos se utiliza un componente de software que se
encarga de conectarse e ingresar términos al API de “Word Reference”, retornando
una lista de sinónimos que son agregados a un archivo de extensión JSON. El
46
proceso de generalizar el conjunto de sinónimos obtenidos en un concepto se
realiza de forma manual con el fin de luego lograr asociar el concepto con un tipo
de nodo o un tipo de relación dentro de la ontología. En la Ilustración 9 se encuentra
el pseudocódigo del componente de software que se encarga de extraer sinónimos.
Ilustración 10 Pseudocódigo de componente que extrae sinónimos (Diseño propio)
7.2.2.1.3. Definición de estructura de datos
Con el fin de manejar las categorías de búsqueda, los sinónimos y términos
generales, así como el modelo de datos (Ver Ilustración 14), se definió el manejo de
una ontología que permita acceder a esta información y controlar los procesos de la
aplicación. Se definió que la ontología debería ser almacenada en una base de
datos en memoria dada la velocidad que ofrecen en comparación con las bases de
datos en disco por lo que se escogió el sistema manejador de base de datos REDIS.
7.2.2.1.4. Carga de conocimiento en la ontología
Con el fin de detectar las relaciones laborales entre los personajes, fue necesario
ingresar en la ontología la organización del gobierno colombiano para reconocer
qué personajes pertenecen a la misma organización gubernamental, así mismo
como determinar qué cargos están relacionados con cada entidad.
7.2.2.2. Tareas de Ingeniería
En la tabla 11 se encuentra la lista de tareas de ingeniería que se realizaron para la
segunda iteración. La descripción de cada tarea de ingeniería se puede encontrar
en el Anexo No 2
47
Tarea
Historia de
usuario Nombre Estado
9 6 Recopilación de categorías de búsqueda de personajes Aceptada
10 6 Validación de categorías en la búsqueda de personajes no registrados Aceptada
11 7 Desarrollo de archivos con la relación de palabras que tienen el mismo significado. Aceptada
12 8
Def inición del modelo de datos (nodos, relaciones y
atributos) Aceptada
13 9 Recopilación de conocimiento para la ontología Aprobada
Tab la 11 Tareas de ingeniería de la segunda iteración.
El desarrollo de las tareas de ingeniería para la segunda iteración dio como
resultado:
7.2.2.2.1. Recopilación de categorías de búsqueda de personajes
La recopilación de categorías y subcategorías de Wikipedia relacionadas con la
política colombiana en el idioma español. En la Ilustración 11 se encuentra un
fragmento de algunas de las 134 categorías encontradas.
{"category": "Representantes de la Cámara de Colombia 2014-2018"} {"category": "Pol\u00edticos de Colombia por partido"} {"category": "Pol\u00edticos del Movimiento Alas Equipo Colombia"}
{"category": "Pol\u00edticos del Partido Cambio Radical"} {"category": "Militantes de Centro Democrático (Colombia)"} {"category": "Pol\u00edticos del Partido Colombia Democrática"}
{"category": "Pol\u00edticos del Movimiento Colombia Viva"} {"category": "Pol\u00edticos del Partido Conservador Colombiano"} {"category": "Pol\u00edticos del Partido Convergencia Ciudadana"} {"category": "Pol\u00edticos del Movimiento Indígena"}
{"category": "Pol\u00edticos del Partido de Integraci ón Nacional"} {"category": "Pol\u00edticos del Partido Liberal Colombiano"} …
Ilustración 11 Categorías de Wikipedia (Diseño propio).
7.2.2.2.2. Validación de categorías en la búsqueda de personajes
La búsqueda de personajes en Wikipedia solamente con las categorías que fueron
cargadas al sistema. Es decir, el sistema filtra los resultados que se encuentren
relacionados con las 134 categorías. La ilustración 12 incluye un diagrama de
actividades del proceso de validación de los resultados de búsquedas con la lista
de categorías que se carga en REDIS.
48
Ilustración 12 Diagrama de actividades de la validación de categorías (Diseño
propio).
7.2.2.2.3. Desarrollo de archivos con relación de palabras que tienen el
mismo significado.
Para esta tarea de ingeniería se crea un archivo con los sinónimos de los términos
encontrados y su generalización a conceptos. En la ilustración 9 se encuentra un
ejemplo de la estructura del archivo de sinónimos que se carga en la ontología.
{
"family": { "parent": [ "papá", "progenitor", "padrazo", "ascendiente", "procreador", "padre", "padres"
], "spouse": [ "consorte", "esposo", "esposa", "contrayente", "marido", "mujer", "cónyuge" ],
49
"son": [ "sucesor", "vástago", "retoño", "fruto", "descendiente", "heredero", "hijo"
] } }, {
"organization": { "academic": [ "Alma máter", "universidad", "instituto", "facultad", "escuela", "seminario", "colegio",
] } } …
Ilustración 13 Ejemplo de segmento del archivo de sinónimos (Diseño propio).
7.2.2.2.4. Definición del modelo de datos (nodos, relaciones y atributos)
Con base a la extracción de los sinónimos y generalización de los términos se define
el modelo de datos del grafo con sus respectivos tipos de nodos, tipos relaciones y
atributos. La ilustración muestra los 5 tipos de nodo y 6 posibles relaciones
resultantes, son sus respectivos atributos (Ver Ilustración 14).
Ilustración 14 Definición de la estructura de datos (Diseño propio)
50
7.2.2.2.5. Recopilación de conocimiento para la ontología
Consultando en la fuente de información que va a alimentar la base de datos de la
página (Wikipedia), se evidenció que el gobierno de Colombia se puede resumir en
ramas del poder público (ejecutiva, legislativa y judicial) y organismos del estado
(de control, electoral y otros), de los que se obtuvo un listado de cargos públicos
(134 cargos) y entidades gubernamentales (94 entidades). Ver Tabla 12
Rama del poder público Entidad Gubernamental Cargo
Rama ejecutiva
Presidencia de la República de Colombia
Presidente de la República de Colombia
Vicepresidente de la República de Colombia
Ministerio de defensa Ministro de defensa
Viceministro de defensa
Ministerio de trabajo Ministro de trabajo
Viceministro de trabajo
Ministerio de agricultura Ministro de agricultura
Viceministro de agricultura
Ministerio de hacienda y crédito público Ministro de hacienda y crédito público
Viceministro de hacienda y crédito público
Ministerio del interior Ministro del interior
Viceministro del interior
Ministerio de relaciones internacionales Ministro de relaciones internacionales
Viceministro de relaciones internacionales
Ministerio de Salud y la Protección Social
Ministro de salud
Viceministro de salud
Ministerio de minas y energía Ministro de minas y energía
Viceministro de minas y energía
Ministerio de comercio, industria y turismo
Ministro de comercio, industria y turismo
Viceministro de comercio, industria y turismo
Ministerio de educación Ministro de educación
Viceministro de educación
Ministerio de ambiente Ministro de ambiente
Viceministro de ambiente
Ministerio de vivienda Ministro de vivienda
Viceministro de vivienda
Ministerio TICs Ministro TICs
Viceministro TICs
Ministerio de transporte Ministro de transporte
Viceministro de transporte
Ministerio de cultura Ministro de cultura
Viceministro de cultura
Gabinete presidencial Secretario General de la Presidencia
51
Alto Consejero Presidencial para el Postconflicto, Derechos Humanos y Seguridad
Alta Consejera Presidencial para el Sector Priv ado y Competitividad
Alto Consejero Presidencial de Comunicaciones
Alto Consejero Presidencial para las Regiones
Consejera Presidencial para la Primera Infancia
Consejera Presidencial para la Equidad de la Mujer
Consejera Presidencial de Derechos Humanos
Secretario Privado de la Presidencia
Secretaria Jurídica de la Presidencia
Secretario de Transparencia de la Presidencia.
Secretaria de Prensa de la Presidencia
Gobernaciones departamentales (por cada departamento (32)) Gobernador
Alcaldías (por cada departamento (32)) Alcalde
Rama legislativa Congreso de la República de Colombia
Presidente del Senado de Colombia
Vicepresidente del Senado de Colombia
Segundo vicepresidente del Senado de Colombia
Senador de la república de Colombia Presidente de la Cámara de Representantes de Colombia
Vicepresidente de la Cámara de Representantes de Colombia
Segundo vicepresidente de la Cámara de Representantes de Colombia
Representante a la cámara
Rama judicial
Corte Constitucional de la República de Colombia
Presidente de la Corte Constitucional de la República de Colombia
Vicepresidente de la Corte Constitucional de la República de Colombia Magistrado de la Corte Constitucional de la República de Colombia
Corte suprema de justicia
Presidente de la Corte suprema de justicia
Vicepresidente Corte suprema de justicia
Magistrado Corte suprema de justicia (23)
Consejo superior de la judicatura Magistrado superior de la judicatura (13)
Consejo de estado Magistrado Consejo de estado (31)
Fiscalía general de la nación Fiscal General
Vicef iscal General
Organismos de control
Procuraduría General de la Nación Procurador general de la nación
Defensoría de pueblo Defensor del pueblo
Contraloría General de la Republica Contralor General de la República
Vice contralor General de la República
Organización electoral
Consejo nacional electoral Consejero nacional electoral
Registradora Nacional del Estado Civil Registrador nacional
52
Otros Banco de la república Gerente general del Banco de la república
Comisión Nacional de televisión Miembro de la junta de la comisión nacional de televisión
Tab la 12 Relación de cargos con entidades gubernamentales de Colombia (Diseño propio).
Para la carga de la información del ítem anterior se generó un listado de las
entidades que hacen parte del gobierno con el fin de realizar la extracción de su
información en Wikipedia y su procesamiento para el registro en la base de datos.
Este listado consta del nombre de la entidad y la dirección URL de la página de
Wikipedia por cada entidad, lo cual permitirá controlar que solo se relacionen cargos
públicos y que de cada relación se tenga información de la entidad.
Ilustración 15 Pseudocódigo Ob tener sniónimo por nodo o relación (Diseño propio)
7.2.2.2.6. Implementación de funciones para la obtención de sinónimos por
cada término
Para la estructuración de archivos se definieron 2 tipos de archivo, los archivos en
los que se describe la generalización de términos en el que el término más general
se encuentra en la raíz de la estructura JSON y los archivos en los que se encuentra
la relación del término con el determinado atributo de nodo o relación.
7.2.2.3. Pruebas de aceptación
La lista de pruebas de aceptación que se realizaron en la segunda iteración se
encuentra en la Tabla 13. Cada prueba de aceptación se realiza de acuerdo con las
diferentes condiciones y pasos descritos en el Anexo No 2.
Prueba
Historia de
usuario Nombre Estado
6 6
Validar f iltro de categorías para la búsqueda de
personajes Aceptada
7 7 Consultar sinónimos por términos Aceptada
8 9 Carga de la información recopilada en la ontología Aprobada
Tab la 13 Pruebas de aceptación de la segunda iteración
53
7.2.3. Tercera iteración
La tercera iteración tuvo como objetivo la carga de los archivos relacionados con la
ontología en la base de datos y la implementación de la interfaz gráfica del buscador
de personajes. Para esta iteración se desarrollaron 2 historias descritas en la Tabla
14, cada una con sus respectivas tareas de ingeniería y pruebas de aceptación
correspondientes.
7.2.3.1. Historias de usuario
Toda la especificación de cada una de las historias de usuario se encuentra en el
Anexo No 3.
Historias Nombre Descripción Estado
10 Componente ejecutable para la carga de la ontología
Se debe implementar un componente que permita la carga de la ontología en el motor de base de datos, por si se presentan fallos que generen la pérdida de la inf ormación Aprobada
11 Interfaz gráfica buscador de personajes
En la interf az web hay una caja de texto con autocompletar donde se ingresa el nombre del personaje. En la parte superior de la interf az debe construirse un panel de nav egación a las distintas páginas de la aplicación. Aprobada
Tab la 14 Historias de usuario tercera iteración.
7.2.3.1.1. Componente ejecutable para la carga de la ontología
Para la carga de la ontología en la base de datos, se realizó la definición de los tipos
de datos tal como se muestra en la Tabla 15.
Información Tipo de dato Clave Valor
Categorías Conjunto Categoría Cada una de las categorías relacionadas
con políticos colombianos.
Sinónimos Cadena Palabra Relación de la palabra con el atributo del
nodo o relación
Nodos Conjunto Nombre de nodo Atributos del nodo
Relaciones Conjunto Nombre de la relación Atributos de la relación
Organizaciones Cadena Nombre del cargo Dirección URL en la que se encuentra
inf ormación única del cargo
54
Partidos políticos Cadena Nombre del cargo Dirección URL en la que se encuentra
inf ormación única del cargo
Características del
nodo para la
aplicación
Hash Nombre del nodo Color del nodo por defecto en la interfaz
gráf ica
Características de la
relación para la
aplicación
Hash Nombre de la relación Color del nodo por defecto en la interfaz
gráf ica
Query para la consulta de la relación
Tab la 15 Asignación tipos de datos en la ontología (Diseño propio).
Para la carga de la ontología desde un componente ejecutable, se desarrolló un
archivo de configuración donde se encuentran los directorios en los que están los
archivos que van a ser cargados y módulos que se encargan de:
La lectura y serialización de los archivos
Carga de información con el motor de la base de datos clave - valor
Control de errores.
7.2.3.1.2. Interfaz gráfica buscador de personajes
En esta iteración se comenzó a diseñar la interfaz web con la que van a interactuar
los usuarios, iniciando con el diseño de la página principal de la aplicación en la cual
se encuentra la barra de navegación en la que se ingresa el nombre del personaje
que se va a consultar, así mismo como las pestañas a otras páginas que hacen
parte de la aplicación.
7.2.3.2. Tareas de ingeniería
En la Tabla 16 se encuentra la lista de tareas de ingeniería que se realizaron para
la tercera iteración. La descripción de cada tarea de ingeniería se puede encontrar
en el Anexo No 3.
55
Tarea Historia de usuario Nombre Estado
14 10 Implementar archivo de configuración Aprobada
15 10 Implementar archivos para la carga de la ontología Aprobada
16 10 Desarrollo componente lectura / escritura de archivos Aprobada
17 10
Implementar componente para la carga de datos en la
ontología Aprobada
18 11 Construir interfaz web del buscador de personajes Aprobada
19 11
Integrar interfaz del buscador de personajes con
componentes back-end Aprobada
Tab la 16 Tareas de ingeniería de la tercera iteración.
El desarrollo de las tareas de ingeniería para esta iteración dio como resultado:
7.2.3.2.1. Implementar archivo de configuración
Para esta tarea de ingeniería se implementa un archivo de configuración en formato
JSON que contiene la ubicación de los archivos de cargue a la ontología y
directorios manejadores de errores. En la Ilustración 16 incluye el archivo de
configuración de los directorios.
{ "fi lePath": "Files/", "logFile": "Scrapy.log", "loads": "Files/Cargues",
"generatedFilePath": "Generated Files/" }
Ilustración 16 Archivo de configuración de directorios (Diseño propio)
7.2.3.2.2. Implementación de archivos para la carga de la ontología
Para la carga de la información mediante el componente ejecutable fue necesario
la implementación de archivos que tuvieran la siguiente información:
● Categorías
● Sinónimos
● Nodos
● Relaciones
● Organizaciones
● Cargos públicos
● Partidos políticos
56
● Características del nodo para la aplicación
● Características de las relaciones para la aplicación
● Consultas para la obtención de la información.
7.2.3.2.3. Desarrollo componente lectura / escritura de archivos
Los archivos que van a ser cargados en la ontología en la base de datos de REDIS
necesitan un componente de lectura y escritura dentro aplicativo. En la Ilustración
17 se encuentra el pseudocódigo de los métodos encargados de leer y escribir
archivos en el aplicativo.
Ilustración 17 Pseudocódigo métodos manejadores de archivos (Diseño propio)
7.2.3.2.4. Implementar componente para la carga de datos en la ontología
Para la implementación del archivo ejecutable se construyeron los módulos pyRedis
que se encarga de la conexión de la base de datos y de los métodos de inserción y
consulta por cada tipo de dato, FileManager el cual es el encargado leer, escribir y
serializar archivos, pyOntology que contiene la lógica para carga de los archivos en
la base de datos Redis (componentes reutilizados de [72]). Los cuales son
detallados en la Ilustración 18.
57
.
Ilustración 18 Componente para la carga de la ontología en la base de datos (Diseño
propio).
7.2.3.2.5. Construcción e integración de interfaz web del buscador de
personajes
Para la construcción de los componentes de la interfaz web se utilizaron plantillas
del framework de front-end como se puede evidenciar en la Ilustración 19.
Ilustración 19 Página principal UMA UD (Diseño propio).
En la barra de búsqueda existen sugerencias de los personajes que fueron
consultados con anterioridad y que por lo tanto ya se encuentran registrados en la
base de datos, para esto se implementó una funcionalidad de autocompletar que
utiliza el componente de consulta de MongoDB. El usuario debe ingresar el nombre
del personaje y cuando se digitan más de tres caracteres el aplicativo sugiere la lista
de personajes registrados que concuerdan con el patrón ingresado.
58
Ilustración 20 Sugerencia de personajes en la barra de búsquedas (Diseño propio).
7.2.3.3. Pruebas de aceptación
Las pruebas de aceptación que se realizaron para esta iteración son descritas en la
Tabla 17. Cada prueba de aceptación se ejecutó según las diferentes condiciones
y pasos descritos en el Anexo No 3.
Prueba
Historia de
usuario Nombre Estado
9 10
Ejecución del componente ejecutable para la carga
de la inf ormación en la ontología Aprobada
10 11
Visualización de la página principal de la página con
la barra de búsqueda y las secciones de la página Aprobada
11 11
Validar sugerencia de personajes ya registrados en
base de datos Aprobada
Tab la 17 Pruebas de aceptación tercera iteración.
7.2.4. Cuarta iteración
El énfasis de esta iteración fue el registro de la información abstraída de los
personajes en la base de datos orientada a grafos para ser consultada por la
aplicación, para esto se empleó la ontología descrita en las iteraciones anteriores
para la obtención de los atributos que hacen parte de cada nodo y relación,
establecer cuáles son las relaciones que se pueden presentar, el empleo de
sinónimos para reducir la cantidad de términos almacenados y de esta manera
59
presentarle al usuario una visualización estándar de la información de cada
personaje o entidad.
La cuarta iteración constó de 3 historias de usuario las cuales son detalladas en la
Tabla 18, donde presenta para cada una sus respectivas tareas de ingeniería y
pruebas de aceptación.
7.2.4.1. Historias de usuario
El énfasis de esta iteración fue el registro de la información abstraída de los
personajes en la base de datos orientada a grafos para ser consultada en la
aplicación, para esto se empleó la ontología descrita en las iteraciones anteriores
para la obtención de los atributos que hacen parte de cada nodo y relación,
establecer cuáles son las relaciones que se pueden presentar, el empleo de
sinónimos para reducir la cantidad de términos almacenados y de esta manera
presentarle al usuario una visualización estándar de la información de cada
personaje o entidad.
El resumen de las historias de usuario definidas para la cuarta iteración se
encuentra en la Tabla 18. Toda la especificación de cada una de las historias de
usuario se encuentra en el Anexo No 4.
Historias Nombre Descripción Estado
12
Lógica de carga de nodos y
relaciones
Se debe cargar en la ontología las asociaciones
entre los términos y el modelo de datos, para
que de esta manera independientemente del
autor de los datos del personaje la inf ormación
sea estructurada. Aprobada
13 Construcción de nodos
Acorde al modelo de datos registrado en la
ontología con la información recuperada de cada
personaje se debe validar si existen entidades
(nodos) que no existan, en dado que no lo esté
se debe extraer la información de esa entidad y
registrar sus datos. Aprobada
14 Construcción de relaciones
Acorde al modelo de datos registrado en la
ontología con la información recuperada de cada
personaje se deben relacionar cada una de las
entidades descritas con su respectiva
inf ormación asociada. Aprobada
Tab la 18 Historias de usuario cuarta iteración.
60
7.2.4.1.1. Lógica de carga de nodos y relaciones
La integración con el crawler “Uru” nos permite obtener una estructura de tipo JSON
con la información contenida de la página web del personaje en Wikipedia, a la cual
se realizan distintos tipos de procesamiento hasta su registro en la base de datos
Neo4j.
La información que es registrada en la base de datos Neo4j sigue el modelo de
datos almacenados en la ontología (Ver historia de usuario No 8), lo que permite
que para realizar cualquier modificación sobre la estructura de un tipo de nodo,
relación o atributo baste solamente con modificar la clave o valor relacionado en la
ontología almacenada en Redis.
Para la lógica de carga de nodos y relaciones fue necesario obtener la estructura
de datos almacenada en la ontología en un objeto de tipo JSON, tal como se
muestra en la Ilustración 21.
{ "person": {
"name": [], "webPage": [], "photo": [], "twitter": [], "religion": [], "facebook": [],"res iden… }, "party": {
"name": [] }, "site": { "birth": []
}, "family": { "spouse": [], "parent": [], "son": []
}, …
Ilustración 21 Estructura de datos de la ontología (Parte 1) (Diseño propio)
Luego fue necesario obtener de la ontología las palabras que generalizan un término
con el fin de poder establecer la ubicación de cada campo en la estructura, para lo
cual también se obtiene un objeto de tipo JSON como se muestra en la Ilustración
22
"sucesor": [
"family", "son" ], "residencia": [
"person", "residency" ],
61
"ascendiente": [ "family", "parent"
], "nombre": [ "person", "name" ],
… Ilustración 22 Estructura de datos de la ontología (Parte 2) (Diseño propio).
Con la estructura obtenida del crawler y de la ontología, se procede a realizar la
asignación de la información para luego realizar el registro los nodos y relaciones.
Ilustración 23 Pseudocódigo para la construcción de la estructura de información
del personaje (Diseño propio).
La Ilustración 24 muestra un ejemplo de la información obtenida de un personaje,
en la cual se encuentra información relacionada con la residencia, que es asignada
a la clave “person”, en la subestructura “residency”.
Información en la página
de Wikipedia
Información abstraída de la página por el crawler
"Información personal": {
"Rel igión": [ {
"URL": "https ://es.wikipedia.org/wiki/Iglesia_cat%C3%B3lica", "ti tle": "Iglesia católica" }
],
62
… "Residencia": [ {
"URL": "https://es.wikipedia.org/wiki/Casa_de_Nari%C3%B1o", "title": "Casa de Nariño" } ], ….
Información en la estructura de datos
JSON
{ "person": { "URL": "https ://es.wikipedia.org/wiki/Juan_Manuel_Santos", …
"residency": [ { "URL": "https://es.wikipedia.org/wiki/Casa_de_Nari%C3%B1o",
"title": "Casa de Nariño" }
], …
Ilustración 24 Información obtenida de la página procesada en la estructura (Diseño propio)
Cuando se termina la asignación de cada campo en la estructura de datos JSON se
procede a realizar la creación de los nodos y relaciones con la información obtenida,
para lo cual es necesario realizar validaciones de los objetos previamente creados
en la base de datos.
7.2.4.2. Construcción de nodos
Para el registro de un nodo lo primero que se validó fue su existencia en la base de
datos, dado que al estar relacionado con múltiples entidades o personajes puede
generar redundancia en la información, si el nodo no se encuentra en la base de
datos, se realiza la abstracción de la información de la página web relacionada,
después se realiza el procesamiento de limpieza de términos y se obtienen los datos
relacionados con el tipo de nodo acorde a la información obtenida en la ontología.
7.2.4.3. Construcción de relaciones
Para la creación de las relaciones primero se valida la existencia de los nodos
implicados para crearlos en caso de que estos nos existan, esto con el fin de obtener
siempre el identificador de cada uno de los nodos, luego con base en la información
de la ontología se establece qué tipo y atributos hacen parte de la relación (Ver
ilustración 23) , adicionalmente para los parámetros relacionados con fechas, se
realizó un cambio a formato Juliano (representación decimal de una fecha) [73] con
63
el fin de facilitar las posibles consultas que se realizan dado que el motor de base
de datos orientado a grafos no maneja las fechas como un tipo de dato especifico.
Ilustración 25 Proceso de creación de nodos y relaciones (Diseño propio).
7.2.4.2. Tareas de ingeniería
Las tareas de reingeniería relacionadas a la cuarta iteración (Ver Anexo No 4)
fueron:
Tarea
Historia de
usuario Nombre Estado
20 12 Implementación de funciones para la
obtención de sinónimos por cada término
Aceptada
64
21 13 Construcción de relaciones Aceptada
22 14 Carga de nodos Aceptada
Tab la 19 Tareas de ingeniería cuarta iteración.
La implementación de las tareas de ingeniería anteriormente mencionadas dio como
resultado:
7.2.4.2.1. Implementación de funciones para la obtención de sinónimos por
cada término.
Para no crear estructuras que almacenen todos los sinónimos al mismo tiempo, se
implementó la estrategia de asignar prefijos a las claves para de esta manera
obtener solo las que tienen alguna relación con el nodo o relación del que se deseen
consultar los términos asignados como sinónimos
Como estos datos fueron almacenados en REDIS con tipo de dato cadena al realizar
la consulta se obtiene un valor único por cada clave, por lo que se decidió almacenar
los resultados de la consulta en objetos JSON que manejan la misma estructuración
de la información clave - valor.
7.2.4.2.2. Construcción de relaciones.
Para las diferentes operaciones relacionadas con la base de datos Neo4j se realizó
la Implementación de una librería en Python con los métodos para la conexión,
registro y consulta en Neo4J por medio del lenguaje declarativo de consulta en
grafos Cypher.
Para la validación de las relaciones previamente ingresadas como no existe un
identificador desde el origen de los datos se implementó un método que valida que
entre dos nodos determinados no exista una relación del mismo tipo con atributos
iguales. Después de obtener el modelo de datos y las generalizaciones de términos
almacenados en la ontología, se utiliza la estructura obtenida del crawler con la
información del personaje para la asignación de la información en un objeto de tipo
JSON, el cual es usado para la creación de nodos y relaciones.
En el modelo de datos mencionado anteriormente se encuentran 6 tipo de
relaciones, en la tabla 20, se describe los nodos que hacen parte de cada relación
y los atributos que pueden ser asignados.
65
Relación Nodo adyacente Nodo incidente Atributos
Pertenece a Persona Partido político
Nació en Persona Lugar Fecha
Es f amiliar de Persona Persona Tipo
Depende de Organización Organización
Estudió en Persona Institución
Trabajó en Persona Organización Cargo
Fecha inicio
Fecha fin
Tab la 20 Relaciones en Neo4J (Diseño propio).
7.2.4.2.3. Construcción de nodos.
De las páginas de Wikipedia de personas y entidades relacionadas, se definió que
la aplicación maneja 5 tipos de nodos con los siguientes atributos:
Nodo Institución académica
Organización política.
Partido político.
Persona Lugar
Atributos
Imagen Siglas Nombre Lema Fecha de fundación. URL
Ámbito Fecha de fundación Jurisdicción Tipo Acrónimo Nombre Imagen
Fecha de fundación Sede Ideología Miembro de Posición URL Nombre Sitio web
Nombre Nacionalidad Religión Facebook Twitter Página web Ocupación Residencia
Nombre Gentilicio Imagen URL
Tab la 21 Tipos de nodo (Diseño propio)
Para la creación de los nodos, mediante los sinónimos de términos generales
descritos en la historia de usuario No 6, se establece a qué atributo y tipo de nodo,
se debe registrar el dato abstraído de la página web (Ver Ilustración 22)
Para la validación de nodos previamente ingresados, se tomó como identificador de
cada nodo la URL de la página dónde se obtuvo la información y se implementó un
método que permite verificar si ya existe un nodo con esa URL.
66
Información en la estructura
{ "person": { "URL": "https ://es.wikipedia.org/wiki/Juan_Manuel_Santos",
… "residency": [ { "URL": "https://es.wikipedia.org/wiki/Casa_de_Nari%C3%B1o", "title": "Casa de Nariño" } ],
…
Información almacenada en
base de datos
Tab la 22 Registro de la información abstraída (Diseño propio)
7.2.4.3. Pruebas de aceptación
Las pruebas de aceptación para esta iteración fueron las siguientes (Ver Anexo No
4):
Prueba
Historia de
usuario Nombre Estado
12 12 Carga de relación de términos y campos del nodo o relación Aceptada
13 12 Relación de términos con campos en nodos y relaciones Aceptada
14 12
Limpieza de los términos obtenidos en la extracción de la
inf ormación Aceptada
15 12 Comparación de términos con sus sinónimos Aceptada
16 13 Validación de la creación de nodos por cada tipo de nodo. Aceptada
17 13 Validación de la no duplicidad de nodos Aceptada
67
18 14
Validación de la creación de relaciones por cada tipo de
relación. Aceptada
19 14 Validación de la no duplicidad de relaciones Aceptada
Tab la 23 Pruebas de aceptación cuarta iteración.
7.2.5. Quinta iteración
Para la quinta iteración aparecen nuevas historias de usuario que se encuentran
descritas en la Tabla 24 con el desarrollo de cada una de las tareas de ingeniería y
pruebas de aceptación correspondientes. El objetivo de la quinta iteración es la
construcción e integración de la interfaz web con la lista de resultados de una
búsqueda realizada por el usuario y la interfaz web que visualiza el grafo del
personaje con sus respectivos nodos y relaciones.
7.2.5.2. Historias de usuario
La lista de las historias de usuario definidas para la quinta iteración se encuentra en
la Tabla 24. Toda la especificación de cada una de las historias de usuario se
encuentra en el Anexo 5.
Historias Nombre Descripción Estado
4 Construir servicio socket
Realizar un servicio socket de tipo bidireccional que permita enviar y recibir información entre Python y Node.js. Aceptada
15 Consultar lista de
personajes
La interfaz web v isualiza la lista de personajes almacenados en MongoDB que coincidan con el texto de búsqueda ingresado por el usuario
Aceptada
16 Consultar lista de
personajes sugeridos por
Wikipedia.
En la parte inferior de página web que visualiza la lista de personajes, aparece una lista de personajes que no se encuentran procesados por el sistema, pero que existen en Wikipedia con la opción de ser procesados por el aplicativo.
Aceptada
17
Visualizar grafo de
personajes
Desarrollar una interfaz web con las personas y distintas entidades relacionadas a un personaje seleccionado por el usuario a través de un grafo. En cada nodo y relación debe aparecer un cuadro descriptivo con información básica tanto de los nodos como de las relaciones.
Aceptada
Tab la 24 Historias de usuario de la quinta iteración
68
7.2.5.2.1. Construcción servicio socket
Esta historia de usuario es extendida de la primera iteración donde se crean dos
nuevos eventos. El primer evento es el canal donde envía la lista de sugerencias
que se obtiene de Wikipedia por medio del buscador de personajes (Ver Ilustración
26). El segundo evento envía un conjunto de configuraciones por tipo de nodo y de
relación que son utilizados en la construcción de filtros y estilos del grafo visualizado
en la interfaz web (Ver El segundo evento que envía el grafo en formato JSON del
personaje consultado en Neo4J (Ver Ilustración 27).
Ilustración 26 Evento de envío y recepción de personajes sugeridos por Wikipedia (Diseño propio).
69
Ilustración 27 Servicio de consulta del grafo de los personajes (Diseño propio).
7.2.5.2.2. Consultar lista de personajes
Para esta historia de usuario se construye la interfaz web que visualiza la lista de
personajes que se encuentran en MongoDB filtrados por medio del criterio de
búsqueda ingresado por el usuario. Por otro lado, se construye un componente web
donde aparece una lista de personajes que se encuentran en Wikipedia, pero no
han sido procesados por la aplicación.
7.2.5.2.3. Consultar lista de personajes sugeridos por Wikipedia
En esta historia de usuario se construye el componente web que se encarga de
visualizar una lista de personajes sugeridos por Wikipedia que no han sido
procesados por el aplicativo web. El aplicativo web se conecta con Wikipedia y trae
las todas las coincidencias que hacen parte de la lista de categorías almacenadas
en la ontología.
70
7.2.5.2.4. Visualizar grafo de personajes
El objetivo de esta historia de usuario es la construcción de la interfaz web que se
encargan de visualizar el grafo del personaje seleccionado donde se puede
visualizar los diferentes nodos y relaciones que se encuentran asociados al
personaje. Asimismo, la construcción de la interfaz web donde aparece la lista de
personajes procesados por el sistema que coinciden con un conjunto de palabras
ingresadas por el usuario.
7.2.5.3. Tareas de ingeniería
La lista de tareas de ingeniería realizadas en la quinta iteración se encuentra en la
Tabla 25. La descripción de cada una de las tareas de ingeniería aparece en el
Anexo No 5.
Tarea
Historia de
usuario Nombre Estado
23 5 Crear servicio de sugerencias API Wikipedia Aceptada
24 5 Crear servicio de consulta de configuraciones del grafo. Aceptada
25 15 Construir interfaz web lista de personajes Aceptada
26 15 Componente web de sugerencias de personajes no procesados Aceptada
27 16 Integrar buscador de personajes con lista de personajes Aceptada
28 17 Construir grafo Aceptada
29 17 Construir interfaz web v isualización del grafo Aceptada
30 17 Integrar visualización del grafo con lista de personajes Aceptada
Tab la 25 Tareas de ingeniería de la quinta iteración.
El desarrollo de todas las historias de usuario y tareas de ingeniería para la quinta
iteración dio como resultado:
7.2.5.3.1. Servicio de sugerencias API Wikipedia
La construcción de un servicio en el socket que se encarga de enviar y recibir de
Python a Node.js la lista de personajes sugeridos que se encuentran en Wikipedia
de acuerdo con el conjunto de caracteres que ingrese el usuario. En la Ilustración
28 se encuentra el pseudocódigo del servicio de sugerencias de los personajes. El
primer procedimiento es el evento del socket que se encarga de recibir y transmitir
las sugerencias. El segundo procedimiento se encarga de conectarse con Wikipedia
y obtener las sugerencias.
71
Ilustración 28 Servicio de sugerencia de personajes (Diseño propio).
7.2.5.3.2. Servicio de consulta de configuraciones del grafo
En esta tarea de ingeniería se construye un servicio de consulta de las
configuraciones de los tipos de nodo y relaciones que son utilizados en la
construcción de los filtros y estilos del grafo. Algunas de las configuraciones son los
colores, las consultas por cada filtro y las restricciones de búsqueda por
profundidad. En la Ilustración 29 se encuentra el pseudocódigo del evento
encargado de enviar las configuraciones.
Ilustración 29 pseudocódigo del servicio de consulta de configuraciones del grafo
7.2.5.3.3. Construcción interfaz web lista de personajes
Para esta tarea de ingeniería se desarrolla la construcción y diseño de las interfaces
de usuario que se encargan de mostrar la lista de personajes procesados por el
usuario y la lista de personajes sugeridos (Ver Ilustración 30).
72
Ilustración 30 Interfaz web lista de personajes (Diseño propio).
En la Tabla 26 se encuentra el esquema donde se detalla y explica las
funcionalidades de la interfaz web.
Número Descripción
1 Personaje procesado por el aplicativo web donde aparece su nombre y f otografía.
2 Botón encargado de redirigir a la página web de Wikipedia del personaje.
3 Botón encargado de redirigir a la página web que visualiza el grafo del personaje.
Tab la 26 Esquema de la interfaz web lista de personajes (Diseño propio).
7.2.5.3.4. Componente web de sugerencias de personajes no procesados
Para esta tarea de usuario se construye un componente web donde aparece una
lista de personajes que se encuentran en Wikipedia, pero no han sido procesados
por la aplicación. Este servicio de sugerencia de personajes es asíncrono ya que va
apareciendo en la interfaz cada una de las sugerencias a medida que va verificando
la existencia del personaje en la base de datos del aplicativo. En la Ilustración 31 se
encuentra el componente web que sugiere personajes con algunos ejemplos y su
esquema correspondiente (Ver Tabla 27).
73
Ilustración 31 Lista de sugerencias (Diseño propio).
Número Descripción
1 Personaje sugerido por Wikipedia que no ha sido procesado por el aplicativo web. Por cada personaje aparece el nombre y su fotografía.
2
Enlace web que se encarga de disparar el flujo de trabajo de extracción, procesamiento y construcción del grafo del personaje por medio de la inf ormación disponible en Wikipedia.
Tab la 27 Esquema lista de sugerencias (Diseño propio)
7.2.5.3.5. Integración del buscador de personajes con lista de personajes
La construcción de un componente web similar al buscador de personajes que
permita también realizar búsquedas desde la misma interfaz que visualiza la lista de
personajes. En la Ilustración 32 se encuentra el componente web del buscador de
personajes con su esquema correspondiente (Ver Tabla 28).
Ilustración 32 Componente buscador de personajes simplificado (Diseño propio)
Número Descripción
1 Caja de texto donde se ingresa el personaje solicitado por el usuario.
2 Botón que se encarga de realizar la búsqueda de personajes a través de los parámetros ingresados en la caja de texto.
Tab la 28 Esquema buscador de personajes simplificado (Diseño propio)
74
La Ilustración 33 visualiza la integración a la interfaz web que visualiza la lista de
personajes también con su esquema (Ver Tabla 29).
Ilustración 33 Integración buscador de personajes simplificado (Diseño propio)
Número Descripción
1 Caja de texto donde se ingresa el personaje solicitado por el usuario.
2 Botón que se encarga de realizar la búsqueda de personajes a través de los parámetros ingresados en la caja de texto.
Tab la 29 Esquema de la integración del buscador de personajes simplificado (Diseño propio)
7.2.5.3.6. Construcción del grafo
Para esta tarea de ingeniería se implementa la construcción del grafo de cada
personaje a través de la librería de JavaScript D3 (Data-Driven-Documents) [74]
donde se realiza una consulta a la base de datos Neo4j de los nodos y relaciones
asociados al personaje solicitado. En la Ilustración 34 se incluye un ejemplo del
grafo construido con D3 y en la Tab la 30 se encuentra un esquema donde detalla
las características del grafo. En la Ilustración 35 se incluye un ejemplo de la
estructura tipo JSON que recibe el componente JavaScript de D3 para construir el
grafo. La estructura recibe una lista de nodos con un identificador único, una URL y
el nombre del nodo y una lista de relaciones donde se encuentra un identificador
único, el tipo de relación el nodo origen y el nodo destino de la relación.
75
Ilustración 34 Visualización del grafo (Diseño propio).
Número Descripción
1 Identifica al nodo del grafo donde el color define el tipo. Cada tipo de nodo puede definir una persona, una institución, organización o lugar.
2 Def ine el nombre del nodo. Puede ser el nombre de una persona, de una institución, organización o lugar.
3 Def ine la relación entre dos nodos y el tipo. Puede ser una relación f amiliar, académica, de trabajo, entre otros.
Tabla 30 Esquema del grafo (Diseño propio)
{ "nodes": [ {
"id": 1, "URL": "https://es.wikipedia.org/wiki/Juan_Manuel_Santos", "name": "Juan Manuel Santos"
}, { "id": 2, "URL": "https://es.wikipedia.org/wiki/%C3%81lvaro_Uribe",
"name": "Álvaro Uribe" } ],
76
"l inks": [ {
"id": 1, "type": 3, "source": 1, "tarjet": 2
} ] }
Ilustración 35 Estructura del grafo para D3 (Diseño propio)
7.2.5.3.7. Construcción de la interfaz web visualización del grafo
Finalmente, para esta tarea de ingeniería se desarrolla la construcción y diseño de
la interfaz de usuario que se encarga de visualizar el grafo de un personaje con sus
correspondientes nodos y relaciones (Ver Ilustración 36). En la Tabla 31 se
encuentra el esquema de la interfaz web.
Ilustración 36 Interfaz web visualización del grafo (Diseño propio).
Número Descripción
1 Personaje al que se quiere visualizar el grafo.
2 Grafo del personaje donde se visualiza las relaciones entre personas, instituciones, organizaciones o lugares.
Tab la 31 Esquema interfaz web visualización del grafo (Diseño propio)
77
7.2.5.4. Pruebas de Aceptación
La lista de pruebas de aceptación que se realizaron en la quinta iteración se
encuentra en la Tabla 32. Cada prueba de aceptación se realiza de acuerdo con las
diferentes condiciones y pasos descritos en el Anexo No 5.
Prueba
Historia de
usuario Nombre Estado
20 4 Consultar lista de personajes Aceptada
21 16 Consultar lista de personajes sugeridos Aceptada
22 17 Consultar grafo de personaje Aceptada
Tab la 32 Pruebas de aceptación de la quinta iteración
7.2.6. Sexta iteración
El objetivo de la última iteración es la construcción de las páginas informativas del
sitio web como lo son: la página de contacto, la página informativa del grupo de
investigación y de los integrantes que hacen parte del proyecto y una página web
que explica el funcionamiento del aplicativo. Asimismo, se añaden filtros al grafo del
personaje de los distintos tipos de nodo que fueron definidos para la ontología.
7.2.6.2. Historias de usuario
La lista de las historias de usuario definidas para la sexta iteración se encuentra en
la Tabla 33. Toda la especificación de cada una de las historias de usuario se
encuentra en el Anexo No 6.
Historias Nombre Descripción Estado
18
Interfaces gráficas
inf ormativas
Crear las interfaces gráficas de contacto, información del grupo de inv estigación y f uncionamiento del aplicativ o web. Aceptada
19 Filtro nodos
Dentro del mismo componente web que v isualiza el grafo del personaje seleccionado, crear un componente web que permita f iltrar los tipos de nodos que el usuario desea v er dentro del grafo. Aceptada
20 Filtro de camino entre nodos
Crear un componente web que permita seleccionar desde dos hasta n nodos de tipo persona para filtrar los caminos disponibles entre dichos nodos Aceptada
21
Visualizar información básica
del nodo y relación
Crear un componente web que despliegue la inf ormación básica de un nodo o una relación al ser seleccionado. Aceptada
Tab la 33 Historias de usuario de la sexta iteración.
78
7.2.6.2.1. Interfaces gráficas informativas
Para esta historia de usuario se construyen e integran las interfaces graficas
informativas al aplicativo. La página web de contacto tiene un formulario básico
donde se solicita el correo electrónico, el nombre de la persona y una pequeña
descripción con el motivo de contacto. La página web del grupo de investigación
tiene una pequeña reseña histórica del grupo, las áreas de trabajo y los integrantes
del proyecto. Finalmente, la página de funcionamiento del aplicativo describe las
funciones básicas del aplicativo web.
7.2.6.2.2. Filtro de nodos
Para esta historia de usuario se añaden filtros al grafo del personaje de los distintos
tipos de nodo que fueron definidos para la ontología. El usuario puede realizar el
filtro seleccionando que tipos de nodo quiere visualizar en el grafo. Además, para el
nodo tipo persona se añade un filtro de profundidad que es la distancia máxima
desde un nodo base o raíz hasta un nodo que se encuentra implícitamente
relacionado por medio de otros nodos. En este caso el nodo raíz es el nodo del
personaje consultado.
7.2.6.2.3. Filtro de camino entre nodos
Con esta historia se realiza un filtro de caminos entre nodos el cual permite mostrar
todos los caminos existentes entre un conjunto de nodos de tipo persona
seleccionados por el usuario.
7.2.6.3. Tareas de ingeniería
La lista de tareas de ingeniería realizadas en la sexta iteración se encuentra en la
Tabla 34. La descripción de cada una de las tareas de ingeniería aparece en el
Anexo No 6
Tarea
Historia de
usuario Nombre Estado
31 18 Construir página web de contacto Aceptada
32 18 Construir página web informativa del grupo Aceptada
33 18 Construir página web de funcionamiento del aplicativo Aceptada
34 18 Integrar páginas web con panel de navegación Aceptada
35 19 Construir componente web de filtro de nodos Aceptada
36 19 Construir consultas de filtros Aceptada
37 19 Obtener estructura de nodos Aceptada
38 19 Integrar filtro con grafo página de visualización del grafo Aceptada
79
39 20 Construir componente web camino entre nodos Aceptada
40 20 Construir consulta filtro de nodos Aceptada
41 20 Seleccionar nodos del grafo Aceptada
42 20
Integrar componente web con página de visualización del
grafo Aceptada
43 21 Visualizar información básica del nodo Aceptada
44 21 Visualizar información básica de la relación Aceptada
Tab la 34 Tareas de ingeniería de la sexta iteración
Finalizada la última iteración con el desarrollo de todas las historias de usuario y
tareas de ingeniería para la sexta iteración se obtuvo:
7.2.6.3.1. Construir página web de contacto
En esta tarea de ingeniería se desarrolla una página web del sistema donde
cualquier persona interesada puede contactar con el grupo de investigación a través
de un correo electrónico con datos básicos de la persona y el motivo de contacto
(Ver Ilustración 37). En la Tabla 35 se encuentra el esquema de página web de
contacto.
Ilustración 37 Página web de contacto (Diseño propio).
Número Descripción
1 Caja de texto donde se ingresa el correo electrónico del usuario 2 Caja de texto donde se ingresa el nombre del usuario
3 Caja de texto donde se ingresa el motivo o asunto 4 Botón que envía la información del formulario.
Tab la 35 Esquema página web de contacto (Diseño propio)
80
7.2.6.3.2. Construcción página web informativa del grupo
La construcción de una página web informativa del grupo de investigación y
miembros participantes en el proyecto. En Ilustración 38 se encuentra una reseña
del grupo de investigación, en la Ilustración 39 se encuentran las áreas de
conocimiento del grupo de investigación y en la Ilustración 40 se encuentran los
miembros participantes en el proyecto.
Ilustración 38 Reseña del grupo de investigación (Diseño propio)
Ilustración 39 Áreas de conocimiento del grupo de investigación (Diseño propio).
81
Ilustración 40 Miembros participantes del proyecto (Diseño propio).
7.2.6.3.3. Construir página web de funcionamiento del aplicativo
En esta tarea de ingeniería se crea una página web que explica cómo funciona el
aplicativo web y las principales funciones de dicho sitio. En la Tabla 36 se encuentra
el esquema de la página web.
Ilustración 41 Pagina web de funcionamiento del aplicativo (Diseño propio).
82
Número Descripción
1 Vídeo que explica aspectos generales del aplicativo web.
2 Botón que descarga el manual de usuario del aplicativo web en formato PDF
Tab la 36 Esquema de página web de funcionamiento del aplicativo
7.2.6.3.4. Integrar páginas web con panel de navegación
En esta tarea de ingeniería se realiza la construcción de un panel de navegación y
se enlazan las páginas web informativas con dicho panel de navegación (Ver
Ilustración 42). En la Tabla 37 se detalla el esquema del panel de navegación del
aplicativo.
Ilustración 42 Panel de navegación del aplicativo (Diseño propio)
Número Descripción
1 Enlace que redirige a la página principal del aplicativo web
2 Enlace que redirige a la página web informativo del grupo 3 Enlace que redirige a la página web de contacto 4 Enlace que redirige a la página web de funcionamiento del aplicativo
Tab la 37 Esquema del panel de navegación del aplicativo (Diseño propio).
7.2.6.3.5. Construcción componente web de filtro de nodos
La construcción de un componente web que permite filtrar y consultar los distintos
tipos de nodo del grafo de cada personaje. Cuando se hace click en un nodo o
relación del grafo del personaje se despliega una modal o popup con información
básica del nodo o relación que ha sido seleccionado por el usuario. En la Ilustración
43 aparece el componente de software con los filtros del grafo. Los nodos con el
icono “checked” significan los tipos de nodos donde se realizará el filtro. El nivel se
refiere al nivel de profundidad en la búsqueda entre los nodos, la profundidad está
definida de 1 a 10. La Ilustración 43 y la Tabla 38 visualizan el esquema de los filtros
definidos para el sistema y cómo se ve reflejado en el grafo resultante.
83
Ilustración 43 Filtros del grafo del personaje (Diseño propio).
Número Descripción
1 Checkbox para seleccionar los tipos de nodos que quieren ser visualizados en el grafo.
2 Slider para seleccionar el nivel de profundidad de búsqueda entre los tipos de nodos. El nivel se encuentra dentro del tango 1-10.
3
Switch para activar o desactivar la selección de nodos. Este componente permite realizar la búsqueda de caminos dentro un conjunto de nodos seleccionados por el usuario.
4 Botón que permite actualizar el grafo del personaje a partir del conjunto de f iltros seleccionados por el usuario.
4.1 Grafo resultante de acuerdo a los filtros aplicados
Tab la 38 Esquema filtros del grafo del personaje (Diseño propio)
7.2.6.3.6. Construcción consultas de filtros
Para esta tarea de ingeniería se construyen las consultas de Neo4j y
configuraciones necesarias por cada tipo de filtro para el componente de software.
En la Ilustración 44 se encuentra un ejemplo de la consulta para el nodo tipo persona
con sus configuraciones correspondientes.
{
"person": { "relation": { "family": { "scrolleable": 1,
84
"query": "MATCH (a {URL:?URL})-[r:family*1..?scrolleable]->(i) RETURN a,r,i" }
}, "color": "#F44336" }, "site": {
"relation": { …
Ilustración 44 Configuraciones de filtro por tipo de nodo (Diseño propio)
7.2.6.3.7. Integración filtro con grafo página de visualización del grafo
Con esta tarea de ingeniería se realiza integración del componente filtro con el
componente visualizar del grafo (Ver Ilustración 45).
Ilustración 45 Interfaz web visualización del grafo integrada con el filtro (Diseño propio)
Número Descripción
1 Componente de filtros integrados a la interfaz web
2 Integración del grafo con los filtros
Tab la 39 Esquema de la integración de los filtros con interfaz web de visualización del grafo (Diseño propio)
85
7.2.6.3.8. Construcción componente web camino entre nodos
Un componente web que permite seleccionar un conjunto de nodos elegidos por el
usuario, donde se visualiza todos los caminos que unen el conjunto de nodos. El
nuevo grafo se visualiza a través de una modal que se despliega de manera
automática. La Ilustración 46 visualiza los nodos que fueron seleccionados por el
usuario, aquellos nodos seleccionados se encuentran coloreados en su totalidad
con el color rojo (Esquema de la interfaz web en la Tabla 40). En la Ilustración 47
se encuentran los caminos encontrados entre los nodos seleccionados por el
usuario de la Ilustración 46.
Ilustración 46 Nodos seleccionados por el usuario (Diseño propio).
Número Descripción
1 Switch que activa la funcionalidad de seleccionar los nodos (En este caso los nodos tipo persona)
2
Luego de activar el switch el usuario puede seleccionar los nodos persona (nodos de color rojo). Al seleccionar el nodo se rellena completamente de color rojo
3 Botón que despliega para este caso una modal con los caminos encontrados entre el conjunto de nodos seleccionados por el usuario
3.1
Grafo resultante de la búsqueda de caminos entre nodos de acuerdo con el conjunto de nodos que seleccionó previamente el usuario (Ver Ilustración 47)
Tab la 40 Esquema para de selección de nodos (Diseño propio)
86
Ilustración 47 Caminos encontrados con los nodos seleccionados en Ilustración 46
(Diseño propio).
7.2.6.3.9. Visualizar información básica del nodo
Para esta historia de usuario se desarrolla de un componente web que visualiza la
información de un nodo que fue recolectada y procesada por el aplicativo. Sobre el
grafo es posible realizar click y el aplicativo despliega una modal con la información
de dicho nodo (Ver Ilustración 47). En la Tabla 41 se encuentra el esquema de la
Ilustración 48.
87
Ilustración 48 Información básica por nodo (Diseño propio).
Número Descripción
1 Nodo donde se realiza click para desplegar su información básica.
1.1 Nombre del nodo 1.2 Inf ormación básica del nodo.
Tab la 41 Esquema visualización información básica por nodo (Diseño propio).
7.2.6.3.10. Visualizar información básica de la relación
Para esta historia de usuario se desarrolla de un componente web que visualiza la
información de una relación. En el grafo es posible realizar click sobre la relación y
el sistema despliega una modal con la información de la relación (Ver Ilustración
49Ilustración 47). En la Tabla 42 se encuentra el esquema de la Ilustración 49.
88
Ilustración 49 Información básica por relación (Diseño propio)
Número Descripción
1 Relación donde se realiza click para desplegar su información básica.
1.1 Nombre del nodo fuente y nombre del nodo destino 1.2 Inf ormación básica de la relación.
Tab la 42 Esquema visualización de información básica por relación (Diseño propio)
7.2.6.4. Pruebas de Aceptación
La lista de pruebas de aceptación que se realizaron la última iteración se encuentra
en la Tabla 43. Cada prueba de aceptación se realiza de acuerdo con las diferentes
condiciones y pasos descritos en el Anexo No 6
Prueba
Historia de
usuario Nombre Estado
23 17 Env iar solicitud de contacto Aceptada
24 17 Visualizar página web informativa del grupo Aceptada
25 17 Visualizar página de funcionamiento del grupo Aceptada
89
26 18 Realizar f iltro de nodos Aceptada
27 19 Realizar f iltro de caminos entre nodos Aceptada
Tab la 43 Pruebas de aceptación de la sexta iteración
90
8. EXPERIMENTACIÓN
En esta sección se describe el trabajo experimental que verifica el funcionamiento
de la herramienta. Para ello se obtuvo un listado de nombres de personajes a partir
de un árbol de categorías de Wikipedia asociadas con aspectos de la política
colombiana. Luego, por cada personaje del listado se extractó la información de las
páginas, su relación con otras entidades y personas resultado del procesamiento
del aplicativo. A continuación, se describe el proceso realizado y los resultados
obtenidos.
8.2. COLECCIÓN DE PRUEBA
El listado de los personajes para realización de pruebas se obtuvo por medio del
recorrido de cada una de las categorías en Wikipedia donde se extraían todas las
paginas asociadas a un personaje (un total de un total de 3450 páginas) (Ver Tabla
44). Para algunos casos las páginas se repetían debido a que pueden pertenecer a
más de una categoría que se encuentra dentro del árbol de categorías recolectado.
Por lo tanto, el algoritmo recolector de personajes verifica que el personaje no se
encuentre dentro de la lista de prueba (Obteniendo 1246 páginas sin repetición).
Categorías Cantidad de enlaces
encontrados
Políticos de Colombia 464
Políticos del Partido Liberal Colombiano 164
Políticas de Colombia 134
Políticos del Partido Conservador Colombiano 133
Políticos de Bogotá 116
Senadores de Colombia 2006-2010 113
Senadores de Colombia 2014-2018 103
Presidentes de Colombia 100
Políticos católicos de Colombia 81
Senadores de Colombia 2010-2014 79
Tab la 44 Categorías con mayor número de páginas encontradas (Diseño propio).
Con el listado recolectado se eliminaron las páginas que no hacían referencia a un
personaje en particular o que se encontraban en construcción y por tanto no
contienen información para ser analizada. Como resultado se obtuvo un listado con
863 personas, las cuales fueron procesadas a través del crawler y guardadas en las
bases de datos.
91
8.3. PRUEBAS DE RENDIMIENTO
UMA UD es una herramienta que realiza la búsqueda de páginas web, el
procesamiento y registro de los resultados en las bases de datos. Para ello, es
necesario verificar el rendimiento en tiempos de respuesta con respecto a los
usuarios finales. El tiempo que se tarda la aplicación en obtener la información de
un personaje depende de las páginas que recorre el crawler, por esto se realizó la
extracción de 863 páginas de personajes desde un solo usuario para obtener un
tiempo promedio, para lo que se utilizó un servidor con sistema operativo Linux
16.04, memoria RAM de 4GB y un ancho de banda de 10Mb/s, con lo que se obtuvo
como resultado un promedio de 1.087 segundos por página, sin un incremento
notable en el uso de memoria o procesador por lo que se considera que el
rendimiento de la herramienta depende principalmente del ancho de banda del
servidor.
8.4. PRUEBAS DE EXTRACCIÓN DE LA INFORMACIÓN.
Al realizar el procesamiento de cada uno de los personajes en la lista se obtuvo la
información de la página y las relaciones con otras personas a las que se ejecutó el
mismo proceso recursivamente. Como resultado en la base de datos se registraron
1047 nodos (Ver Tabla 45), los cuales en su mayoría eran de tipo “person”, 863 que
hacían parte de la lista y 184 que se obtuvieron al tener relación de tipo familiar con
algún personaje.
Tipo de nodo Descripción Cantidad
Person Personas 1128
Institution Instituciones académicas 145
Organization Organizaciones 277
Party Partidos políticos 13
Site Lugares (Departamentos/ Municipios) 371
Tab la 45 Cantidad de nodos ob tenidos (Diseño propio)
132 páginas no contaban con información estructurada, es decir las páginas solo
contaban con una reseña de la vida del personaje por lo que en el crawler solo se
obtiene una cadena de texto con la información del personaje. Por otro lado, si la
información se encontraba estructurada en el objeto obtenido por el crawler, pero
no existían direcciones web a otras páginas web no se puede establecer las
relaciones con otras personas o entidades existentes.
La cantidad de atributos obtenidos por cada nodo se describe en la Tabla 46
92
Tipo de nodo Atributo Cantidad
Institución
académica
Imagen 59
Siglas 74
Nombre 145
Lema 145
Fecha de fundación 20p
URL 145
Organización
política.
Ámbito 5
Fecha de fundación 75
Jurisdicción 50
Tipo 37
Acrónimo 49
Nombre 277
Imagen 135
Partido político.
Fecha de fundación 13
Sede 13
Ideología 13
Miembro de 3
Posición 12
URL 13
Nombre 13
Sitio web 13
Persona
Nombre 1047
Nacionalidad 738
Religión 245
Facebook 29
Twitter 68
Página web 169
Ocupación 761
Residencia 310
image 472
URL 1047
Lugar
Nombre 371
Gentilicio 304
Imagen 371
URL 371
Tab la 46 Cantidad de atributos por cada tipo de nodo (Diseño propio)
93
Las relaciones que se obtuvieron del procesamiento de la lista se encuentran
registradas en la Tabla 47
Tipo de relación Cantidad
Pertenece a 504
Nació en 2008
Es f amiliar de 374
Depende de 300
Estudió en 615
Trabajó en 1349
Tab la 47 Cantidad de relaciones por cada tipo (Diseño propio).
La cantidad de atributos por cada tipo de relación se encuentran en la Tabla 48
Relación Atributos Cantidad
Pertenece a N/A N/A
Nació en Fecha 1545
Es f amiliar de Tipo 374
Depende de N/A N/A
Estudió en N/A N/A
Trabajó en Cargo 1349
Fecha inicio 1349
Fecha fin 1349
Tab la 48 Cantidad de atributos por cada tipo de relación (Diseño propio).
8.5. PRUEBAS DE USUARIO FINAL
Con el fin de conocer la funcionalidad de la herramienta en usuarios finales se
hicieron pruebas 15 personas a las cuales se les solicitó que realizaran la búsqueda
5 personajes de la política colombiana a su preferencia, con lo cual se obtuvieron
los siguientes resultados.
94
Los personajes que escogieron los usuarios se pueden ver en la Tabla 49.
Identificando que la mayoría de los usuarios escogieron los mismos personajes.
Personaje Cantidad
Antanas Mockus 10
Sergio Fajardo 9
Claudia López 8
Gustavo Petro 8
Álv aro Uribe Vélez 5
Tab la 49 Personajes más buscados por los usuarios (Diseño propio).
Con respecto a los tiempos de respuesta de la aplicación, los resultados fueron
satisfactorios (menos de un segundo) dado que todos los personajes que fueron
consultados por los usuarios se encontraban previamente cargados.
Para validar la satisfacción de los usuarios al consultar la información de cada uno
de los personajes, se les preguntó de las 5 consultas que realizaron cuales
contenían la información que esperaban (Ver Ilustración 50), encontrando que a los
usuarios les gustaría encontrar más información de cada personaje a pesar de que
no se encuentre publicado en Wikipedia.
Ilustración 50 Cantidad de páginas con la información esperada (Diseño propio)
0%
7%
27%
53%
13%
Cantidad de páginas con la información esperada
1
2
3
4
5
95
Al preguntar a los usuarios acerca de la utilidad de la herramienta la mayoría contestó que les parecía útil (Ver Ilustración 51). Sin embargo, algunos consideraron
que es necesario que la herramienta consulte más fuentes para poder obtener más
información de ciertos personajes.
Ilustración 51 Utilidad de la herramienta (Diseño propio).
27%
73%
Utilidad de la herramienta
si
no
96
9. TRABAJO FUTURO
A pesar de que la mayoría de personajes de la política colombiana cuentan con
páginas en Wikipedia, no se obtiene la totalidad de las relaciones dado que no
contienen enlaces a otras personas o entidades. Por lo tanto, para obtener más
información y realizar un mejor análisis de las relaciones es necesario que la
información de las páginas que se encuentre en Wikipedia contenga un mayor grado
de detalle.
Para las páginas que solo cuentan con una reseña del personaje (sin enlaces), se
pueden utilizar técnicas propias de lenguaje natural y la inteligencia artificial que
permita procesar los textos con el fin de obtener nuevos nodos y relaciones
asociados al personaje.
La única fuente de información del aplicativo web es Wikipedia. Se puede ampliar
la información de cada personaje a través de otros medios o fuentes de información
como: hojas de vida públicas en internet, redes sociales, páginas gubernamentales
o sitios web propios de los personajes.
Dentro del alcance de la ontología solo consulta, extrae y procesa información de
personajes de la política colombiana. Se podría añadir nuevas categorías para
extraer información de personajes de otros contextos de Wikipedia como: políticos
de otros países, famosos, académicos, deportistas, entre otros. Por ende, se
extiende y vuelve más robusta la funcionalidad del aplicativo.
97
10. CONCLUSIONES
El modelo de la base de datos orientada a grafos, los términos generalizadores, las
correlaciones para la extracción de la información y consultas para la obtención de
grafos se encuentran registrados en la ontología, para extender las funcionalidades
de la aplicación es necesario agregar nueva información.
La aplicación utiliza un crawler que realiza un proceso de extracción descargando
páginas web y procesando su contenido, por lo que depende altamente de la
conexión de internet y ancho de banda.
A pesar de que Wikipedia busca que la información de las páginas sigue una
estructura estándar, muchas páginas necesitan un mayor grado de detalle. Por lo
tanto, cada vez que los usuarios ingresan nueva información a Wikipedia sirve como
insumo para el aplicativo web.
Con la base de datos orientada a grafos se pueden buscar patrones de
comportamiento entre las personas y entidades que son inmediatas como aquellas
que no son obvias y que pueden dar a conocer aspectos recurrentes del gobierno
de nuestro país [72].
La información presentada en la aplicación ayuda a conocer el contexto de la política
colombiana, identificando la relación que tienen las entidades académicas y
gubernamentales con la información personal y familiar de cada personaje, por lo
que puede ser de gran interés para trabajos académicos relacionados con política,
periodismo o cualquier usuario que quiera conocer información más detallada de un
personaje.
Se pueden incluir diferentes bases de datos con diferentes objetivos, con el fin de
no recargar las consultas y disminuir tiempos de respuesta. Las bases de datos
orientada a grafos son totalmente aplicables a modelos de negocio cambiantes por
su flexibilidad para la creación de nuevos nodos y relaciones, con el fin de disminuir
tiempos es posible incluir bases en memoria en la capa de presentación.
98
11. REFERENCIAS
[1] D. Lizorkin, O. Medelyan, and M. Grineva, “Analysis of community structure in Wikipedia,” Proc. 18th Int. Conf. World wide web WWW 09, vol. 14, No August,
p. 1221, 2009.
[2] X. Zhang, Y. Asano, and M. Yoshikawa, “A generalized flow-based method for analysis of implicit relationships on wikipedia,” IEEE Trans. Knowl. Data Eng.,
vol. 25, No 2, pp. 246–259, 2013.
[3] V. Hardik, V. Anirudh, and P. Balaji, “Link Analysis of Wikipedia Documents Using MapReduce,” Inf. Reuse Integr. (IRI), 2015 IEEE Int. Conf., pp. 582–
588, 2015.
[4] D. P. T. Nguyen, “Relation Extraction from Wikipedia Using Subtree Mining,” Artif. Intell., vol. 22, No April, pp. 1414–1420, 2007.
[5] Z. Baoyao, L. Ping, X. Yuhong, and L. Wei, “Wikipedia-graph based key concept extraction towards news analysis,” 2009 IEEE Conf. Commer. Enterp. Comput. CEC 2009, pp. 121–128, 2009.
[6] R. P. Biuk-Aghai and K. K. Ng, “A method for automated document classification using Wikipedia-derived weighted keywords,” Proc. 2014 Int.
Conf. Data Softw. Eng. ICODSE 2014, pp. 0–5, 2014.
[7] N. Bloom, B. V Pagelink, and F. De Jong, “Document Categorization using Multilingual Associative Networks based on Wikipedia,” pp. 841–846.
[8] G. Wu, M. Harrigan, and P. Cunningham, “Characterizing Wikipedia pages using edit network motif profiles,” Proc. 3rd Int. Work. Search Min. user-generated contents - SMUC ’11, p. 45, 2011.
[9] F. Author and S. Author, “With a Little Help from my Neighbors : Person Name
Disambiguation Using the Wikipedia Social Network,” pp. 985–990, 2006.
[10] J. Geiß, A. Spitz, and M. Gertz, “Beyond Friendships and Followers: The Wikipedia Social Network,” Adv. Soc. Networks Anal. Min., pp. 472–479, 2015.
[11] F. Nazir and H. Takeda, “Extraction and analysis of tripartite relationships from Wikipedia,” Int. Symp. Technol. Soc. Proc., 2008.
[12] P. Sinclair, P. Lewis, and K. Martinez, “Dynamic Link Service 2 . 0 : using Wikipedia as a linkbase Categories and Subject Descriptors,” pp. 161–162, 2003.
[13] M. Pei, K. Nakayama, T. Hara, and S. Nishio, “Constructing a global ontology
99
by concept mapping using Wikipedia thesaurus,” Proc. - Int. Conf. Adv. Inf.
Netw. Appl. AINA, pp. 1205–1210, 2008.
[14] D. Torres, P. Molli, H. Skaf-Molli, and A. Diaz, “From DBpedia to Wikipedia: Filling the gap by discovering Wikipedia conventions,” Proc. - 2012 IEEE/WIC/ACM Int. Conf. Web Intell. WI 2012, pp. 535–539, 2012.
[15] A. Nadamoto, “Gist of a Thread in Social Network Services B ased on C redibility o f Wikipedia,” pp. 1–10, 2011.
[16] Y. J. Han, S. Y. Park, S. B. Park, Y. H. Lee, and K. Y. Kim, “Reconstruction of people information based on an event ontology,” IEEE NLP-KE 2007 - Proc. Int. Conf. Nat. Lang. Process. Knowl. Eng., pp. 446–451, 2007.
[17] E. Ben Ahmed, “ONTOSSN : Scientific Social Network ONTOlogy,” pp. 3–6, 2014.
[18] I. G. S. Rahayuda and N. P. L. Santiari, “Crawling and cluster hidden web using crawler framework and fuzzy-KNN,” 2017 5th Int. Conf. Cyber IT Serv.
Manag. CITSM 2017, 2017.
[19] R. Q. W. Ojrulwkp, D. Rq, H. P. Frp, H. P. O. X. Frp, H. P. Jmg, M. M. S. Zkx,
H. G. X. Fq, and H. P. T. T. Frp, “Research on text mining algorithm based on focused crawler,” No Iccse, pp. 454–457, 2017.
[20] Z. Zheng and D. Quian, “An Improved Focus Crawler Based on Keyword Extrction,” pp. 386–390, 2016.
[21] X. Diao, “Research of focused crawler for financial social network,” Proc. 2016 5th Int. Conf. Comput. Sci. Netw. Technol. ICCSNT 2016, pp. 608–611, 2017.
[22] A. Amalia, D. Gunawan, A. Najwan, and F. Meirina, “Focused crawler for the acquisition of health articles,” Proc. 2016 Int. Conf. Data Softw. Eng. ICoDSE 2016, 2017.
[23] D. Ganesh Chandra, “BASE analysis of NoSQL database,” Futur. Gener. Comput. Syst., vol. 52, pp. 13–21, 2015.
[24] M. a. Mohamed, O. G. Altrafi, and M. O. Ismail, “Relational vs. NoSQL databases: A survey,” Int. J. Comput. Inf. Technol. (IJCIT ), vol. 3, No 3, pp.
598–601, 2014.
[25] J. Bhogal and I. Choksi, “Handling Big Data Using NoSQL,” Proc. - IEEE 29th
Int. Conf. Adv. Inf. Netw. Appl. Work. WAINA 2015, pp. 393–398, 2015.
[26] R. Kaliyar, “Graph Databases : A Survey,” Int. Conf. Comput. Commun.
100
Autom., pp. 785–790, 2015.
[27] R. Jain, S. Iyengar, and A. Arora, “Overview of popular graph databases,” 2013 Fourth Int. Conf. Comput. Commun. Netw. Technol., pp. 1–6, 2013.
[28] F. Zarrinkalam, M. Kahani, and S. Paydar, “Using graph database for file recommendation in PAD social network,” Telecommun. (IST), 2014 7th Int. Symp., pp. 470–475, 2014.
[29] S. Miyokawa, T. Tokuda, and S. Yamaguchi, “Elasticity Improvement of Cassandra,” Proc. 10th Int. Conf. Ub iquitous Inf. Manag. Commun., p. 37:1--
37:7, 2016.
[30] a Salminen and F. W. Tompa, “Requirements for XML document database systems,” Proc. 2001 ACM Symp. Doc. Eng., pp. 85–94, 2001.
[31] F. González, Redes sociales y comunidades educativas. 2008.
[32] S. Wasserman, K. Faust, and M. Grannovetter, Social Network Analysis:
Methods and Applications, vol. 8. 1994.
[33] J. J. Prieto Gutiérrez, “Herramientas para el análisis y monitoreo en Redes Sociales,” IRIE. Int. Rev. Inf. Ethics, vol. 16, No 181, pp. 33–40, 2011.
[34] S. Ordoñez, “Representación computacional Del Lenguaje Natural Escrito,”
vol. 15, No 1, pp. 6–21, 2010.
[35] Jaime Carbonell, “El procesamiento del lenguaje natural, tecnología en transición,” Congreso de Sevilla, 1992. [Online]. Available:
http://cvc.cervantes.es/obref/congresos/sevilla/tecnologias/ponenc_carbonell
.htm.
[36] M. A. Niño Barón and S. Ordoñez Salinas, “Identificación de relaciones entre los nodos de una red social,” Ingeniería, vol. 18, No 1, p. 2, 2013.
[37] M. Osborne and C. K. MacNish, “Processing natural language software requirement specifications,” Proc. Second Int. Conf. Requir. Eng., pp. 229–
236, 1996.
[38] I. Sommerville and M. I. A. Galipienso, Ingeniería del software, Séptima.
Madrid: Pearson Educación S.A., 2005.
[39] Paper Rational Software White, “Rational Unified Process Best Practices for Software,” Development, pp. 1–21, 2004.
[40] R. S. Pressman, Ingeniería del software. Un enfoque práctico, Séptima Ed.
101
Mexico D.F.: MacGraw-Hill, 2002.
[41] I. T. Christou, S. T. Ponis, and E. Palaiologou, “Using the agile unified process in banking,” IEEE Softw., vol. 27, No 3, pp. 72–79, 2010.
[42] H. Guang-Yong, “Study and practice of import Scrum agile software development,” 2011 IEEE 3rd Int. Conf. Commun. Softw. Networks, ICCSN 2011, pp. 217–220, 2011.
[43] K. Schwaber and J. Sutherland, “La Guía de Scrum.” Scrum.Org and ScrumInc, pp. 1–21, 2013.
[44] S. M. M. Valladarez, M. E. Gaitan, and N. N. P. Reyes, “Metodologia Ágil De Desarrollo De Software Programacion Extrema.,” vol. 1, p. 146, 2016.
[45] K. Beck and C. Andres, Praise for Extreme Programming Explained. 1999.
[46] S. Neo4j, “Neo4j 2.0 GA - Graphs for Everyone,” 2013. [Online]. Available: http://blog.neo4j.org/2013/12/neo4j-20-ga-graphs-for-everyone.html.
[47] Neo Technology, “What Is NEO4j,” 2016. [Online]. Available: http://neo4j.com/.
[48] T. Hoff, “Neo4j - A Graph Database That Kicks Buttox,” 2009. [Online]. Available: http://highscalability.com/neo4j-graph-database-kicks-buttox.
[49] Neo4j, “Intro to Cypher - Neo4j Graph Database,” 2015. [Online]. Available:
http://neo4j.com/developer/cypher-query-language/.
[50] Redislab, “Introduction to Redis,” 2010. .
[51] I. MongoDB, “Reinventando la gestión de datos,” 2016. [Online]. Available: https://www.mongodb.com/es.
[52] MongoDB, “Introduction to MongoDB,” 2016. .
[53] Jon Cianciullo, “Social Mention.” [Online]. Available: http://www.socialmention.com/about/.
[54] CASOS, “AutoMap: Extract, Analyze and Represent Relational Data from Texts,” 2008. [Online]. Available:
http://www.casos.cs.cmu.edu/projects/automap/.
[55] Escuela de negocios y Dirección, “Qué es y para qué sirve google trends,” 2014. [Online]. Available: http://br.escueladenegociosydireccion.com/business/marketing-digital/que-
102
es-y-para-que-sirve-google-trends/.
[56] D. Murray and C. Chabot, Tab leau Your Data!: Fast and Easy Visual Analysis
with Tab leau Software. 2013.
[57] T. N. Centre for Science and Technology Studies, Leiden University,
“Welcome to CitNetExplorer,” 2016. [Online]. Available: http://www.citnetexplorer.nl/.
[58] K. B. Jones, Search Engine Optimization: Your Visual Blueprint for Effective Internet Marketing Volume 59 of Visual Blueprint. 2008.
[59] J. Edwards, K. McCURLey, and J. Tomlin, “An adaptive model for optimizing performance of an incremental web crawler,” Proc. tenth Int. Conf. World Wide
Web - WWW ’01, pp. 106–113, 2001.
[60] Ando Saabas, “Sphider,” 2005. [Online]. Available:
http://www.sphider.eu/about.php.
[61] R. Jesse and C. Ronald, Httrack. 2012.
[62] S. del C. Ordoñez Salinas, J. M. Pérez Trujillo, and R. A. Sánchez Montero,
“MT_URU_V1.0_001Manual tecnico.” Dirección Nacional de derechos de autor, Bogotá, p. Libro 13, tomo: 66, partida: 17, 2018.
[63] D. R. Velandia and Y. D. Ramos, Prototipo de herramienta de software que permite realizar minería de opinión en español utilizando un motor de bases
de datos no relacional. 2017.
[64] Hardik Vasa, “wikipedia-crawler,” GitHub , 2015. [Online]. Available:
https://github.com/hardikvasa/wikipedia-crawler/blob/master/Licence.md.
[65] Codeorroad, “wiki-crawler,” npm Community, 2018. [Online]. Available:
https://www.npmjs.com/package/wiki-crawler.
[66] Rahul Mishra, “Wiki_Crawler,” GitHub , 2015. [Online]. Available:
https://github.com/Rahul91/Wiki_Crawler/blob/master/LICENSE.
[67] InfoSpace Holdings LLC, “Web Crawler,” 2018.
[68] Comunity, “socket.io,” GitHub . [Online]. Available:
https://github.com/socketio/socket.io/blob/master/LICENSE.
[69] M. Grinberg, “Flask-SocketIO,” GitHub , 2014. [Online]. Available:
https://github.com/miguelgrinberg/Flask-SocketIO/blob/master/LICENSE.
103
[70] J. Goldsmith, “No Title,” GitHub , 2013. [Online]. Available:
https://github.com/goldsmith/Wikipedia/blob/master/LICENSE.
[71] MediaWiki.org, “mediawiki,” MediaWiki.org, 2018. [Online]. Available:
https://www.mediawiki.org/wiki/API:Main_page/es.
[72] S. Ordoñez, A. Malagon Tavera, and J. M. Pérez Trujillo, “Integración de corpus y ontología a partir de los datos abiertos relacionados con el conflicto armado colombiano,” Lib r. Resúmenes del Prim. Congr. Int. Lingüística
Comput. y Corpus, pp. 31–33, 2017.
[73] E. Ziegel, W. Press, B. Flannery, S. Teukolsky, and W. Vetterling, Numerical Recipes: The Art of Scientific Computing, vol. 29, No 4. 1987.
[74] M. Bostock, “d3.js,” GitHub . [Online]. Available:
https://github.com/d3/d3/blob/master/LICENSE.
104
12. ANEXOS
A continuación se presentan los anexos relacionados en el documento.
12.1. ANEXO NO 1 - PRIMERA ITERACIÓN
En el siguiente apartado se encuentran todos los anexos que corresponden a la
primera iteración.
Historias de usuario
De la Tab la 50 hasta la Tab la 54 se encuentra la descripción de todas las historias
de usuario implementadas para la primera iteración.
Historia de Usuario
Número 1 Usuario Sistema
Nombre de Historia Extraer inf ormación de Wikipedia
Prioridad en Negocio Media
Puntos Estimados 10 Iteración Asignada 1
Responsables Romario Sánchez, Juan Manuel Pérez
Descripción
El sistema debe extraer la información de Wikipedia en español
de los personajes que sean solicitados por el usuario
Observaciones
Tab la 50 Historia de usuario No 1.
Historia de Usuario
Número 2 Usuario Sistema
Nombre de Historia Def inición o desarrollo del crawler a utilizar
Prioridad en Negocio Alta
Puntos Estimados 10 Iteración Asignada 1
Responsables Romario Sánchez, Juan Manuel Pérez
Descripción
Se debe realizar un análisis de crawlers de código abierto que se
puedan integrar al sistema y de los cuales se pueda obtener
inf ormación relacionada con personajes de la política
colombiana.
Observaciones
El crawler debe ser de código abierto dado que es necesario
modificar su código f uente con el fin de realizar las modificaciones
necesarias para cumplir con las necesidades de la aplicación.
Tab la 51 Historia de usuario No 2.
105
Historia de Usuario
Número 3 Usuario Sistema
Nombre de Historia Integrar crawler en el aplicativ o
Prioridad en Negocio Alta
Puntos Estimados 20 Iteración Asignada 1
Responsables Romario Sánchez, Juan Manuel Pérez
Descripción Para obtener la inf ormación de las personas relacionadas a determinado personaje es necesario realizar un recorrido por cada una de las páginas que se mencionan en la página a consultar, abstraer la inf ormación de estas y repetir el proceso por cada página v isitada.
Observaciones
Tab la 52 Historia de usuario No 3.
Historia de Usuario
Número 4 Usuario Sistema
Nombre de Historia Cargar inf ormación del crawler
Prioridad en Negocio Media
Puntos Estimados 5 Iteración Asignada 1
Responsables Romario Sánchez, Juan Manuel Pérez
Descripción
Construir un componente de software que permita almacenar
toda la información extractada por el crawler en la base de datos
MongoDB.
Observaciones
El componente debe almacenar un documento en la base de
datos de toda la información que fue extractada por personaje
con sus correspondientes datos de auditoria.
Tab la 53 Historia de usuario No 4.
Historia de Usuario
Número 5 Usuario Sistema
Nombre de Historia Construir serv icio socket
Prioridad en Negocio Media
Puntos Estimados 10 Iteración Asignada 1
Responsables Romario Sánchez, Juan Manuel Pérez
Descripción
Realizar un serv icio socket de tipo bidireccional que permita enviar
y recibir inf ormación entre Py thon y Node.js.
Observaciones
Tab la 54. Historia de usuario No 5.
106
Tareas de ingeniería
De la Tab la 55 a la Tab la 60 se encuentra la descripción de las tareas de
ingeniería implementadas en la primera iteración.
Tarea de Ingeniería
Número de Tarea 1 Número de historia 1
Nombre de Tarea Integrar librería “Wikipedia API”
Tipo de Tarea Desarrollo Puntos Estimados 5
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Integrar y extraer información de personajes de Wikipedia a través
de la librería “Wikipedia API”
Tab la 55. Tarea de ingeniería No 1.
Tarea de Ingeniería
Número de Tarea 2 Número de historia 1
Nombre de Tarea Integrar librería “WPTools”
Tipo de Tarea Desarrollo Puntos Estimados 5
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Integrar y extraer información de personajes de Wikipedia a través de
la librería “WPTools”
Tab la 56 Tarea de ingeniería No 2.
Tarea de Ingeniería
Número de Tarea 3 Número de historia 2
Nombre de Tarea Búsqueda de crawlers
Tipo de Tarea Desarrollo Puntos Estimados 5
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Se de realizar una inv estigación acerca de crawlers ya existentes que faciliten la obtención de la información así como la integración con los demás componentes a desarrollar
Observaciones
Tab la 57 Tarea de ingeniería No 3.
Tarea de Ingeniería
Número de Tarea 4 Número de historia 3
Nombre de Tarea Integración del crawler
Tipo de Tarea Desarrollo Puntos Estimados 8
Responsable Juan Manuel Pérez, Romario Sánchez
107
Descripción
Implementación del código para enviar los parámetros necesarios y recibir la respuesta esperada desde el aplicativo
Observaciones
Tab la 58 Tarea de ingeniería No 4.
Tarea de Ingeniería
Número de Tarea 5 Número de historia 3
Nombre de Tarea Adaptación de la inf ormación obtenida del crawler
Tipo de Tarea Desarrollo Puntos Estimados 4
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
En caso de que la información que obtenga el crawler no sea en totalidad la que se necesita para el aplicativo se debe realizar los cambios necesarios para obtener dicha información
Observaciones
Tab la 59 Tarea de ingeniería No 5.
Tarea de Ingeniería
Número de Tarea 6 Número de historia 4
Nombre de Tarea Insertar inf ormación de personajes
Tipo de Tarea Desarrollo Puntos Estimados 3
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Realizar un componente de sof tware que reciba la inf ormación
extractada del Scrapy e inserte la información en forma de documento
sobre la base de datos MongoDB
Tab la 60 Tarea de ingeniería No 6.
Tarea de Ingeniería
Número de Tarea 7 Número de historia 4
Nombre de Tarea Consultar inf ormación de personajes
Tipo de Tarea Desarrollo Puntos Estimados 2
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Realizar un componente de software que consulte la información de la
colección de MongoDB.
Tab la 61 Tarea de ingeniería No 7.
Tarea de Ingeniería
Número de Tarea 8 Número de historia 5
Nombre de Tarea Construir serv icio básico del socket
Tipo de Tarea Desarrollo Puntos Estimados 4
108
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Realizar el montaje se un servicio de tipo socket bidireccional donde
se pueda env iar y recibir inf ormación en f ormato JSON.
Tab la 62 Tarea de ingeniería No 8.
Pruebas de aceptación
De la Tab la 63 a la Tab la 67 se encuentran las pruebas de aceptación realizadas
para las historias de usuario que fueron definidas en la primera iteración.
Prueba de aceptación
Número de prueba 1 Número de historia 1
Nombre de prueba Extraer inf ormación de Wikipedia
Condiciones de
ejecución
Debe ingresar la URL de la página de Wikipedia a la cual se le
quiere extraer su información.
Entradas/Pasos
● Ingresar URL de la página de Wikipedia
● Buscar toda la información relacionada con la página de
Wikipedia
● Obtener toda la información encontrada de la página de
Wikipedia.
Resultado esperado
Obtener la Inf ormación de la página ingresada en el menor tiempo
posible.
Estado Rechazado
Tab la 63 Prueba de aceptación No 1.
Prueba de aceptación
Número de prueba 2 Número de historia 2
Nombre de prueba Extraer inf ormación del crawler
Condiciones de
ejecución
Debe ingresar la URL de la página del personaje de Wikipedia en
español a la cual se le quiere extraer su información.
Entradas/Pasos
● Ingresar URL de la página de Wikipedia
● Buscar toda la información relacionada con la página de
Wikipedia
● Obtener toda la información encontrada de la página de
Wikipedia en formato JSON.
Resultado esperado
Obtener toda la información relacionada con la página del personaje
de Wikipedia ingresada en f ormato JSON.
Estado Aceptada
Tab la 64 Prueba de aceptación No 2.
109
Prueba de aceptación
Número de prueba 3 Número de historia 3
Nombre de prueba Insertar inf ormación de personajes
Condiciones de
ejecución
El conjunto de información del personaje previamente descargado
que se va ingresar en la colección de MongoDB debe estar en
f ormato JSON.
Entradas/Pasos
● Abrir conexión a la base de datos MongoDB
● Buscar la colección de MongoDB.
● Crear documento en MongoDB
Resultado esperado
Documento de MongoDB con toda la información del personaje que
f ue descargada.
Estado Aceptada
Tab la 65 Prueba de aceptación No 3.
Prueba de aceptación
Número de prueba 4 Número de historia 4
Nombre de prueba Consultar inf ormación de personajes
Condiciones de
ejecución
Debe haberse insertado documentos de personajes a la base de
datos de MongoDB
Entradas/Pasos
● Abrir conexión a la base de datos MongoDB
● Ingresar parámetro de búsqueda (nombre o URL de
Wikipedia).
● Obtener lista de documentos.
Resultado esperado
Lista de documentos en formato JSON relacionados con el parámetro
de búsqueda prev iamente ingresado.
Estado Aceptada
Tab la 66 Prueba de aceptación No 4.
Prueba de aceptación
Número de prueba 5 Número de historia 5
Nombre de prueba Env iar inf ormación a trav és del socket
Condiciones de
ejecución Objeto tipo JSON de la información que se va enviar
Entradas/Pasos
● Abrir canal del socket
● ingresar objeto tipo JSON a enviar en un punto.
● recibir en el otro punto el objeto tipo JSON.
Resultado esperado
Recibir el punto receptor de la conexión del socket un objeto de tipo
JSON.
Estado Aceptada
Tab la 67 Prueba de aceptación No 5.
110
12.2. ANEXO NO 2 - SEGUNDA ITERACIÓN
En este anexo se encuentran todas las historias de usuario, tareas de ingeniería y
pruebas de aceptación definidas para la segunda iteración.
Historias de usuario
Desde la Tab la 68 hasta la Tab la 71 se encuentra las descripción o especificación
de cada de una de las historias de usuario definidas para la segunda iteración.
Historia de Usuario
Número 6 Usuario Sistema
Nombre de Historia Controlar categorías de búsqueda de personajes
Prioridad en Negocio Alta
Puntos Estimados 5 Iteración Asignada 2
Responsables Romario Sánchez, Juan Manuel Pérez
Descripción Con el f in de delimitar los resultados de búsqueda que se presentaran al usuario en la ontología se deben cargar las categorías de Wikipedia que tenga relación con el gobierno colombiano.
Observaciones
Tab la 68 Historia de usuario No 6
Historia de Usuario
Número 7 Usuario Sistema
Nombre de Historia Cargar sinónimos de términos generales
Prioridad en Negocio baja
Puntos Estimados 12 Iteración Asignada 2
Responsables Romario Sánchez, Juan Manuel Pérez
Descripción Wikipedia al ser una enciclopedia libre en la que múltiples usuarios interactúan, existen una gran multiplicidad de términos que hacen referencia a la misma información, de esta manera debe existir un mecanismo que identifique sinónimos almacenados en la antología.
Observaciones La carga de sinónimos debe manejar prefijos que permitan la f ácil adición de más casos.
Tab la 69 Historia de usuario No 7.
Historia de Usuario
Número 8 Usuario Sistema
Nombre de Historia Def inir de estructura de datos
Prioridad en Negocio alta
111
Puntos Estimados 8 Iteración Asignada 2
Responsables Romario Sánchez, Juan Manuel Pérez
Descripción La inf ormación almacenada en la base de datos orientada a grafos debe estar estructurada según un modelo de datos prev iamente diseñado, esto tiene el f in de que independiente de la f uente de inf ormación el almacenamiento se realizará sobre los nodos y relaciones prev iamente diseñados.
Observaciones La def inición del modelo de datos debe manejar prefijos en los nombres de cada entidad que permitan su fácil identificación.
Tab la 70 Historia de usuario No 8.
Historia de Usuario
Número 9 Usuario Sistema
Nombre de Historia Carga de conocimiento en la ontología
Prioridad en Negocio Baja
Puntos Estimados 9 Iteración Asignada 2
Responsables Romario Sánchez, Juan Manuel Pérez
Descripción Para mejorar la búsqueda de relaciones entre personajes es
necesario ingresar conocimiento acerca de la estructura
política colombiana.
Observaciones
Tab la 71 Historia de usuario No 9.
Tareas de ingeniería
De la Tab la 72 a la Tab la 76 se encuentra la descripción de las tareas de
ingeniería implementadas en la segunda iteración.
Tarea de Ingeniería
Número de Tarea 9 Número de historia 6
Nombre de Tarea Recopilación de categorías de búsqueda de personajes
Tipo de Tarea Desarrollo Puntos Estimados 2
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Se debe obtener el listado de todas las categorías de Wikipedia que hacen relación a personajes de la política Colombiana
Observaciones
Tab la 72 Tarea de ingeniería No 9
112
Tarea de Ingeniería
Número de Tarea 10 Número de historia 6
Nombre de Tarea
Validación de categorías en la búsqueda de personajes no registrados
Tipo de Tarea Desarrollo Puntos Estimados 3
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Se debe comparar los resultados obtenidos de la búsqueda de Wikipedia con la categorías cargadas en la ontología para de esta manera solo sugerir al usuario personajes de la política colombiana
Observaciones
Tab la 73 Tarea de ingeniería No 10
Tarea de Ingeniería
Número de Tarea 11 Número de historia 7
Nombre de Tarea Desarrollo de archivos con la relación de palabras que
tienen el mismo signif icado.
Tipo de Tarea Desarrollo Puntos Estimados 5
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Debe implementarse un componente que mediante la lectura de los archivos los cargue según cada caso en la base datos.
Observaciones
Tab la 74 Tarea de ingeniería No 11.
Tarea de Ingeniería
Número de Tarea 12 Número de historia 8
Nombre de Tarea
Def inición del modelo de datos (nodos, relaciones y
atributos)
Tipo de Tarea Desarrollo Puntos Estimados 1
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Se deben definir los tipos de nodos, relaciones y atributos
que manejará el aplicativo que servirán para dar al usuario
una v isión estandarizada de la inf ormación.
Observaciones
Tab la 75 Tarea de ingeniería No 12.
Tarea de Ingeniería
Número de Tarea 13 Número de historia 9
Nombre de Tarea Recopilación de conocimiento para la ontología
113
Tipo de Tarea Desarrollo Puntos Estimados 1
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Se debe estructurar la información de la estructura política
de Colombia, en archivos con formato JSON con el fin de
realizar su posterior carga en la ontología
Observaciones
Tab la 76 Tarea de ingeniería No 13.
Pruebas de aceptación
A continuación se describen las pruebas de aceptación que fueron definidas para
validación de las tareas de la segunda iteración.
Prueba de aceptación
Número de prueba 6 Número de historia 6
Nombre de prueba Validar f iltro de categorías para la búsqueda de personajes
Condiciones de
ejecución
El usuario realiza la búsqueda de un personaje que no se
encuentra registrado en la base de datos.
Entradas/Pasos
● El usuario ingresa nombre del personaje a buscar
● Se muestra una lista de los resultados de la
búsqueda en Wikipedia
Resultado esperado
Se v isualiza un listado de la búsqueda del personaje, pero
solo se muestran personas relacionadas con el gobierno
colombiano, omitiendo otros resultados.
Estado Aceptada
Tab la 77 Prueba de aceptación No 6.
Prueba de aceptación
Número de prueba 7 Número de historia 7
Nombre de prueba Consultar sinónimos por términos
Condiciones de
ejecución
Se desea validar si existe un término que tenga el mismo
significado de uno en particular
Entradas/Pasos
● Se env ía al método de validación como parámetro
un térmiNo
● Se obtiene como retorno un término con el mismo
significado al enviado.
Resultado esperado Obtener el término esperado
Estado Aceptada
Tab la 78 Prueba de aceptación No 7.
114
Prueba de aceptación
Número de prueba 8 Número de historia 9
Nombre de prueba Carga de la información recopilada en la ontología
Condiciones de
ejecución No aplica
Entradas/Pasos
● Se ejecutan métodos de consulta de la información
cargada
Resultado esperado
Se obtienen los cargos públicos son su respectiva asociación
a entidades gubernamentales.
Estado Aceptada
Tab la 79 Prueba de aceptación No 8.
12.3. ANEXO NO 3 - TERCERA ITERACIÓN
En este anexo se encuentran todas las historias de usuario, tareas de ingeniería y
pruebas de aceptación definidas para la tercera iteración.
Historias de usuario
Desde la Tab la 80 hasta la Tab la 81 se encuentra las descripción o especificación
de cada de una de las historias de usuario definidas para la tercera iteración.
Historia de Usuario
Número 10 Usuario Sistema
Nombre de Historia Componente ejecutable para la carga de la ontología
Prioridad en Negocio baja
Puntos Estimados 9 Iteración Asignada 3
Responsables Romario Sánchez, Juan Manuel Pérez
Descripción Se debe implementar un componente que permita la carga de
la ontología en el motor de base de datos, por si se presentan
f allos que generen la perdida de la inf ormación
Observaciones
Tab la 80 Historia de usuario No 10
Historia de Usuario
Número 11 Usuario Sistema
Nombre de Historia Interf az gráf ica buscador de personajes
Prioridad en Negocio Media
Puntos Estimados 12 Iteración Asignada 3
115
Responsables Romario Sánchez, Juan Manuel Pérez
Descripción
Desarrollar un buscador de personajes con autocompletar que
actualmente ha procesado el aplicativ o web.
Observaciones
En la interf az web hay una caja de texto con autocompletar
donde se ingresa el nombre del personaje. En la parte superior
de la interfaz debe construirse un panel de navegación a las
distintas páginas de la aplicación.
Tab la 81 Historia de usuario No 11
Tareas de ingeniería
De la Tab la 82 a la Tab la 87 se encuentra la descripción de las tareas de ingeniería
implementadas en la tercera iteración.
Tarea de Ingeniería
Número de Tarea 14 Número de historia 10
Nombre de Tarea Implementar archivo de configuración
Tipo de Tarea Desarrollo Puntos Estimados 1
Fecha Inicio Fecha Fin
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Se debe implementar un archivo de configuración en el
que se registre la ubicación de los archivos necesarios
para la carga y control de errores.
Observaciones
Tab la 82 Tarea de ingeniería No 14.
Tarea de Ingeniería
Número de Tarea 15 Número de historia 10
Nombre de Tarea Implementar archivos para la carga de la ontología
Tipo de Tarea Desarrollo Puntos Estimados 1
Fecha Inicio Fecha Fin
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Como respaldo de la ontología se deben crear archivos
en formato JSON de los que se pueda abstraer la
información necesaria, para cargar cada una de las
estructuras.
Observaciones
Tab la 83 Tarea de ingeniería No 15.
116
Tarea de Ingeniería
Número de Tarea 16 Número de historia 10
Nombre de Tarea Desarrollo componente lectura / escritura de archivos
Tipo de Tarea Desarrollo Puntos Estimados 1
Fecha Inicio Fecha Fin
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Para leer los archivos de carga de la ontología y
registrar los errores del proceso de carga se debe
implementar un componente.
Observaciones
Tab la 84 Tarea de ingeniería No 16
Tarea de Ingeniería
Número de Tarea 17 Número de historia 10
Nombre de Tarea
Implementar componente para la carga de datos en la
ontología
Tipo de Tarea Desarrollo Puntos Estimados 1
Fecha Inicio Fecha Fin
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Debe implementarse un componente que mediante la
lectura de los archivos mencionados cargue según
cada caso en la base datos.
Observaciones
Tab la 85 Tarea de ingeniería No 17
Tarea de Ingeniería
Número de Tarea 18 Número de historia 11
Nombre de Tarea Construir interfaz web del buscador de personajes
Tipo de Tarea Desarrollo Puntos Estimados 1
Fecha Inicio Fecha Fin
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Construir y diseñar los componentes HTML sobre los
componentes de front-end Bootstrap que permitirán realizar
las búsquedas de personajes sobre el aplicativo web. Añadir
un panel de navegación en la parte superior de la página web
117
para explorar las diferentes páginas disponibles en el
aplicativo web.
Tab la 86 Tarea de ingeniería No 18
Tarea de Ingeniería
Número de Tarea 19 Número de historia 11
Nombre de Tarea
Integrar interfaz del buscador de personajes con
componentes back-end
Tipo de Tarea Desarrollo Puntos Estimados 1
Fecha Inicio Fecha Fin
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Realizar la construcción e integración entre los componentes
HTML del buscador de personajes con los componentes
back-end del aplicativo. La funcionalidad de autocompletar
debe consultar sobre la base de datos MongoDB y mostrar
desplegar la lista de personajes procesados.
Tab la 87 Tarea de ingeniería No 19
Pruebas de aceptación
A continuación se presentan las pruebas de aceptación que dieron validez las
historias de usuario de la tercera iteración.
Prueba de aceptación
Número de prueba 9 Número de historia 9
Nombre de prueba
Ejecución del componente ejecutable para la carga de la
inf ormación en la ontología
Condiciones de
ejecución No aplica
Entradas/Pasos
Se ubican los archivos a ser cargados en una determinada ruta.
Se ingresa la ruta en el archivo de configuración.
Se ejecuta el componente.
Resultado esperado
Se realiza consultas en la base de datos y todos los datos ya se
encuentran cargados (para validar la información realizar las
pruebas de aceptación 8 y 12 )
Estado Aceptada
Tab la 88 Prueba de aceptación No 9.
Prueba de aceptación
118
Número de prueba 10 Número de historia 10
Nombre de prueba
Visualización de la página principal de la página con la barra de
búsqueda y las secciones de la página.
Condiciones de
ejecución El usuario ingresa a la página web.
Entradas/Pasos
El usuario ingresa a la página web
Se v isualiza la barra de búsqueda, las pestañas a otras páginas
Resultado esperado
Se v isualiza la página principal con todos sus componentes
Al dar click en cada una de las páginas se es dirigido al contenido
de esta.
Estado Aceptada
Tab la 89 Prueba de aceptación No 10.
Prueba de aceptación
Número de prueba 11 Número de historia 11
Nombre de prueba Validar sugerencia de personajes ya registrados en base de datos.
Condiciones de
ejecución Un ingresa a la barra de búsqueda de personajes.
Entradas/Pasos
El usuario ingresa a la página principal.
Digita en el buscador de personajes cuatro letras.
Se v isualiza un listado de los personajes ya almacenados
Resultado esperado
Se observa la lista de nombres personajes que contengan los
caracteres ingresados en la barra de búsqueda.
Estado Aceptada
Tab la 90 Prueba de aceptación No 11.
12.4. ANEXO NO. 4 - CUARTA ITERACIÓN
En este anexo se encuentran todas las historias de usuario, tareas de ingeniería y
pruebas de aceptación definidas para la cuarta iteración.
Historias de usuario
Desde la Tabla 91 hasta la Tabla 93 se encuentra las descripción o especificación
de cada de una de las historias de usuario definidas para la cuarta iteración.
Historia de Usuario
Número 12 Usuario Sistema
Nombre de Historia Lógica de carga de nodos y relaciones
Prioridad en Negocio Alta
119
Puntos Estimados 4 Iteración Asignada 4
Responsables Romario Sánchez, Juan Manuel Pérez
Descripción Se debe cargar en la ontología las asociaciones entre los términos y el
modelo de datos, para que de esta manera independientemente del
autor de los datos del personaje la inf ormación sea estructurada.
Observaciones
Tab la 91 Historia de usuario No 12
Historia de Usuario
Número 13 Usuario Sistema
Nombre de Historia Construcción de nodos
Prioridad en Negocio Alta
Puntos Estimados 4 Iteración Asignada 4
Responsables Romario Sánchez, Juan Manuel Pérez
Descripción Acorde al modelo de datos registrado en la ontología con la información
recuperada de cada personaje se debe v alidar si existen entidades
(nodos) que no existan, en dado que no lo esté se debe extraer la
inf ormación de esa entidad y registrar sus datos.
Observaciones
Tab la 92 Historia de usuario No 13
Historia de Usuario
Número 14 Usuario Sistema
Nombre de Historia Construcción de relaciones
Prioridad en Negocio Alta
Puntos Estimados 4 Iteración Asignada 4
Responsables Romario Sánchez, Juan Manuel Pérez
Descripción Acorde al modelo de datos registrado en la ontología con la información
recuperada de cada personaje se deben relacionar cada una de las
entidades descritas con su respectiv a inf ormación asociada.
Observaciones
Tab la 93 Historia de usuario No 14
Tareas de ingeniería
120
De la Tabla 94 a la Tabla 96 se encuentra la descripción de las tareas de ingeniería
implementadas en la cuarta iteración.
Tarea de Ingeniería
Número de Tarea 20 Número de historia 6
Nombre de Tarea
Implementación de funciones para la obtención de sinónimos por cada término
Tipo de Tarea Desarrollo Puntos Estimados 7
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Debe implementarse las funciones para obtenerse los sinónimos por cada nodo para de esta manera reducir la cantidad de términos que maneja el sistema, con el fin de facilitar la estructuración de la información.
Observaciones
Tab la 94 Tarea de ingeniería No 20
Tarea de Ingeniería
Número de Tarea 21 Número de historia 11
Nombre de Tarea Construcción de relaciones
Tipo de Tarea Desarrollo Puntos Estimados 1
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Se debe implementar la lógica necesaria para la creación de
relaciones entre los nodos de acuerdo a la información almacenada
en la ontología.
Observaciones
Se debe v alidar las relaciones entre nodos previamente creadas
con el f in de ev itar la duplicidad de estas
Tab la 95 Tarea de ingeniería No 21
Tarea de Ingeniería
Número de Tarea 22 Número de historia 12
Nombre de Tarea Carga de nodos
Tipo de Tarea Desarrollo Puntos Estimados 1
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Se debe implementar la lógica necesaria para la creación de nodos
a partir de la inf ormación almacenada en la ontología.
Observaciones
Se debe v alidar si la inf ormación del personaje ya f ue registrada
con anterioridad, para evitar la duplicidad de la información de un
personaje, en caso de que esta ya exista no se debe v olver a
realizar su registro.
121
Tab la 96 Tarea de ingeniería No 22
Pruebas de aceptación
A continuación se presentan las pruebas de aceptación que dieron validez las
historias de usuario de la cuarta iteración.
Prueba de aceptación
Número de prueba 12 Número de historia 12
Nombre de prueba Carga de relación de términos y campos del nodo o relación
Condiciones de ejecución
El usuario busca un personaje que no se encuentra registrado, se realiza
el scrapy del personaje y es necesario obtener las relación de términos y
campos del nodo o relación
Entradas/Pasos
● Se obtiene la estructura del scrapy
● Se realiza la consulta a la base de datos en la que se
encuentra registrada la ontología
● Se obtiene el objeto esperado
Resultado esperado
Se obtiene un objeto en el que están todos y cada uno de los términos y
campos del nodo o relación registrados en la ontología.
Estado Aceptada
Tab la 97 Prueba de aceptación No 12
Prueba de aceptación
Número de prueba 13 Número de historia 12
Nombre de prueba Relación de términos con campos en nodos y relaciones
Condiciones de ejecución
El usuario busca un personaje que no se encuentra registrado, se realiza
el scrapy del personaje y es necesario obtener la relación de términos con
campos en nodos y relaciones
Entradas/Pasos
● Se obtiene la estructura del scrapy
● Se realiza la consulta a la base de datos en la que se
encuentra registrada la ontología
● Se obtiene el objeto esperado
Resultado esperado
Se recorre la estructura obtenida del scrapy, asignando los valores de
acuerdo al objeto obtenido, f inalmente se encuentra asignada la
inf ormación esperada
122
Estado Aceptada
Tab la 98 Prueba de aceptación No 13
Prueba de aceptación
Número de prueba 14 Número de historia 12
Nombre de prueba Limpieza de los términos obtenidos en la extracción de la inf ormación
Condiciones de ejecución
El usuario busca un personaje que no se encuentra registrado, se realiza
el scrapy del personaje,
Entradas/Pasos
● Se obtiene la estructura del scrapy
● Se recorre la estructura obtenida del scrapy imprimiendo los
términos obtenidos después de la limpieza
Resultado esperado
No se v isualizan términos con caracteres no soportados y solo se
muestran la ‘raíz’ de la palabra
Estado Aceptada
Tab la 99 Prueba de aceptación No 14
Prueba de aceptación
Número de prueba 15 Número de historia 12
Nombre de prueba Limpieza de los términos obtenidos en la extracción de la inf ormación
Condiciones de ejecución Comparación de términos con sus sinónimos
Entradas/Pasos
● Se obtiene la estructura del scrapy
● Se recorre la estructura obtenida del scrapy comparando cada
término con su generalización, registrando el valor en caso de
ser coincidente.
● Se obtiene el objeto listo para ser insertado en base de datos.
● Se compara el objeto obtenido con la página web del personaje
para v alidar que la información esperada se encuentre en el
objeto
Resultado esperado
La estructura para ingresar en la base de datos cuenta con todos los
v alores esperados
Estado Aceptada
Tab la 100 Prueba de aceptación No 15
Prueba de aceptación
123
Número de prueba 16 Número de historia 13
Nombre de prueba Validación de la creación de nodos por cada tipo de nodo.
Condiciones de ejecución
Se ingresa un nuev o personaje a la base de datos , con relaciones a
instituciones, organizaciones, partido político y lugares que no se han
registrado
Entradas/Pasos
● Se obtiene objeto para insertar en la base de datos
● Se recorre la estructura, insertando cada tipo de nodo
● Se consulta desde la consola de neo4j si los nodos fueron
creados
Resultado esperado Existe cada uno de los nodos con todos los atributos esperados.
Estado Aceptada
Tab la 101 Prueba de aceptación No 16
Prueba de aceptación
Número de prueba 17 Número de historia 13
Nombre de prueba Validación de la no duplicidad de nodos
Condiciones de ejecución
Se ingresa un personaje a la base de datos, con re laciones a
instituciones, organizaciones, partido político y lugares que y a f ueron
prev iamente registrados.
Entradas/Pasos
● Se obtiene objeto para insertar en la base de datos
● Se recorre la estructura, insertando cada tipo de nodo
● Se consulta desde la consola de neo4j si los nodos fueron
creados
Resultado esperado Solo se v en los nodos que f ueron ingresados con anterioridad
Estado Aceptada
Tab la 102 Prueba de aceptación No 17
Prueba de aceptación
Número de prueba 18 Número de historia 13
Nombre de prueba Validación de la creación de relaciones por cada tipo de relación.
Condiciones de ejecución
Se ingresa un nuev o personaje a la base de datos, con relaciones a
instituciones, organizaciones, partido político y lugares.
124
Entradas/Pasos
● Se obtiene objeto para insertar en la base de datos
● Se recorre la estructura, insertando cada tipo de relación
● Se consulta desde la consola de neo4j si las relaciones fueron
creadas
Resultado esperado Existe cada relación con todos los atributos esperados.
Estado Aceptada
Tab la 103 Prueba de aceptación No 18
Prueba de aceptación
Número de prueba 19 Número de historia 13
Nombre de prueba Validación de la no duplicidad de relaciones
Condiciones de ejecución
Se ingresa dos veces el mismo personaje con relación a cada tipo de
nodo
Entradas/Pasos
● Se obtiene objeto para insertar en la base de datos
● Se recorre la estructura, insertando cada tipo de relación
● Se consulta desde la consola de neo4j si las relaciones fueron
creadas
Resultado esperado No existe redundancia de relaciones
Estado Aceptada
Tab la 104 Prueba de aceptación No 19
12.5. ANEXO NO. 5 - QUINTA ITERACIÓN
En este anexo se encuentran todas las historias de usuario, tareas de ingeniería y
pruebas de aceptación definidas para la quinta iteración.
Historias de usuario
Desde la Tabla 105 hasta la Tabla 107 se encuentra las descripción o especificación
de cada de una de las historias de usuario definidas para la cuarta iteración.
Historia de Usuario
Número 15 Usuario Sistema
Nombre de Historia Consultar lista de personajes
125
Prioridad en Negocio Media
Puntos Estimados 14 Iteración Asignada 5
Responsables Romario Sánchez, Juan Manuel Pérez
Descripción
Desarrollar la interfaz web con la lista de personajes que han sido procesados y guardados en las bases de datos de MongoDB y Neo4j por el sistema.
Observaciones
La interf az web v isualiza la lista de personajes almacenados en MongoDB que coincidan con el texto de búsqueda ingresado por el usuario. En la parte inf erior de página web aparece una lista de personajes que no se encuentran procesados por el sistema, pero que existen en Wikipedia con la opción de ser procesados por el aplicativo.
Tab la 105 Historia de usuario No 15
Historia de Usuario
Número 16 Usuario Sistema
Nombre de Historia Consultar lista de personajes sugeridos por Wikipedia.
Prioridad en Negocio Media
Puntos Estimados 1 Iteración Asignada 5
Responsables Romario Sánchez, Juan Manuel Pérez
Descripción
Construir un componente web que se encarga de desplegar una lista de personajes que no se encuentran procesados por el sistema, pero que existen en Wikipedia con la opción de ser procesados por el aplicativo.
Observaciones
En la parte inf erior de la página que v isualiza la lista de personajes
procesados, realizar la integración del componente web.
Tab la 106 Historia de usuario No 16
Historia de Usuario
Número 15 Usuario Sistema
Nombre de Historia Visualizar grafo de personajes
Prioridad en Negocio Media
Puntos Estimados 16 Iteración Asignada 5
Responsables Romario Sánchez, Juan Manuel Pérez
126
Descripción
Desarrollar una interf az web con las personas y distintas entidades relacionadas a un personaje seleccionado por el usuario a través de un grafo. En cada nodo y relación debe aparecer un cuadro descriptivo con inf ormación básica tanto de los nodos como de las relaciones.
Observaciones
● La inf ormación será consultada en la base de datos Neo4j. ● El sistema redirigirá a esta página web cuando sea
seleccionado un personaje a partir de la lista de personajes.
Tab la 107 Historia de usuario No 17
Tareas de ingeniería
De la Tabla 108 a la Tabla 115 se encuentra la descripción de las tareas de
ingeniería implementadas en la quinta iteración.
Tarea de Ingeniería
Número de Tarea 23 Número de historia 5
Nombre de Tarea Crear serv icio de sugerencias API Wikipedia
Tipo de Tarea Desarrollo Puntos Estimados 1
Fecha Inicio Fecha Fin
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Construir un servicio en el socket que se encargue de env iar y recibir de
Py thon a Node.js la lista de personajes sugeridos que se encuentran en
Wikipedia que recibe como parámetro un conjunto de caracteres ingresados
por el usuario.
Tab la 108 Tarea de ingeniería No 23
Tarea de Ingeniería
Número de Tarea Número de historia 4
Nombre de Tarea Crear servicio de consulta de configuraciones del grafo
Tipo de Tarea Desarrollo Puntos Estimados 1
Fecha Inicio Fecha Fin
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Construir un servicio de consulta de las configuraciones de los tipos de nodo y relaciones que son utilizados en la construcción de los filtros y
estilos del grafo. La consulta de las configuraciones debe realizarse sobre la ontología que se encuentra almacenada en la base de datos de Redis.
127
Tab la 109 Tarea de ingeniería No 24
Tarea de Ingeniería
Número de Tarea 25 Número de historia 15
Nombre de Tarea Construir interf az web lista de personajes
Tipo de Tarea Desarrollo Puntos Estimados 1
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Cuando el usuario ingrese un texto a través de buscador de personajes, redirigir la página web a la lista de personajes encontrados. Si se encuentra en la página de la lista de personajes encontrados y se realiza una nuev a búsqueda, cargar la nuev a lista de personajes .
Tab la 110 Tarea de ingeniería No 25
Tarea de Ingeniería
Número de Tarea 26 Número de historia 15
Nombre de Tarea Componente web de sugerencias de personajes no procesados
Tipo de Tarea Desarrollo Puntos Estimados 5
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
En la parte inferior de la página web debe aparecer un panel con la lista de personajes sugeridos que han sido consultados a través de un API de Wikipedia pero que no han sido procesados por el aplicativo web. Los personajes sugeridos son coincidencias a partir del texto ingresado por el usuario.
Tab la 111 Tarea de ingeniería No 26
Tarea de Ingeniería
Número de Tarea 27 Número de historia 16
Nombre de Tarea Integrar buscador de personajes con lista de personajes
Tipo de Tarea Desarrollo Puntos Estimados 1
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Cuando el usuario ingrese un texto a través de buscador de personajes, redirigir la página web a la lista de personajes encontrados. Si se encuentra en la página de la lista de personajes encontrados y se realiza una nuev a búsqueda, cargar la nuev a lista de personajes.
Tab la 112 Tarea de ingeniería No 27
Tarea de Ingeniería
128
Número de Tarea 28 Número de historia 17
Nombre de Tarea Construir grafo
Tipo de Tarea Desarrollo Puntos Estimados 5
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Construir y diseñar los componentes back -end y f ront-end para la v isualización del grafo. Los diferentes tipos de nodos deben diferenciarse a trav és de colores y las relaciones deben llevar un label con el tipo de relación. Cada nodo y relación pueden ser seleccionados y debe aparecer un cuadro con su inf ormación correspondiente.
Tab la 113 Tarea de ingeniería No 28
Tarea de Ingeniería
Número de Tarea 29 Número de historia 17
Nombre de Tarea Construir interf az web v isualización del grafo
Tipo de Tarea Desarrollo Puntos Estimados 6
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Construir y diseñar los componentes HTML donde aparecerá el grafo del personaje seleccionado. En un componente HTML debe aparecer un panel donde se visualizará el grafo y en otro información básica del personaje.
Tab la 114 Tarea de ingeniería No 29
Tarea de Ingeniería
Número de Tarea 30 Número de historia 17
Nombre de Tarea Integrar v isualización del grafo con lista de personajes
Tipo de Tarea Desarrollo Puntos Estimados 5
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Cuando el usuario seleccione un personaje de la lista de personajes redirigir la página a la página web v isualiza el grafo del personaje seleccionado.
Tab la 115 Tarea de ingeniería No 30
Pruebas de aceptación
A continuación se presentan las pruebas de aceptación que dieron validez las
historias de usuario de la quinta iteración.
Prueba de aceptación
129
Número de prueba 20 Número de historia 5
Nombre de prueba Consultar lista de personajes
Condiciones de ejecución Debe haberse ingresado un término de búsqueda en la caja de texto.
Entradas/Pasos
● Realizar el f iltro con el término ingresado en la base de datos
MongoDB.
● Obtener lista de personajes filtrados.
● Visualizar la lista de personajes filtrados en la interfaz web.
Resultado esperado
Una lista de personajes organizados y paginados en la interf az web con
inf ormación básica de cada personaje.
Estado Aceptada
Tab la 116 Prueba de aceptación No 20
Prueba de aceptación
Número de prueba 21 Número de historia 16
Nombre de prueba Consultar lista de personajes sugeridos
Condiciones de ejecución Debe haberse ingresado un término de búsqueda en la caja de texto.
Entradas/Pasos
● Env iar a través del socket el término de búsqueda ingresado por
el usuario.
● Consultar por medio del API de Wikipedia los personajes
sugeridos.
● Obtener la lista de personajes sugeridos
● Visualizar la lista de personajes sugeridos en la interfaz web.
Resultado esperado
Una lista de personajes sugeridos con su f otografía (si la tiene) y su
nombre.
Estado Aceptada
Tab la 117 Prueba de aceptación No 21
Prueba de aceptación
Número de prueba 22 Número de historia 17
Nombre de prueba Consultar grafo del personaje
Condiciones de ejecución
El usuario debe seleccionar un personaje de la lista de personajes
haciendo click sobre el botón “v er grafo”.
130
Entradas/Pasos
● Env iar identificador el personaje a través del socket
● Consultar personaje en Neo4j.
● Obtener diccionario con la lista de nodos y relaciones
encontradas en Neo4j.
● Construir y visualizar grafo a partir del diccionario que se obtuvo
en Neo4j
Resultado esperado
Grafo con sus respectivos nodos y relaciones del personaje en la interfaz
web del aplicativ o
Estado Aceptada
Tab la 118 Prueba de aceptación No 22
12.6. ANEXO NO. 6 - SEXTA ITERACIÓN
En este anexo se encuentran todas las historias de usuario, tareas de ingeniería y
pruebas de aceptación definidas para la sexta iteración.
Historias de usuario
Desde la Tabla 119 hasta la Tabla 122 se encuentra las descripción o especificación
de cada de una de las historias de usuario definidas para la cuarta iteración.
Historia de Usuario
Número 18 Usuario Sistema
Nombre de Historia Interf aces gráf icas inf ormativ as
Prioridad en Negocio Media
Puntos Estimados 12 Iteración Asignada 6
Responsables Romario Sánchez, Juan Manuel Pérez
Descripción
Crear las interf aces gráf icas de contacto, inf ormación del grupo de inv estigación y f uncionamiento del aplicativ o web.
Observaciones
El usuario puede acceder a estas páginas web a trav és del panel de nav egación de la página principal o buscador de personajes.
Tab la 119 Historia de usuario No 18
Historia de Usuario
Número 19 Usuario Sistema
131
Nombre de Historia Filtro de nodos
Prioridad en Negocio Media
Puntos Estimados 8 Iteración Asignada 6
Responsables Romario Sánchez, Juan Manuel Pérez
Descripción
Dentro del mismo componente web que v isualiza el grafo del personaje seleccionado, crear un componente web que permita filtrar los tipos de nodos que el usuario desea v er dentro del grafo.
Observaciones
El usuario puede seleccionar desde un tipo de nodo hasta todos los tipos de nodos que se desean f iltrar.
Tab la 120 Historia de usuario No 19
Historia de Usuario
Número 20 Usuario Sistema
Nombre de Historia Filtro de camino entre nodos
Prioridad en Negocio Media
Puntos Estimados 10 Iteración Asignada 6
Responsables Romario Sánchez, Juan Manuel Pérez
Descripción
Crear un componente web que permita seleccionar desde dos hasta n nodos de tipo persona para f iltrar los caminos disponibles entre dichos nodos.
Observaciones El resultado de este f iltro se v isualiza a trav és de una modal que va a desplegar el aplicativ o web.
Tab la 121 Historia de usuario No 20
Historia de Usuario
Número 21 Usuario Sistema
Nombre de Historia Visualizar inf ormación básica del nodo y relación
Prioridad en Negocio Media
Puntos Estimados 1 Iteración Asignada 6
Responsables Romario Sánchez, Juan Manuel Pérez
132
Descripción Crear un componente web que despliegue la información básica de un nodo o una relación al ser seleccionado.
Observaciones
Cuando el usuario selecciona un nodo o una relación del nodo desplegar
un modal con la inf ormación básica de este.
Tab la 122 Historia de usuario No 21
Tareas de ingeniería
De la Tabla 123 a la Tabla 136 se encuentra la descripción de las tareas de
ingeniería implementadas en la quinta iteración.
Tarea de Ingeniería
Número de Tarea 31 Número de historia 18
Nombre de Tarea Construir página web de contacto
Tipo de Tarea Desarrollo Puntos Estimados 3
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Construir y diseñar los componentes HTML de un formulario de contacto que env íe un correo electrónico con la inf ormación ingresada por el usuario.
Tab la 123 Tarea de ingeniería No 31
Tarea de Ingeniería
Número de Tarea 32 Número de historia 18
Nombre de Tarea Construir página web de inf ormativ a del grupo
Tipo de Tarea Desarrollo Puntos Estimados 3
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Construir y diseñar los componentes HTML de página web donde aparezca la inf ormación del grupo de investigación y los participantes en el proy ecto.
Tab la 124 Tarea de ingeniería No 32
Tarea de Ingeniería
Número de Tarea 33 Número de historia 18
Nombre de Tarea Construir página web de f uncionamiento del aplicativ o
Tipo de Tarea Desarrollo Puntos Estimados 3
133
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Construir y diseñar los componentes HTML de página web donde explique las f uncionalidades del sistema.
Tab la 125 Tarea de ingeniería No 33
Tarea de Ingeniería
Número de Tarea 34 Número de historia 18
Nombre de Tarea Integrar páginas web con panel de nav egación.
Tipo de Tarea Desarrollo Puntos Estimados 3
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción Integrar las páginas informativas con el panel de navegación en la página web del buscador de personajes.
Tab la 126 Tarea de ingeniería No 34
Tarea de Ingeniería
Número de Tarea 35 Número de historia 19
Nombre de Tarea Construir componente web de f iltro de nodos
Tipo de Tarea Desarrollo Puntos Estimados 3
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción Construir los componentes web que realizan los filtros de nodo sobre el grafo.
Tab la 127 Tarea de ingeniería No 35
Tarea de Ingeniería
Número de Tarea 36 Número de historia 19
Nombre de Tarea Construir consultas de f iltros
Tipo de Tarea Desarrollo Puntos Estimados 1
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Construir las consultas en Neo4j que se encargan de realizar los filtros sobre el grafo y obtener la nuev a estructura del grafo
Tab la 128 Tarea de ingeniería No 36
134
Tarea de Ingeniería
Número de Tarea 37 Número de historia 19
Nombre de Tarea Obtener estructura de nodos
Tipo de Tarea Desarrollo Puntos Estimados 2
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Construir el componente de software que obtenga la estructura de nodos sobre la ontología para el cargue de f iltros del grafo.
Tab la 129 Tarea de ingeniería No 37
Tarea de Ingeniería
Número de Tarea 38 Número de historia 19
Nombre de Tarea Integrar f iltro con grafo y página de v isualización del grafo.
Tipo de Tarea Desarrollo Puntos Estimados 2
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Integrar los componentes de sof tware de los f iltros del grafo sobre el componente web que se encarga de v isualizar y construir el grafo.
Tab la 130 Tarea de ingeniería No 38
Tarea de Ingeniería
Número de Tarea 39 Número de historia 20
Nombre de Tarea Construir componente web camino entre nodos
Tipo de Tarea Desarrollo Puntos Estimados 4
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Construir los componentes web que se encargan de v isualizar los f iltros de camino entre nodos y el nuev o grafo que se v isualizara en un modal.
Tab la 131 Tarea de ingeniería No 39
Tarea de Ingeniería
Número de Tarea 40 Número de historia 20
Nombre de Tarea Construir consulta f iltro de caminos.
135
Tipo de Tarea Desarrollo Puntos Estimados 1
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción Construir la consulta sobre la base de datos de Neo4j que realiza el f iltro de caminos entre nodos y se obtiene la nueva estructura de nodos y relaciones.
Tab la 132 Tarea de ingeniería No 40
Tarea de Ingeniería
Número de Tarea 41 Número de historia 20
Nombre de Tarea Seleccionar nodos del graf o
Tipo de Tarea Desarrollo Puntos Estimados 3
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Realizar la nueva funcionalidad de permitir seleccionar nodos de tipo persona sobre el grafo principal para realizar el f iltro de caminos entre nodos.
Tab la 133 Tarea de ingeniería No 41
Tarea de Ingeniería
Número de Tarea 42 Número de historia 20
Nombre de Tarea Integrar componente web con página de v isualización del grafo.
Tipo de Tarea Desarrollo Puntos Estimados 2
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Integrar los componentes web y de sof tware con la página que v isualiza el grafo. El nuev o grafo debe desplegarse en un modal.
Tab la 134 Tarea de ingeniería No 42
Tarea de Ingeniería
Número de Tarea 43 Número de historia 21
Nombre de Tarea Visualizar inf ormación básica del nodo
Tipo de Tarea Desarrollo Puntos Estimados
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
136
Tab la 135 Tarea de ingeniería No 43
Tarea de Ingeniería
Número de Tarea 44 Número de historia 21
Nombre de Tarea Visualizar inf ormación básica de la relación
Tipo de Tarea Desarrollo Puntos Estimados
Responsable Juan Manuel Pérez, Romario Sánchez
Descripción
Tab la 136 Tarea de ingeniería No 44
Pruebas de aceptación
De la Tabla 137 a la Tabla 141 se encuentran las pruebas de aceptación realizadas
para las historias de usuario que fueron definidas en la sexta iteración.
Prueba de aceptación
Número de prueba 23 Número de historia 17
Nombre de prueba Env iar solicitud de contacto
Condiciones de ejecución El usuario debe realizar click en el menú superior llamado “Contacto”
Entradas/Pasos
● Ingresar correo electrónico, nombre y razón de contacto.
● Realizar click en “Enviar”.
● Obtener información ingresada por el usuario y enviar información a
un correo electrónico definido por el administrador del sitio.
Resultado esperado
El administrador del sitio debe recibir un correo electrónico con la información
ingresada y env iada por el usuario.
Estado Aceptada
Tab la 137 Prueba de aceptación No 23
Prueba de aceptación
Número de prueba 24 Número de historia 17
Nombre de prueba Visualizar página inf ormativ a del grupo
Condiciones de ejecución Ninguna
137
Entradas/Pasos
● Hacer click en el menú superior en la opción “Nosotros”.
● Redireccionar sitio a página web informativa del grupo.
● Consultar y visualizar la información del grupo.
Resultado esperado Una página web con toda la inf ormación del grupo de inv estigación.
Estado Aceptada
Tab la 138 Prueba de aceptación No 24
Prueba de aceptación
Número de prueba 25 Número de historia 17
Nombre de prueba Visualizar página de f uncionamiento del aplicativ o
Condiciones de ejecución Ninguna
Entradas/Pasos
● Hacer click en el menú superior en la opción “Como funciona”.
● Redireccionar sitio a página web de funcionamiento del aplicativo.
● Consultar y visualizar la información de cómo funciona el sitio web.
Resultado esperado Una página web con toda la inf ormación y f uncionamiento del sitio web.
Estado Aceptada
Tab la 139 Prueba de aceptación No 25
Prueba de aceptación
Número de prueba 26 Número de historia 18
Nombre de prueba Realizar f iltro de nodos
Condiciones de ejecución El usuario debe consultar el grafo de un personaje.
Entradas/Pasos
● Seleccionar los nodos y nivel de profundidad deseados.
● Hacer click en “Actualizar”.
● Consultar grafo con filtros seleccionados.
● Dibujar nuevo grafo con los filtros previamente seleccionados
Resultado esperado Un nuev o grafo con los f iltros seleccionados por el usuario.
Estado Aceptada
Tab la 140 Prueba de aceptación No 26
Prueba de aceptación
138
Número de prueba 27 Número de historia 19
Nombre de prueba Realizar f iltro de caminos entre nodos
Condiciones de ejecución El usuario debe consultar el grafo de un personaje.
Entradas/Pasos
● Colocar en estado “ON” el switch “Seleccionar nodos” en el panel de
f iltros.
● Seleccionar los nodos en el grafo con los que se quiere buscar
caminos.
● Hacer click en “Actualizar”.
● Consultar grafo con nodos seleccionados.
● Desplegar una modal con el nuevo grafo.
Resultado esperado
Un grafo con todos los caminos entre los nodos seleccionados por el usuario
en una nuev a modal.
Estado Aceptada
Tab la 141 Prueba de aceptación No 27
