Prototipo de Herramienta que Permita Identificar Relaciones de Pertenencia en el Entorno Público Utilizando un Motor de Bases de Datos NoSQL

Texto completo

(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 1.

(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 2.

(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 herram ientas b rindadas durante todo este proceso para com pletar este trab ajo satisfactoriam ente. A nuestra fam ilia y am igos por sus consejos, com prensión y estar con nosotros cuando m ás lo necesitáb am os b rindándonos todo su apoyo. A la profesora Alb a Consuelo Nieto Lem us, quien siem pre estuvo dispuesta a colab orarnos, orientarnos y com partir sus conocim ientos. A los com pañeros del grupo de investigación GESDATOS por com partir sus conocim ientos con nosotros.. 3.

(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.. 5.. 6.. 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. OBJETIVOS ............................................................................................................... 28 5.1.. OBJETIVO GENERAL ....................................................................................... 28. 5.2.. OBJETIVOS ESPECÍFICOS ............................................................................. 28. DESARROLLO DE LA METODOLOGÍA ............................................................... 29 6.1.. 7.. MARCO TECNOLÓGICO.................................................................................. 23. ARTEFACTOS DEFINIDOS ............................................................................. 29. DESARROLLO DE LA PROPUESTA .................................................................... 31 7.1.. ARQUITECTURA DEL SISTEMA .................................................................... 31. 7.2.. DESARROLLO METODOLÓGICO.................................................................. 32. 7.2.1.. Primera iteración.......................................................................................... 34 4.

(5) 8.. 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. 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. 5.

(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 6.

(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 filtro 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. 7.

(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 8.

(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 se xta 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. 9.

(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.. 10.

(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?. 11.

(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 Biukaghai 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 preprocesamiento 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.. 12.

(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, SeYoung, 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 TFIDF 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 13.

(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].. 14.

(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 15.

(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, 16.

(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 dim ensionalidad”. Entre las actividades más comunes están la eliminación de palabras irrelevantes, la lem atización o stem m ing (identificación de la raíz de cada 17.

(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]. 18.

(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 m odelamiento á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 b asado en prueb as (TDD), gestión ágil al cambio y refactorización de bases de datos [41]. 19.

(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 20.

(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. 21.

(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. 22.

(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. 23.

(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: 24.

(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, 25.

(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 26.

(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].. 27.

(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.. 28.

(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 Nombre de Historia Prioridad en Negocio Puntos estimados. Identif icador único. Usuario. Individuo que va interactuar con la f uncionalidad. Nombre de la historia de usuario Grado de importancia de la historia 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 b asado 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.. 29.

(30) Tarea de Ingeniería Número de Tarea Nombre de Tarea. identificador único. Número de historia. Número de historia a la que pertenece la 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 b asado 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 a la Número de historia que pertenece la prueba. Nombre de la prueba 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.. Nombre de la tarea o activ idad. Tab la 3 Plantilla prueb as de aceptación ((Diseño b asado 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.. 30.

(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. 31.

(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 32.

(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).. 33.

(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. 1. 2. 3. 4 5. Nombre. Descripción El sistema debe extraer la información de Wikipedia en Extraer información español de los personajes que sean solicitados por el de Wikipedia usuario 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 Def inición o desarrollo política colombiana. Luego de revisar y probar las distintas del crawler a utilizar opciones encontradas se elige el crawler Uru Realizar la integración del crawler Uru al aplicativo web por Integrar crawler en el medio del montaje de s us componentes de sof tware e aplicativo instalación de sus dependencias. 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 Cargar inf ormación semiestructurada. Para lo cual después de revisar varias del crawler opciones se determinó que la mejor era MongoDB. Construir servicio Realizar un servicio socket de tipo bidireccional que permita socket env iar y recibir información entre Python y Node.js.. Estado. Rechazada. Aceptada. Aceptada. Aceptada 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. 34.

(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. 35.