prototipo de herramienta de software para la...

PROTOTIPO DE HERRAMIENTA DE SOFTWARE PARA LA EXTRACCIÓN DE INFORMACIÓN EN DOCUMENTOS PDF UTILIZANDO UN MOTOR DE BASES

DE DATOS NOSQL

EDISON ARMANDO ROBLES MORALES

ANDREA NATHALY PARRA BAQUERO

Proyecto de grado

SONIA ORDOÑEZ

DOCTORA EN INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD DE INGENIERÍA

INGENIERÍA DE SISTEMAS

BOGOTÁ

2017

TABLA DE CONTENIDO

INTRODUCCIÓN ..................................................................................................... 9

1. PLANTEAMIENTO DEL PROBLEMA ............................................................. 10

2. MARCO TEÓRICO ......................................................................................... 12

2.1 CRAWLER ................................................................................................ 12

2.2 PROCESAMIENTO DE LENGUAJE NATURAL ....................................... 12

2.3 EXTRACCIÓN DE INFORMACIÓN .......................................................... 13

2.4 RECONOCIMIENTO OCR ........................................................................ 13

2.5 JSON ........................................................................................................ 14

2.6 BASES DE DATOS NO SQL .................................................................... 14

2.7 RECUPERACIÓN DE INFORMACIÓN ..................................................... 14

2.8 METODOLOGÍA ÁGIL EXTREME PROGRAMMING XP ......................... 15

3. MARCO REFERENCIAL ................................................................................ 17

3.1 PROTOTIPO INFORMÁTICO PARA EXTRACCIÓN DE RECURSOS DIGITALES SOBRE INTERNET ........................................................................ 17

3.2 CRAWNET: CRAWLER DE RECURSOS MULTIMEDIA PARA LA WEB SUPERFICIAL Y OCULTA ................................................................................. 17

3.3 GOOGLE’S DEEP WEB CRAWL ............................................................. 17

3.4 DEEP BOT: A FOCUSED CRAWLER FOR ACCESING HIDDEN WEB CONTENT .......................................................................................................... 18

4. ESTADO DEL ARTE ...................................................................................... 19

5. OBJETIVOS .................................................................................................... 20

6. METODOLOGÍA ............................................................................................. 21

6.1 Definición de iteraciones y etapas ............................................................ 21

6.2 Resultados esperados por etapa .............................................................. 22

7. DESARROLLO DE LA HERRAMIENTA MASK’AY ........................................ 24

7.1 Primera iteración ....................................................................................... 24

7.1.1 Historias de usuario ............................................................................ 24

7.1.1.1 Rastreo de enlaces. ............................................................................ 25

7.1.1.2 Extracción de documentos PDF. ........................................................ 25

7.1.1.3 Guardar resultados de la extracción ................................................... 26

7.1.2 Tareas de ingeniería. ......................................................................... 27

7.1.3 Resultados de la primera iteración. .................................................... 28

7.1.4 Pruebas de aceptación ....................................................................... 34

7.2 Segunda iteración ..................................................................................... 34

7.2.1 Historias de usuario ............................................................................ 34

7.2.3 Resultados de la segunda iteración ................................................... 37

7.2.3.4 Limpieza del buffer de documentos descargados ............................... 38

7.2.3.5. Diagrama de actividades ................................................................... 38

7.2.4. Pruebas de aceptación. ........................................................................ 39

7.3 Tercera iteración ....................................................................................... 40

7.3.1 Historias de usuario. .............................................................................. 40

7.3.2 Tareas de ingeniería. ............................................................................. 41

7.3.3 Resultados de la tercera iteración. ........................................................ 43

7.3.3.2 Búsqueda de la cadena por párrafo. ................................................... 43

7.4 Cuarta iteración ........................................................................................ 45

7.4.1 Historias de usuario. .............................................................................. 45

7.4.2 Tareas de ingeniería. ............................................................................. 46

7.4.3 Resultados de la cuarta iteración. .......................................................... 48

7.4.3.3 Pantalla para el ingreso de la búsqueda. ............................................ 51

8. PRUEBAS CON LA HERRAMIENTA MASK’AY ............................................. 56

8.1 Pruebas de rendimiento ............................................................................ 56

8.2 Pruebas del usuario final .......................................................................... 56

9. TRABAJO FUTURO ....................................................................................... 60

10. CONCLUSIONES ........................................................................................ 61

11. BIBLIOGRAFÍA ............................................................................................ 62

LISTA DE FIGURAS

Figura 1. Arquitectura de un sistema de recuperación de información. (Ramírez Benavidez, 2012) ................................................................................................... 10

Figura 2. Esquema de un Sistema de Recuperación de Información (Tolosa & Bordignon, 2007) ................................................................................................... 15

Figura 3. Metodología Extreme Programming (Wells, 2000) ................................. 16

Figura 4. Estructura clave-valor en REDIS para enlaces (Diseño propio) ............ 25

Figura 5. Estructura clave-valor en REDIS para enlaces a documentos (Diseño propio) .................................................................................................................... 26

Figura 6. Estructura en MONGO DB(Diseño propio) ............................................. 27

Figura 7. Pseudocógico de buscar enlaces (Diseño propio) .................................. 28

Figura 8. Diagrama de Flujo de modificar URL (Diseño propio)............................. 29

Figura 9. Pseudocódigo de revisar enlaces repetidos (Diseño Propio) .................. 29

Figura 10. Ejemplo de almacenamiento de información de documento PDF en MongoDB ............................................................................................................... 30

Figura 11. Diagrama de la arquitectura durante la primera iteración. (Scrapy Developers, 2016) .................................................................................................. 31

Figura 12. Diagrama de Actividades del componente de rastreo .......................... 33

Figura 13. Convertir PDF a texto (Diseño propio) ................................................. 37

Figura 14. Pseudocódigo para convertir PDF a texto (Diseño propio) ................... 38

Figura 15. Pseudocódigo de limpiar buffer (Diseño propio) ................................... 38

Figura 16. Diagrama de Actividades componente de transformación .................... 39

Figura 17. Pseudocódigo para hacer descomposición en párrafos (Diseño propio) ............................................................................................................................... 43

Figura 18. Pseudocódigo para contar coincidencias (Diseño propio) .................... 43

Figura 19. Pseudocódigo para buscar cadena (Diseño propio) ............................. 44

Figura 20. Almacenamiento de correos electrónicos (Diseño propio) .................... 47

Figura 21. Almacenamiento de un enlace (Diseño propio) .................................... 48

Figura 22. Diagrama de colaboración (Diseño propio) ........................................... 49

Figura 23. Arquitectura de tres capas (Basado en (Ruiz & Delgado, 2017)) ......... 50

Figura 24. Diagrama de componentes (Diseño propio) ......................................... 51

Figura 25. Pantalla de ingreso de datos para la búsqueda (Diseño propio) .......... 52

Figura 26. Resultados de la búsqueda (Diseño propio) ......................................... 52

Figura 27. Ingreso al módulo administrador (Diseño propio) ................................. 53

Figura 28. Pantalla de edición para palabras restringidas (Diseño propio) ............ 53

Figura 29. Pseudocódigo para registrar un correo electrónico (Diseño propio) ..... 54

Figura 30. Pseudocódigo para enviar notificación (Diseño propio) ........................ 54

Figura 31 Percepción del Tiempo de respuesta (Diseño propio) ........................... 58

Figura 32 Percepción de la efectividad de la consulta (Diseño propio) .................. 59

Figura 33 Percepción de la utilidad de la herramienta (Diseño propio) .................. 59

LISTA DE TABLAS

Tabla 1. Definición de iteraciones y etapas para el desarrollo de la herramienta (Ruiz & Delgado, 2017) ................................................................................................... 21

Tabla 2. Formato para describir una historia de usuario (Ruiz & Delgado, 2017) .. 22

Tabla 3. Formato para describir tareas de ingeniería (Ruiz & Delgado, 2017) ...... 23

Tabla 4. Formato para describir prueba de aceptación (Ruiz & Delgado, 2017) ... 23

Tabla 5. Resumen de historias de usuario de iteración 1(Diseño propio) .............. 24

Tabla 6. Resumen de las tareas de ingeniería de la iteración 1(Diseño propio) .... 27

Tabla 7. Resumen de pruebas de aceptación de la iteración 1 (Diseño propio) .... 34

Tabla 8. Resumen de historias de usuario de la iteración 2(Diseño propio) .......... 35

Tabla 9. Resumen de las tareas de ingeniería de la iteración 2 (Diseño propio) ... 36

Tabla 10. Comparación librerías de conversión PDF a archivo de texto (Diseño propio) .................................................................................................................... 36

Tabla 11. Comparación de herramientas para reconocimiento óptico de caracteres (Diseño propio) ...................................................................................................... 37

Tabla 12. Resumen de pruebas de aceptación de la iteración 2 (Diseño propio) . 39

Tabla 13. Resumen de historias de usuario de iteración 3 (Diseño propio) ........... 40

Tabla 14. Resumen de tareas de ingeniería de iteración 3(Diseño propio) ........... 41

Tabla 15. Comparación librerías para NER (Diseño propio) .................................. 42

Tabla 16. Resumen de pruebas de aceptación de iteración 3(Diseño propio) ....... 44

Tabla 17. Resumen de historias de usuario iteración 4(Diseño propio) ................. 45

Tabla 18. Resumen de tareas de ingeniería iteración 4 (Diseño propio) ............... 46

Tabla 19. Resumen de pruebas de aceptación de iteración 4(Diseño propio) ....... 55

Tabla 20. Sitios web rastreados por primera vez (Diseño propio) .......................... 56

Tabla 21. Tiempos de extracción de información (Diseño propio) ......................... 57

Tabla 22. Tipos de documento PDF incluidos en las pruebas (Diseño propio) ...... 57

9

INTRODUCCIÓN

Uno de los resultados de la revolución tecnológica que ha tenido lugar en los últimos 60 años debido a la invención del internet, es un enorme repositorio en el que algunas veces buscar un documento resulta ser una tarea dispendiosa pese al desarrollo de potentes motores de búsqueda.

Actualmente, la web ofrece un gran cúmulo de información sobre variados temas y en diferentes formatos a la que se puede acceder desde cualquier lugar y se encuentra disponible para cualquier persona. Sin embargo, y pese a esta disposición, la búsqueda no es tan fácil como se quisiera, pues en muchas ocasiones el formato de los documentos impide realizar búsquedas de manera automática obligando a que el usuario deba leer uno o varios documentos para encontrar la información relevante a la búsqueda. Es el caso de los documentos que vienen en formato PDF y que son producto de un proceso óptico.

Por lo anterior, en este trabajo se documenta el desarrollo de un prototipo de software que a través de técnicas propias del procesamiento del lenguaje natural busca y recupera información de un documento en formato PDF (imagen o no). Dicha búsqueda se hace a partir de una entidad nombrada (persona, lugar, cosa, empresa, entre otros) expresada en lenguaje natural y un localizador uniforme de recurso (URL). Como resultado de la búsqueda sistemática dentro del sitio identificado mediante la URL (incluyendo todas las dependencias virtuales) recupera los PDF y la información de los párrafos donde aparece dicha entidad.

Para la presentación de esta propuesta, en el capítulo 1 se muestra el planteamiento del problema para contextualizar el espacio, el tiempo y el modo como se muestra la problemática. El capítulo 2 presenta el marco teórico en el cual se describen conceptos relacionados con el problema mientras que en el capítulo 3 se dan a conocer descripciones de documentos que sirven como referencia en la búsqueda de una solución. Seguido a esto, en el capítulo 4 se presenta el estado del arte el cual da una perspectiva de lo que ha sido la evolución de herramientas de rastreo hasta la actualidad. En el capítulo 6 se describe detalladamente la metodología que se llevó a cabo para realizar este proyecto. Finalmente, en el capítulo 8 y 9 se presenta el desarrollo de la herramienta y las pruebas que se realizaron a la misma.

10

1. PLANTEAMIENTO DEL PROBLEMA

Los sistemas de recuperación de información permiten la búsqueda y almacenamiento de grandes cantidades de datos para ser mostrados al usuario. Un sistema de recuperación de información es un buscador en general se compone de: 1) un Crawler que recorre la web buscando las páginas que serán indexadas, 2) un indexador, que mantiene un índice con las páginas recolectadas, 3) motor de búsqueda, que realiza las búsquedas en el índice y finalmente 4) una interfaz para que el usuario pueda realizar sus peticiones y visualizar los resultados (Ramírez Benavidez, 2012). En la Figura 1, se muestra un diagrama de la arquitectura de un buscador donde se puede observar su funcionamiento.

Figura 1. Arquitectura de un sistema de recuperación de información. (Ramírez Benavidez, 2012)

Las herramientas de búsqueda en la web o los Sistemas de Recuperación de Información “permiten identificar páginas web que resulten relevantes para satisfacer la necesidad de información”1, sin embargo, estas se limitan a encontrar una palabra o un conjunto de

1 Martínez Mendez, F. J. (2004). Digitum. Recuperado el 4 de Noviembre de 2016, de

https://digitum.um.es/xmlui/bitstream/10201/4316/1/libro-ri.PDF. Pág 15

https://digitum.um.es/xmlui/bitstream/10201/4316/1/libro-ri.PDF

11

palabras en la mayor cantidad de páginas disponibles en la web, ocasionando que los usuarios encuentren mucha información irrelevante para sus búsquedas en documentos.

Para el caso de búsquedas sobre documentos que se encuentren en formato PDF, los Sistemas de Recuperación de Información proveen la lista de enlaces donde se encuentran los caracteres que coinciden con la búsqueda, pero no permiten extractar los párrafos que los contienen. Lo anterior se puede observar, cuando se quiere buscar los artículos de las leyes correspondientes a un tema, por ejemplo, si se busca ley de educación saldrán varios resultados con el enlace del documento y el renglón donde coinciden las palabras ingresadas para la búsqueda, sin embargo, no es posible saber que dice explícitamente cada uno de los artículos. Para poder leer y extraer los apartes de interés donde se menciona una persona, por ejemplo, es necesario recorrer manualmente cada uno de los documentos que arrojé la búsqueda. La tarea que se encarga de extractar segmentos de texto relativos a una búsqueda se conoce como Extracción de información, mientras que los Sistemas de Recuperación de Información se ocupan de recuperar los enlaces de los documentos relevantes a una consulta.

Por otro lado, cuando los PDF son generados a partir de procesos ópticos los Sistemas de Recuperación de Información que generalmente se basan en texto, no pueden ubicar las palabras dentro del documento. Actualmente, las herramientas de búsqueda especializadas en la extracción de información de documentos en formato PDF generados a partir de procesos ópticos son escasos y más, si se buscan bajo licencia libre. Por esta razón que se plantea la siguiente pregunta: ¿Se pueden simplificar las búsquedas de información en documentos PDF alojados en un dominio, sin importar si han pasado por un proceso óptico previo, a través de métodos automáticos y bases de datos NoSql?

12

2. MARCO TEÓRICO

El marco teórico da a conocer los conceptos relevantes en el contexto del proyecto desarrollado.

Se ha identificado que los conceptos base para el proyecto son: Crawler, Procesamiento de Lenguaje Natural, Extracción de Información, Reconocimiento OCR, Json, Bases de datos NO SQL, Recuperación de Información y Metodología Extreme Programming. La herramienta a construir utilizará un Crawler para hacer rastreo de documentos en la web, a partir de una búsqueda que ingresa el usuario por lo cual es necesario hacer procesamiento de lenguaje natural.

Por otro lado, la herramienta permite la extracción de información y es necesario tener claro la diferencia entre ambos conceptos. El almacenamiento de la información se llevará a cabo usando bases de datos NoSql y objetos Json. Finalmente, la metodología de desarrollo que se aplicará es Extreme Programming por lo cual es necesario conocer sus principios.

2.1 CRAWLER

Un web Crawler es un programa que inspecciona páginas web de forma metódica y automatizada (Kobayashi & Takeda, 2000). Los motores de búsqueda utilizan un Crawler para poder visitar diferentes páginas web y de esa manera encontrar resultados que concuerden con la búsqueda. El funcionamiento de los Web Crawler consiste en visitar una lista de URLs, luego identificar los enlaces y agregarlos a la lista de URLs (Ramírez Benavidez, 2012). En otras palabras, un Web Crawler debe recibir una URL semilla de donde se extraerán todos los enlaces que esta contenga y los guardará en un repositorio para acceder a ellos recurrentemente.

2.2 PROCESAMIENTO DE LENGUAJE NATURAL

El procesamiento de Lenguaje Natural es un área de investigación de la Inteligencia Artificial que tiene como objetivo lograr la interacción de personas y computadores utilizando el lenguaje cotidiano. Un aspecto fundamental es que gran parte del conocimiento humano se encuentra codificado en lenguaje natural escrito o hablado, por esta razón existen productos comerciales que realizan diversos tipos de tareas relacionadas con el procesamiento de lenguaje natural. Entre estos se encuentran: 1) sistemas de consulta en lenguaje natural de bases de datos, 2) sistemas de búsqueda, 3) reconocimiento y categorización de textos, 4) sistemas de traducción automática, entre otros (Pino, Gómez, & Martínez, 2001).

13

2.3 EXTRACCIÓN DE INFORMACIÓN

La extracción de información es el proceso de transformar texto a un formato estructurado desde diferentes tipos de documentos que se encuentran en lenguaje natural. Para llevar a cabo dicho proceso es preciso definir reglas de extracción las cuales permitan identificar la información que se extraerá de manera correcta. (Martínez Mendez, 2004)

Por otra parte, la extracción de información se puede hacer desde diferentes tipos de texto: 1) texto libre, 2) texto estructurado y 3) texto semiestructurado. En el texto libre la extracción de información se hace tomando textos cortos de lenguaje natural y extraer un rango de palabras claves. Mientras que en el texto estructurado es definida una información textual en una base de datos o archivo con un formato predefinido y el texto semiestructurado es una combinación de los dos anteriores.

Los documentos de las páginas web pueden ser semiestructurados o no estructurados, los semiestructurados pueden contener tuplas con atributos ocultos mientras que los no estructurados exigen tener conocimiento lingüístico para extraer los atributos correctamente (ibídem).

Los criterios de extracción de los datos pueden ser léxicos, sintácticos, semánticos o de discurso. El patrón más usado para hacer extracción de información es el sintáctico, que consiste en identificar la categoría gramatical a la que pertenece una palabra y hacer un etiquetado conocido como pos-tag que permita reconocer características morfológicas y sintácticas del lenguaje, por ejemplo los nombres o sustantivos generalmente designan personas, lugares, cosas, y otros conceptos físicos y abstractos; los verbos suelen utilizarse para designar acciones y procesos y los adjetivos describen propiedades y estados de los nombres (Beltrán, 2007).

2.4 RECONOCIMIENTO OCR

Las técnicas de reconocimiento de caracteres asocian una identidad simbólica con la imagen de un carácter. El reconocimiento de caracteres ópticos (en inglés Optical Character Recognition OCR) aborda el problema de reconocimiento de caracteres ópticamente procesados (Verma, Arora, & Verma, 2016).

El reconocimiento óptico de caracteres se compone de las fases (Eikvil, Optical Character Recognition, 1993):

1. Escaneado óptico: Mejora la imagen de acuerdo a un umbral de visibilidad configurado. 2. Localización y segmentación: Determina los componentes de una imagen y localizar las

regiones en las que se han impreso datos. 3. Pre-procesado: Elimina defectos y suaviza los caracteres. 4. Extracción de características: Captura características esenciales de los símbolos.

14

5. Clasificación: Identifica cada carácter y asigna una clase de carácter correcto. 6. Post-procesado, asocia los símbolos a cadenas mediante agrupación de los mismos.

2.5 JSON

JavaScript Object Notation es un formato diseñado para ser un lenguaje de intercambio de datos legible y fácil para los computadores (Crockford, 2006). Es importante mencionar que la principal ventaja de JSON es la facilidad de escritura y debido a esto ha tenido gran aceptación por parte de la comunidad de desarrolladores.

El formato JSON es usado usualmente en aplicaciones donde deben intercambiarse objetos entre el cliente (navegador) y el servidor. Adicionalmente los objetos JSON son una colección de pares (nombre, valor) que representan cuatro tipos primitivos (strings, numbers, booleans and null) y dos tipos estructurados (objetos y arreglos) (Nurseitov, Paulson, Reynolds, & Izurieta, 2006).

2.6 BASES DE DATOS NO SQL

Las bases de datos NoSQL son fácilmente escalables, ofrecen mínimos tiempos de consulta y pueden trabajar con grandes volúmenes de datos. Sin embargo, no garantizan las propiedades ACID (Atominicidad, Consistencia, Aislamiento, Durabilidad). (Fernández, 2012)

Un ejemplo de base de datos NoSQL es MongoDB, reconocida base de datos que almacena objetos en formato muy similar a JSON y resulta ser eficiente para aplicaciones que requieran: hacer la búsqueda por campos, consultar rangos y expresiones regulares, indexar cualquier campo en un documento, replicar y hacer balanceo de carga entre otros. (Polo, 2015)

2.7 RECUPERACIÓN DE INFORMACIÓN

La recuperación de información es un proceso que permite entregar al usuario enlaces o referencias de documentos relativos a una consulta planteada en lenguaje natural. En la Figura 2 se puede observar el funcionamiento de un sistema de recuperación de información, compuesto por: una colección de documentos, usuarios con necesidades de información y referencias a documentos relevantes para la búsqueda de un usuario (Tolosa & Bordignon, 2007).

15

Figura 2. Esquema de un Sistema de Recuperación de Información (Tolosa & Bordignon, 2007)

2.8 METODOLOGÍA ÁGIL EXTREME PROGRAMMING XP

Es una metodología ágil enfocada en resolver los problemas de entrega de software a tiempo y las necesidades cambiantes del cliente durante el proceso de desarrollo. Surgió a partir de las ideas de Kent Beck y Ward Cunningham y se utilizó por primera vez en 1996. Es adecuada para proyectos cortos que involucren pequeños y medianos equipos de desarrollo. Su característica principal es emplear al extremo las buenas prácticas de la Ingeniería de Software. (Noriega, 2015)

La metodología Extreme Programming sugiere aplicar las siguientes prácticas:

Mantener comunicación continua con el cliente permitiéndole una participación durante el desarrollo del proyecto.

Teniendo en cuenta las necesidades descritas en pequeñas tarjetas llamadas historias de usuario se planifican las funcionalidades.

La programación se lleva a cabo por dos desarrolladores permitiendo la constante revisión de código.

Entregar versiones actualizadas del software al cliente a lo largo del proceso de desarrollo.

Los desarrolladores escriben pruebas antes de hacer la codificación con el fin de que se haga un diseño de métodos y clases antes de iniciar la construcción del software.

Se lleva a cabo una reorganización del código fuente para mejorar la calidad interna haciendo el código más legible.

Establecer estándares de codificación

Hacer integración del código continuamente

16

Reuniones de trabajo para evaluar el trabajo ejecutado el día anterior. (Laínez Fuentes, 2015)

En la ¡Error! No se encuentra el origen de la referencia.Figura 3 se puede observar el proceso que se lleva a cabo para aplicar la Metodología Extreme Programming, inicialmente se lleva a cabo la identificación de las historias de usuario, luego se hace una fase de planeación por iteraciones, cada iteración tiene una fase de pruebas de aceptación que determinan si se continua con una nueva iteración o se deben resolver los defectos encontrados y finalmente se hacen entregas incrementales al cliente.

Figura 3. Metodología Extreme Programming (Wells, 2000)

17

3. MARCO REFERENCIAL

En este ítem se incluye la revisión de herramientas que puedan incluir algunos de los elementos objeto de este trabajo y que sirvan de apoyo para el desarrollo del mismo.

3.1 PROTOTIPO INFORMÁTICO PARA EXTRACCIÓN DE RECURSOS DIGITALES SOBRE INTERNET

Este prototipo informático es una herramienta diseñada para explorar recursos digitales de una librería denominada Europeana. (Gaona, Sánchez, & Gaona, 2013). La extracción de se realiza de acuerdo a los metadatos del PDF para luego poder clasificarlos y almacenarlos. El autor menciona que una de las principales desventajas del desarrollo de herramientas de extracción de datos sobre internet es que la estructura semántica de la URL cambia a través del tiempo. El modo de funcionamiento de dicha herramienta consiste en realizar una consulta de términos a la librería digital en la cual se identifican el número de recursos por término, posteriormente se extraen dichos recursos y se almacenan en una base de datos.

3.2 CRAWNET: CRAWLER DE RECURSOS MULTIMEDIA PARA LA WEB SUPERFICIAL Y OCULTA

La herramienta Crawnet (Pedroza, Pach-May, Martínez, & Estrada, 2015) permite realizar búsquedas, consultas y análisis de información en la web superficial y oculta. Es importante mencionar que la web oculta se define como aquella que contiene información a la que no es posible acceder mediante un motor de búsqueda tradicional, porque su contenido se encuentra detrás de formularios HTML que deben ser diligenciados manualmente para ver los documentos. Crawnet fue desarrollado con dos algoritmos: el primero permite acceder a la web superficial y el segundo para la web oculta. El primer algoritmo consiste en recuperar todos los enlaces existentes en el contenido HTML de una URL, posteriormente seleccionarlos y clasificarlos mediante el uso de patrones y por último almacenarlos en una base de datos. Mientras que el segundo tiene cuatro pasos: busca los parámetros solicitados en el formulario, extrae las propiedades que definen los elementos HTML, asigna y envía datos al formulario y finalmente procesa el contenido generado a partir de las consultas realizadas.

3.3 GOOGLE’S DEEP WEB CRAWL

Es un sistema para rastrear la web oculta, a partir de la recolección de información del código de los formularios HTML. Dicha herramienta tiene un algoritmo que permite la

18

recolección de todas las posibles entradas de datos a un campo y utiliza como estrategia un producto cartesiano que arroja todas las potenciales combinaciones. La herramienta fue desarrollada para aproximadamente 45 lenguajes y cientos de dominios. En el desarrollo de la herramienta se identificaron dos retos principales: decidir qué entradas diligenciar en el formulario para enviar las consultas y la segunda encontrar valores apropiados para diligenciar estas entradas (Madhavan, y otros, 2008).

3.4 DEEP BOT: A FOCUSED CRAWLER FOR ACCESING HIDDEN WEB CONTENT

Esta herramienta permite hacer búsquedas en la web oculta a partir del procesamiento del código del formulario. El proceso para buscar en cada formulario consiste en tres pasos: el primero, para cada dominio el sistema intenta encontrar sus atributos con los campos de los formularios usando una distancia visual y heurísticas de similitud en el texto; para usar la salida del paso anterior, el sistema determina si el formulario es relevante con respecto al dominio; si el formulario es relevante, el Crawler usa este para ejecutar las consultas definidas en el dominio. Para cada consulta, se obtiene una nueva ruta para añadir a la lista de rutas (Alvarez, Raposo, & Pan, 2007).

19

4. ESTADO DEL ARTE

El estado del arte muestra trabajos de investigación que se han llevado a cabo para resolver problemas similares permitiendo contextualizar la información relevante. En el trabajo presentado (Alvarez, Raposo, & Pan, 2007), implementan un Crawler que funciona a partir de una URL semilla, una palabra clave o la ruta de un archivo de texto con los datos de entrada, dicha herramienta procede a buscar en internet todos los enlaces que contengan la palabra clave o se encuentren en la URL o estén asociados al archivo de texto y luego los muestra en una ventana. El rastreador web diseñado es capaz de comparar el texto encontrado en un enlace con el archivo de texto de entrada. El rastreador utiliza algoritmos de reconocimiento de patrones y genera el número de veces que el texto de entrada existe en el texto encontrado en un enlace. El rastreador realiza el reconocimiento de patrones usando tres algoritmos independientes y genera el número de reconocimientos realizados por cada algoritmo, de esta manera la información generada da una idea de la eficiencia del algoritmo (Gupta & Johari, 2009).

De otro lado, para búsquedas dentro de documentos se han planteado metodologías como la descrita en (Gupta & Johari, 2009) la cual permite analizar archivos PDF y encontrar palabras claves, que serán usadas para crear archivos anclables y generar de manera automática la hipermedia del documento. Es importante mencionar que hipermedia se denomina a la combinación de hipertexto y multimedia, y que para llevar este proceso se debe recurrir a técnicas como el reconocimiento de caracteres ópticos (OCR) (Chakraborty, Liu, & Hsu, 2003).

Así mismo, para llevar a cabo procesos de rastreo se ha planteado el uso de un Framework (Chakraborty, Liu, & Hsu, 2003) de modo que este permita tomar decisiones sobre el rastreo a partir de un análisis exhaustivo de la página, este enfoque ha revelado la mejora en la extracción de la información de los enlaces y sirve como guía al rastreador para obtener el dominio más relevante. La arquitectura del Framework tiene componentes como: controlador de rastreo, herramienta de rastreo, administrador de página, analizador de página y proveedor de contenido de página analizado (Kumar & Singh, 2015).

20

5. OBJETIVOS

OBJETIVO GENERAL

Desarrollar una herramienta de búsqueda para documentos PDF basada en la recuperación de información utilizando técnicas de procesamiento de lenguaje natural y en un motor de bases de datos NoSql.

OBJETIVOS ESPECIFÍCOS

Identificar los requerimientos funcionales y no funcionales para la construcción de la herramienta

Desarrollar el componente de rastreo para documentos PDF en español

Desarrollar el componente de recuperación para documentos PDF en español

Realizar el diseño de la arquitectura de la herramienta teniendo en cuenta los requerimientos identificados

Desarrollar el código necesario para cumplir con las funcionalidades de la herramienta

Realizar pruebas sobre la herramienta para garantizar su funcionalidad

21

6. METODOLOGÍA

Para el desarrollo de la herramienta se utilizó la metodología ágil Extreme Programming XP que garantiza las buenas prácticas en el desarrollo de software.

Es importante mencionar, que se seleccionó dicha metodología teniendo en cuenta que: a) es un proyecto corto que requiere emplear correctas prácticas de Ingeniería de software; b) la metodología sugiere que la codificación se haga por dos desarrolladores garantizando la continua revisión de código y de esta manera un producto que cumpla con estándares de programación; c) es un proyecto de tipo experimental donde podrán aparecer historias de usuario que se deban eliminar porque no dieron los resultados esperados, bifurcar cuando abarcan varias funcionalidades o modificar cuando cambian pequeños detalles.

6.1 DEFINICIÓN DE ITERACIONES Y ETAPAS

Teniendo en cuenta que la metodología XP propone la definición de iteraciones para desarrollar el producto final, se definió el desarrollo de un componente en cada iteración.

En la Tabla 1 se puede observar la definición de cuatro iteraciones y en cada iteración se llevan a cabo cuatro etapas de desarrollo de software: análisis, diseño, codificación y pruebas.

Tabla 1. Definición de iteraciones y etapas para el desarrollo de la herramienta (Ruiz & Delgado, 2017)

Iteración Componente Etapas

Análisis Diseño Codificación Pruebas

1 Componente de rastreo

Definición de las historias de usuario relacionadas con el componente.

Elaboración de diagramas que permitan plasmar la solución al requerimiento del usuario y definir las tareas de ingeniería que deberán llevarse a cabo por historia de usuario.

Elaboración de código para satisfacer las necesidades identificadas en las historias de usuario

Se realizan pruebas de aceptación por cada historia de usuario.

2 Componente de transformación

3 Componente de extracción

4 Componente de interfaz gráfica

22

6.2 RESULTADOS ESPERADOS POR ETAPA

En la etapa de análisis se obtuvieron las historias de usuario siguiendo el formato que se ve en la Tabla 2.

Tabla 2. Formato para describir una historia de usuario (Ruiz & Delgado, 2017)

Historia de Usuario

Número Número de la historia de usuario. Ejemplo HU1

Usuario Sistema

Nombre Nombre de la historia de usuario

Prioridad La prioridad se define como Alta, Media o Baja

Riesgo El riesgo se mide de 1 a 5, siendo 1 menos riesgoso y 5 más riesgoso.

Puntos

Los puntos corresponden al número de semanas que se emplearán para el desarrollo de la historia de usuario

Iteración Iteración en la cual se está desarrollando la historia de usuario

Programador Nombres de los programadores que desarrollan la historia de usuario

Descripción:

Breve descripción de la historia de usuario

Observaciones:

Observaciones pertinentes a la historia de usuario

En la etapa de diseño se realizaron diagramas de actividades para ilustrar el flujo de trabajo entre los usuarios y el sistema, y modelar elementos de arquitectura de software, tales como método, función y operación. Adicionalmente, se obtuvieron las tareas de ingeniería por cada historia de usuario siguiendo el formato que se muestra en la Tabla 3.

23

Tabla 3. Formato para describir tareas de ingeniería (Ruiz & Delgado, 2017)

Tarea de Ingeniería

Número Número de la tarea de ingeniería. Ejemplo TI1

Número Historia

Número de historia de usuario a la que pertenece la tarea de ingeniería.

Nombre Nombre de la tarea de ingeniería

Tipo Etapa a la que pertenece la tarea de ingeniería

Puntos Días que se emplearan para llevar a cabo la tarea de ingeniería

Fecha inicio Fecha en la que se inicia la ejecución de la tarea de ingeniería

Fecha fin Fecha en la que se finaliza la ejecución de la tarea de ingeniería

Programador Nombres de los programadores que desarrollan la tarea de ingeniería

Descripción:

Descripción de la tarea de ingeniería

En la etapa de codificación se realizaron los métodos y clases para resolver cada tarea de ingeniería.

Y finalmente en la etapa de pruebas se obtuvieron las pruebas de aceptación siguiendo el formato que se observa en la Tabla 4. En dicho formato se contempla un campo que especifica se la prueba ha sido Aceptada o Rechazada.

Tabla 4. Formato para describir prueba de aceptación (Ruiz & Delgado, 2017)

Prueba de Aceptación

Número Número de la prueba de aceptación. Ejemplo ‘PA1’

Número Historia

Número de historia de usuario a la que pertenece la prueba de aceptación.

Nombre Nombre de la prueba de aceptación.

Condición Requisito para llevar a cabo la prueba de aceptación.

Entrada Entradas para llevar a cabo la prueba de aceptación

Resultado esperado

Comportamiento esperado luego de ejecutar la prueba.

Evaluación Se especifica si la prueba ha sido Aceptada o Rechazada.

24

7. DESARROLLO DE LA HERRAMIENTA MASK’AY

La herramienta se construyó utilizando la metodología XP, como ya se mencionó en el capítulo 6, para lo cual se incluyeron cuatro iteraciones, cada iteración permitió el desarrollo de un componente.

7.1 PRIMERA ITERACIÓN

El componente de rastreo permite a partir de una URL, recorrer dentro del sitio y sus sub-sitios todos los enlaces que contenga una página web y encontrar aquellos que sean documentos PDF para guardarlos y procesarlos posteriormente.

La primera iteración comprende el desarrollo del componente de rastreo, para el cual se plantearon sus respectivas historias de usuario y tareas de ingeniería, y posteriormente se hicieron las pruebas de aceptación.

7.1.1 Historias de usuario. En la Tabla 5 se muestran las historias de usuario para la primera iteración.

Tabla 5. Resumen de historias de usuario de iteración 1(Diseño propio)

No Nombre de historia de usuario

Descripción Estado

HU1 Rastreo de enlaces El sistema debe analizar el código de la página web enviada en busca de todos los enlaces en un tiempo límite de 10 minutos.

Rechazada

HU2 Rastreo de enlaces usando Framework

El sistema debe analizar el código de la página web enviada en busca de todos los enlaces en un tiempo límite de 10 minutos.

Aceptada

HU3 Extracción de documentos PDF

El sistema debe guardar los documentos sin repetir en el servidor.

Aceptada

HU4 Guardar resultados de la extracción

El sistema debe guardar en una base de datos la información de los documentos que fueron descargados.

Aceptada

25

7.1.1.1 Rastreo de enlaces. Para realizar el Rastreo de enlaces primero se experimentó creando una clase y utilizando librerías de Python para realizar peticiones a una página web y luego extraer los enlaces que se encontraban allí, el resultado esperado era la obtención de los enlaces de un dominio en 10 minutos, pero el tiempo para que terminara el rastreo superaba el límite establecido.

Por esta razón se optó por utilizar un Framework de código abierto para extracción de información que se llama Scrapy, el cual es extensible y de fácil uso, se realizaron las debidas configuraciones para que realizara el rastreo de los enlaces como lo requería el proyecto y lograr extraer los documentos PDF de la página web ingresada.

7.1.1.2 Extracción de documentos PDF. Por otra parte, se experimentó con el motor de base de datos Mongo DB para guardar los resultados obtenidos del Crawler y la principal problemática que se presentó durante esta historia de usuario es que se estaban guardando enlaces repetidos, es decir que tenían la misma URL. En primer lugar, se decidió realizar una consulta para verificar si la información acerca del documento ya se encontraba en la base de datos, en este caso se revisaba la URL de extracción, pero esto demoraba alrededor de 0.049 segundos para una consulta en 9000 registros lo cual era mucho tiempo ya que se esperaba que la base de datos fuera aumentando el número de registros con el paso del tiempo. Por esta razón, se concluyó que hacer este tipo de consultas retrasaba de manera notoria el funcionamiento del componente.

Para poder abordar la problemática se decidió experimentar con una Base de Datos clave-valor donde la clave sería la URL y el valor la fecha, la principal ventaja de usar este tipo de base de datos es que se puede configurar para que cada pareja (clave-valor) no se duplique, además REDIS hace el almacenamiento en memoria RAM mejorando el rendimiento. En la Figura 4 se puede observar la estructura clave-valor que se definió para los enlaces.

Figura 4. Estructura clave-valor en REDIS para enlaces (Diseño propio)

Del mismo modo los enlaces a documentos PDF también se almacenaron en una estructura clave-valor, la clave sería la URL del documento y el valor el tamaño del PDF, como se observa en la Figura 5. Cabe resaltar, que se decidió almacenar el atributo tamaño del PDF

26

porque algunos documentos podrían permanecer en el mismo URL, sin embargo, estos pudieron ser modificados y una forma para detectar estos cambios fue comparando los tamaños de los documentos, es decir, que si el tamaño cambiaba se guardarían los datos de ambas versiones del documento.

Figura 5. Estructura clave-valor en REDIS para enlaces a documentos (Diseño propio)

7.1.1.3 Guardar resultados de la extracción. En MONGO DB se almacenó la información de los enlaces a documentos como se ve en la Figura 6 , luego de eliminar los enlaces repetidos a partir del almacenamiento en las estructuras de REDIS, es decir que se optó por hacer un volcado de información desde REDIS a MONGODB.

El id corresponde a un valor numérico generado automáticamente cada vez que se guarda un registro, el nombre corresponde al nombre del archivo PDF, la fecha de creación es la fecha en la cual se ha descargado el documento en el servidor, el campo num_visitas es el número de veces que se ha consultado el documento, la fecha_actualizacion indica la fecha de la última vez que se visitó el enlace, la url_extraccion es la URL donde se encontró el documento PDF. Finalmente, los campos ana_text y ana_img indican si el documento PDF fue generado a partir de un archivo de texto o a partir de procesos ópticos. Este campo solo se actualiza después de hacer la transformación del documento, ya que hasta ese momento se determina la manera en que fue generado el PDF.

27

Figura 6. Estructura en MONGO DB(Diseño propio)

7.1.2 Tareas de ingeniería. Para poder completar las historias de usuario se llevaron a cabo las tareas de ingeniería que se describen en la Tabla 6, para mayor detalle ver Anexo A1.

Tabla 6. Resumen de las tareas de ingeniería de la iteración 1(Diseño propio)

No de tarea No de historia Nombre de la tarea

TI1 HU1 Realizar código de búsqueda de enlaces

TI2 HU1 Realizar código para modificar URL

TI3 HU1 Revisar enlaces repetidos

TI4 HU2 Filtrar documentos PDF por tamaño

TI5 HU3 Guardar información de un documento PDF

7.1.2.1 Realizar código de búsqueda de enlaces. La búsqueda de enlaces consiste en la revisión del código fuente de cada página web, para poder identificar todos los enlaces que contiene la página. Algunos de estos enlaces direccionan a otras páginas web, por lo cual se deberá revisar cada uno de estos enlaces de manera recursiva e ir identificando aquellos enlaces que sean de documentos PDF.

7.1.2.2 Realizar código para modificar URL. Fue común encontrar enlaces con una serie de características que se debían mejorar ya que impedían la búsqueda de los documentos con extensión PDF, las mejoras consisten en normalizar todos los enlaces para que queden completos siguiendo un mismo formato, por ejemplo http://registraduria/actas/gov.co.

http://registraduria/actas/gov.co

28

7.1.2.3 Revisar enlaces repetidos. Al realizar el proceso de rastreo se pueden encontrar enlaces repetidos ya que varias páginas web pueden tener referencia a un mismo enlace. Por ejemplo, en el índice de una página se puede encontrar un enlace a una noticia, y en otra página de contenido se puede volver a encontrar el enlace a la misma noticia. De manera que al hacer el rastreo debían identificarse los enlaces repetidos para no almacenar información duplicada.

7.1.2.4 Filtrar documentos PDF por tamaño. Luego de verificar los enlaces repetidos, se puede dar el caso de que un documento que tenga el mismo enlace sea diferente, esto ocurre cuando un documento se modifica a través del tiempo. Para poder identificar estos cambios se analiza el tamaño del archivo, y cuando es diferente se almacena como un nuevo documento PDF.

7.1.2.5 Guardar información de un documento PDF. Finalmente, el componente de rastreo debe guardar la información relacionada con los documentos PDF encontrados, y para ello se usa una Base de Datos NoSql que permite optimizar las consultas para grandes cantidades de datos.

7.1.3 Resultados de la primera iteración. Luego de realizar las tareas de ingeniería se obtuvieron los siguientes resultados:

7.1.3.1 Búsqueda de enlaces. Se realizó una función en Python que recibía como parámetro el código HTML de la página web, posteriormente se hace una validación de las etiquetas <a> en búsqueda del atributo href para capturar todos los enlaces que contiene la página. Esta función se repite por cada enlace, es decir que si el enlace encontrado no es de un documento, sino el de una página web, accede a dicha página y realiza el mismo procedimiento.

Figura 7. Pseudocógico de buscar enlaces (Diseño propio)

7.1.3.2 Realizar código para modificar URL. El código para modificar la URL se muestra en un diagrama de flujo (ver Figura 8), donde se hicieron las respectivas verificaciones que permitían detectar si la URL estaba completa para poder enlazar un recurso.

29

Figura 8. Diagrama de Flujo de modificar URL (Diseño propio)

7.1.3.3 Revisión de enlaces repetidos. Se creó una estructura clave-valor (ver Figura 4) que contenía el enlace y la fecha en que se almacenó, de esta manera solo quedaban guardados enlaces no repetidos ya que el enlace era la clave. En la Figura 9 se puede observar el pseudocódigo que hace dicha revisión.

Figura 9. Pseudocódigo de revisar enlaces repetidos (Diseño Propio)

7.1.3.4 Filtro de documentos PDF por tamaño. Para evitar descargar documentos repetidos se utilizó otra estructura clave-valor (ver Figura 5) que contiene el nombre del documento PDF y su tamaño. En primer lugar, se verificó que ningún documento con el mismo nombre se almacene en el servidor, y en caso de encontrar un documento con el mismo nombre se comparaba el tamaño, ya que este pudo ser modificado, si el tamaño era diferente se guardaba este nuevo valor.

30

7.1.3.5 Guardar información de un documento PDF. Teniendo en cuenta la estructura clave-valor que contenía el enlace del documento PDF y su tamaño, se guarda la información relacionada (ver Figura 6) con el documento en una Base de Datos NoSql como se ve en la Figura 10.

Figura 10. Ejemplo de almacenamiento de información de documento PDF en MongoDB

31

7.1.3.6 Arquitectura del componente de rastreo. En la Figura 11 se puede observar la arquitectura obtenida durante esta iteración.

Figura 11. Diagrama de la arquitectura durante la primera iteración. (Scrapy Developers, 2016)

El componente de rastreo se hizo empleando el Framework Scrapy. Los componentes que se usaron del Framework para el desarrollo del componente de rastreo son:

Spider: Es la clase personalizada en donde se procesa las respuestas de las páginas examinadas y se extraen los documentos PDF, también se realiza el análisis en Redis para revisar que no se repitan las páginas y los documentos.

Engine: Es el encargado de mantener el control del flujo de datos entre todos los componentes del sistema y de activar eventos cuando se producen ciertas acciones, estas acciones se explican en el flujo de datos.

Scheduler: Es el encargado de manejar la cola de peticiones, agrega y despacha las peticiones cuando el Engine le solicita.

Downloader: Es el encargado de ir a la página web y descargar la información que contiene.

Downloader middlewares: Son métodos que se ejecutan cuando se envíe una petición al Downloader, o cuando éste retorne alguna respuesta. Para este componente se utilizó un middleware que se ejecuta al momento de enviar la petición, es el encargado de cambiar aleatoriamente los agentes de usuario para evitar ser bloqueados del servidor al que se realiza la petición.

Item Pipeline: Se encarga de guardar el documento PDF rastreado.

32

El Engine controla el flujo de datos de la siguiente manera:

1. El Engine obtiene la petición inicial para rastrear desde el Spider.

2. El Engine programa la petición en el Scheduler.

3. El Engine pide al Scheduler la siguiente petición que se encuentra en la cola.

4. El Scheduler retorna la petición en la cola

5. El Engine envía la petición al Downloader, pasando por el Downloader middleware

6. Una vez que el Downloader haya terminado de extraer la información de la página, la envía como respuesta al Engine.

7. El Engine recibe la respuesta y la envía al Spider para ser procesada.

8. El Spider procesa la respuesta en búsqueda de documentos PDF y nuevas peticiones, en el caso del documento lo revisa si ya se encuentra en la base de datos, si no se encuentra retorna el documento al Engine, en el caso de las nuevas peticiones consulta la fecha en Redis para revisar si necesita ser rastreada, en el caso de que necesite revisión las retorna al Engine.

9. El Engine envía los documentos rastreados al Item Pipeline para que sean almacenados, y las peticiones las envía a la cola del Scheduler.

El proceso se repite desde el paso 1 hasta que el Scheduler no tenga más peticiones en cola.

7.1.3.7 Diagrama de actividades. Para poder observar el funcionamiento del componente de rastreo se utilizó un diagrama de actividades que se muestra en la Figura 12.

33

Figura 12. Diagrama de Actividades del componente de rastreo

34

7.1.4 Pruebas de aceptación

En la Tabla 7 se presenta un resumen de las pruebas de aceptación diseñadas para verificar la solución dada a las historias de usuario (ver Anexos A.1).

Tabla 7. Resumen de pruebas de aceptación de la iteración 1 (Diseño propio)

No de prueba

No de historia

Nombre de la prueba Evaluación

PA1 HU1 Obtener enlaces con rastreador utilizando librerías en una clase

Rechazada

PA2 HU2 Obtener enlaces con rastreador utilizando Framework Scrapy

Aceptada

PA3 HU3 Guardar documentos sin repetir en el servidor.

Aceptada

PA4

HU4 Guardar información de los documentos en base de datos

Aceptada

Durante esta iteración se rechazó la PA1 correspondiente a la historia de HU1 porque no se cumplió con los criterios de aceptación definidos (Ver Anexos A.1). Las otras pruebas de aceptación fueron aceptadas, y se dio por terminado el componente de rastreo.

7.2 SEGUNDA ITERACIÓN

La segunda iteración consiste en el desarrollo del componente de transformación que permite manipular el documento PDF convirtiéndolo en un archivo de texto para que se facilite el proceso de búsqueda de información.

7.2.1 Historias de usuario. La iteración se desarrolla aplicando las historias de usuario que se incluyen en la Tabla 8.

35

Tabla 8. Resumen de historias de usuario de la iteración 2(Diseño propio)


Descripción Estado

HU5 Transformación de documentos PDF

El sistema debe transformar los documentos PDF a documentos TXT.

Bifurcada

HU5-1 Transformación de documentos PDF generados a partir de un archivo de texto

El sistema debe transformar los documentos PDF que fueron generados a partir de un archivo de texto.

Aceptada

HU5-2 Transformación de documentos PDF generados a partir de un proceso óptico

El sistema debe transformar los documentos PDF que fueron generados a partir de una fotografía, escáner o a través de un proceso óptico.

Aceptada

HU6

Eliminar documentos PDF

El sistema debe eliminar de la memoria principal los documentos PDF descargados luego de ser procesados.

Aceptada

7.2.1.1 Transformación de documentos La historia de usuario transformación de documentos PDF se completó buscando librerías que permitieran la conversión de documentos PDF a archivos de texto. Inicialmente se utilizó pdf-miner, una librería de Python de uso libre para conversión de PDF, sin embargo, se observó que la librería no hacia conversión de documentos PDF generados a partir de un escáner o una fotografía.

Se realizaron las mismas pruebas con la librería PyPDF, otra herramienta de uso libre para convertir PDF y se observó la misma problemática con los documentos PDF generados a partir de procesos ópticos. De esta manera, se identificó que a este tipo de documentos PDF se les haría un tratamiento diferente con una herramienta que permitiera convertirlos a imagen y posteriormente a texto.

Mientras que los documentos PDF generados a partir de un archivo de texto sí podrían utilizar alguna de estas librerías (Pdf-miner o PyPDF). Para evaluar cual tenía mejor desempeño se optó por utilizar un analizador ortográfico denominado Hunspell y determinar el número de errores ortográficos en el archivo de texto. Adicionalmente se midió el tiempo de conversión de cada librería.

36

7.2.1.2 Transformación de documentos PDF generados a partir de un proceso óptico. Teniendo en cuenta lo anterior, se buscaron librerías que permitieran la transformación para los documentos que fueron generados a partir de imágenes, se probaron las librerías Tesseract-ocr para Python y PyOCR, observando que el texto producido incluye palabras mal escritas, incoherentes y el texto no se puede entender.

Por esta razón, se indagó acerca de mejoras para estas librerías, se encontró un intérprete especializado en documentos PDF que permitía convertir el PDF a imágenes y posteriormente analizar cada imagen con Tesseract-OCR. El uso de este intérprete mejoró los resultados obteniendo un texto susceptible de lectura.

7.2.2 Tareas de ingeniería. Las historias de usuario se llevaron a cabo las desarrollando las tareas de ingeniería incluidas en la Tabla 9.

Tabla 9. Resumen de las tareas de ingeniería de la iteración 2 (Diseño propio)

No de tarea No de historia

Nombre de la tarea

TI6 HU5-1 Buscar librería para convertir un PDF a texto

TI7 HU5-2 Buscar librería para convertir PDF generados a partir de un proceso óptico

TI8 HU6 Realizar código para limpiar buffer de documentos PDF descargados.

7.2.2.1 Buscar librería para convertir un PDF a texto. Esta tarea se llevó a cabo probando varias librerías que fueran compatibles con la versión de Ubuntu 16. Los criterios para evaluarlas fueron tiempo y número de palabras con errores ortográficos.

En la Tabla 10 se pueden observar los resultados del tiempo de respuesta y conteo de errores ortográficos para cada librería. Cabe mencionar que el tamaño promedio de los documentos que se utilizaron para la prueba es de 170 KB.

Tabla 10. Comparación librerías de conversión PDF a archivo de texto (Diseño propio)

Herramienta Tiempo de conversión de 20 documentos PDF (segundos)

Palabras con errores

ortográficos

Total palabras Porcentaje de error

PyPDF 88 68 905 7.51%

PDFMiner 125 50 749 6.67%

37

7.2.2.2 Buscar librería para convertir PDF generados a partir de un proceso óptico. Se utilizó una combinación de una librería que hace reconocimiento óptico y un intérprete de documentos PDF. En la Tabla 11 se puede observar la comparación de las herramientas que se probaron para completar dicha tarea.

Tabla 11. Comparación de herramientas para reconocimiento óptico de caracteres (Diseño propio)

Característica/Herramienta Usando ghostscript con tesseract-ocr

Usando OCROPUS

Tiempo por página 1 minuto 5 minutos

Texto legible Alto Alto

Transformación de tildes Medio Bajo

Diccionario para idioma español Si No

Documentación Disponible No disponible

7.2.2.3 Realizar código para limpiar buffer de documentos PDF descargados. Esta tarea consiste en borrar los documentos descargados en memoria principal luego de hacer el proceso de transformación a archivo de texto. Esta tarea se hace necesaria para evitar que la memoria del servidor se llene.

7.2.3 Resultados de la segunda iteración. Como resultado de las tareas de ingeniería se obtuvieron los siguientes resultados:

7.2.3.1 Librería para convertir un PDF a texto. Se eligió la librería PyPDF porque tiene mejor desempeño respecto al tiempo a pesar de que el porcentaje de errores ortográficos fue muy similar en ambas librerías. En la Figura 13 se puede observar el procedimiento para convertir un PDF a un archivo de texto usando PyPDF.

Figura 13. Convertir PDF a texto (Diseño propio)

38

7.2.3.2 Librería para convertir PDF generados a partir de procesos ópticos. Se eligió la combinación de Tesseract-ocr y el intérprete Ghostscript porque tenía mejor tiempo de respuesta y estaba disponible para el idioma español. En la Figura 14 se muestra el pseudocódigo para usar dicha librería en el componente de transformación.

Figura 14. Pseudocódigo para convertir PDF a texto (Diseño propio)

7.2.3.4 Limpieza del buffer de documentos descargados. En la Figura 15 se puede observar el pseudocódigo para borrar los documentos PDF descargados en la memoria principal.

Figura 15. Pseudocódigo de limpiar buffer (Diseño propio)

7.2.3.5. Diagrama de actividades. El comportamiento del componente de transformación se puede observar en el diagrama de actividades que se muestra en la Figura 16.

39

Figura 16. Diagrama de Actividades componente de transformación

7.2.4. Pruebas de aceptación. En la Tabla 12, se presenta un resumen de las pruebas de aceptación diseñadas para verificar el funcionamiento de las historias de usuario.

Tabla 12. Resumen de pruebas de aceptación de la iteración 2 (Diseño propio)

No de prueba

No de historia


PA5 HU5 Convertir un documento PDF a archivo de texto

Rechazada

PA6 HU5-1 Convertir un documento PDF a archivo de texto

Aceptada

PA7 HU5-2 Convertir un documento PDF generado a partir de imágenes a archivo de texto

Aceptada

PA8 HU6 Limpiar buffer Aceptada

40

La prueba de aceptación PA5 fue rechazada ya que al intentar llevar a cabo la conversión de documentos PDF a texto se debía usar un procedimiento diferente dependiendo el proceso mediante el cual se había generado el archivo PDF.

7.3 TERCERA ITERACIÓN

La tercera iteración comprende el desarrollo del componente de extracción que tiene como objeto localizar y extraer los párrafos que son relevantes a las palabras que hacen parte de la consulta

7.3.1 Historias de usuario. En la Tabla 13 se pueden observar las historias de usuario para desarrollar la tercera iteración.

Tabla 13. Resumen de historias de usuario de iteración 3 (Diseño propio)


Descripción Estado

HU7 Descomponer el documento en párrafos

El sistema debe descomponer el documento en párrafos.

Aceptada

HU8 Quitar stopwords

El sistema debe quitar las palabras consideradas como stopwords (preposiciones, artículos etc.).

Rechazada

HU9 Analizar documento en busca de las palabras

El sistema debe analizar el documento para buscar las palabras introducidas por el usuario.

Modificada

HU9-1

Analizar documento en busca de las entidades nombradas

El sistema debe analizar el documento para buscar las entidades nombradas introducidas por el usuario.

Aceptada

HU10 Extracción del párrafo

El sistema debe extraer el párrafo donde se han encontrado las palabras.

Modificada

HU10-1 Extracción del párrafo

El sistema debe extraer el párrafo donde se han encontrado las entidades nombradas que ha ingresado el usuario.

Aceptada

41

7.3.1.1 Descomponer el documento en párrafos. Para completar la historia de usuario Descomponer el documento en párrafos, fue necesario explorar algunas funciones del lenguaje Python que permiten manipular cadenas, como la función split() que divide una cadena y la función find() que busca una cadena en otra.

7.3.1.2 Analizar documento. En la historia de usuario Analizar documento en busca de palabras inicialmente se definió que se buscarían exactamente las mismas palabras introducidas por el usuario y en el mismo orden, por lo cual debía advertírsele al usuario que debía definir la búsqueda con precisión y en el orden adecuado ya que sería un factor determinante en el funcionamiento del buscador.

Sin embargo, luego de experimentar se encontró que la herramienta sería más funcional para buscar palabras específicas dentro de un contexto. Es por ello que se indagó sobre una tarea de Procesamiento de Lenguaje Natural denominada reconocimiento de entidades nombradas, la cual permite reconocer y clasificar nombres de personas, lugares, organizaciones o cantidades.

De esta manera, en los párrafos se identificaron las entidades nombradas y se compararon con las entidades nombradas ingresadas por el usuario, permitiendo que la búsqueda fuese más precisa al omitir todas las palabras que no se identifiquen como una entidad nombrada, incluyendo los stopwords. Es importante mencionar que stopwords se les denomina a las palabras que carecen de significado léxico, suelen ser artículos, preposiciones, conjunciones, pronombres, entre otras. Por esta razón se rechazó la historia de usuario quitar stopwords.

7.3.2 Tareas de ingeniería. Para poder completar las historias de usuario se llevaron a cabo las tareas de ingeniería que se observan en la Tabla 14.

Tabla 14. Resumen de tareas de ingeniería de iteración 3(Diseño propio)

No de tarea

No de historia

Nombre de la tarea

TI9 HU7 Realizar código para descomponer el documento en párrafos

TI10 HU8 Realizar código para quitar stopwords de la cadena de texto a buscar

TI11 HU8 Realizar código para quitar stopwords de los párrafos en los cuales se buscará la cadena

TI12 HU9 Realizar código para buscar cadena por párrafo

TI13 HU9 Realizar código para contar coincidencias por documento

TI14 HU10 Realizar código para extraer párrafo

TI15 HU9 Buscar librería para Reconocimiento de Entidades Nombradas (NER).

TI16 HU9 Agregar reconocimiento de entidades nombradas a la búsqueda.

42

7.3.2.1 Realizar código para descomponer el documento en párrafos. La tarea de ingeniería consiste en dividir el texto del documento en párrafos para poder localizar más fácil el fragmento de texto que se muestra al usuario. En la herramienta Mask’ay se considera un párrafo, el fragmento de texto delimitado por saltos de línea. De manera que se encontraron párrafos de diferentes tamaños y los títulos fueron considerados como párrafos del documento.

7.3.2.2 Realizar código para quitar stopwords de la cadena de texto a buscar. Cuando el usuario ingresa una frase puede incluir artículos, preposiciones, entre otras palabras consideradas como stopwords. Estas palabras no deberían buscarse dentro del texto porque usualmente aparecen varias veces en un texto y no son relevantes para la búsqueda. Esta tarea de ingeniería se descartó.

7.3.2.3 Realizar código para quitar stopwords de los párrafos en los cuales se buscará la cadena. Del mismo modo que se eliminan las stopwords de la cadena ingresada por el usuario se quitaron de los párrafos, para que al realizar la búsqueda de las palabras se encontraran coincidencias. Esta tarea de ingeniería se descartó.

7.3.2.4 Realizar código para buscar cadena por párrafo. Esta tarea se realizó buscando las palabras ingresadas por el usuario en el mismo orden. Por ejemplo, si el usuario ingresó: “el carro es azul”, la cadena buscada en cada párrafo fue carro azul.

7.3.2.5 Buscar librería para Reconocimiento de Entidades Nombradas (NER). Para poder hacer reconocimiento de entidades nombradas fue necesario buscar varias librerías que hacen este procesamiento, entre las cuales se encuentran NLTK- posTag, NLTK-StandfordPostagger y Freeling, dichas librerías se evaluaron y se obtuvieron los resultados que se muestran en la Tabla 15, razón por la cual se escogió NLTK-StandfordPostagger.

Tabla 15. Comparación librerías para NER (Diseño propio)

Librerías

Características NLTK-PosTag NLTK-Standford Postagger

Freeling

Reconocimiento de entidades nombradas en español

Bajo Alto Medio

Prerrequisitos de instalación

NLTK NLTK Libtools, incompatible con versión de Ubuntu

Velocidad de procesamiento

30 segundos por párrafo



7.3.2.6 Agregar reconocimiento de entidades nombradas a la búsqueda. Para hacer reconocimiento de entidades nombradas (NER) se usó el patrón sintáctico llamado part-of-speech (POS) de una palabra, que consiste en clasificar la palabra como sustantivo, verbo,

43

artículo o adjetivo. De esta manera, la búsqueda se limita a comparar los sustantivos propios que se han detectado luego de usar la librería.

7.3.3 Resultados de la tercera iteración. Después de realizar las tareas de ingeniería se obtuvieron los siguientes resultados:

7.3.3.1 Descomposición del documento en párrafos. En la Figura 17 se puede observar el proceso que se lleva a cabo para descomponer el texto de un documento en párrafos.

Figura 17. Pseudocódigo para hacer descomposición en párrafos (Diseño propio)

7.3.3.2 Búsqueda de la cadena por párrafo. El proceso de búsqueda incluye el Reconocimiento de Entidades Nombradas a partir del patrón sintáctico Pos-Tagger, en la Figura 19 se puede observar cómo se utilizó dicha librería para hacer la búsqueda.

7.3.3.3 Conteo de coincidencias por documento. Cada vez que encuentra la cadena en un párrafo se va aumentando el valor de una variable para detectar cuantas veces se encuentran coincidencias en el documento. En la Figura 18 se puede observar cómo se hace este proceso.

Figura 18. Pseudocódigo para contar coincidencias (Diseño propio)

44

Figura 19. Pseudocódigo para buscar cadena (Diseño propio)

7.3.4 Pruebas de aceptación. En la Tabla 16 se presenta un resumen de las pruebas de aceptación diseñadas para verificar el funcionamiento de las historias de usuario.

Tabla 16. Resumen de pruebas de aceptación de iteración 3(Diseño propio)

No de prueba

No de historia


PA9 HU7 Descomponer documento en párrafos Aceptada

PA10 HU8 Quitar stopwords Rechazada

PA11 HU9 Buscar palabras Modificada

PA12 HU9-1 Buscar entidades nombradas Aceptada

PA13 HU10 Extraer párrafo Modificada

PA14 HU10-1 Extraer párrafo Aceptada

La prueba de aceptación Quitar Stopwords fue rechazada porque, aunque cumplía con los criterios inicialmente definidos (Ver Anexos A.3) la modificación de la historia de usuario Buscar palabras ocasionó que no fuera necesario realizar esta historia de usuario

45

7.4 CUARTA ITERACIÓN

La cuarta iteración comprende el desarrollo del componente de la interfaz gráfica que se mostrará al usuario, lo cual incluye el formulario en el cual el usuario ingresará la URL y las palabras a buscar, la pantalla de visualización de resultados de la búsqueda, la pantalla de acceso al módulo administrador y una pantalla para modificar palabras restringidas.

7.4.1 Historias de usuario. En la Tabla 17 se muestra la descripción de las historias de usuario contempladas en la cuarta iteración.

Tabla 17. Resumen de historias de usuario iteración 4(Diseño propio)


Descripción Estado

HU11 Capturar URL y palabras a buscar

El sistema debe mostrar al usuario dos campos, uno para ingresar URL y otro para ingresar palabras a buscar

Aceptada

HU12 Mostrar resultados de la búsqueda

El sistema debe mostrar el fragmento de texto donde ha encontrado las palabras ingresadas por el usuario

Aceptada

HU13 Habilitar opciones de administrador

El sistema debe permitir el ingreso de un usuario administrador para restringir palabras en el proceso de rastreo de documentos.

Aceptada

HU14 Ajustar la herramienta

El sistema debe solicitar al usuario registrar el correo electrónico para enviarle una notificación cuando se termine de rastrear el enlace ingresado.

Aceptada

7.4.1.1 Capturar URL y palabras a buscar. La definición de la búsqueda está dada por una URL y las palabras que ha ingresado el usuario. La URL es el insumo del componente de rastreo para empezar con la búsqueda de todos los enlaces ésta que contiene. Por otra parte, las palabras que ingresa el usuario son las palabras que se buscarán en cada uno de los párrafos que contienen los documentos PDF encontrados.

46

7.4.1.2 Mostrar resultados de la búsqueda. El fragmento de texto que se muestra es el primer párrafo en el cual se encuentran coincidencias, sin embargo, se le indica al usuario cuantas veces se encontraron coincidencias en caso de existir otros párrafos que contengan la cadena que ha ingresado para hacer la búsqueda.

7.4.1.3 Habilitar opciones de administrador. Las opciones de administrador consisten en una interfaz para modificar palabras restringidas en la búsqueda, en la cual el usuario se debe autenticar para poder ingresar.

7.4.1.4 Ajustar la herramienta. El ajuste a la herramienta consistió en solicitar al usuario un correo electrónico para enviarle una notificación al terminar de rastrear un enlace. Debido a que cuando se ingresa un enlace que nunca ha sido rastreado por la herramienta puede tardar mucho tiempo ocasionando que el usuario cancele la búsqueda y determine que la herramienta no le sirvió.

Por esta razón, el sistema le enviará una notificación al usuario cuando la URL haya terminado de ser rastreada, para que éste pueda volver a hacer la búsqueda y obtener los resultados en un menor tiempo de respuesta.

7.4.2 Tareas de ingeniería. Para poder completar las historias de usuario se llevaron a cabo las tareas de ingeniería que se observan en la Tabla 18.

Tabla 18. Resumen de tareas de ingeniería iteración 4 (Diseño propio)

No de tarea No de historia

Nombre de la tarea

TI17 HU11 Realizar código para captura de URL y palabras de búsqueda

TI18 HU12 Realizar código para mostrar resultados de la búsqueda

TI19 HU13 Realizar código para crear login de módulo administrador

TI20 HU13 Realizar código para pantalla de restricción de palabras

TI21 HU14 Realizar código para registrar correo

TI22 HU14 Realizar código para enviar notificación

7.4.2.1 Realizar código para captura de URL y palabras de búsqueda. Cuando se captura la URL se debe hacer una validación para determinar que la cadena ingresada coincida con el formato de una URL, esto se hace comparando con una expresión regular. Así mismo, se verifica que las palabras ingresadas no superen los 100 caracteres.

7.4.2.2 Realizar código para mostrar resultados de la búsqueda. Para que el usuario visualice de manera más sencilla los resultados de la búsqueda se muestra el primer

47

fragmento de texto del documento donde se han encontrado coincidencias. Para poder visualizar otras coincidencias dentro del documento o leer el artículo completo, podrá dar clic sobre el enlace al documento. También podrá ver el número de veces que se han encontrado coincidencias en el texto.

7.4.2.3 Realizar código para crear login de módulo administrador. El módulo administrador es un módulo para validar palabras restringidas y para poder acceder a dicho módulo se hace necesario ingresar un usuario y una contraseña. El sistema realiza la validación y permite o niega el acceso.

7.4.2.4 Realizar código para pantalla de restricción de palabras. Se puede ingresar como usuario administrador para seleccionar palabras restringidas. Las palabras restringidas pueden ser palabras que el administrador desee se descarten en la búsqueda para optimizar el tiempo de respuesta, por ejemplo manual, libro, acuerdo entre otras palabras que describen documentos de gran tamaño que no son relevantes para las búsquedas de los usuarios. De esta manera, mientras se realice el rastreo de documentos en la web se descarten aquellos documentos cuyo título contenga alguna palabra restringida. Estas palabras se almacenarán en una colección de MONGO DB y podrán ser agregadas, modificadas o eliminadas.

7.4.2.5 Realizar código para registrar correo. El sistema debe solicitar al usuario un correo electrónico al cual se le enviará una notificación. Para poder hacer dicho registro es necesario que el sistema almacene el correo electrónico en una colección de MONGO DB (Ver Figura 20).

Figura 20. Almacenamiento de correos electrónicos (Diseño propio)

7.4.2.6 Realizar código para enviar notificación. El envío de notificaciones es un proceso que se hace luego de que la herramienta ha terminado de rastrear un enlace, para ello se maneja una colección en MONGO DB (Ver Figura 21) que permite guardar el estado de los enlaces y cuando el sistema cambia del estado “Buscando” a “Analizado” automáticamente se envía un mensaje al correo electrónico del usuario que ingresó ese enlace.

48

Figura 21. Almacenamiento de un enlace (Diseño propio)

7.4.3 Resultados de la cuarta iteración. Luego de realizar las tareas de ingeniería se obtuvieron los siguientes resultados:

7.4.3.1 Arquitectura. Para completar las historias de usuario de la iteración 4, fue necesario definir una arquitectura que permitiera la integración de los tres componentes desarrollados en las iteraciones anteriores con una vista gráfica para el usuario. Para ello se tuvo en cuenta que los lenguajes utilizados permitieran asincronismo con la finalidad de reducir los tiempos de respuesta.

En la Figura 22 se visualiza un diagrama de colaboración para ver las interacciones entre los objetos que componen la herramienta. En el paso número 2 se puede observar que dependiendo la existencia del dominio en base de datos, puede realizar dos acciones, estas son invocadas asíncronamente para permitir que la aplicación pueda realizar otras búsquedas u otros rastreos y no bloquear la herramienta esperando alguna respuesta, ya que estos métodos pueden demorarse bastante tiempo. Por otra parte, en el paso 5 se evidencia el uso de procesos en paralelo para realizar búsqueda dentro de los documentos, esto reduce hasta en un 25% el tiempo de búsqueda ya que examina varios documentos al mismo tiempo, si se hiciera este procesamiento en serie haría la búsqueda uno a uno y tardaría más tiempo de lo deseado.

La arquitectura cliente-servidor de tres capas permite optimizar la transferencia de información entre el servidor web y el servidor de la base de datos, de esta manera para manejar la recuperación de información de la base de datos se utiliza un middleware eficiente que soporte consultas a la base de datos (Sommerville, 2005).

La capa visible para el usuario comprende una interfaz de usuario que es un navegador web que se comunica con la capa intermedia, más exactamente con un servidor web que transfiere la solicitud a un servidor de aplicaciones cuyo papel es manejar la lógica empresarial necesaria para procesar la solicitud, y esta a su vez puede implicar el acceso a una base de datos que se ejecuta en la capa subyacente. En la Figura 23 se observa un diagrama que refleja los lenguajes utilizados en cada una de las capas de la arquitectura de la herramienta Maskay.

49

Figura 22. Diagrama de colaboración (Diseño propio)

Capa de presentación: En esta capa se utilizó HTML para crear la vista de la herramienta y CSS para definir los estilos de la vista.

Capa de proceso o intermedia: Se utilizó NODE JS para hacer el procesamiento entre la capa de presentación y la base de datos. Adicionalmente se utilizó EXPRESS como Framework web para NODE JS.

Se crearon funciones en PYTHON que contienen la lógica para rastrear, extraer y analizar documentos PDF, se utilizó el Framework SCRAPY que está desarrollado en PYTHON y permitió el desarrollo del componente de rastreo. Para evitar guardar documentos duplicados se utilizó REDIS, una estructura clave-valor.

Para articular funciones JavaScript en las vistas se utilizó JADE que es un preprocesador de código HTML.

50

Capa de datos: En esta capa se utilizó MONGODB una base de datos No SQL que resulta ser bastante rápida para realizar sus operaciones. Allí se almacenarán colecciones que van a contener la información relacionada con los documentos PDF encontrados.

Figura 23. Arquitectura de tres capas (Basado en (Ruiz & Delgado, 2017))

7.4.3.2 Diagrama de componentes. La forma como se ha estructurado la herramienta y la relación entre los diferentes componentes se puede ver mediante el diagrama de compontes que se observa en la Figura 24.

51

Figura 24. Diagrama de componentes (Diseño propio)

7.4.3.3 Pantalla para el ingreso de la búsqueda. La pantalla que se muestra en la Figura 25, contiene dos campos que deben ser diligenciados por el usuario con la URL y las palabras a buscar.

En la pantalla principal también se visualiza un vídeo que da una breve introducción sobre qué es una entidad nombrada y algunos ejemplos, para que el usuario tenga claridad sobre el concepto. Teniendo en cuenta que el proceso de búsqueda está basado en la identificación de entidades nombradas, y se espera que el usuario ingrese una o varias entidades nombradas en el campo de búsqueda.

cmp Diagrama de componentes

Presentacion

Negocio

Transformación

Presentacion

Rastreo

Serv idor de Base de Datos

BaseDatosExtracción

Logica de NegocioGestor datos

«use»

52

Figura 25. Pantalla de ingreso de datos para la búsqueda (Diseño propio)

7.4.3.4 Pantalla que muestra los resultados de la búsqueda. En la pantalla que se muestra en la Figura 26 se puede observar un ejemplo de los resultados que arroja una búsqueda.

Figura 26. Resultados de la búsqueda (Diseño propio)

53

7.4.3.5 Acceso al módulo administrador. En la Figura 27 se puede observar la pantalla que se mostrará al usuario para acceder al módulo administrador. En dicha pantalla debe ingresar el correo electrónico y la contraseña para autenticarse en el sistema.

Figura 27. Ingreso al módulo administrador (Diseño propio)

En la Figura 28 se observa la pantalla en la cual el usuario puede: a) Agregar palabras restringidas; b) Editar una palabra restringida existente; c) Eliminar una palabra restringida.

Figura 28. Pantalla de edición para palabras restringidas (Diseño propio)

54

7.4.3.6 Registrar correo electrónico. En la Figura 29 se puede observar el proceso que el sistema lleva a cabo para hacer el registro de un correo electrónico.

Figura 29. Pseudocódigo para registrar un correo electrónico (Diseño propio)

7.4.3.7 Enviar notificación al correo electrónico. En la Figura 30 se puede observar el proceso para enviar una notificación al correo electrónico que un usuario ha registrado en el sistema. Es importante mencionar, que solo se enviará una notificación cuando un usuario ingrese una URL que nunca ha sido rastreada por la herramienta, ya que para hacer este proceso la herramienta se va a demorar y por esto debe notificar al usuario cuando haya terminado.

Figura 30. Pseudocódigo para enviar notificación (Diseño propio)

55

7.4.4 Pruebas de aceptación. En la Tabla 19, se presenta un resumen de las pruebas de aceptación diseñadas para verificar el funcionamiento de las historias de usuario.

Tabla 19. Resumen de pruebas de aceptación de iteración 4(Diseño propio)

No de prueba

No de historia


PA15 HU11 Capturar de datos de búsqueda Aceptada

PA16 HU12 Mostrar resultados Aceptada

PA17 HU13 Acceder a módulo administrador y modificar palabras restringidas

Aceptada

PA18 HU14 Envío de notificaciones Aceptada

Las pruebas de aceptación de esta iteración cumplieron con los criterios de aceptación definidos (Ver Anexos A.4) por lo tanto las cuatro pruebas de aceptación definidas para las respectivas historias de usuario de la cuarta iteración se aceptaron.

56

8. PRUEBAS CON LA HERRAMIENTA MASK’AY

8.1 PRUEBAS DE RENDIMIENTO

La herramienta se configuró en un servidor Linux Ubuntu 16, con memoria de 36gb y ancho de banda de 50mb/s, se hicieron pruebas de rendimiento en dos escenarios, el primero simulando ejecuciones del componente de rastreo paralelamente y el segundo simulando el proceso de extracción de la información paralelamente.

En el primer escenario se tuvo como resultado que con 10 ejecuciones simultáneas consume todo el ancho de banda del servidor y comienza a retrasarse notoriamente el proceso de descarga de los documentos.

En el segundo escenario se observó que el servidor puede realizar 20 búsquedas simultáneamente ya que después de esta cantidad utiliza toda la memoria RAM y esto conlleva a que el proceso en el servidor se detenga ocasionando que no arroje ningún resultado y colapse la herramienta.

Lo anterior nos permite concluir que la herramienta construida requiere de alta capacidad en memora RAM.

8.2 PRUEBAS DEL USUARIO FINAL

En la Tabla 20 se presentan los resultados obtenidos luego de realizar la búsqueda en algunos sitios web por primera vez.

Tabla 20. Sitios web rastreados por primera vez (Diseño propio)

Nombre del sitio Tiempo de rastreo (segundos) Documentos PDF encontrados

Universidad Distrital 93745.67 264

UPME 1365,59 564

Derecho de autor 104586.81 37

Bogotá 32999.93 3

Restitución de tierras 7969,55 180

Ministerio de las Telecomunicaciones

2171,72 2147

57

En las pruebas se incluyeron las páginas de los sitios web de Davivienda, Escuela de ingenieros Julio Garavito, Supernotariado y SEDICI, pero por motivos de seguridad no pudieron ser rastreadas correctamente.

En la Tabla 21 se observan los resultados que se obtuvieron luego de buscar los documentos que contienen la Entidad Nombrada ingresada por el usuario

Tabla 21. Tiempos de extracción de información (Diseño propio)

Nombre del sitio Tiempo de extracción(Segundos)

Resultados Encontrados

Palabra buscada

Universidad Distrital 7,97 1 Calculo diferencial

UPME 52,08 6 Ana Maria

Derecho de autor 3,02 6 Software

Bogotá 1,52 1 Suba

Restitución de tierras 9,47 5 Cordoba


207 447 IPv6

En la Tabla 22 se puede observar los tipos de documentos que se contemplaron en las pruebas. Es importante mencionar, que esto dependía de que el usuario marcará la opción incluir documentos PDF generados a partir de imágenes.

Tabla 22. Tipos de documento PDF incluidos en las pruebas (Diseño propio)

Nombre del sitio Tipos de documentos PDF Número de documentos PDF (Generados a partir de imágenes)

Universidad Distrital Texto Imágenes

30

UPME Texto Imágenes

173

Derecho de autor Texto No aplica

Bogotá Texto No aplica

Restitución de tierras Texto No aplica


Texto Imágenes

921

58

En el anexo C se puede observar la encuesta que se realizó a 10 personas para medir el rendimiento y usabilidad de la herramienta. En dicha encuesta se preguntó acerca del tiempo de respuesta, efectividad de la consulta y utilidad de la herramienta.

Tiempo de respuesta: En la Figura 31 se puede observar la percepción que los usuarios tuvieron sobre el tiempo de respuesta, en donde el 50% de los usuarios piensa que es regular y el otro 50% piensa que es bueno. Cabe resaltar, que el tiempo de respuesta irá mejorando a través del tiempo con el uso de la aplicación, ya que algunas páginas no tendrán que ser rastreadas por primera vez porque otros usuarios ya habrán hecho la búsqueda, mejorando la experiencia del usuario con la herramienta.

Figura 31 Percepción del Tiempo de respuesta (Diseño propio)

Efectividad de la consulta: En la Figura 32 se observa que más de la mitad de los usuarios que probaron la herramienta consideran que los resultados obtenidos están relacionados con la búsqueda que ingresaron. Aquellos que respondieron que los resultados no estaban relacionados no encontraron resultados porque la herramienta no pudo rastrear el enlace dado por cuestiones de seguridad en el mismo.

59

Figura 32 Percepción de la efectividad de la consulta (Diseño propio)

Utilidad de la herramienta: Aunque en la Figura 33 se observa que la herramienta le parece útil a más de la mitad de los usuarios que la probaron, es importante mencionar, que los usuarios a los que no les pareció útil no fue por la herramienta sino por las restricciones de seguridad de algunos sitios y por lo cual la herramienta Maskay no pudo hacer búsquedas en dichas páginas.

Figura 33 Percepción de la utilidad de la herramienta (Diseño propio)

60

9. TRABAJO FUTURO

La herramienta Maskay enfatiza en la búsqueda de documentos PDF que contengan Entidades Nombradas, con la finalidad de automatizar las búsquedas en documentos PDF haciendo procesamiento de lenguaje natural.

Sin embargo, se ha detectado que pese a que la librería usada para el Reconocimiento de Entidades Nombradas funciona correctamente, no se hace reconocimiento de palabras que designan Entidades Oficiales o Legislaciones especiales, por lo cual se podría crear un API que contenga una colección de entidades nombradas propias del estado Colombiano.

Por otra parte, la herramienta Maskay hace el proceso de rastreo correctamente, pero no puede acceder a páginas con filtros de seguridad especiales como sitios web bancarios o entidades públicas que almacenan documentos con cierto nivel de confidencialidad, esto podría solucionarse implementando un proxy que de acceso a estos sitios.

61

10. CONCLUSIONES

Cuando se realiza reconocimiento de entidades nombradas el uso de una librería que haga procesamiento de lenguaje natural, como NLTK-Stanford -PosTagger es fundamental para determinar las palabras que se buscarán en el texto.

El tiempo de respuesta depende en gran medida del tiempo que la herramienta ocupe en hacer el proceso de rastreo, ya que este proceso incluye el recorrido por cada uno de los enlaces que contiene una página en busca de documentos PDF. Por esta razón cuando una página es rastreada por primera vez se solicita al usuario ingresar su correo electrónico para enviar una notificación cuando el proceso de rastreo termine, y de esa manera el uso de la herramienta resulte más eficiente para el usuario.

La ejecución en paralelo tanto en el componente de rastreo, como en el componente de extracción permitió reducir el tiempo de respuesta, debido a que se podían ejecutar varios procesos a la vez.

El uso de una librería para la conversión de documentos PDF a archivos de texto impacta en la precisión de los resultados ya que algunas veces las palabras no vienen con la correcta ortografía, ocasionando que se descarten algunos documentos que si contenían las palabras pero estaban mal escritas.

Se detectó que un proceso que gasta bastante tiempo es la descarga de los documentos en el servidor y que la manera de optimizarlo es teniendo un ancho de banda que permita una alta velocidad de descarga.

La transformación de documentos PDF incluye transformar documentos generados a partir de archivos de texto y de procesos ópticos (imágenes), es por esta razón que se deben utilizar dos procesos diferentes y la conversión desde imágenes tiene una duración mayor que la conversión desde archivos de texto ya que debe realizarse Reconocimiento Óptico de Caracteres, además los resultados pueden ser menos precisos y se pueden detectar más errores ortográficos en el texto obtenido.

62

11. BIBLIOGRAFÍA

Alvarez, M., Raposo, J., & Pan, A. (2007). DeepBot: a focused crawler for accessing hidden web content. ACM International Conference Proceeding Series, 236, 18.

Beltrán, R. O. (2007, Marzo 29). Extracción y Recuperación de la Información I. Retrieved from http://recupera1patrones.50webs.com/#patrones

Casali, A., Deco, C., & Beltramone, S. (2016). An Assistant to populate repositories: Gathering Educational Digital Objects and Metadata Extraction. REVISTA IBEROAMERICANA DE TECNOLOGIAS DEL APRENDIZAJE, 11(2), 87-94.

Chakraborty, A., Liu, P., & Hsu, L. (2003). Extracting anchorable information units from PDF files. Proceedings - IEEE International Conference on Multimedia and Expo.

Crockford, D. (2006). The application/json Media Type for JavaScript Object Notation (JSON). Internet Engineering Task Force.

Eikvil, L. (1993). Optical Character Recognition. Oslo: Norsk Regnesentral.

Eikvil, L. (1999). Information Extraction from World Wide Web. Oslo: Norwegian Computing Center.

ERA. (n.d.). ERA. (RUP) Retrieved Noviembre 30, 2016, from https://era.nih.gov/docs/rup_fundamentals.htm

Fernández, A. (2012). Python al descubierto. Madrid: RC Libros.

Gaona, P., Sánchez, S., & Gaona, E. (2013). Prototipo informático para extracción de recursos digitales sobre internet. Revista Tecnura, 17(1), 79-92.

Gupta, P., & Johari, K. (2009). Implementation of web Crawler. 2nd International Conference on Emerging Trends in Engineering and Technology, ICETET.

Kobayashi, M., & Takeda, K. (2000). Information retrieval on the web. ACM Computing Surveys, 32(2), 144-173.

Kroll, P., & Krutchten, P. (2004). The Rational Unified Process Made Easy. Boston: Pearson Education.

Kumar , N., & Singh, M. (2015). Framework for Distributed Semantic Web Crawler. 2015 International Conference on Computational Intelligence and Communication Networks (CICN), 1403-1407.

63

Laínez Fuentes, J. R. (2015). Desarrollo de Software ÁGIL: Extreme Programming y Scrum. Paperback.

Madhavan, J., Ko, D., Kot, L., Halevy, A., Rasmussen, A., & Ganapathy, V. (2008). Google's Deep Web crawl. Proceedings of the VLDB Endowment archive, 1(2), 1241-1252.

Martínez Mendez, F. J. (2004). Digitum. Retrieved Noviembre 4, 2016, from https://digitum.um.es/xmlui/bitstream/10201/4316/1/libro-ri.PDF

Noriega, R. (2015). El proceso de desarrollo de software. IT Campus Academy.

Nurseitov, N., Paulson, M., Reynolds, R., & Izurieta, C. (2006). Comparison of JSON and XML Data Interchange Formats: A Case Study. Bozeman: Montana State University.

Pedroza, E., Pach-May, F., Martínez, A., & Estrada, H. (2015). Crawnet: un Crawler para Obtener Información de Recursos Multimedia de la Web Superficial y Oculta. Lámpsakos(13), 39-50.

Pino, R., Gómez, A., & Martínez, N. (2001). Introducción a la inteligencia artificial: sistemas expertos, redes neuronales artificiales y computación evolutiva. Oviedo: Universidad de Oviedo.

Polo, M. (2015). Mongo DB: gestión, administración y desarrollo de aplicaciones. Macario Polo Usaola.

Ramírez Benavidez, K. D. (2012, Marzo 12). Escuela de Ciencias de la Computación e Informática. Retrieved Noviembre 4, 2016, from http://www.kramirez.net/RI/Material/Presentaciones/SRI.pdf

Ruiz, D., & Delgado, Y. (2017). 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. Bogotá.

Scrapy Developers. (2016). Scrapy. Retrieved from https://doc.scrapy.org/en/latest/topics/architecture.html

Sommerville, I. (2005). Ingeniería del sotware. Madrid: Pearson.

Tolosa, G., & Bordignon, F. (2007). Introducción a la recuperación de información. Retrieved Noviembre 29, 2016, from http://eprints.rclis.org/12243/1/Introduccion-RI-v9f.pdf

Verma, A., Arora, S., & Verma, P. (2016). OCR Optical Character Recognition. 7th International Conference on Recent Innovations in Science, Engineering and Management. Nueva Delhi.

64

Wells, D. (2000). ExtremeProgramming. Retrieved from http://www.extremeprogramming.org/map/project.html

prototipo de herramienta de software para la...

Documents