Extraction and Analysis System of Topics For Software History Reports

Facultad de Ciencias Exactas
Universidad Nacional del Centro de la Pcia. de Bs. As.
Sistema de Extraccin y Anlisis de Tpicos sobre

Historial de Reportes de Software
Trabajo final para la carrera Ingeniera de Sistemas
Tesista: Martn I. Pacheco

mpacheco@alumnos.exa.unicen.edu.ar
Director: Dra. Daniela Godoy Co-Director: Ing. Alejandro Corbellini

{dgodoy, acorbellini}@exa.unicen.edu.ar
Febrero de 2015
A mi familia por haberme brindado el privilegio de

concurrir a la universidad pblica, por su esfuerzo,
dedicacin y entera confianza. A mis profesores que
en este andar por la vida, influyeron con sus lecciones y experiencias en formarme como una persona
de bien y preparada para los retos que pone la vida.
ndice general
1. Introduccin
1.1. Contexto
14
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.2. Motivacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
1.3. Tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
1.4. Organizacin del trabajo . . . . . . . . . . . . . . . . . . . . . . .
18
2. Estado del Arte
20
2.1. Concepto de Descubrimiento de Conocimiento
. . . . . . . . . .
21
2.1.1. El proceso de KDD . . . . . . . . . . . . . . . . . . . . . .
22
2.2. Minera de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.2.1. Los fundamentos de la Minera de Datos . . . . . . . . . .
24
2.2.2. Principales caractersticas y objetivos de la Minera de

Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.3. Minera de Repositorios de Software . . . . . . . . . . . . . . . .
27
2.3.1. Los repositorios de software . . . . . . . . . . . . . . . . .

2.3.1.1. Cdigo fuente . . . . . . . . . . . . . . . . . . .
28
28
2.3.1.2. Vulnerabilidad y errores de bases de datos . . .
29
2.3.1.3. Listas de correo y registros (logs) de chats . . .
29
2.3.1.4. El sistema de control de versiones . . . . . . . .
30
2.3.1.5. Documenntos de requerimientos y discusiones sobre el diseo . . . . . . . . . . . . . . . . . . . .
30
2.3.1.6. Registros de ejecucin . . . . . . . . . . . . . . .
31
2.3.1.7. Repositorios del sistema de software . . . . . . .
31
2.4. Modelos de Tpicos . . . . . . . . . . . . . . . . . . . . . . . . . .
31
2.4.1. Terminologa empleada . . . . . . . . . . . . . . . . . . .
32
2.4.2. Vector Space Model . . . . . . . . . . . . . . . . . . . . .
35
2.4.3. Latent Semantic Indexing . . . . . . . . . . . . . . . . . .
35
2.4.4. Independent Component Anlysis . . . . . . . . . . . . . .
36
2.4.5. Probabilistic Latent Semantic Indexing . . . . . . . . . .
36
2.4.6. Latent Dirichlet Allocation . . . . . . . . . . . . . . . . .
37
NDICE GENERAL
2.4.6.1. Estimacin de parmetros Dirichlet e inferencia

del tpico . . . . . . . . . . . . . . . . . . . . . .
41
2.4.7. Sntesis de las semejanzas y diferencias entre PLSA y

LDA, ventajas e inconvenientes comparativos . . . . . . .
42
2.5. Modelos de evolucin de tpicos . . . . . . . . . . . . . . . . . . .
43
2.6. Trabajos relacionados . . . . . . . . . . . . . . . . . . . . . . . .
44
2.6.1. Localizacin de conceptos o caractersticas . . . . . . . . .
44
2.6.1.1. Tcnicas basadas en LSI . . . . . . . . . . . . . .
44
2.6.1.2. Tcnicas basadas en LDA . . . . . . . . . . . . .
46
2.6.2. Recuperacin de la trazabilidad y localizacin de bugs . .
47
47
2.6.2.2. Comparacin de estudios . . . . . . . . . . . . .
49
2.6.3. Mtricas sobre cdigo fuente . . . . . . . . . . . . . . . .
50
51
2.6.3.2. Tcnicas basadas en LDA . . . . . . . . . . . . .
51
2.6.4. Depuracin de estadstica y anlisis de causa principal . .
52
2.6.5. Evolucin de software y anlisis de tendencias . . . . . . .
52
2.6.6. Agrupamiento de documentos . . . . . . . . . . . . . . . .
53
2.6.7. Organizar y buscar en repositorios de software . . . . . .

2.6.8. Otras tareas . . . . . . . . . . . . . . . . . . . . . . . . . .
54
55
2.7. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
3. Metodologa y mtricas
58
3.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2. Conjuntos de datos . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1. Descripcin del conjunto de datos
58
59
. . . . . . . . . . . . .
59
3.3. Analizador para el conjunto de datos . . . . . . . . . . . . . . . .
61
3.4. Generacin de documentos y de versiones . . . . . . . . . . . . .
62
3.5. Extraccin de tpicos
. . . . . . . . . . . . . . . . . . . . . . . .
3.5.1. Algoritmo de muestreo Gibbs
63
. . . . . . . . . . . . . . .
63
3.5.2. Pre-procesamiento de los documentos . . . . . . . . . . .
68
3.5.2.1. Eliminacin de smbolos de puntuacin . . . . .
68
3.5.2.2. Desglose de trminos . . . . . . . . . . . . . . .
68
3.5.2.3. Conversin de maysculas a minsculas . . . . .
69
3.5.2.4. Eliminacin de stop words . . . . . . . . . . . .
69
3.5.2.5. Aplicacin de un algoritmo de Stemming (Porter) 69

3.5.3. Resultado de la aplicin del algoritmo . . . . . . . . . . .
69
3.6. Resultados y mtricas para la evolucin de tpicos . . . . . . . .
71
3.7. Anlisis de la evolucin de tpicos . . . . . . . . . . . . . . . . .

3.8. Conclusin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
80
4. Indexacin y bsqueda mediante Lucene

4.1. Utilizacin de ndices con Lucene . . . . . . . . . . . . . . . . . .
81
81
4.1.1. Indizacin . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
4.1.2. Bsqueda dentro del ndice . . . . . . . . . . . . . . . . .
83
4.1.3. Extensin de las bsquedas . . . . . . . . . . . . . . . . .
84
4.1.3.1. Ejemplo de una bsqueda con los trminos de

4.2. Conclusin
un tpico . . . . . . . . . . . . . . . . . . . . . .
85
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
5. Aplicacin para la extraccin y anlisis de tpicos
87
5.1. Descripcin de la aplicacin . . . . . . . . . . . . . . . . . . . . .
87
5.2. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
5.3. Conclusin
97
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6. Conclusin
99
6.1. Contribucin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

6.2. Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Bibliografa
103
A. Historial de versiones de Android
117
ndice de figuras
2.1.1.Proceso de KDD . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.4.1.Camino desde los datos puros hasta el TM. Aqu TM incluye LSI,
ICA, PLSI, LDA y todas las variantes de LDA. . . . . . . . . . .
35
2.4.2.Representacin grfica del modelo LDA. Las cajas son "placas"

que representan rplicas. La placa exterior representa documentos, mientras que la placa interior representa la eleccin repetida
de temas y palabras dentro de un documento. . . . . . . . . . . .
40
3.2.1.Distribucin de los componentes de los bugs. Grfico generado

por la aplicacin. . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1.Estapas (pipes) de pre-procesamiento de los documentos.
61
. . . .
68
3.7.1.Mtricas del tpico Z99 . . . . . . . . . . . . . . . . . . . . . . . .
74
3.7.2.Mtricas del tpico Z92 . . . . . . . . . . . . . . . . . . . . . . . .
76
3.7.3.Mtrica assignment para el tpico Z22 .
. . . . . . . . . . . . . .
77
3.7.4.Mtrica focus para el tpico Z86 . . . . . . . . . . . . . . . . . . .
78
3.7.5.Mtrica weight para el tpico Z20 . . . . . . . . . . . . . . . . . .
79
3.7.6.Mtrica assignment para el tpico Z71 . . . . . . . . . . . . . . . .
80
5.1.1.Pantalla inicial de la aplicacin. Primera pestaa. . . . . . . . . .
88
5.1.2.Segunda pestaa. . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
5.1.3.Tercera pestaa. . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
5.1.4.Cuarta pestaa. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
5.1.5.Quinta pestaa. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
5.2.1.Diagrama de clases de los algoritmos utilizados.
. . . . . . . . .
93
5.2.2.Diagrama de clases del mdulo lucene. . . . . . . . . . . . . . . .
94
5.2.3.Diagrama de clases del mdulo DAO.
. . . . . . . . . . . . . . .
95
5.2.4.Diagrama de clases del mdulo DTO. . . . . . . . . . . . . . . .
96
5.2.5.Diagrama de clases del mdulo de las mtricas. . . . . . . . . . .
96
ndice de cuadros
3.1. Esquema del conjunto de datos.
. . . . . . . . . . . . . . . . . .
60
3.2. Distribucin de la contribucin de los usuarios. . . . . . . . . . .
61
3.3. Dimensiones usadas en el modelo de tpicos.
. . . . . . . . . . .
65
3.4. Arreglos usados en el modelo de tpios. . . . . . . . . . . . . . .
65
3.5. Tpicos extrados con sus cinco trminos mas influyentes ordenados descendientemente por sus respectivas probabilidades. . . . .
70
4.1. Tipos de analizadores de la librera Lucene. . . . . . . . . . . . .
82
4.2. Los diez trminos mas relevantes del tpico Z27 . Ordenados en
forma decreciente. . . . . . . . . . . . . . . . . . . . . . . . . . .
85
4.3. Resultados obtenidos de la consulta para los trminos del cuadro

4.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
Algoritmos
2.1. Algoritmo de generacin de un proceso LDA. . . . . . . . . . . .
39
3.1. Creacin de los documentos a partir de los bugs. . . . . . . . . .
62
3.2. Creacin de las versiones a partir de los parmetros iniciales establecidos en la aplicacin.
. . . . . . . . . . . . . . . . . . . . .
3.3. Algoritmo del modelo de tpicos aplicado.
. . . . . . . . . . . .
64
66
Captulo 1
Introduccin
1.1.
Contexto
La calidad del software es una preocupacin importante en la ingeniera

del software porque el costo de arreglar los defectos en un sistema pueden ser
excesivamente altos (Slaughter et al., 1998). En consecuencia los investigadores
han tratado de descubrir las posibles causas de los defectos de la calidad del
software, tales como mtricas de producto (por ejemplo tamao), mtricas de
proceso (por ejemplo tiempo para arreglar un defecto) y mtricas de proyecto
(por ejemplo tamao del equipo) (Hall et al., 2011; Kan, 2002).
En efecto, tales enfoques han mostrado cierto xito explicando la propensin
a defectos en ciertas entidades de software (por ejemplo mtodos, clases, archivos
o mdulos) (Hall et al., 2011). Sin embargo, estas clases de mtricas no toman
en cuenta las preocupaciones (concerns) conceptuales del sistema de software
(los requerimientos principales y las decisiones de diseo) que pueden afectar
los detalles de implementacin (Robillard & Murphy, 2007; Liu et al., 2009).
Analizar lineas de cdigo puede ser una buena forma de medir de manera general los defectos pero esto no siempre es as. Por ejemplo, el archivo mas grande
del proyecto Mylyn1 tiene 2771 lineas de cdigo pero sin defectos, mientras que
un archivo mucho mas pequeo, con 23 lineas de cdigo contiene defectos en la
versin 1.0.
Es por ello que los desarrolladores para verificar la calidad de los mismos
emplean casos de test para descubrir defectos en un sistema de software durante
el ciclo de vida. Sin embargo estas mtricas no consideran las preocupaciones
(concerns) conceptuales en el cdigo fuente. Los tests a nivel de concerns (Weyuker, 1998) permiten identificar que concerns requieren mas sometimiento a
casos de tests que otros, de esta forma se pueden identificar donde se deben
1 https://projects.eclipse.org/projects/mylyn
14
CAPTULO 1. INTRODUCCIN
15
aplicar mas recursos de manera tal que permita mejorar la calidad del cdigo
fuente.
En el desarrollo de proyectos de software tanto el cdigo fuente de un sistema de software como tambin otros datos relacionados con el mismo, como por
ejemplo defectos detectados mediante los casos de test mencionados anteriormente, se almacenan en forma digital en repositorios de software. Esto facilita el
acceso y las bsquedas de datos relacionados con el mismo y a su vez transforma a los repositorios en una fuente voluminosa e importante de datos de donde
se puede extraer informacin relevante a los concerns mediante el empleo de
mtodos de la Inteligencia Artificial (IA), como es la Minera de Datos. Esta
tcnica se emplea en el campo de la Ingeniera de Software y se conoce como
Minera de Repositorios de Software (MSR, por sus siglas en ings). Se focaliza
en el anlisis y entendimiento de los repositorios relacionados con el desarrollo
de un proyecto de software (Godfrey et al., 2009; Hassan, 2006; Hassan & Holt,
2005).
El principal objetivo es hacer un uso inteligente de estos repositorios de
software para mejorar al proceso de decisin de un proyecto de software. Esta
tcnica se ha aplicado con xito prediciendo localizacin de defectos en el cdigo
fuente, descubriendo puntos de trazabilidad entre documentos, requerimientos y
el cdigo fuente. Con ello se indexan los repositorios para proveer una bsqueda
rpida para los stakeholders y tambin inferir la red social de desarroladores
basndose en patrones de comunicacin mediante el correo electrnico (Tichy,
2010; Zimmermann et al., 2005).
Estos repositorios se componen de datos estructurados y no estructurados. El
cdigo fuente puede considerarse como un dato estructurado en si, aunque este
tambin contiene datos que no son estructurados como los comentarios, nombres
identificatorios que capturan la semntica de ciertas estructuras y las intenciones
del desarrollador del documento. Otros tipos de repositorios contienen especficamente datos no estructurados, como correos electrnicos, documentacin de
requerimientos y reportes de defectos (bugs) en un sentido mas tradicional.
1.2.
Motivacin
Recientemente un nuevo tipo de enfoque se ha vuelto mas popular en la

forma de analizar estos datos no estructurados que se denomina modelo de tpicos. Permite descubrir relaciones entre palabras y documentos (Thomas et al.,
2012; Linstead et al., 2008a; Liu et al., 2009; Maskeri et al., 2008; Nguyen et al.,
2011b). Los modelos de tpicos, como Latent Semantic Indexing (LSI) y Latent
Diriechlet Allocation (LDA) son atractivos porque estos no requieren datos de
entrenamiento, son completamente automticos y tambin pueden escalar desde
16
miles a millones de documentos. Estas tcnicas, LSI y LDA, han sido recientemente descubiertas por la comunidad de la Ingeniera de Software y provienen
del campo de Proceso de Lenguaje Natural (NLP) y de Recuperacin de la
Informacin (IR).
Estos estudios aproximan las preocupaciones (concerns) como tpicos haciendo uso de los modelos de tpicos (o Latent Topic Model o Statistical Topic
Model), como por ejemplo Dirichlet Allocation (LDA) (Blei et al., 2003). Los
tpicos son una coleccin de palabras o trminos relacionados que co-ocurren
frecuentemente en el cuerpo de un documento, por ejemplo, un tpico podra
ser {mouse, click, drag, right, left} o {user, account, password, authentication}.
Debido a la naturaleza del uso del lenguaje, los trminos que constituyen un
tpico a menudo se relacionan semnticamente (Blei et al., 2003).
LDA es un modelo diseado para extraer tpicos desde el cuerpo de texto
de los documentos. Investigaciones relacionadas proveen una evidencia inicial
de que los tpicos en sistemas de software estn relacionados a los defectos en
los archivos de cdigo fuente, creando de esta manera una nueva perspectiva de
porque algunos defectos son mas propensos que otros.
Analizar y caracterizar cmo un sistema de software cambia en el tiempo, o
la evolucin de un proyecto de software (Lehman, 1980), ha sido de inters para
los investigadores durante muchos aos. Ambas, cmo y porqu un sistema de
software varia puede ayudar a mejorar el rendimiento de los procesos empleados
en un determinado proyecto de software.
Se ha aplicado LDA (Linstead et al., 2008a) a varias versiones de cdigo
fuente de un proyecto en un esfuerzo por identificar las tendencias de los tpicos
a travs del tiempo. Cuando documentos relativos a un tpico son agregados
por primera vez al sistema, los tpicos experimentaran un aumento en su probabilidad total.
Similarmente se ha evaluado en (Thomas et al., 2010) la efectividad de la
evolucin de los modelos de tpicos para detectar tendencias en el proceso de
desarrollo de software. Los autores aplicaron LDA a una serie de versiones del
cdigo fuente y calcularon la popularidad de un tpico a lo largo del tiempo.
Luego verificaron estos aumentos o cadas de popularidad de los tpicos y en
efecto coincidieron con la actividad mencionada en las notas de las versiones
y otros documentos de los proyectos, otorgando evidencia de que los modelos
de evolucin de tpicos proporcionan un buen resumen sobre la historia de un
sistema de software.
Tambin se aplico LDA (Hindle et al., 2010, 2009b) a los mensajes de logs
de los commits que se realizan en un cdigo fuente para observar en que tpicos estn trabajando los desarrolladores en un determinado momento. Estos
autores aplicaron LDA a 18 mensajes de logs en un periodo de 30 das y luego
17
unieron estos periodos de tiempo usando una medida de similitud de tpicos

(por ejemplo, dos tpicos son unidos o similares si comparten entre si 8 o 10
de los primeros trminos en comn). A estos autores les resulto til LDA para identificar las tendencias de las actividades de los desarrolladores. Neuhaus
y Zimmerman (Neuhaus & Zimmermann, 2010) usaron LDA para analizar las
Vulnerabilidades y Exposiciones Comunes (CVE) en las bases de datos, con
reportes de vulnerabilidades desde diferentes fuentes. El objetivo de esa investigacin era buscar las tendencias de cada vulnerabilidad, para observar cuales
se incrementaban y cuales decrecan. Encontraron que sus resultados eran en su
mayora comparables con un estudio normal del mismo conjunto de datos.
1.3.
Tesis
El fin de este trabajo es implementar una herramienta que permita analizar

reportes de software mediante el empleo de una tcnica de extraccin de tpicos
y caracterizar la evolucin de los mismos mediante el empleo de mtricas ya
probadas en trabajos como (Thomas et al., 2012).
La herramienta tambin permite la creacin de un ndice para poder realizar
diferentes tipos de consultas sobre el conjunto de datos. Tambin permite elegir
entre un conjunto de algoritmos de agrupamiento (clustering) para refinar el
resultado a una consulta dada.
Se aplic un pre-proceso a los datos para quitar ruido y se almacen en
una base de datos. A partir de esta base de datos se realiza la extraccin de
tpicos mediante el empleo de la tcnica llamada Latent Dirichlet Allocation
(LDA) (Blei et al., 2003). La evaluacin de estos tpicos obtenidos es analizada
mediante el empleo de mtricas como assignment, weight, scattering, entre otras
(Thomas et al., 2012).
Adems, se establecen las ventajas y desventajas de este algoritmo. Para
experimentar con la herramienta desarrollada y realizar la evaluacin de los
resultados se utiliz un conjunto de datos estndar (dataset) propuesto en un
desafo sobre minera de datos que se realiza desde el ao 2006 en la International
Working Conference on Mining Software Repositories (MSR); espeficificamente
al desafio propuesto en el ao 20122 . Este conjunto se centra en reportes de
bugs de diferentes aplicaciones que corren sobre la plataforma Android. La informacin brindada en cada bug es: identificador, ttulo, estado, tipo, prioridad,
componente, fecha de inicio, persona que lo reporta, descripcin y una lista de
comentarios (Shihab et al., 2012).
A travs del anlisis que realiza la aplicacin se puede extender la misma
2 http://2012.msrconf.org/
18
mediante la incorporacin de otras tcnicas y as mejorar las mismas y su respectivo desempeo.
1.4.
Organizacin del trabajo
Este trabajo se encuentra organizado de la siguiente manera. En el captulo

2 se describen los conceptos generales que incluyen: concepto de Descubrimiento
de Conocimiento, Minera de Datos, Minera de Repositorios de Software, modelos de tpicos, diferencias y similitudes entre los dos modelos mas empleados
en distintos trabajos e investigaciones relacionadas sobre los modelos de tpicos, organizados de acuerdo a las tareas mas relevantes que tiene la ingenira de
software.
En el captulo 3 se presenta el conjunto de datos utilizado para las pruebas de
la herramienta. Luego se introducen los algoritmos empleados asi como tambin
el pre-procesamiento necesario para los mismos. Luego se introducen las mtricas
aplicadas para observar la evolucin de los tpicos y los resultados obtenidos.
En el captulo 4 se detalla el proceso de indexacin y bsqueda implementado
mediante la librera Lucene3 .
En el captulo 5 se ilustra la aplicacin desarrollada para la recuperacin de
datos y extracin de tpicos as como tambin su arquitectura.
El captulo 6 se describen las conclusiones obtenidas en este trabajo e identifican posibles trabajos futuros.
En la literatura existen diferencias en el uso de los terminos como error,
defecto y falla dado que poseen diferencias en sus definiciones. Trataremos
estos terminos como sinonimos de bug de forma indistinta.
3 http://lucene.apache.org/
Captulo 2
Estado del Arte

En los ltimos aos, ha existido un gran crecimiento en nuestras capacidades
de generar y colectar datos, debido bsicamente al gran poder de procesamiento
de las mquinas como a su bajo costo de almacenamiento. Sin embargo, dentro
de estas enormes masas de datos existe una gran cantidad de informacin oculta,
de gran importancia estratgica, a la que no se puede acceder por las tcnicas
clsicas de recuperacin de la informacin.
El descubrimiento de esta informacin oculta es posible gracias a la Minera de Datos (Data Mining), que entre otras sofisticadas tcnicas aplica la
inteligencia artificial para encontrar patrones y relaciones dentro de los datos
permitiendo la creacin de modelos, es decir, representaciones abstractas de la
realidad, pero es el descubrimiento del conocimiento (Knowledge Discovery in
Databases, KDD) que se encarga de la preparacin de los datos y la interpretacin de los resultados obtenidos, los cuales dan un significado a estos patrones
encontrados.
As el valor real de los datos reside en la informacin que se puede extraer de
ellos, informacin que ayude a tomar decisiones o mejorar nuestra comprensin
de los fenmenos que nos rodean. Hoy, ms que nunca, los mtodos analticos
avanzados son el arma secreta de muchos negocios exitosos.
Empleando mtodos analticos avanzados para la explotacin de datos, los
negocios incrementan sus ganancias, maximizan la eficiencia operativa, reducen
costos y mejoran la satisfaccin del cliente.
20
CAPTULO 2. ESTADO DEL ARTE
2.1.
21
Concepto de Descubrimiento de Conocimiento
De forma general, los datos son la materia prima bruta. En el momento que
el usuario les atribuye algn significado especial pasan a convertirse en informacin. Cuando los especialistas elaboran o encuentran un modelo, haciendo que
la interpretacin de la informacin y ese modelo representen un valor agregado,
entonces nos referimos al conocimiento.
La capacidad de generar y almacenar informacin creci considerablemente
en los ltimos tiempos, se ha estimado que la cantidad de datos en el mundo
almacenados en bases de datos se duplica cada 20 meses. Es as que hoy las
organizaciones tienen gran cantidad de datos almacenados y organizados, pero
a los cuales no los pueden analizar eficientemente en su totalidad.
Con las sentencias SQL se puede realizar un primer anlisis, aproximadamente el 80 de la informacin se obtiene con estas tcnicas. El 20 % restante,
que la mayora de las veces, contiene la informacin ms importante, requiere
la utilizacin de tcnicas ms avanzadas.
El KDD apunta a procesar automticamente grandes cantidades de datos
para encontrar conocimiento til en ellos, de esta manera permitir al usuario
el uso de esta informacin valiosa para su conveniencia. El KDD es el proceso
no trivial de identificar patrones vlidos, novedosos, potencialmente tiles y, en
ltima instancia, comprensibles a partir de los datos (Fayyad et al., 1996).
El objetivo fundamental del KDD es encontrar conocimiento til, vlido,
relevante y nuevo sobre un fenmeno o actividad mediante algoritmos eficientes,
dadas las crecientes rdenes de magnitud en los datos. Al mismo tiempo hay un
profundo inters por presentar los resultados de manera visual o al menos de
manera que su interpretacin sea muy clara. Otro aspecto es que la interaccin
humano-mquina deber ser flexible, dinmica y colaboradora.
El resultado de la exploracin deber ser interesante y su calidad no debe
ser afectada por mayores volmenes de datos o por ruido en los datos. En este
sentido, los algoritmos de descubrimiento de informacin deben ser altamente
robustos.
Las metas del KDD son:
Procesar automticamente grandes cantidades de datos crudos.
Identificar los patrones ms significativos y relevantes.
Presentarlos como conocimiento apropiado para satisfacer las metas del
usuario.
22
Figura 2.1.1: Proceso de KDD
2.1.1.
El proceso de KDD
El proceso de KDD consiste en usar mtodos de minera de datos (algoritmos

y tcnicas) para extraer e identificar lo que se considera como conocimiento de
acuerdo a la especificacin de ciertos parmetros empleando una base de datos
junto con pre-procesamientos y post-procesamientos. En la figura 2.1.1 se ilustra
el proceso de KDD. Se estima que la extraccin de patrones (minera) de los
datos ocupa solo el 15 % a 20 % del esfuerzo total del proceso de KDD.
El proceso de descubrimiento de conocimiento en bases de datos involucra
varios pasos:
Determinar las fuentes de informacin: que pueden ser tiles y dnde conseguirlas.
Disear el esquema de un almacn de datos (Data Warehouse): que consiga
unificar de manera operativa toda la informacin recogida.
Implantacin del almacn de datos: que permita la navegacin y visualizacin previa de sus datos, para discernir qu aspectos puede interesar que
sean estudiados. Esta es la etapa que puede llegar a consumir el mayor
tiempo.
Seleccin, limpieza y transformacin de los datos que se van a analizar:
la seleccin incluye tanto un filtro o fusin horizontal (filas) como vertical
(atributos). La limpieza y pre-pocesamiento de datos se logra diseando
una estrategia adecuada para manejar ruido, valores incompletos, secuencias de tiempo, casos extremos (si es necesario), etc.
Seleccionar y aplicar el mtodo de minera de datos apropiado: esto incluye la seleccin de la tarea de descubrimiento a realizar, por ejemplo,
clasificacin, agrupamiento, regresin, etc. La seleccin de l o de los algoritmos a utilizar. La transformacin de los datos al formato requerido
23
por el algoritmo especfico de minera de datos. Para llevar a cabo el proceso de minera de datos, se buscan patrones que puedan expresarse como
un modelo o simplemente que expresen dependencias de los datos, el modelo encontrado depende de su funcin (clasificacin) y de su forma de
representarlo (rboles de decisin, reglas, etc.), se tiene que especificar un
criterio de preferencia para seleccionar un modelo dentro de un conjunto
posible de modelos, se tiene que especificar la estrategia de bsqueda a
utilizar (normalmente est predeterminada en el algoritmo de minera).
Evaluacin, interpretacin, transformacin y representacin de los patrones extrados: Interpretar los resultados y posiblemente regresar a los pasos
anteriores. Esto puede involucrar repetir el proceso, quizs con otros datos,
otros algoritmos, otras metas y otras estrategias. Este es un paso crucial en
donde se requiere tener conocimiento del dominio. La interpretacin puede beneficiarse de procesos de visualizacin, y sirve tambin para borrar
patrones redundantes o irrelevantes.
Difusin y uso del nuevo conocimiento.
Incorporar el conocimiento descubierto al sistema (normalmente para mejorarlo)
lo cual puede incluir resolver conflictos potenciales con el conocimiento existente.
El conocimiento se obtiene para realizar acciones, ya sea incorporndolo dentro
de un sistema de desempeo o simplemente para almacenarlo y reportarlo a las
personas interesadas. En este sentido, KDD implica un proceso interactivo e
iterativo involucrando la aplicacin de varios algoritmos de minera de datos.
2.2.
Minera de Datos
Aunque desde un punto de vista acadmico el trmino minera de datos es

una etapa dentro de KDD, (como se mencion en la seccin anterior) en el
entorno comercial, as como en este trabajo, ambos trminos se usan de manera
indistinta.
Lo que en verdad hace la minera de datos es reunir las ventajas de varias
reas como la Estadstica, la Inteligencia Artificial, la Computacin Grfica, las
Bases de Datos y el Procesamiento Masivo, principalmente usando como materia
prima las bases de datos.
Una definicin tradicional es la siguiente:
Un proceso no trivial de identificacin vlida, novedosa, potencialmente til y entendible de patrones comprensibles que se encuentran ocultos en los datos. (Fayyad et al., 1996).
Desde el punto de vista empresarial , se define como:
24
La integracin de un conjunto de reas que tienen como propsito

la identificacin de un conocimiento obtenido a partir de las bases
de datos que aporten un sesgo hacia la toma de decisin. (Flix &
Carlos, 2002).
La idea de la minera de datos no es nueva. Ya desde los aos sesenta los estadsticos manejaban trminos como data fishing, data mining o data archaeology
con la idea de encontrar correlaciones sin una hiptesis previa en bases de datos
con ruido. A principios de los aos ochenta, Rakesh Agrawal, Gio Wiederhold,
Robert Blum y Gregory Piatetsky-Shapiro, entre otros, empezaron a consolidar
los trminos de data mining y KDD (Orallo et al., 2000).
A finales de los aos ochenta slo existan un par de empresas dedicadas a
esta tecnologa; en 2002 existen ms de 100 empresas en el mundo que ofrecen
alrededor de 300 soluciones. Las listas de discusin sobre este tema las forman
investigadores de ms de ochenta pases. Esta tecnologa ha sido un buen punto
de encuentro entre personas pertenecientes al mbito acadmico y al mundo de
los negocios.
La minera de datos es una tecnologa compuesta por etapas que integra
varias reas y que no se debe confundir con un gran software. Durante el desarrollo de un proyecto de este tipo se usan diferentes aplicaciones de software en
cada etapa que pueden ser estadsticas, de visualizacin de datos o de inteligencia artificial, principalmente. Actualmente existen aplicaciones o herramientas
comerciales de minera de datos muy poderosas que contienen un sin fn de
utileras que facilitan el desarrollo de un proyecto. Sin embargo, casi siempre
acaban complementndose con otra herramienta.
La minera de datos es la etapa de descubrimiento en el proceso de KDD:
Paso consistente en el uso de algoritmos concretos que generan una enumeracin
de patrones a partir de los datos pre-procesados (Fayyad et al., 1996). Aunque
se suelen usar indistintamente los trminos KDD y Minera de Datos.
2.2.1.
Los fundamentos de la Minera de Datos
Las tcnicas de Data Mining son el resultado de un largo proceso de investigacin y desarrollo de productos. Esta evolucin comenz cuando los datos de
negocios fueron almacenados por primera vez en computadoras, y continu con
mejoras en el acceso a ellos, y ms recientemente con tecnologas generadas para
permitir a los usuarios navegar a travs de los datos en tiempo real.
La minera de datos toma este proceso de evolucin ms all del acceso y navegacin retrospectiva de los datos, hacia la entrega de informacin prospectiva
y proactiva. La minera de datos est lista para su aplicacin en la comunidad de
negocios porque est soportada por tres tecnologas que ya estn suficientemente
25
maduras:
Recoleccin masiva de datos.
Potentes computadoras con multiprocesadores.
Algoritmos de Data Mining.
Las bases de datos comerciales estn creciendo a un ritmo sin precedentes. Un
reciente estudio del Meta Group Chaudhuri & Dayal (1997) sobre los proyectos
de Data Warehouse encontr que el 19 % de los que contestaron estn por encima del nivel de los 50 Gigabytes, mientras que el 59 % lo alcanz en el segundo
trimestre de 1997. En algunas industrias, tales como ventas al por menor, estos
nmeros pueden ser an mayores. MCI Telecommunications Corp. cuenta con
una base de datos de 3 terabytes mas 1 terabyte de ndices y overhead corriendo
en un sistema operativo MVS (Multiple Virtual Storage) sobre IBM SP2. La necesidad paralela de motores computacionales mejorados puede ahora alcanzarse
con tecnologa de computadoras con multiprocesamiento paralelo. Los algoritmos de Data Mining utilizan tcnicas que han existido por lo menos desde hace
10 aos, pero que slo han sido implementadas recientemente como herramientas maduras, confiables, extendibles que consistentemente son ms performantes
que mtodos estadsticos clsicos.
En la evolucin desde los datos de negocios a informacin de negocios, cada
nuevo paso se basa en el previo. Por ejemplo, el acceso a datos dinmicos es crtico para las aplicaciones de navegacin de datos, y la habilidad para almacenar
grandes bases de datos es crtica para Data Mining.
Los componentes esenciales de la tecnologa de Data Mining han estado bajo
desarrollo por dcadas, en reas de investigacin como estadsticas, inteligencia
artificial y aprendizaje de mquinas. Hoy, la madurez de estas tcnicas, junto
con los motores de bases de datos relacionales de alta performance, hicieron que
estas tecnologas fueran prcticas para los entornos de Data Warehouse actuales.
2.2.2.
Principales caractersticas y objetivos de la Minera

de Datos
A continuacin se enumeran cada una de las principales caracteristicas y

obejetivos:
Explorar los datos se encuentran en las profundidades de las bases de datos, como los almacenes de datos, que algunas veces contienen informacin
almacenada durante varios aos.
En algunos casos, los datos se consolidan en un almacn de datos y en
mercados de datos; en otros, se mantienen en servidores de Internet.
26
El entorno de la minera de datos suele tener una arquitectura clienteservidor.

Las herramientas de la minera de datos ayudan a extraer el mineral de
la informacin enterrado en archivos corporativos o en registros pblicos,
archivados.
El minero es, muchas veces un usuario final con poca o ninguna habilidad
de programacin pero es asistido por poderosas herramientas indagatorias
para efectuar preguntas adhoc y obtener respuestas rpidamente.
Hurgar a menudo implica el descubrimiento de resultados valiosos e inesperados.
Las herramientas de la minera de datos se combinan fcilmente y pueden
analizarse y procesarse rpidamente.
Debido a la gran cantidad de datos, algunas veces resulta necesario usar
procesamiento en paralelo para la minera de datos.
La minera de datos produce cinco tipos de informacin:
Asociaciones.
Secuencias.
Clasificaciones.
Agrupamientos.
Pronsticos.
Los mineros de datos usan varias herramientas y tcnicas.
La minera de datos es un proceso que invierte la dinmica del mtodo cientfico
en el siguiente sentido:
En el mtodo cientfico, primero se formula la hiptesis y luego se disea
el experimento para coleccionar los datos que confirmen o refuten la hiptesis.
Si esto se hace con la formalidad adecuada (cuidando cules son las variables
controladas y cules experimentales), se obtiene un nuevo conocimiento.
En la minera de datos, se coleccionan los datos y se espera que de ellos
emerjan hiptesis. Se busca que los datos describan o indiquen por qu son como son. Luego entonces, se valida esa hiptesis inspirada por los datos en los
datos mismos, ser numricamente significativa, pero experimentalmente invlida. De ah que la minera de datos debe presentar un enfoque exploratorio, y no
confirmador. Usar la minera de datos para confirmar las hiptesis formuladas
puede ser peligroso, pues se est haciendo una inferencia poco vlida.
27
La minera de datos es una tecnologa compuesta por etapas que integra

varias reas y que no se debe confundir con un gran software. Durante el desarrollo de un proyecto de este tipo se usan diferentes aplicaciones software en
cada etapa que pueden ser estadsticas, de visualizacin de datos o de inteligencia artificial, principalmente. Actualmente existen aplicaciones o herramientas
comerciales de minera de datos muy poderosas que contienen un sinfn de utileras que facilitan el desarrollo de un proyecto. Sin embargo, casi siempre acaban
complementndose con otra herramienta.
2.3.
Minera de Repositorios de Software
La Minera de Repositorios de Software (MSR) es una tcnica usada en el

campo de la Ingeniera de Software (SE) con el fin de analizar y entender los
repositorios de datos de un proyecto en desarrollo Godfrey et al. (2009); Hassan
(2006); Hassan & Holt (2005).
La meta principal de MSR es hacer un uso inteligente de estos repositorios
de software para apoyar en el proceso de toma de decisiones de un proyecto de
software. Algunos ejemplos de MSR que se realizaron con xito incluyen prediccin de bugs en el cdigo fuente, descubrir trazabilidad entre los documentos de
los requerimientos y el cdigo fuente, indexacin de repositorios para proveer
una bsqueda rpida para stakeholders e inferir la red social de desarolladores
basado en el uso del patrones de correos electrnicos(Tichy, 2010; Zimmermann
et al., 2005).
Los repositorios en un proyecto de software contienen en su mayora datos
no estructurados. Pese a que el cdigo fuente son datos estructurados contiene
comentarios, nombres identificactorios y tiene literales de texto (strings) que
capturan la semntica e intenciones del desarrollador en ese documento. Desde
que los desarrolladores tienden a utilizar nombre identificatorios, proveyendo
comentarios que describen la funcionalidad del cdigo y escribiendo los mensajes
de error que se emiten por la pantalla permiten utilizar estas tres fuentes para
analizar y tener una buena aproximacin de lo que est ocurriendo en el cdigo
fuente sin saber exactamente como. Otros repositorios, como archivos de correo
electrnico, documentos de los requerimientos y reportes de bugs contienen texto
no estructurado en el sentido ms tradicional.
Una manera que se esta volviendo mas popular de analizar texto no estructurado en otros dominios es mediante modelos de tpicos que hace ahnco en
descrubrir relaciones entre las palabras y los documentos Anthes (2010); Srivastava & Sahami (2010); Steyvers & Griffiths (2007); Zhai (2008). Los modelos
de tpicos como Latent Semantic Indexing (LSI) y Latent Dirichlet Allocation
(LDA), son atractivos porque no requieren datos de entrenamientos, son com-
28
pletamente automticos y se puede aplicar a miles o millones de documentos.

Originalmente desde el Procesamiento del Lenguaje Natural (NLP) y del campo de la Recuperacin de la Informacin (IR) los modelos de tpicos han sido
recientemente descubiertos por la comunidad de la SE.
2.3.1.
Los repositorios de software
El mantenimiento de software, es decir, la fase donde los desarrolladores

reaccionan a los cambios de requerimientos, es la fase ms costosa del desarrollo,
porque cambiar un sistema grande es extremadamente difcil.
Cmo se puede juzgar entonces el impacto de un cambio en un proyecto
que ha vivido varios aos, ha sido escrito por un equipo de desarrollo de gran
tamao (potencialmente distribuido), y tiene miles (si no millones) de lneas de
cdigo?
En este contexto, cada informacin adicional sobre el sistema que se mantiene es til. Para hacer frente a estos desafos, los investigadores en el rea
de investigacin de MSR exploran los repositorios de informacin ms precisos
que tenemos sobre el desarrollo de software: los desarrolladores almacenarn
discusiones de diseo, informes de problemas, y los cambios que realizan en
herramientas especializadas, llamadas repositorios de software. Una vez recuperada (en un proceso que puede ser difcil) la informacin tiene un enorme
valor para los desarrolladores, testeadores, encargados de mantener el sistema,
arquitectos y administradores.
Estos repositorios ofrecen un punto de vista rico y detallado del camino
tomado para realizar un sistema de software. Analizando estos repositorios proporciona una gran cantidad de informacin histrica que puede beneficiar el
futuro proyecto de software Tichy (2010); Zimmermann et al. (2005). A continuacin se enumeran los tipos de repositorios de software mas comunes que se
emplean en el desarrollo de software principalmente en la SE.
2.3.1.1.
Cdigo fuente
El cdigo fuente de un proyecto de software es una especificacin ejecutable

del comportamiento del sistema de softwareLethbridge & Laganiere (2001). Es
considerado generalmente por los desarrolladores como el depsito ms importante, ya que es en ltima instancia, lo que crea el ejecutable que se entrega al
cliente. El repositorio de cdigo fuente se compone de una serie de documentos
de cdigo fuente escrito en uno o ms lenguajes de programacin. Estos documentos que contienen el cdigo fuente se agrupan generalmente en entidades
lgicas denominadas paquetes o mdulos. Todo el conjunto de documentos de
cdigo fuente que normalmente se conoce como el sistema.
29
Para las tareas de minera, el foco de atencin es solo sobre los identificadores
(por ejemplo, el nombre de las variables), comentarios, cadenas de texto literales
dentro del cdigo fuente. Las palabras correspondientes al lenguaje especfico
en que fue programado se descartan.
2.3.1.2.
Vulnerabilidad y errores de bases de datos
Una base de datos de bugs es usado para mantener informacin acerca de la

creacin de bugs, la resolucin de los mismos, mejoras en la funciones y otras
tareas de mantenimiento del proyectoSerrano & Ciordia (2005). Por lo general,
cuando los desarrolladores o usuarios experimentan un error en un sistema de
software, lo asientan en la base de datos de bugs como una issue, el cual incluye
informacin como y qu tarea que estaban realizando cuando se produjo el error,
si el error es repetible, y lo importante que si el error surge en la funcionalidad del
sistema. Luego los encargados de mantenimiento del sistema investigan esa issue
y si la resuelven la cierran. Luego los encargados de verificar la solucin cierran
la issue o si no la reabren. Todas estas tareas son capturadas y almacenadas en
este tipo de base de datos.
Un ejemplo de este tipo de sistema de bases datos son Bugzilla (Foundation
(2010)) y Trac (Sofware (2012)), aunque existen muchos mas.
En la literatura existen diferencias en el uso de los trminos como error,
defecto y falla dado que poseen diferencias en sus definiciones. Trataremos
estos trminos como sinnimos de bug de forma indistinta.
Una base de datos de vulnerabilidades almacena vulnerabilidades de seguridad y de riesgos potenciales Neuhaus & Zimmermann (2010). El objetivo de esta
base de datos es compartir con la comunidad y aplicaciones y tambin asignarle
un nombre a las vulnerabilidades mas conocidas.
2.3.1.3.
Listas de correo y registros (logs) de chats
Las listas de correo junto con los logs de los chats de un proyecto es un archivo
de comunicacin textual entre los desarrolladores, gerentes y otros stakeholders
del proyecto Shihab et al. (2010a). La lista de correo por lo general consta de un
conjunto de correos con fecha y hora, que contienen una cabecera (que posee el
emisor, receptor (s), y de fecha y hora), un cuerpo del mensaje con el contenido
y un conjunto de archivos que se adjuntaron. Los registros de los chats contienen
el registro de las conversaciones de mensajera instantnea entre los involucrados
en el proyecto y por lo general contienen una marca de tiempo, el autor y el
contenido del mensaje Bettenburg et al. (2009); Shihab et al. (2009a,b).

2.3.1.4.
30
El sistema de control de versiones
Una base de datos para el control de versiones es un sistema usado para

mantener y registrar la historia de cambios del cdigo fuente. Los desarrolladores las emplean para editar o mantener el cdigo fuente de un sistema de
software. Algunos ejemplos de los mas populares son Concurrent Versions System (CVS), Subversion (SVN) o GITHUB entre otros. Estos les permite a los
desarrolladores:
Obtener una copia del repositorio en su sistema de archivos local;
realizar cambios en esos documentos, agregar nuevos, cambiar la estructura de directorios y
aplicar esos cambios locales en el repositorio para luego ser compartidos
con el resto del equipo.
Cada revisin de control tiene dos ventajas escenciales. Primero, permite a los
desarrolladores realizar cambios en sus copias locales independientemente de los
dems desarrolladores que pueden tambin acceder al repositorio. Esta independencia permite el trabajo en paralelo sin tener que mandar cambios o nuevos
documentos por correo. La segunda ventaja de este esquema de versiones es que
permite llevar una historia de cambios de cada uno de los documentos con lo
cual si alguien desea una versin previa de algn documento puede solicitarlo
al sistema de control de versiones y este de forma automtica le revierte los
cambios.
2.3.1.5.
Documenntos de requerimientos y discusiones sobre el diseo
Los documentos de requerimientos, generalmente escritos en conjuncin (o la

aprobacin) del cliente, son documentos que enumeran el comportamiento deseado del sistema de softwareLethbridge & Laganiere (2001). Los requerimientos
pueden ser categorizados como funcionales, indicando que comportamiento debe tener el programa, y no funcionales, que describen las cualidades que debe
poseer el sistema de software, por ejemplo accesibilidad, fiabilidad, etc.
Los documentos sobre discusiones de diseo son documentos que describen
el diseo global del sistema de software, donde se incluyen descripciones arquitectnicas, algoritmos importantes y los casos de uso. Estos documentos pueden
ser en formas de diagramas (por ejemplo, UML Fowler (2004)) o simplemente
texto libre.

2.3.1.6.
31
Registros de ejecucin
Un registro de ejecuciones es un documento que contiene la salida y/o resultados de la ejecucin de una aplicacin y tambin uno o varios test de prueba
predefinidos. Estos test generalmente contienen una lista con los mtodos o funciones que fueron invocados con su registro temporal. Tambin los valores de
ciertas variables y otros detalles acerca de los detalles de la ejecucin. Estos
tipos de detalles son especialmente tiles para la tarea de realizar la depuracin
(debugging) en sistemas muy grandes.
2.3.1.7.
Repositorios del sistema de software
Un repositorio de sistemas de software es una coleccin (generalmente con

licencia Open Source) de sistemas de software. Estas colecciones tienen cientos
o miles de sistemas cuyo cdigo fuente puede ser descargado por alguien interesado. Algunos ejemplos de este tipo de repositorios pueden ser Source Forge
Geeknet. (2010) y Google Code Google (2012).
2.4.
Modelos de Tpicos
Antes de presentar el modelo LDA que fue utilizado en este trabajo, es

menester recordar primero los diferentes modelos analticos utilizados para la
co-ocurrencia de las observaciones en el contexto de la minera de textos. Aunque estos modelos de anlisis de datos se propusieron inicialmente para revelar
la vinculacin intrnseca entre los documentos y las palabras, es adecuado y
razonable para introducir la idea bsica en ciertos problemas de investigacin,
que nos ayudan a comprender fcilmente los fundamentos tericos, as como las
fortalezas de las tcnicas propuestas.
Como se mencion en el primer captulo los modelos de tpicos (o latent topic
model o statistical topic model) son modelos diseados para extraer tpcos de
forma automtica desde el cuerpo de documentosThomas et al. (2012); Linstead
et al. (2008a); Liu et al. (2009); Maskeri et al. (2008); Nguyen et al. (2011b).
Un tpico es una coleccin de trminos o palabras que co-ocurren de manera
frecuente en el cuerpo de los documentos analizados. Por ejemplo {mouse, click,
drag, right, left} y {user, account, password, authentication}. Dada la naturaleza
del lenguaje de los documentos, estos trminos que constituyen un tpico estan
a menudo relacionados semnticamente Blei et al. (2003).
Los modelos de tpicos fueron originalmente desarrollados en el campo de
NLP y en el campo de la IR como medio indexacin automtica, bsqueda,
agrupamiento y estructuramiento de documentos grandes y no etiquetados.
32
Usando los modelos de tpicos, los documentos pueden ser representados

por tpicos incluidos en los propios documentos, y por lo tanto todo el cuerpo
de los documentos pueden ser indexados y organizados en trminos de la estructura semntica descubierta en ellos. Los modelos de tpicos permiten una
representacin pequea del texto, con relaciones semnticas no descubiertas lo
que permite un rpido anlisis sobre el texto Zhai (2008).
2.4.1.
Terminologa empleada
Antes de exponer la definicin formal de los modelos de tpicos primero se

introduce el siguiente ejemplo de la aplicacin de un modelo de tpicos sobre
tres documentos. Los ejemplos son extrados de Thomas (2012), los mismos son
los siguientes:
1. Predicting the incidence of faults in code has been commonly associated
with measuring complexity. In this paper, we propose complexity metrics
that are based on the code change process instead of on the code.
2. Bug prediction models are often used to help allocate software quality assurance efforts (for example, testing and code reviews). Mende and Koschke
have recently proposed bug prediction models that are effort-aware.
3. There are numerous studies that examine whether or not cloned code is
harmful to software systems. Yet, few of these studies study which characteristics of cloned code in particular lead to software defects (or faults).
Trmino (palabra) w: es un texto con caracteres alfanumricos. En el ejemplo tenemos un total de 101 terminos. Por ejemplo, predicting, bug, there,
have, bug y of son todos trminos. Los trminos podran no ser nicos de
un solo documento.
Documento d: es un conjunto ordenado de N trminos w1 , . . . , wN . En el
ejemplo hay tres documentos: d1 , d2 y d3 . d1 con N = 34, d2 con N = 35
y d3 con N = 32.
Cuerpo C: es un conjunto no ordenado de documentos, d1 , . . . , dn . En el ejemplo hay un cuerpo que consiste de n = 3 documentos: d1 , d2 y d3 .
Vocabulario V : es un conjunto no ordenado de m trminos nicos que aparecen en un cuerpo. En el ejemplo el vocabulario consiste de m = 71
trminos nicos extrados a travs de los tres documentos del ejemplo.
Algunos trminos seran: code, are, that, to, the, sof tware,. . .
33
Matriz Trminos-Documentos A: Esta matriz tiene una dimensin de m

n en la cual una entrada (i, j) tiene el peso de un trmino wi en el documento dj (de acuerdo a alguna funcin de peso como puede ser la de la
frecuencia de un trmino). En el ejemplo tenemos la siguiente matriz:

A =

d1
d2
code
of
are
...
...

d3

2

2

1

En esta matriz podemos observar que por ejemplo para el trmino code en
el documentos d1 aparece con una frecuencia de tres veces, en el documento d2 con una frecuencia de uno y en el documento d3 con una frecuencia
de dos. As sucesivamente para cada trmino podremos encontrar sus frecuencias en cada documento.
Tpico (concepto o tema) Z: Es un vector de tamao m con las probabilidades sobre el vocabulario de un cuerpo. En el ejemplo tendramos en
siguiente tpico:

code

Z1 =
0,25
of
are
that
to
the
sof tware
0,1
0,05
0,01
0,1
0,17
0,3

. . .

...
indicando que, por ejemplo, cuando el trmino es extrado del tpico Z1

hay un 25 % de posibilidades de que sea el trmino code y un 30 % de
chances de que el trmino sea sof tware. En este ejemplo se asumi que se
extrajeron los tpicos. Mas adelante se explicar como funcionan los dos
modelos principales LSI y LDA para obtener estos tpicos.
Vector de pertenencia a un tpico d : Para un documento di , existe un
vector de las probabilidades para K tpicos. Continuando con el ejemplo un vector para el documento d1 sera:

Z

1
d1 =
0,25
Z2
Z3
Z4
0,0
0,0
0,7

. . .

...
Esto nos indica que cuando un tpico es seleccionado para componer el

documento d1 , existe una probabilidad del 25 % de que sea el tpico Z1 y
un 70 % de que sea el tpico Z4 .
Matriz Documento-Tpico : Es una generalizacin del vector anterior, en
donde la matriz tiene n por K elementos. Un entrada (i, j) obtiene la
34
probabilidad de que un tpico Zj aparezca en el documento di , Cada fila

se corresponde a un di . Siguiendo con el ejemplo la matriz es la siguiente:

d1
=
d2

d3
Z1
Z2
Z3
Z4
0,25
0,0
0,0
0,7
0,0
0,0
0,0
1,0
0,1
0,4
0,2
0,0

. . .

. . .
. . .

...
Matriz Tpico-Trmino : Es una generalizacin del vector Zj . Las dimensiones de esta matriz sera de K por m elementos. Una entrada (i, j) obtiene la probabilidad de que un trmino wj aparezca en el tpicoZi .Cada fila
de la matriz se corresponde a un tpico. En el ejemplo la matriz quedara
representada de forma genrica como:

=

code
of
are
that
to
the
sof tware
Z1
0,25
0,1
0,05
0,01
0,1
0,17
0,3
Z2
0,0
0,0
0,0
0,05
0,2
0,0
0,05
Z3
0,1
0,04
0,2
0,0
0,07
0,1
0,12
...
...

. . .

...

. . .

...

Ahora si, luego de explicar la terminologa se introduce el concepto de modelo

de tpicos.
Modelo de tpicos (TM): Es un modelo que toma como entrada la matriz
A (Trminos-Documentos) y da como salida una matriz (DocumentoTpico) y la matriz (Tpico-Trmino).
Esta definicin describe los requerimientos mnimos de un modelo de tpicos.
Como se vera mas adelante algunos modelos de tpicos proveen mas informacin adems de las matrices mencionadas en su definicin como relaciones y
correlaciones entre tpicos, tpicos multi-lenguaje y tpicos etiquetados.
En este tipo de lenguajes del modelo surgen algunos problemas comunes a
todos ellos, como los siguientes:
Sinonimia: Dos trminos w1 y w2 , con w1 6= w2 , son sinnimos si ellos poseen
significados semnticos similares.
Polisemia: Un trmino w es una polisemia si tiene mltiples significados semnticos.
Se debe entender en este punto que la semntica es difcil de definir dado que
toma diferentes significados de acuerdo a su contexto. En algunos casos los
significados semnticos de un trmino son creados manualmente.
35
Figura 2.4.1: Camino desde los datos puros hasta el TM. Aqu TM incluye LSI,
ICA, PLSI, LDA y todas las variantes de LDA.
2.4.2.
Vector Space Model
Aunque no es un modelo de tpicos en si mismo, el Vector Space Model

(VSM) es la base para muchas tcnicas avanzadas en IR y para otros modelos de
tpicos. El VSM es un modelo algebraico simple basado en la matriz TrminosDocumentos A (Salton et al., 1975).
En VSM, un documento es representado por una columnah en la matriz A. Por
i
ejemplo, si el vector de trminos para un documento d fuese 0 1 1 0 0 ,

entonces de acuerdo a VSM, d contiene dos trminos, nombrados con los ndices
2 y 3 del respectivo vector. Igualmente, es posible determinar que documentos

contienen el trmino w seleccionando los elementos que no tengan ceros para
cada fila de la matriz A.
Con esta representacin, se puede realizar un consulta contra el cuerpo del
texto de la siguiente manera. Primero, calculamos el tamao m del vector para
la consulta q como si fuera el cuerpo de un documento. Luego, calculamos la
relacin semntica (a menudo se emplea la similitud del coseno) contra cada
columna de la matriz A. Finalmente lo resultados obtenidos los ordenamos de
acuerdo a la similitud obtenida en cada caso en forma de una lista con ranking.
De manera muy similar, tambin es posible determinar cual de los documentos
originales en el cuerpo son mas similares entre si. En la figura 2.4.1 se puede
observar este proceso de manera grfica.
2.4.3.
Latent Semantic Indexing
Latent Semantic Indexing (LSI), tambin conocido como Latent Semantic

Analysis (LSA), es un modelo que extiende a VSM reduciendo la dimensin de
la matriz A usando Singular Value Descomposition (SVD) (Deerwester et al.,
1990). Durante la fase de reduccin de la dimensiones, los trminos que estn
36
relacionados (en trminos de su co-ocurrencia) son agrupados juntos en tpicos.

La tcnica empleada para la reduccin del ruido ha sido probada incrementando notablemente el desempeo sobre VSM en trminos de como lidia con la
sinonimia y la polisemia (Baeza-Yates et al., 1999).
SVD es una fatorizacin de la matriz original A que reduce las dimensiones de
esta aislando valores singulares de A (Salton & McGill, 1983). SVD descompone
A en tres matrices: A = T SDT , donde T es un m por r = rank (A), de la matriz
Trminos-Tpicos, S es de r por r valores y D es de n por r valores de la matriz
Documento-Tpicos.
El paso de reduccin de SVD que emplea LSI lo hace eligiendo un factor de
reduccin K. Este valor K es generalmente mas chico que el valor de r de la
funcin rank (A). En lugar de reducir la matriz de entrada A en r dimensiones,
LSI reduce la matriz a K dimensiones. No hay una eleccin perfecta para el valor
de K dado que depende en gran medida de los datos, pero segn la literatura
generalmente oscila entre 50 y 300.
Como en VSM, los trminos y documentos son representados por los vectores de las filas y las columnas en la matriz A. Tambin, dos trminos (o dos
documentos) pueden ser comparados empleando alguna tcnica de medida de
distancias entre vectores, (por ejemplo la distancia del coseno) y las consultas pueden ser evaluadas contra la matriz. Sin embargo, porque la reduccin
de dimensionalidad de la matriz Trminos-Documentos despus de SVD, estas
medidas estn mas preparadas para lidiar con el ruido en los datos.
2.4.4.
Independent Component Anlysis
Idependent Component Analysis (ICA) (Comon, 1994) es una tcnica estadstica utilizada para descomponer una variable aleatoria en componentes estadsticamente independientes (dimensiones). Aunque generalmente no es considerada
una tcnica de modelos de tpicos, fue usada en forma similar a LSI para modelar documentos de cdigo fuente en un espacio conceptual de K dimensiones
.
Como LSI, ICA reduce las dimensiones de la matriz A para ayudar a reducir
el ruido de los trminos asociados. Sin embargo, a diferencia LSI, las dimensiones
resultantes de ICA son estadsticamente independientes unas de otras, lo que
ayuda a capturar mas variacin en los datos subyacentes (Grant & Cordy, 2009).
2.4.5.
Probabilistic Latent Semantic Indexing
Probabilistic Latent Semantic Indexing (PLSI), tambin conocido como Probabilistic Latent Semantic Analysis (PLSA) (Hofmann, 2001, 1999a), argumenta
37
que desde que LSI usa SVD en la fase de reduccin de dimensiones, LSI esta haciendo de forma implcita la suposicin de que la cuenta de trminos siguen una
distribucin de Gauss. Desde este supuesto no se verifica, LSI es "insatisfactoria
e incompleta" (Hofmann, 1999b).
Para superar este supuesto, PLSI define un modelo generativo con variables
latentes donde estas son tpicos en los documentos. A un alto nivel, un modelo
generativo tiene las ventajas de ser evaluado con tcnicas de estadstica estandar como por ejemplo modelos de chequeo, cross-validacion y control complejo.
LSI no puede ser evaluado bajo ninguna de estas tcnicas. Desde que se emplea variables latentes como tpicos en los documentos, PLSI est tambin bien
equipado para manejar ms fcilmente la polisemia y sinonimia.
Los pasos realizados por el modelo generativo pueden ser resumidos con los
siguientes:
1. Seleccionar un documento di con probabilidad P (di ).
2. Seleccionar un tpico Zk con probabilidad P (Zk |di ).
3. Generar un trmino wi con una probabilidad P (i |Zk ).
Teniendo en cuenta las observaciones en un conjunto de datos (es decir los trminos), uno puede realizar inferencia contra este modelo de tpicos no descubiertos
Zi , . . . , Zk . Como se indic anteriormente el modelo generativo PLSI sufre dos
problemas importantes. Primero, desde que d es usado como una variable de
ndice en el primer paso, el nmero de parmetros que necesitan ser estimados crece linealmente con el nmero de cuerpos de los documentos, que puede
conducir a graves problemas de ajuste. Segundo desde que los vectores Zk son
estimados por los documentos con el conjunto de datos no pueden volver a ser
aplicados para documentos nuevos.
2.4.6.
Latent Dirichlet Allocation
Latent Dirichlet Allocation (LDA) es un modelo generativo probabilstico de

observaciones co-ocurrentes muy popular (Blei et al., 2003) que a sustituido en
gran medida a PLSI.
Dice que un documento se crea mediante la seleccin de los temas y las
palabras de acuerdo a las representaciones probabilsticas del texto natural. Por
ejemplo, las palabras que se utilizan para escribir este prrafo se refieren a un
subtema de este documento como un todo. Las palabras reales que se usan y
lo componen son elegidas en base a ese tema. La probabilidad inherente en
los modelos de seleccin de cada palabra se deriva del hecho de que el lenguaje
natural nos permite utilizar mltiples palabras diferentes para expresar la misma
38
idea. Expresar esta idea en el modelo LDA, sirve para crear un documento sin
un cuerpo, lo que se podria determinar cmo una distribucin de temas. Para
cada palabra del documento que se est generando, se escoge un tema de una
distribucin de Dirichlet de temas. A partir de ese tema, se coge una palabra
elegida al azar basada en otra distribucin de probabilidad condicionada en ese
tema. Esto se repite hasta que el documento se ha generado.
La idea bsica que est detrs del modelo de un cuerpo con una distribucin Dirchilet sobre temas es que los documentos tienen varios temas y estos
se superpondrn. Por ejemplo, dentro de un cuerpo de documentos sobre la
Universidad de Princeton, habr ponencias individuales que forman parte del
Departamento de Ciencias de la Computacin. Es probable que haya algunas
palabras que se utilizan con ms frecuencia cuando se habla del Departamento
de Ciencias de la Computacin que de otros departamentos en el campus, tales
como: computadoras, algoritmos, grficos, datos, modelado, y redes. Otros departamentos, como Sociologa pueden tener temas donde encontremos algunas
palabras tales como: gnero, raza, edad, economa y redes. El modelo LDA ve
esto como un todo y elige los temas a partir de all. Si los documentos se compararon de forma individual, podra ser el caso de que ciertos temas no fueron
recogidos, y slo cuando todo el cuerpo es visto se empiezan a notar ciertos tpicos. En este ejemplo, palabras como redes pueden aparecer varias veces en los
documentos relativos a cualquier departamento. Esencialmente, LDA crea un
modelo ms realista del cuerpo, y por lo tanto, de los documentos individuales.
Las palabras que aparecen con menos frecuencia en los documentos nicos, pero
son comunes en muchos documentos diferentes probablemente es indicativo de
que existe un tema comn entre los documentos. Cuando se genera un resumen,
la capacidad de recoger los matices de los tpicos del documento permiten que
la informacin ms relevante sea incluida con menos posibilidades de repeticin
y dar as un mejor resumen.
La clave en LDA es que las palabras siguen una hiptesis de bolsa de palabras o, ms bien que el orden no importa, que el uso de una palabra es ser
parte de un tema y que comunica la misma informacin sin importar dnde se
encuentra en el documento. Esta hiptesis dice que Juan contrat a Pedro es lo
mismo que Pedro contrat a Juan. En ambos casos, el conjunto de palabras es la
misma junto con la frecuencia de cada palabra. Este supuesto es necesario para
que las probabilidades sean intercambiables y que permitan una mayor aplicacin de mtodos matemticos. A pesar de que de vez en cuando trata frases
semnticamente diferentes como la misma cosa, funciona bien en un documento
general.
La idea bsica del modelo LDA es que los documentos en el cuerpo se representan como una mezcla al azar sobre los temas latentes y cada tema se
39
Algoritmo 2.1 Algoritmo de generacin de un proceso LDA.

for cada tema
muestra la mezcla de las palabras kDir ()
end
for cada uno de los documentosm = 1 : M
muestra la mezcla de las palabras mDir ()
muestra la longitud de los documentos NmP oiss ()
for cada palabra n = 1 : Nm en el documento m
muestra el ndice del tema Zm,nM ult (m )

muestra el peso de la palabra Wm,nM ult Zm,n
end
end
caracteriza por una distribucin de las palabras en los documentos. A continuacin se pueden observar las notaciones empleadas y el procedimiento generador
del modelo LDA en el algoritmo 2.1.
M : nmero de documentos.
K: nmero de temas.
V : el tamao del vocabulario.
, : parmetros de la distribucin de Dirichlet.
m : el tema asignado al documento m.
= m , m = 1, . . . , M : las estimaciones del corpus del tema, una matriz
M K.
k : la distribucin de palabras del tema K.
= k, k = 1, . . . , K:: las asignaciones de la palabra de los temas, una
matriz K V .
Dir y P oiss son funciones de distribucin Dirichlet y Poisson respectivamente.
El modelo generativo puede ser expresado de la siguiente manera:
Escoger una distribucin de la mezcla () de Pk con una probabilidad de
Pk ().
40
Figura 2.4.2: Representacin grfica del modelo LDA. Las cajas son "placas" que
representan rplicas. La placa exterior representa documentos, mientras que la
placa interior representa la eleccin repetida de temas y palabras dentro de un
documento.
Para cada palabra.
Eligir un tema z con una probabilidad (z).
Elegir una palabra Wi del tema z con una probabilidad Tz (Wi ).
La probabilidad de observar una secuencia de palabras, w = w1 , w2 , . . . , wn , en
este modelo es:
PLDA (w) =
(Y
n X
k
Pk
)
(z) Tz (w1 ) Pk () d
i=1z=1
donde
Pk () =
k
X
z=1
!
z
k
1
Y
(z) z
(z )
z=1
Esta es la distribucin de Dirichlet con parmetros 1 , 2, . . . , k . En este

modelo, el objetivo final es estimar los parmetros de la distribucin de Dirichlet y los parmetros para cada uno de los k modelos de los temas. A pesar
de que la integral de esta expresin es intratable para una inferencia exacta,
Tz (Wi ) en realidad se calcula mediante el uso de una amplia gama de algoritmos de inferencia de aproximacin, como el algoritmo de inferencia variacional.
La representacin grfica del modelo LDA se ilustra en la figura 2.4.2.
41
En LDA, un documentodm = {wm,n , n = 1, . . . , Nm } es generado por escoger

una distribucin en los temas de una distribucin de Dirichlet (Dir ()).
Y teniendo en cuenta la distribucin del tema, tomamos la asignacin del
tpico para cada palabra especfica. A continuacin, la asignacin del tpico
para cada marcador de posicin de la palabra [m, n] se calcula por muestreo de
un tpico en particular de la distribucin multinomial de Zm,n . Y, por ltimo,
una palabra especial de wm,n se genera para el marcador de posicin [m, n] por

muestreo del peso de la distribucin multinomial de M ult Zm,n .
Como en la descripcin anterior, teniendo en cuenta los parmetros y de
Dirichlet, podemos formular una distribucin conjunta de un documento dm ,
una mezcla de temas de dm , es decir, m , y un conjunto de tpicos Nm , es decir,
Zm es de la siguiente manera:
Pr (m , zm , dm , |, ) = Pr (m |) Pr (|)
N
m
Y

Pr wm,n |zm,n Pr (zm,n |m )
n=1
A continuacin, mediante la integracin de m , zm,n , y sumando zm , se obtiene

la probabilidad de el documento dm :

Pr (dm |, ) =
Pr (m |) Pr (|)
N
m
Y

Pr wm,n |zm,n Pr (zm,n |m ) dm d
n=1
Por ltimo, la probabilidad del documento del corpus D = {dm , m = 1, . . . , M }

es un producto de la probabilidad de todos los documentos del corpus.
Pr (D|, ) =
N
m
Y
Pr (dm |, )
n=1
2.4.6.1.
Estimacin de parmetros Dirichlet e inferencia del tpico
En general, la estimacin de los parmetros del LDA se lleva a cabo mediante

la maximizacin de la probabilidad de todos los documentos. En particular, dado
un corpus de documentos D = {dm mm = 1, . . . , M }, hacemos una estimacin
de los parmetros y que maximizan la probabilidad de registro de los datos:
(est , est ) = max ` (, ) = max
M
X
log Pr (dm |, )
m=1
Sin embargo, el clculo directo de los parmetros y es intratable debido a

la naturaleza de la computacin. La solucin a esto es el uso de diversos mtodos
alternativos de estimacin aproximada. Aqu se emplea el algoritmo variacional
Expextation Maximization (EM) para estimar los parmetros de variaciones que
42
maximizan la probabilidad total del corpus con respecto a los parmetros del
modelo de y . El algoritmo variacional EM se describe brevemente como
sigue:
1. Paso E: Para cada documento, encontrar los valores de los parmetros de
optimizacin variacional m y m.
2. Paso M: Maximizar la banda baja del resultado de la probabilidad con
respecto a los parmetros del modelo y . Esto corresponde a la bsqueda de la estimacin de mxima verosimilitud con la posterior aproximada
que se calcula en el paso E.
3. El paso E y el paso M se ejecutan iterativamente hasta alcanzar un valor
de mxima verosimilitud. Mientras tanto, los parmetros de estimacin
calculada pueden utilizarse para inferir la distribucin del tpico de un
nuevo documento mediante la realizacin de la inferencia variacional.
2.4.7.
Sntesis de las semejanzas y diferencias entre PLSA

y LDA, ventajas e inconvenientes comparativos
El Modelado del Lenguaje (LM), como un enfoque estadstico para la IR,

emplea la probabilidad condicional de una consulta q dado un documento d ,
P (q|d), como una forma de clasificacin por relevancia. Un enfoque particular
del LM basado en IR es el PLSI. PLSI ha demostrado ser un modelo de lenguaje
de baja perplejidad y supera la indexacin semntica en trminos de precisin
y recall en un nmero de colecciones de documentos pequeo. Sin embargo, las
semnticas generativas del PLSI no son completamente consistentes con lo que
hay problemas en la asignacin de probabilidad para documentos previamente
no observados. LDA es tambin un modelado de lenguaje probabilstico que
posee semntica generativa consistente y supera algunas de las carencias que
tiene el PLSI.
El propsito de usar los mtodos de modelado como el PLSA y el LDA
en el contexto de la clasificacin automatizada es para reducir el ruido y para
comparar las similitudes de los documentos.
El modelo PLSI capta la posibilidad de que un documento puede contener
varios tpicos ya que p (z|d) es el peso de la mezcla de los tpicos de un documento d en particular. Sin embargo, es importante tener en cuenta que d es un
ndice mudo en la lista de documentos en el conjunto de entrenamiento. Por lo
tanto, d es una variable aleatoria multinomial con tantos valores posibles como
documentos de formacin y el modelo aprende de las mezclas de temas p (z|d)
slo para aquellos documentos en los que se entrena. Por esta razn, PLSI no es
un modelo generativo bien definido de los documentos, no hay manera natural
43
de que se utilicen para asignar probabilidades a un documento indito. Otra

dificultad con PLSI, que tambin se deriva del uso de una distribucin de documentos indexados por la formacin, es que el nmero de parmetros que deben
ser estimados crece linealmente con el nmero de documentos de entrenamiento.
Los parmetros para un modelo k-tpicos de PLSI son k distribuciones multinomiales de tamao V y M mezclas sobre los k temas ocultos. Esto le da
kV + kM parmetros y por lo tanto, el crecimiento lineal en M . El crecimiento
lineal en los parmetros indica que el modelo es propenso a sobreajuste (overfitting) y, empricamente, overfitting es de hecho un problema grave.
2.5.
Modelos de evolucin de tpicos
Se han propuesto varias tcnicas para extraer la evolucin de un tpico en

un cuerpo con sello de tiempos, cmo el uso de un tpico (y algunas veces el
propio tpico) cambia con el tiempo y como los trminos en los documentos
se cambian con el tiempo. Este modelo suele ser una extensin a un modelo
de tpicos bsico que representa el tiempo de alguna manera. Se llama a este
modelo Topic Evolution Model.
Inicialmente, el modelo Dynamic Topic Model (Blei & Lafferty, 2006) fue
introducido. Este modelo representa el tiempo como un proceso discreto de Markov, donde los tpicos en si mismos evolucionan de acuerdo a una distribucin
de Gauss. As pues, este modelo penaliza a los cambios bruscos entre perodos
de tiempo sucesivos, desalentando fluctuacin rpida en los tpicos a travs del
tiempo.
El modelo Topics Over Time (TOT) (Wang & McCallum, 2006) representa
el tiempo como una distribucin beta contnua, donde efectivamente remueve la
penalizacion de cambios abruptos que sufre el modelo anterior Dynamic Topic
Model. Sin embargo, la distribucin beta sigue siendo bastante inflexible dado
que asume que un tpico tendr una sola cada y un solo ascenso a lo largo de
todo el cuerpo del documento.
El modelo Hall (Hall et al., 2008) aplica LDA a toda la coleccin de documentos al mismo tiempo y realiza calculos post hoc basados en la probabilidad
observada en cada documento para trazar un mapa de los tpicos en las versiones. (Linstead et al., 2008a) y (Thomas et al., 2010) tambin usaron este
modelo sobre las versiones de diferentes sistemas de software. La principal ventaja de este modelo es que no hay limitaciones sobre la evolucin de los tpicos,
proporcionando la flexibilidad necesaria para describir grandes cambios en un
cuerpo.
El modelo Link, propuesto por (Mei & Zhai, 2005) y empleado por primera
vez por (Hindle et al., 2009a), aplica LDA a cada versin del repositorio sepa-
44
radamente, seguido de un post-procesamiento para vincular (link) los tpicos

a travs de las versiones. Una vez que los tpicos se encuentran vinculados, la
evolucin del mismo puede ser computada de la misma manera que el modelo de
Hall. La fase de post-procesamiento debe vincular los tpicos encontrados en la
versin con los tpicos encontrados en la versin anterior. Este proceso inherentemente implica el uso de umbrales de similitud para determinar si dos tpicos
pueden ser interpretado como iguales, ya que LDA es un proceso probabilstico
y no est garantizado para encontrar los mismos tpicos exactos en diferentes
versiones de un cuerpo. Como resultado de esto en cada sucesiva versin, algunos tpicos que son exitosamente vinculados mientras que otros no, causando
de esta manera que algunos tpicos mueran y otros nazcan. Estos huecos
que se pueden producir en la vida de algunos tpcos agregan mas dificultad.
2.6.
Trabajos relacionados
En esta seccin se describen los trabajos relacionados y evaluados empleados

en los modelos de IR para realizar minera en repositorios de software y mejorar
algunas tareas de la SE. (Thomas, 2011) organiz los trabajos de acuerdo a
las tareas de la SE dando una breve explicacin de cada tarea seguida de los
trabajos mas relevantes de forma cronolgica.
2.6.1.
Localizacin de conceptos o caractersticas
La tarea de localizacin de conceptos (o localizacin de caractersticas) es

identificar las partes (por ejemplo, documentos o mtodos) del cdigo fuente que
implementa una caracterstica dada del sistema de software (Rajlich & Wilde,
2002). Esto es til para los desarrolladores que deseen depurar o mejorar una
determinada caracterstica. Por ejemplo, si la llamada a la funcin de impresin
de archivo contena un error, entonces la tcnica de localizacin de conceptos
intentara encontrar automticamente las partes del cdigo fuente que implementar la impresin de archivos.
Relacionado al concepto de localizacin es la Programacin Orientada a Aspectos (Aspect-Oriented Programming (AOP)) cuya finalidad es proporcionar
a los desarrolladores los mecanismos para fcilmente implementar aspectos que
son transversales en varios documentos. Es decir extraer cierto concepto que es
transversal a varios documentos y separarlo.
2.6.1.1.
Tcnicas basadas en LSI
LSI fue aplicada por primera vez para la localizacin de tareas por (Marcus et al., 2004), quien desarrollo una tcnica para tomar una consulta de un
45
desarrollador y retornar una lista de documentos de cdigo fuente. Los autores

mostraron que LSI provee mejores resultados que lo mtodos ya existentes y
que es fcilmente aplicable al cdigo fuente, debido a la flexibilidad de LSI. Los
autores tambin observaron que desde que LSI fue aplicado a los comentarios e
indentificadores del cdigo fuente es independiente del lenguaje y por lo tanto
accesible para cualquier sistema.
En (Marcus et al., 2005) demostraron que la localizacin de conceptos es
necesaria en el caso de los lenguajes orientados a objetos, contrario a lo que
se crea previamente. Los autores compararon LSI contra otras dos tcnicas,
llamadas expresiones regulares y grafos de dependencia, para la locaclizacin
de conceptos en cdigo fuente orientado a objetos. Los autores concluyeron que
todas las tcnicas son beneficiosas y necesarias y cada proceso tiene sus propias
debilidades y fortalezas.
En (Poshyvanyk et al., 2006) combinaron LSI con Scenario Based Probabilistic obteniendo una lista de eventos de ejecucin para la locaclizacin de
caractersticas en el cdigo fuente. Los autores demostraron que el uso de las
dos tcnicas, cuando se aplican juntas, superan a cualquiera de las tcnicas individualmente. Ms tarde, en (Poshyvanyk & Marcus, 2007) combinaron LSI con
Formal Concept Analysis (FCA) para localizar conceptos en el cdigo fuente.
LSI fue usado primero para vincular las consultas de los desarrolladores con los
documentos de cdigo fuente, luego FCA fue usado para organizar los resultados
en un concepto de celosa. Los autores encontraron que esta tcnica funciona
bien, y que los conceptos de celosa han resultado cuatro veces mas efectivo que
agrupando la informacin con los simples mtodos de ranking.
En (Cleary et al., 2009) compararon varias tcnicas de IR (por ejemplo,
VSM, LSI) y tcnicas de NLP para la localizacin de conceptos. Despus de un
extenso experimento, los autores encontraron que las tcnicas de NLP no ofrecen
una gran mejora sobre las tcnicas de IR lo cual es contrario a los resultados en
otras reas.
En (van der Spek et al., 2008) usaron LSI para buscar conceptos en el cdigo fuente. Lo autores consideraron de varios pasos de pre-procesamiento, como
stemming, remocin de stop-words, e importancia de trminos. Los autores evaluaron manualmente los conceptos que resultaron con la ayuda de expertos del
dominio.
En (Grant et al., 2008) usaron ICA. el cual es un modelo conceptualmente
similar a LSI, para localizar conceptos en el cdigo fuente. Los autores argumentaron que desde que ICA esta disponible para identificar seales estadsticamente independientes en el texto, puede ser mejor para buscar conceptos en
el cdigo fuente. Los autores mostraron que la viabilidad de ICA para extraer
conceptos a travs de casos de estudio en sistemas pequeos.
46
En (Revelle & Poshyvanyk, 2009) usaron LSI, junto con el anlisis esttico
y dinmico, para abordar la tarea de localizacin de caractersticas. Lo autores
combinaron las diferentes tcnicas pero de otro modo. Por ejemplo, para la similitud de textos fue usada para atravesar grficos de dependencia de programas
estticos, y anlisis dinmico para remover mtodos que no fueron ejecutados
en el escenario. Lo autores encontraron que ninguna tcnica supero a todas las
dems en todos los casos de estudio. Mientras que en (Revelle et al., 2010) realizaron una fusin entre LSI, anlisis dinmico y algoritmos de minera de paginas
web (por ejemplo, HITS y PageRank) para abordar la localizacin de caractersticas. Los autores encontraron que la combinacin de estas tres tcnicas supera
a cada una de ellas individualmente.
2.6.1.2.
Tcnicas basadas en LDA
En (Linstead et al., 2007b) hizo el primer uso de LDA para localizar conceptos en el cdigo fuente en la forma de tpicos. Su tcnica puede ser aplicada
a sistemas individualmente o grandes colecciones de sistemas para extraer los
conceptos que se encuentran dentro de los identificadores y comentarios en el
cdigo fuente. Los autores demostraron cmo agrupar documentos de cdigo
fuente en grupos basados basados en la comparacin de los tpicos.
En (Linstead et al., 2007a) aplicaron una variante de LDA, la variante
Author-Topic (Rosen-Zvi et al., 2004), al cdigo fuente para extraer relaciones
entre los desarrolladores (autores) y los tpicos del cdigo fuente. La tcnica
permite la sumarizacin automtica de de quien trabajo en que, y los autores proveyeron pequeos argumentos cualitativos como la efectividad en sus
tcnicas.
En (Maskeri et al., 2008) aplicaron LDA al cdigo fuente para extraer los
conceptos del negocio embebidos en comentarios y los nombres de los identificadores.Los autores aplicaron un sistema de ponderacin para cada palabra clave
en el sistema, basndose en donde la palabra clave fue encontrada (por ejemplo,
nombre de la clase, parmetros, mtodos). Los autores encontraron que su tcnica basada en LDA permite extraer satisfactoriamente los tpicos del negocio,
tpicos implementados, y tpicos transversales desde el cdigo fuente.
En (Baldi et al., 2008) propusieron una teora en donde una preocupacin de
software es equivalente a los tpicos latentes encontrados mediante modelos de
tpicos estadsticos. Adems, ellos propusieron que estos aspectos son tpicos
latentes que tienen un alto valor en su mtrica de scattering. Los autores aplicaron su tcnica a un gran conjuntos de sistemas Open Source para identificar
un conjunto de tpicos globales, as como realizar un anlisis ms detallado es
algunos sistemas en especial. Los autores encontraron que los tpicos latentes
47
con alto valor en la mtrica scattering son precisamente los que se clasifican
generalmente como aspectos en la comunidad de AOP.
En (Savage et al., 2010) introdujeron una herramienta de visualizacin, llamada TopicXP, la cual soporta la exploracin interactiva para observar los tpicos localizados en el cdigo fuente.
2.6.2.
Recuperacin de la trazabilidad y localizacin de

bugs
Una pregunta que a menudo se hace en el desarrollo es: Que documento (cdigo fuente) implementa el requerimiento X. La recuperacin de la trazabilidad
tiene como objetivo de descubrir vnculos entres pares de artefactos de software
como documentos de cdigo fuente y los documento de los requerimientos. Esto
permite a los stakeholders trazar los requerimientos a su implementacin, por
ejemplo para asegurarse chequear si un requerimiento fue implementado correctamente o no. La recuperacin de la trazabilidad entre un par de documentos de
cdigo fuente es tambin importante para los desarrolladores que desean saber
que otros documentos de cdigo fuente estn relacionados con el documento
en el que ellos se encuentran trabajando. La localizacin de bugs es un caso
especial de la recuperacin de la trazabilidad en el cual se buscan vnculos de
trazabilidad entre los reportes de bugs y cdigo fuente.
2.6.2.1.
En (Marcus & Maletic, 2003) fue la primera vez que se us LSI para la recuperacin de la trazabilidad de vnculos entre cdigo fuente y documentacin
(por ejemplo, los documentos de los requerimientos). Lo autores aplicaron LSI
a los identificadores y comentarios en el cdigo fuente y los documentos, luego
calcularon los valores de similitud entre cada par de documentos. Entonces, un
usuario podra especificar una medida de similitud para determinar los vnculos
actuales. Lo autores compararon su trabajo con la tcnica de recuperacin basada en VSM y se encontraron con que la performance fue al menos tan buena
como VSM en todos los casos de estudio.
En (De Lucia et al., 2004) integraron una herramienta, basada en LSI, en un
artefacto de software de un sistema de administracin llamado ADAMS. Los autores presentaron varios casos de estudio usando su tcnica basada en LSI para
recuperar los vnculos entre el cdigo fuente, casos de test y los documentos de
los requerimientos. En subsecuentes trabajos (De Lucia et al., 2006) propusieron
una tcnica para recuperacin de la trazabilidad de vnculos. En esta tcnica, un
usuario de forma semi-automtica interacta con el sistema para buscar un medida de similitud ptima entre documentos (por ejemplo, una medida apropiada
48
para discriminar entre documentos relacionados y no relacionados). Lo autores

sostuvieron que un umbral mejor resulta en un menor nmero de enlaces para
el desarrollador a tener en cuenta, y por lo tanto menos posibilidades de error,
por lo que la interaccin humana en una necesidad.
En (Hayes et al., 2006) evaluaron varias tcnicas de IR para la generacin
de trazabilidad de vinculos entre varios requerimientos (de alto y bajo nivel),
concentrando en los modelos tf-idf y LSI. Lo autores implementaron una herramienta llamada RETRO para ayudar a un analista de requerimientos en su
tarea. Los autores concluyeron que, aunque no es perfecta, tcnicas IR proporcionan ayuda al analista.
En (Lormans & Van Deursen, 2006) evaluaron diferentes estrategias para recuperar la trazabilidad usando LSI realizando tres casos de estudio. Los autores
concluyeron que LSI es una tcnica muy prometedora para recuperar vnculos
entre cdigo fuente y los documentos de los requerimientos y con diferentes estrategias se obtienen diferentes resultados. Sin embargo, los autores observaron
que la estrategia de vinculacin es ptima bajo ciertos escenarios. En trabajos subsecuentes, (Lormans, 2007) introdujeron un framework para la gestin
de lo requerimientos (y sus vnculos de trazabilidad) en el ciclo de desarrollo de
software. La tcnica que usaron LSI sugiere vnculos entre artefactos candidatos.
En (Lormans et al., 2006) usaron LSI para construir vistas de requerimientos, que son diferentes puntos de vistas de los requerimientos. Por ejemplo, un
requerimiento podra mostrar solo requerimientos que hayan sido implementados. Los autores implementaron en su herramienta, llamada ReqAnalyst, y la
emplearon en varios casos de estudio del mundo real.
En (Lucia et al., 2007) fueron los primeros en realizar un estudio de casos
humanos, el cual evaluaba la efectividad del uso de LSI para la recuperacin
de la trazabilidad de vnculos durante el proceso de desarrollo de software. Los
autores concluyeron que LSI es ciertamente un paso til para lo desarrolladores,
pero su principal inconveniente inevitable es el trade off entre la precisin y la
recuperacin.
En (Jiang et al., 2008) propuso una tcnica incremental para mantener los
vnculos de trazabilidad como un sistema de software evoluciona en el tiempo.
El autor de la tcnica, llamaron LSI incremental, usando vnculos (y la matriz
LSI) desde las versiones previas cuando se calculan los links hasta la version
actual, tambin almacenando el esfuerzo de calculo.
En (De Boer & van Vliet, 2008) desarrollaron una herramienta para dar soporte a las auditoras en la localizacin de documentos que son de inters. La
herramienta, basada en LSI, sugiere al auditor documentos que son relacionados
a la consulta, como tambin documentos semnticamente relacionados al documento consultado. Este proceso le brinda al auditor, quien no esta familiarizado
49
con la documentacin, una gua para realizar una fcil y entendible exploracin
de los documentos del sistema.
En (Antoniol et al., 2008) introdujeron una herramienta llamada Reuse or
Rewrite (ReORe) para ayudar a los stakeholders decidir si ellos deberan actualizar cdigo existente (por ejemplo, la introduccin de funcionalidades nuevas)
o reescribir completamente desde el inicio. ReORe logra esto por el uso de la
combinacin del anlisis esttico (LSI), manual y dinmico para crear los vnculos de trazabilidad entre los requerimientos y el cdigo fuente. Los stakeholders
pueden entonces revisar los vnculos de trazabilidad recuperados para decidir
que tan bien el sistema implementa los requerimientos.
(McMillan et al., 2009) usa dos tipos de informacin, una textual (va LSI) y
una estructural (via Evolving Interoperation Graphs) para recuperar la trazabilidad de vnculos entre el cdigo fuente y los documentos de los requerimientos.
Los autores realizaron un caso de estudio sobre un pequeo pero bien entendido sistema llamado CoffeeMaker. Los autores demostraron que la combinacin
de informacin textual y estructural mejora modestamente los resultados de la
trazabilidad en la mayora de los casos.
2.6.2.2.
Comparacin de estudios
Mientras que la mayora de las investigaciones solo evaluaron su tcnica con

respecto a un solo modelo de tpicos, otra poca cantidad de investigaciones
directamente compraron el desempeo de mltiples modelos de tpicos.
En (Lukins et al., 2008, 2010) usaron LDA para la localizacin de bugs. Los
autores primero construyeron un modelo LDA sobre el cdigo fuente a nivel
de mtodos usando los pasos de procedimientos estndar. Luego de obtener el
reporte de bugs, los autores calculan la similitud del contenido del texto de los
reportes de bugs contra todos los documentos de cdigo fuente. Luego retornan
un ranking de los documentos de cdigo fuente. Por la performance sobre casos
de estudios sobre Eclipse y Mozilla (sobre un total de 3 y 5 reportes de bugs,
respectivamente), encontraron que LDA a menudo supera a LSI.
En (Nguyen et al., 2011a) introdujeron un nuevo modelo de tpicos basado en LDA, llamado BugScout, en un esfuerzo para mejorar la performance
en la localizacin de bugs. BugScout considera explcitamente los reportes de
bugs antiguos, adems de los identificadores y comentarios, cuando representan
documentos de cdigo fuente, usando dos fuentes concurrentemente para identificar los conceptos tcnicos. Los autores aplicaron BugScout a cuatro sistemas
diferentes y encontraron que BugScout mejora la performance incrementando
un 20 % sobre LDA aplicado al cdigo fuente.
En (Rao & Kak, 2011) compararon varios modelos de IR para la localizacin
50
de bugs, incluyendo VSM, LSI y LDA as como varias combinaciones. Los autores realizaron un caso de estudio con un conjunto de datos pequeo, llamado
iBUGS (Dallmeier & Zimmermann, 2007), y concluyeron que los modelos de IR
ms simples a menudo superan a los modelos ms sofisticados.
En (Capobianco et al., 2009) compararon la habilidad de cuatro tcnicas
(VSM, LSI, Jenson-Shannon, y B-Spline) para recuperar la trazabilidad de
vnculos entre el cdigo fuente, casos de prueba, y diagramas UML. Los autores
encontraron que B-Spline mejora a VSM y LSI y es comparable con respecto al
mtodo Jenson-Shannon.
En (Oliveto et al., 2010) compararon la efectividad de cuatro tcnicas (JensonShannon, VSM, LSI, y LDA) de IR para la recuperacin de la trazabilidad. Los
autores mostraron que LDA provee una dimensionalidad nica comparada con
respecto a las otras cuatro tcnicas.
En (Asuncion et al., 2010) introdujeron una herramienta llamada TRASE
que usa LDA para prospectivamente, a diferencia de forma retrospectiva, recuperar enlaces de trazabilidad entre los diversos artefactos en los repositorios
de software. Esto significa que los desarrolladores pueden crear y mantener los
vnculos de trazabilidad como ellos los hicieron en el sistema. Tambin mostraron que LDA supera a LSI en trminos de precisin y exhaustividad.
2.6.3.
Mtricas sobre cdigo fuente
La prediccin de bugs trata de predecir que partes (por ejemplo documentos

o mtodos) del cdigo fuente que podran tener bugs. Esta tarea es a menudo
realizada por una coleccin de mtricas sobre el cdigo fuente, formando un
modelo estadstico para las mtricas que tenga bugs ya conocidos, y usando este
modelo entrenado predecir si lo nuevos documentos contienen bugs.
A menudo, el estado del arte en la prediccin de bugs avanza hacia la prediccin de nuevas mtricas o usando modelos estadsticos an no explorados.
(por ejemplo en (Kamei et al., 2010; Nguyen et al., 2010; Shihab et al., 2010b)).
Hasta ahora se han introducido un gran conjunto de mtricas. Adicionalmente
tambin se han introducido cientos de modelos estadsticos con diferentes grados
de xito.
La mayora de las mtricas son medidas directamente sobre el cdigo (por
ejemplo, el nmero de mtodos por clase) o tambin los procesos de cambios que
se han aplicado (mtodos que han sido frecuentemente cambiados por clase). Sin
embargo, los investigadores usaron modelos de tpicos para introducir mtricas
semnticas o conceptuales, que estn basadas ms en los comentarios y palabras
claves en el cdigo fuente.

2.6.3.1.
51
En (Marcus et al., 2008) introdujeron una nueva mtrica de cohesin de clase,

llamada Conceptual Cohesion of Classes (C3), para medir la cohesin de una
entidad de un programa. La mtrica basada en la informacin semntica en la
clase, como son identificadores y comentarios, esta basada en el modelo LSI. Las
entidades altamente cohesivas se cree que siguen mejor los principios de diseo
y muestran que se correlacionan negativamente con los fallos de los programas.
En (Bavota et al., 2010) usaron la mtrica C3 en el desarrollo de una tcnica
para dar soporte a la refactorizacin automtica de las denominadas clases blob
(por ejemplo, clases que contienen demasiada funcionalidad y tambin tienen
un bajo coeficiente de cohesin). En (Kagdi et al., 2010) usaron una mtrica
similar, la similitud conceptual entre pares de mtodos de clases, como parte de
una novedosa tcnica de anlisis de impacto.
En (Gall et al., 2008) evaluaron extensivamente una suite de mtricas semnticas que fueron calculadas sobre documentos de diseo y requerimientos
y sobre el cdigo fuente a lo largo del proceso de desarrollo. Algunas mtricas
estn basadas en el modelo LSI. A travs de tres casos de estudio, los autores
encontraron correlacin significativa entre las mtricas medidas sobre los documentos de diseo y requerimientos y las mismas mtricas sobre el cdigo fuente,
aportando una fuerte evidencia sobre la similitud semntica entre estos documentos. Los autores argumentan que este tipo mtricas pueden colaborar en la
deteccin de decisiones de diseo problemticas en la fase temprana del proceso
de desarrollo.
En (jhzi et al., 2010) definieron dos nuevas mtricas conceptuales para
medir el grado de acoplamiento y cohesin de los mtodos en un sistema de
software. Ambas mtricas estn basadas en LSI. Los autores compraron sus dos
nuevas mtricas con las mtricas de la suite (incluyendo (Marcus et al., 2008)) y
encontraron que las nuevas mtricas proveen mejoras significativas comparadas
con las mtricas previas.
2.6.3.2.
Tcnicas basadas en LDA
En (Linstead & Baldi, 2009) aplicaron LDA a reportes de bugs del sistema
GNOME con el objetivo de medir la coherencia del reporte de bugs, por ejemplo
cuan fcil es de leer y cuan focalizado es el reporte. Esta mtrica de coherencia
es definida como la mezcla de tpicos de LDA, por ejemplo, cuantos tpicos son
encontrados en el reporte (menor cantidad es mejor).
En (Liu et al., 2009) aplicaron LDA a mtodos de cdigo fuente con el fin de
calcular una novedosa clase de mtrica de cohesin llamada Maximum Weighted
Entropy (MWE). MWE es calculada basndose en la ocupacin y peso de un
52
tpico en un mtodo de una clase. Los autores demostraron que esta mtrica
captura la novedosa variacin en los modelos para predecir fallas de software.
En (Gethers & Poshyvanyk, 2010) introdujeron una nueva mtrica, llamada
Relational Topicbased Coupling (RTC), basado en un variante de LDA llamada
Relational Topic Models (RTM). RTM extiende LDA modelando vnculos explcitos entre los cuerpos de los documentos. RTC usa estos vnculos para definir
el acople entre el cuerpo de dos documentos. Los autores demostraron que la
mtrica propuesta proporciona valor porque es estadsticamente diferente de las
mtricas existentes.
2.6.4.
Depuracin de estadstica y anlisis de causa principal
En (Andrzejewski et al., 2007) realizaron una depuracin estadstica usando Delta LDA, una variante de LDA. La depuracin estadstica es una tarea
para identificar una pieza problemtica de cdigo, obteniendo un registro de la
ejecucin de ese cdigo. Delta LDA es capaz de modelar dos tipos de tpicos:
tpicos de uso y tpicos de bugs. Los tpicos de bugs son aquellos que solo se
encuentran en los registros de ejecuciones fallidas. Por lo tanto lo autores fueron
capaces de identificar piezas de cdigo que probablemente posean bugs.
En (Jagadeesh Chandra Bose & Suresh, 2008) usaron LSI como una herramienta para el anlisis de la causa raz (RCA), por ejemplo, para identificar la
causa raz de la falla de un software. Los autores construyeron y ejecutaron un
conjunto de escenarios para probar la ejecucin de varios mtodos del sistema
en varias secuencias. Luego, los autores usaron LSI para construir una matriz
(method-to-test co-occurrence) que clasifica test de prueba que ejecutan funcionalidades similares, ayudando a caracterizar las diferentes manifestaciones de
una falla.
En (Zawawy et al., 2010) presentaron un framework para reducir el tamao
y complejidad de los registros de ejecucin de modo que el trabajo manual
realizado por un analista es reducido durante RCA. La reduccin es acompaada
por lderes de LSI para detectar falsos positivos y mayor recuperacin durante
el proceso de filtrado.
2.6.5.
Evolucin de software y anlisis de tendencias
Analizar y caracterizar -como un sistema de software cambia en el tiempo

o la evolucin de un sistema de software(Lehman, 1980), ha sido de inters
para los investigadores por muchos aos. Ambos, como un sistema de software
cambia (por ejemplo, crece rpidamente cada 12 meses) y porque un sistema de
software cambia (por ejemplo, la correccin de un bug) puede ayudar a conocer
53
el rendimiento en los procesos utilizados por un sistema de software especfico,

as como el desarrollo de software en su conjunto.
En (Linstead et al., 2008a) aplicaron LDA a varias versiones de cdigo fuente
de un sistema en un esfuerzo por identificar las tendencias de los tpicos a travs
del tiempo. Las tendencias en el historial del cdigo fuente puede ser medido en
una probabilidad de como se ve el tpico en una determinada versin. Cuando
documentos que pertenecen a un tpico particular es primero agregado al sistema, por ejemplo los tpicos experimentarn un crecimiento en su probabilidad
global.
En un esfuerzo similar, (Thomas et al., 2010) evalu la efectividad de los
modelos de evolucin de tpicos para la deteccin de tendencias en el proceso
de desarrollo. Los autores aplicaron LDA a una serie de versiones de el cdigo
fuente y calcularon la popularidad de un tpico a travs del tiempo. Los autores
tambin realizaron una verificacin manual del crecimiento o cada de la popularidad de un tpico y coincidieron aportando evidencia de que ese modelo de
evolucin de tpicos provee un buen resumen de la historia de ese software.
En (Hindle et al., 2009a, 2010) aplicaron LDA al registro de los mensajes de
los commits con el fin de observar en qu tpicos estn trabajando los desarrolladores. Los autores aplicaron LDA a el registro de commints durante el periodo
de 30 das, y luego vincularon los sucesivos periodos juntos usando una medida de similaridad de tpicos (por ejemplo, dos tpicos son vinculados si ellos
comparten entre 8 a 10 de sus trminos con ms alta probabilidad). Los autores
encontraron a LDA muy til para identificar las tendencias de las actividades
de los desarrolladores.
En (Neuhaus & Zimmermann, 2010) usaron LDA para analizar Common
Vulnerabilities and Exposures (CVE) de una base de datos, con el fin de lograr
reportes de vulnerabilidades desde diferentes fuentes. La meta de los autores
fue buscar tendencias de cada vulnerabilidad con el fin de observar cuales se
incrementaron y cuales decrecieron. Los autores encontraron que sus resultados
son en su mayora comparables a un estudio el manual anterior sobre el mismo
conjunto de datos.
2.6.6.
Agrupamiento de documentos
El agrupamiento de documentos es una tarea que consiste en agrupar los

documentos de acuerdo a su contenido, en general para mejorar la comprensin de los programas para reducir el esfuerzo de bsqueda de un desarrollador
(Kuhn et al., 2005, 2007). Los documentos pueden ser clasificados usando varios
atributos posibles, incluyendo la similitud semntica o dependencia de grafos.
En (Maletic & Marcus, 2001; Maletic & Valluri, 1999) primero aplicaron
54
LSI para la clasificacin de documentos. Los autores afirmaron como el agrupamiento puede mejorar la comprensin durante el mantenimiento y las fases
evolutivas del ciclo desarrollo de software. Los autores encontraron que LSI produce agrupamientos tiles, desde que LSI est automatizado, puede aportar un
valor significativo para los desarrolladores.
En un esfuerzo similar (Kuhn et al., 2005, 2007) introdujeron una herramienta llamada HAPAX para el agrupamiento de documentos de cdigo fuente.
Los autores extendieron este trabajo por (Maletic & Marcus, 2001) agregando la
visualizacin de los agrupamientos resultantes y proveyendo cada agrupamiento
con un nombre basado en todas las palabras en la clase, no justamente el nombre
de las clases.
En (Lin et al., 2006) introdujeron una herramienta llamada Prophecy que
permite a los desarrolladores buscar grupos de la API de Java relacionados con
la funcionalidades. Los autores aplicaron LSI a los documentos de Javadocs de
la API de Java para buscar similitudes en sus funcionalidades. Un desarrollador
puede entonces buscar en el ndice resultante de LSI para obtener un conjunto
de clases relacionadas.
En (Kuhn et al., 2008, 2010) crearon un mapa de dos dimensiones de un
sistema de software, donde las posiciones de las entidades y distancias entre
ellas estn basadas en sus vocabularios. LSI es usado para reducir las dimensiones de la matriz Documentos-Trminos por lo que los documentos pueden
estar estrechamente alineados en el mapa. Esta cartografa puede ayudar a los
desarrolladores a entender la disposicin y las relaciones del cdigo fuente.
2.6.7.
Organizar y buscar en repositorios de software
En (Kawaguchi et al., 2006) presentaron una herramienta llamada MUDABlue para organizar automticamente gran cantidad de colecciones de sistemas
de software open-source (por ejemplo, SourceForge y Google Code) en grupos
relaciones, llamados categoras. MUDABlue aplica LSI para identificar nombre
encontrados en cada sistema de software. Lo autores demostraron que MUDABlue puede lograr en recuperacin y precisin una puntuacin por encima de
80, comparado con la creacin manual de las etiquetas de un sistema.
En (Tian et al., 2009) desarrollaron LACT, una tcnica para categorizar
sistemas basados en los tpicos subyacentes del mismo. Este trabajo tiene una
naturaleza similar a (Kawaguchi et al., 2006), excepto que en este el trabajo
emplea LDA en lugar de LSI. Los autores compararon su tcnica contra MUDABLue y concluyeron que las tcnicas son comparables en su eficacia.
En (Linstead et al., 2009, 2008b) introdujeron y usaron un crawler para
repositorios llamado Sourcerer para analizar un gran conjunto de datos de varios
55
sistemas de software. Los autores aplicaron LDA y el modelo Autor-Tpico para

extraer los conceptos en el cdigo fuente y desarrollaron tambin contribuciones
en el cdigo fuente. Los autores tambin definieron nuevas tcnicas para la
bsqueda de cdigo, basados en la extraccin a travs de un modelo de tpicos.
Sourcerer puede ser usado para analizar sistemas existentes (por ejemplo, tener
una vista de la mayora de los nombres de los identificadores populares de los
tpicos de LDA) como tambin buscar que mdulos contienen la funcionalidad
deseada.
En (Poshyvanyk & Grechanik, 2009) propusieron una tcnica llamada S3
para la bsqueda, seleccin y sntesis de sistemas existentes. La tcnica est
destinada a desarrolladores que deseen encontrar los fragmentos de cdigo desde
un repositorio en lnea adaptados a sus necesidades de desarrollo. Esta tcnica
crea un diccionario de llamadas a una API con palabras claves relacionadas,
basadas en la documentacin en lnea. Entonces, los desarrolladores pueden
buscar este diccionario para buscar fragmentos de cdigo relacionado. Usaron
LSI en conjunto con Apache Lucene para proveer las bsquedas.
2.6.8.
Otras tareas
En (Marcus & Maletic, 2001) fueron los primeros en detectar clones de alto
nivel (Bellon et al., 2007; Rahman et al., 2012; Roy et al., 2009) de mtodos de
cdigo fuente por la similitud semntica entre pares de mtodos. Los autores
usaron LSI para agrupar mtodos relacionados en el concepto de espacio (por
ejemplo, un espacio K-dimensional de un documento, basado en la pertenencia
a los tpicos), y un conjunto de agrupamientos representan clones. A pesar
de los bajos niveles de precisin, los autores argumentaron que esta tcnica
es econmica y por lo tanto se puede utilizar en conjuncin con tcnicas de
deteccin de clones ya existentes para mejorar los resultados generales.
En (Grant & Cordy, 2009) usaron ICA para detectar mtodos clones. Los
autores argumentaron que desde que ICA puede identificar muchas seales distintas que LSI, entonces el concepto de espacio usado para analizar la similitud
de dos mtodos ser mucho ms efectivo. Los autores mejoraron un pequeo
caso de estudio sobre un paquete del kernel de Linux, pero no compararon sus
resultados contra LSI.
En (Ahsan et al., 2009) tuvieron el objetivo de crear un sistema de desambiguacin de bugs, que determina que desarrolladores deberan seguir un reporte
de bugs. Los autores extrajeron el texto del contenido desde ttulos y resmenes
de los reportes de bugs de un sistema y aplicaron LSI para obtener la matriz
Trmino-Documentos ms reducida. Luego varios clasificadores vinculan cada
reporte de bug con un desarrollador, entrenado con reportes de bugs previos
56
y desarrolladores relacionados. En el mejor caso, esta tcnica logr un 45 % de

precisin en la clasificacin.
En (Bajracharya & Lopes, 2009, 2012) aplicaron LDA al uso de registros de
las bsquedas de cdigo fuente de un buscador popular (Koders) para analizar
las consultas de los usuarios en el tiempo. Su meta fue determinar cuales tpicos
son los mas populares en las bsquedas, y si el motor de bsqueda provee a los
usuarios las caractersticas que ellos necesitan para identificar el cdigo que ellos
necesitan. Encontraron que LDA puede ser una herramienta efectiva para esta
tarea.
En (Dit et al., 2008) midieron la cohesin del contenido de un reporte de bugs
por la aplicacin de LSI. Los datos utilizados fueron un conjunto de reportes de
bugs y luego calcularon una medida de similaridad en cada comentario dentro
de un reporte de bugs. Los autores compararon sus mtricas con los anlisis
realizados manualmente de los comentarios y encontraron una alta similitud.
En (Grant & Cordy, 2010) abordaron el desafo de elegir el nmero ptimo de
tpicos como entrada al modelo LDA cuando analizaron el cdigo. Los autores de
la tcnica variaron el nmero de tpicos y usaron una heurstica para determinar
cun buena es cada eleccin para identificar dos piezas de cdigo ubicadas en el
mismo documento. Los autores concluyeron recomendaciones generales y casos
de estudio.
En (Wu et al., 2008) abordaron el desafo de construir una herramienta para
descubrir servicios web basado en la semntica. Su tcnica construida sobre LSI
permite descubrir automticamente los servicios web basados en conceptos en
lugar de palabras claves.
2.7.
Conclusiones
En el presente captulo se ha introducido al campo KDD, referido al proceso

que intenta descubrir patrones en grandes volmenes de conjuntos de datos, los
objetivos y los inicios. Luego se focaliza en la definicin de la Minera de Datos y
en particular sobre repositorios de software en el cual se bas esta tesis. Tambin
se introdujeron los modelos de tpicos mas importantes como son LSI y LDA.
LDA es un modelo simple, y aunque lo vemos como un competidor de mtodos
tales como la LSI y PLSI en el marco de reduccin de dimensionalidad de las
colecciones de documentos y otros aspectos discretos, tambin tiene la intencin de ser ilustrativo de la forma en que los modelos probabilsticos pueden ser
ampliados para proporcionar una maquinaria til en los dominios de la participacin de mltiples niveles de la estructura. De hecho, las principales ventajas
de los modelos generativos como LDA son su modularidad y su extensibilidad.
Como un mdulo probabilstico, LDA puede ser fcilmente integrado en
57
un modelo ms complejo. Una propiedad que no es posible por LSI. En un

trabajo reciente se han utilizado pares de mdulos de LDA para modelar las
relaciones entre las imgenes y sus ttulos descriptivos correspondientes (Blei
et al., 2003). Por otra parte, existen numerosas posibilidades de extensin del
LDA. Por ejemplo, LDA puede extenderse fcilmente a datos continuos u otros
datos no multinomiales.
Otra simple extensin del LDA viene de permitir mezclas de distribuciones de
Dirichlet en el lugar de la Dirichlet nica de LDA. Esto permite una estructura
ms rica en el espacio de temas latentes y, en particular, permite una forma
de agrupacin de documentos que es diferente de la agrupacin que se logra a
travs de temas compartidos.
Por ltimo, en este captulo se introdujeron las investigaciones (Thomas,
2012) realizadas en donde solo se utilizan los modelos bsicos de la IR como son
LSI o VSM. Tambin hay que destacar que la mayora de los trabajos usan un
solo modelo a pesar que en otras reas indican que la combinacin de mltiples
modelos mejoran el desempeo global. La mayora de los trabajos no presentan
ninguna justificacin, o no dan mas detalles, de porque se realizan algunos pasos
y otros se omiten. Tambin no se encuentran muchos trabajos que reflejen la
sensibilidad de los modelos de IR con respecto a sus parmetros.
Captulo 3
Metodologa y mtricas
3.1.
Introduccin
El objetivo de este trabajo fue la creacin de una herramienta que permite

extraer tpicos aplicando la tcnica LDA. La herramienta cumple con varias
etapas. Primero, extraer la informacin del conjunto de datos ha analizar por
medio de la aplicacin de un parser para archivos XML. Luego de esta etapa
se procede a la generacin de los documentos. Esta generacin simplemente
prepara los documentos que van ha ser introducidos en el modelo de tpicos
tomando ciertas consideraciones sobre los bugs extraidos desde el conjunto de
datos. La siguiente etapa es la generacin de la lnea de tiempo por la cual se
analizarn los tpicos. Esta lnea de tiempo se divide en espacios de tiempo
llamadas versiones. Finalmente con estas versiones se puede lograr el objetivo
principal de la herramienta que es analizar las diferentes mtricas de los tpicos
deseados a travs del tiempo. De esta forma la herramienta puede informar al
usuario las partes o caractersticas del proyecto que son mas problemticas en
un determinado espacio de tiempo (versin en particular).
Estas ideas estan soportadas por los resultados obtenidos, analizando las
descripciones de los bugs y los comentarios vertidos en el conjunto de datos
como tambin su relacin con el crecimiento y diferentes versiones del sistema
operativo Android.
A continuacin en el transcurso de las siguientes secciones de ste captulo
se explican en detalle los pasos implementados. Posteriomente se culmina el
captulo con un anlisis de algunos tpicos seleccionados.
58
CAPTULO 3. METODOLOGA Y MTRICAS
3.2.
59
Conjuntos de datos
El conjunto de datos empleado (Shihab et al., 2012) proviene de un desafo

de MSR del ao 20121 . Este desafo tiene el fin de analizar los datos disponibles
en repositorios de software para descubrir informacin interesante y procesable
sobre sistemas y proyectos de software. Este desafo provee dos conjuntos de
datos, ambos compuestos con datos relacionados con la plataforma Android2 .
Android es un sistema operativo mvil desarrollado por Google y la Open Handset Alliance, y ha visto un nmero de actualizaciones a su sistema operativo base
desde su lanzamiento original. Estas actualizaciones tpicamente corrigen fallos
de programa y agregan nuevas funcionalidades.
El primer conjunto es el llamado Android changes. Este consta de cambios
realizados en 275 sub-poyectos pertenecientes al kernel del proyecto Android que
se ubica en un repositorio GIT. 3 . El segundo conjunto de datos es el analizado
en este trabajo. Este consta de datos sobre bugs extrados de un sistema de
seguimiento de bugs publicos de Android (Android, 2012). A continuacin se
describen los mismos.
3.2.1.
Descripcin del conjunto de datos
Los reportes de bugs extraidos estan preprocesados y luego almacenados en

un archivo con formato XML. El esquema de etiquetado del archivos se muestra
en el cuadro 3.1.
A continuacin se enumeran algunos datos estadsticos descriptivos del conjunto de datos:
El promedio de cantidad de palabras en el campo de la descripcin del
bug ingresado por un usuario tiene un promedio de 189 palabras. Solo el
16 % de ellos contienen los pasos para reproducir los detalles.
Contiene un total de un65 % de bugs nuevos. Solo el 5 % de los bugs reportados fueron cerrados con xito. El 12 % de fueron bugs que no cerraron
porque eran invalidos o bien por algunas otras razones.
El 99 % de los bugs tiene como prioridad del tipo Medium.
El tiempo promedio que toma la solucin de un bug es de 2, 43 meses.
Como se puede observar en la figura 3.2.1 la mayora de los bugs no tienen
asignado ningun tipo de componentes.
1 http://2012.msrconf.org/
2 http://www.android.com/
3 git://android.git.kernel.org/
+ nombre del sub-proyecto
Etiqueta
Contenido
Identificador del
bug en el reporte
Ttulo del reporte
del bug
BugId
Title
Status
Estado del bug
Valores
1-18162
Texto
New, Assigned, Fixed,
Duplicate, Sapm, Invalid,
Wont fix, Closed, Verified
Type
Desarrolador que
creo el bug
Tipo de bug
Priority
Prioridad del bug
Component
Subproyecto/mdulo
donde se encontr
el bug
Text
ClosedOn
Fecha en que se
cerr el bug
mm-aaaa (si se cerr),

Open Issue (si no se
cerr)
Owner
Starts
ReportedBy
OpenedDate
Description
Comment
Author
When
What
Cuantas personas
tomaron el bug
Usuario que
report el bug
Fecha en que se
report el bug
Descripcin del
bug por el usuario
que lo report
Detalle de
Usuario que
coment en el
reporte del bug
Fecha del
comentario
realizado
Descripcin del
comentario vertido
Correo electrnico
Defect, Enhancement
Critical, High, Medium,
Low
Entero >= 0
Correo electrnico
mm-dd-aaaa
Texto
cada comentario
Correo electrnico
mm-dd-aaaa
Texto
Cuadro 3.1: Esquema del conjunto de datos.
60
61
Figura 3.2.1: Distribucin de los componentes de los bugs. Grfico generado por
la aplicacin.
Cantidad de
contribuciones
1
2-10
11-50
51-100
101-200
201-500
501-1000
1001 o mas
Cantidad de usuarios
Bugs
Comentarios
reportados en reportes
de bugs
8803
34514
2710
12378
133
545
8
32
0
14
1
7
0
5
0
5
Cuadro 3.2: Distribucin de la contribucin de los usuarios.

En el cuadro 3.2 se puede observar la distribucin de la contribucin de los
usuarios. Un total de 11655 usuarios individuales reportaron bugs mientras que unos 47500 usuarios individuales ingresaron comentarios y participaron en el proceso de resolucin de bugs. La mayora de los usuarios
(entre un 72 % a 75 % aproximadamente) ingresaron bugs o comentaron
en reportes de bugs solo una vez durante su tiempo de asociacin en el
proyecto.
3.3.
Analizador para el conjunto de datos
Para transformar los 20169 bugs en documentos, para luego usarlos como
entrada para un modelo tpico, se cre un parser para transformar las etiquetas de los mismos (cuadro 3.1) en objetos Java empleando una API llamada
Simple API for XML (ms conocida como SAX). Originalmente es una API
nicamente para el lenguaje de programacin Java que despus se convirti en
62
Algoritmo 3.1 Creacin de los documentos a partir de los bugs.

for cada bug en el conjuntos de datos
crea un documento (Title, Description, OpenedDate)
for cada comentario en el bug
if What no es vaco
crea un documento (What, When)
end
end
la API estndar de facto para usar XML en JAVA. Existen versiones de SAX
no slo para JAVA, sino tambin para otros lenguajes de programacin (como
Python). SAX es una API basada en eventos (inicio y fin de elementos) reportando directamente a la aplicacin a travs de llamadas de retorno (callbacks),
y no construye un rbol como es el caso del Modelo de Objetos del Documento
(DOM) del W3C.
SAX es un API de secuencia de procesamiento de XML que permite procesar
un documento XML sin almacenar mucho ms que el contexto del nodo actual
que se est procesando en memoria. Permite procesar archivos XML de gran
tamao sin que sea necesario ocupar un espacio en memoria demasiado grande.
SAX define una interfaz manejada por eventos y mtodos para analizar XML.
A medida que el analizador lee el documento XML y encuentra los componentes
del documento (BugId, Title, Status, etc.) va detectando errores e invocando a
las funciones que se han asociado.
3.4.
Generacin de documentos y de versiones
Para cada entrada en el reporte de bugs se extrajo el campo Title y Description del bug para formar el contenido de un documento. Adicionalmente, el
contenido de cada comentario (campo What) fue tratado como un documento
individual. Cada uno de estos documentos se le asigno como fecha de creacin el
campo OpenedDate, en el caso de los bugs, y el campo When en el caso de los comentarios. Es decir que se crea un documento por cada bug y un documento por
cada comentario (3.1). Se omitieron aquellos casos en donde el campo este vaco.
Este proceso de generacin de documentos tuvo como resultado la creacin de
un total de 76479 documentos, en donde se incluyen los bugs y comentarios.
Se obtubo como resultado la creacin de documentos, con su respectivas
fechas, acerca de los problemas o defectos en el proyecto de open source Android.
Para porder analizar la evolucin de los tpicos se deben definir las versiones.
63
Una versin V de un sistema es un conjunto de documentos d1 , d2 , . . . , dn que

poseen la misma fecha (o time-stamp) t(V ). Tambin se puede definir como un
delta de entre fechas. Desde la aplicacin se fijaron los siguientes parmetros
para la creacin de las versiones:
Tipo: Mes
Cantidad: 1
Fecha inicial: 1/11/2007 (lanzamiento de Android beta)
Fecha final: 1/4/2011 (Android 3.1 Honeycomb)
Con estos parmetros el algoritmo crea las versiones con sus respectivas ventanas de tiempo a partir de la fecha inicial incrementando de acuerdo a los dos
primeros parmetros. La ltima versin tendr como fecha final de su ventana
la fecha final indicada anteriormente. Por ejemplo la primer versin tendra como ventana temporal las fechas 1/11/2007 y 1/12/2007. Con este algoritmo se
crearon un total de 41 versiones sobre las cuales se analizar la evolucin de las
mtricas. En el algoritmo 3.2 se puede observar como se crean las versiones.
3.5.
Extraccin de tpicos
Una vez creados los documentos y las versiones se defini el modelo LDA
empleado. La versin del modelo de tpcicos LDA que se aplic es la versin
Gibbs 4 . Esta versin esta basada en el optimizador L-BFGS (Liu & Nocedal,
1989) y basada en el entrenador de muestreo de LDA del juego de herramienta
de MALLET version 2.0.65 McCallum (2002).
3.5.1.
Algoritmo de muestreo Gibbs
Antes de exponer el pseudo-cdigo del algoritmo empleado para la extraccin

de tpicos, se introducen las dimensiones claves y el tamao de los paremetros
que describen el cuerpo (D, W, N y L) de los documentos y el modelo de tpicos
(T e IT ER), cuadro 3.3 . En el cuadro 3.4 se muestran los arreglos usados en
el modelo de tpicos junto con sus tamaos.
El modelo de tpicos expresa la idea de que las palabras (tambin llamados
trminos) y los documentos estan conectados a travs de los tpicos. La ecuacin
3.5.1 muestra que la probabilidad de una determinada palabra en un documento
en particular depende de la probabilidad de esa palabra en la poderacin que le
asignan los tpicos por la probabilidad de todos los tpicos en ese documento.
4 http://gibbslda.sourceforge.net/
5 http://mallet.cs.umass.edu
64
Algoritmo 3.2 Creacin de las versiones a partir de los parmetros iniciales

establecidos en la aplicacin.
fechaTemp = fechaInicial
while fechaTemp < fechaFinal
crea una version V
fechaInicialTemp = fechaTemp
V .FechaInicial = fechaInicialTemp
switch (Tipo)
Dia: fechaTemp.Dia = fechaTemp.dia + Cantidad
Mes: fechaTemp.Mes = fechaTemp.dia + Cantidad
default: fechaTemp.Ao = fechaTemp.dia + Cantidad
end
V .FechaFinal = fechaTemp
se guarda la versin V
end
if (fechaInicialTemp < FechaFinal)
crea una version V
V .FechaInicial = fechaInicialTemp
V .FechaFinal = FechaFinal
se guarda la versin V
end
Parmetro
Descripcin
Nmero de
documentos en el
cuerpo
Nmero de
palabras en el
vocabulario
Nmero total de
palabras en el
cuerpo
Promedio del
tamao de los
documentos en
cantidad de
palabras
(L = N/D)
Nmero de tpicos
IT ER
Nmero de
iteraciones del
algoritmo de
meustreo Gibbs
Cuadro 3.3: Dimensiones usadas en el modelo de tpicos.
Arreglo
Descripcin
wid (N )
Id de la palabra
did (N )
id del documento
z (N )
Asignacin del tpico de n

palabras
Cwt (W, T )
Cuenta las palabras w en un

tpico t
Ctd (T, D)
Cuenta el tpico t en un
documento d
Ct (T )
Cuenta del tpico t
Cuadro 3.4: Arreglos usados en el modelo de tpios.
65
66
Algoritmo 3.3 Algoritmo del modelo de tpicos aplicado.

for iter = 1 : IT ER
for n = 1 : N
t = z (n)
Ctd (t, did (n)) , Cwt (wid (n) , t) , Ct (t)
for t = 1 : T
P (t) = (Cwt (wid (n) , t) + ) Ctd (t, did (n)) + ) / (Ct(t) + W )
// Ecuacin 3.5.2
end
sample t from P (t)
z (i) = t
Ctd (t, did (n)) + +, Cwt (wid (n) , t) + +, Ct (t) + +
end
end
X
P (w|d) =
P (w|t) P (t|d)
(3.5.1)
t=1
Siguiendo esta idea, se puede escribir un proceso generativo, que formalmente

deriba en un proceso de muestreo Gibbs, como se muestra en la ecuacin 3.5.2.
Esta expresin obtiene la probabilidad de una palabra (posicin n en el tpico)
en el cuerpo que pertenece a un tpico t. En esta ecuacin se puede observar
de forma explcita varios arreglos, incluyendo Cwt, Ct y Ctd. El n es una
notacin estndar de muestreo para indicar que la palabra actual (palabra n)
ha sido removida de estos conteos. Los parmetros y son de Dirichlet, y
pueden ser interpretados informalmente como pseudo-cantidades.
P (Zn = t|Zn )
n

Cwt
+
n
Ctd
+
n
Ct + W
(3.5.2)
El pseudo-cdigo del modelo de tpicos Gibbs se muestra en 3.3. Como se

puede observar el algoritmo contempla la ecuacin 3.5.2 en la iteracin sobre
los T tpicos, N palabras en el cuerpo y una cantidad de IT ER barridos del
muestreo de Gibbs. Despus de un nmero suficiente de iteraciones, la cantidad
de datos en Cwt y Ctd tiene los datos para estimar las distribuciones sobre las
palabras en cada tpico, P (w|t) y sobre los tpicos en cada documento, P (t|d).
Si se observan las ciertas lneas del algoritmo 3.3 se puede estimar la complejidad del tiempo y espacio del mismo.
67
T iempo O ( IT ER N T )
(3.5.3)
Espacio O ( 3 N + (D + W ) T )
(3.5.4)
Para un conjunto de datos muy grande, D W y N = D L, entonces la

frmula anterior 3.5.4 quedara como
Espacio O ( (3 L + T ) D)
(3.5.5)
Para apreciar estas medidas de complejidad se deben considerar millones de

documentos con los siguientes tamaos en los parmetros: D = 106 , W = 104
y L = 103 (N = DL = 109 ). Para estos cuerpos de documentos es razonable
interar con T = 103 tpicos y IT ER = 103 iteraciones. Para mas informacin
detallada del modelo matemtico del algoritmo Gibbs se puede ver en (Casella &
George, 1992). En este trabajo se opto por elegir un nmero de 5000 iteraciones
y generar 100 tpicos. El nmero de interaciones indicado permite obtener un
conjunto de tpicos lo suficientemente consistente, sin embargo se puede obtener
an mas precisin aumentando el nmero de iteraciones. Para cualquier cuerpo
de un documento dado no existe una opcin ptima para el valor de la cantidad
de tpicosWallach et al. (2009). La eleccin de este valor es lo que se denomina
en ingls como trade-off entre tpicos muy amplios (un valor de T muy pequeo)
y tpicos muy pequeos (un valor de T muy grande). Es decir que si elegimos un
valor muy pequeo de tpicos obtendremos tpicos que contendrn demasiados
conceptos (por ejemplo, un slo tpico que contiene todos los conceptos de un
cuerpo), mientras que un valor muy alto de tpicos se obtienen tpicos que
son demasiado finos para ser significativos y slo revelan la idiosincrasia de
los datos. El nmero de tpicos seleccionado en este trabajo permite obtener
una granularidad adecuada de tpicos para poder obtener los conceptos mas
relevantes del conjunto de datos. Elegir el nmero de tpicos no es una tarea
fcil dado que depende en gran medida de los datos analizados y del tipo de
aplicacin que se le darn a los mismos. La cantidad de tpicos seleccionados se
baso en los trabajos presentados en Shihab et al. (2012) dado que estn basados
en el mismo conjunto de datos.
Para la seleccin de los valores de los parmetros y se tomarn lo valores
usados por defecto, = 50/T = 50/100 = 0, 5 y = 0, 01.
El algoritmo se corri sobre una pc con un procesador i5 320M de 2.60Ghz.
con 12Gb de memoria RAM y un disco de estado slido de 128Gb.
68
Figura 3.5.1: Estapas (pipes) de pre-procesamiento de los documentos.
3.5.2.
Pre-procesamiento de los documentos
Sobre cada uno de los documentos que se va ha introducir en el algoritmo

de muestreo Gibbs, se lleva a cabo un pre-procesamiento del contenido de los
mismos. La finalidad de dichos procesamientos es eliminar o diminuir el ruido
que puede presentarse en dichos documentos. Por ejemplo, signos de puntuacin, formando emoticones, jergas, palabras conectoras, etc. El procesamiento
de dichos textos consta de las siguientes etapas (figura 3.5.1).
3.5.2.1.
Eliminacin de smbolos de puntuacin
La eliminacin de los smbolos de puntuacin remueve smbolos como :),

los cuales no aportan semntica a los documentos para determinar el contenido
de los mismos. Para el caso especfico del trabajo presentado en esta tesis, los
smbolos de puntuacin se consideran como ruido debido a que no aportan
informacin para los tpicos extraidos. El proceso para eliminar los smbolos de
puntuacin es muy sencillo. Cada documento es separado en tokens, a partir
de all se analizan cada uno de ellos en busca de estos smbolos de puntuacin.
Por ejemplo, al encontrar el carcter : se elimina dado que generalmente es
empleado para indicar llamados a funciones de forma anidada.
3.5.2.2.
Desglose de trminos
El desglose de trminos consta de dividir un token en dos o mas tokens. Por

ejemplo, cuando se encuentran tokens con la forma trmino1Termino2, es decir
el desarrollador intenta hacer notar la separacin de ambos trminos. En este
caso se divide por la letra mayscula y se separan en dos trminos, trmino1 y
Trmino2. El desglose de trminos ha sido muy importante dado que permite
aumentar la co-ocurrencia de ambos trminos. Otro caso cotemplado es de la
forma trmino1:trmino2 en donde se separa en base al smbolo :.

3.5.2.3.
69
Conversin de maysculas a minsculas
La eliminacin de maysculas y su posterior pasaje a minsculas es muy

importante debido a que por ejemplo, en algunos comentarios se puede encontrar
el trmino request y en otros Request. Esto permite aumentar la eficiencia del
algoritmo de extraccin de tpicos.
3.5.2.4.
Eliminacin de stop words
Las denomindas stop words son palabras que estn constituidas por conectores, algunos verbos muy utilizados, preposiciones, etc. Esta supresin en los documentos disminuye ampliamente la performance del algoritmo, asi como tambin la cantidad de trminos que esta analiza. Adems hay que destacar que
estos trminos son comunes en todos los documentos y no aportan informacin
relevante sobre el tema tratado en los mismos.
3.5.2.5.
Aplicacin de un algoritmo de Stemming (Porter)
Stemming es un mtodo para reducir una palabra a su raz, Tambin denominado stem por su siglas en ingls. Hay algunos algoritmos de Stemming que
ayudan en sistemas de recuperacin de la informacin. Stemming aumenta el
recall que es una medida sobre el nmero de documentos que se pueden encontrar en una consulta. Aqu se empleo el algoritmo de Porter (Porter, 1980). Este
permite extraer los sufijos y prefijos comunes de palabras literalmente diferentes
pero con una raz comn que pueden ser consideradas como un slo trmino. Al
realizar una bsqueda, utilizando el ndice el usuario puede perderse porque las
palabras estn escritas de otra forma en el documento. Para eso puedo guiarse
por los trminos extraidos del algoritmo para realizar las bsquedas.
Al aplicar stemming, se asegura que la forma de las palabras no penalize
la frecuencia de estas. Cuando se aplica el algoritmo de Porter (Porter, 1980),
el documento, se divide en tokens, luego se itera por esos tokens aplicando
el algoritmo de Porter a cada uno de ellos. Existe una condicin dentro del
algoritmo que si el token no es una palabra, esto es, si el token contiene un
nmero o algn smbolo adems de letras de a-z, se supone que no es una
palabra y no se analiza. Este algoritmo es implementado para ser utilizado con
la gramtica inglesa dada la naturaleza del conjunto de datos.
3.5.3.
Resultado de la aplicin del algoritmo
Como se meciono en la seccin 2.5 existen varios modelos para aplicar a la

evolucin de tpicos. En este trabajo se opt por elegir el modelo Hall dado
que ha tenido xito para tratar la evolucin de los tpicos como en (Linstead
70
et al., 2008a; Thomas et al., 2010). Es decir que se aplic colectivamente a todos
los cuerpos de los documetnos de todas las versiones al mismo tiempo. De esta
manera el tiempo de clculo para este trabajo disminuye drsticamente dado
que si se hubiese aplicado el modelo Link, adems del proceso del modelo Gibbs
para la extraccin de los tpicos, se le debe adicionar el proceso unir o vincular
los tpicos a travs de las versiones de acuerdo a alguna medida de similitud.
Como se puede observar en el cuadro 3.5 se extrejeron unos 100 tpicos en
total. Los tpicos denotados con color rojo (un total de 58 tpicos) son aquellos
que tienen una varianza estadstica significativa superior a un 40 %.
Cuadro 3.5: Tpicos extrados con sus cinco trminos mas influyentes ordenados
descendientemente por sus respectivas probabilidades.
Luego de una observacin cuidadosa de los tpicos podemos concluir en primer medida que la agrupacin de trminos que realizo el algoritmo es consistente. Se observa que tenemos en principio unos 100 tpicos que denotan reportes
de fallas bastante puntules en su mayoria. Por ejemplo el tpico Z6 , presenta
fallas relacionadas con la soncronizacin de los correos de gmail. Otro tpico
que denota problemas es Z11 , en donde seala fallas con el dispositivo de manos
libres con coneccin bluetooth.
Otro punto importante a tener en cuenta a la hora de analizar los tpicos es
que muchos de ellos representan temas mas generales que otros. Por ejemplo el
tpico Z1 , se compone de palabras como diseo, implementacin, estandar, etc.
por lo que son trminos muy genricos.
71
Como es sabido la sptima versin del sistema operativo Android llamada

Gingerbread (Android, 2010) que se publico en diciembre del ao 2010 opto
por un cambio grande en su Garbage Collector para mejorar la velocidad de las
aplicaciones, pero especialmente aquellas aplicaciones que hacen un uso intenso
de los grficos. Usando ese dato podemos especular que cerca de ese perodo
de tiempo antes de su publicacin debieron existir bugs con respecto a Android
runtime y aplicaciones que hacen uso intenso de libreras grficas. Dada esta
informacin vemos que hay tpicos relacionados con este tipo de temas, como
los tpicos Z34 y Z48 .
En la seccin 3.7 se analizarn con mas detalle ejemplos similares al mencionado anteriormente mediante el empleo mtricas y se cotejarn estos resultados
con eventos anunciados de la plataforma Android. De manera podemos observar
como los cambios en la mtricas se condicen con los enventos de la realidad.
3.6.
Resultados y mtricas para la evolucin de

tpicos
Para medir como un tpico varia en el tiempo se calculan mtricas sobre

cada uno de los tpicos en cada versin.
A continuacin se describen cada una de las mtricas mas comunes que se
pueden usar para caracterizar la evolucin de los tpicos, aunque existen muchas
otras variantes de estas mtricas. Las mtricas contempladas en este trabajo
son aquellas que aplic (Thomas et al., 2012) en donde prueban que son fiables
para el analisis evolutivo de los tpicos. Ellos hicieron un experimento de forma
manual y otro mediante empleao de mtricas. Como resultado obtuvieron que
estas mtricas son fiables para realizar un anlisis de evolucin de los tpicos.
La mtrica assignment de un tpico es la suma de la presencia de un tpico
sobre cada documento de la versin analizada. Lo que nos da una presencia de
ese tpico a lo largo del reporte de bugs (Baldi et al., 2008). Un tpico con un alto
valor de esta mtrica siginfica que una gran porcin del reporte es relacionada
con este tpico. En la ecuacin 3.6.1 se define el valor de assignment para un
tpico Zk en la versin Vj .
|Vj |
X
A (Zk , Vj ) =
dij [k]
(3.6.1)
i=1
La mtrica weight de un tpico es similar a la mtrica assignment, pero

considera adicionalmente el tamao (cantidad de palabras) de cada documento.
Esta mtrica captura exactamente cuantas palabras en todo el cuerpo fueron
generadas por un tpico, mientras que la mtrica assignment captura la porcin
72
de documentos que se generaron por un tpico, y por lo tanto pueden estas

sesgadas por pequeos documentos. En la ecuacin 3.6.2 se define el valor de
weight para un tpico Zk en la versin Vj .
|Vj |
X
W (Zk , Vj ) =
dij [k] |dij |
(3.6.2)
i=1
La mtrica scattering de un tpico es la entropa normalizada de un tpico

sobre todos los documentos (Baldi et al., 2008). La entropa es una mtrica
comunmente usada en la teora de la informacin para determinar cuan incierta
es una distribucin (Shannon, 2001). En (Thomas et al., 2012) normalizan este
nmero de documentos para tener en cuenta diferentes nmeros de documentos
en cada versin. Un tpico con alta entropa siginifica que el tpico estar mas
extendido a travs de todo el reporte, una baja entropa indica lo contrario. En
la ecuacin 3.6.3 se define el valor de scattering para un tpico Zk en la versin
Vj .
S (Zk , Vj ) =
|Vj |
X

dij [k] log dij [k]
(3.6.3)
i=1
La mtrica focus revela cuan denso, en promedio, un tpico esta presente

en cada documento que lo contiene, lo que no puede ser capturado por las
mtricas de assignment o scattering. Los tpicos que sean altamente dominantes
en los documentos en los que aparecen tendrn un alto valor de focus, mientras
que lo tpicos que tienden a desempear un papel secundario, en cuanto a
influencia, tendrn un valor bajo de focus. En la ecuacin 3.6.4 se define el valor
de scattering para un tpico Zk en la versin Vj .
|Vj |
X
|{dij (k ) threshold}|
F (Zk , Vj ) =
|Vj |
i=1
3.7.
(3.6.4)
Anlisis de la evolucin de tpicos
A continuacin se han seleccionado algunos de los tpicos extrados (Z99 , Z92 ,

Z22 , Z93 , Z20 y Z71 ) para ejemplicar el uso de las mtricas y ver como estas se
condicen con los eventos que surguieron a travs de las sucesivas versiones. En
el apndice A se encuentran las versiones de Android, con sus caractersticas,
que fueron lanzadas en el perodo de tiempo que se tomo para la generacin de
las versiones.
El tpico Z99 se refiere a problemas relacionados con los diferentes modelos
73
de telfonos celulares de la marca HTC6 . Aqu no se refiere a problemas con

el handset (trmino empleado para la palabra en espaol auricular) sino que
el trmino es en referencia a la alianza comercial78 que se dedica a desarrollar
estndares abiertos para dispositivos mviles. Los modelos implicados en este
tpico por orden cronolgico son Dream, Magic, Hero, Desire y Evo. Es un
tpico con conceptos no tan genricos. La mtrica assignment (figura 3.7.1a)
para este tpico nos indica que la precencia de este tpico ha ido en aumento
conforme con el crecimiento y las ventas de celulares con Android. En esta
mtrica podemos encontrar varios picos. Estos picos indican que ese perodo de
tiempo la precencia del tpico se ha disparado. Por ejemplo el pico de junio del
2009 (versin 20) se debe al lanzamiento del modelo Hero. Luego baja y vuelve
a aumentar por el lanzamiento del modelo Hero 2 con fecha en noviembre del
2009. Luego otro pico lo encontramos en julio de 2010 (versin 33) que se condice
con la salida de la versin del modelo Evo. En la fecha febrero del 2011 (versin
39) nos encontramos con la salida del modelo EvoShift 4G. Con esta mtrica
podemos indenticar que los picos encontrados indican una fuerte presencia de
los modelos lanzados. Hay que mencionar que esa tendencia de crecimiento es
acompaada por el crecimiento del sistema operativo Android por lo que la
cantidad de bugs y de desarrolladores aumenta considerablemente. Es decir con
la salida al mercado de un nuevo modelo de HTC.
6 http://www.htc.com/
7 Open Handset Alliance (OHA) es una alianza comercial de 84 compaas que se dedica a
desarrollar estndares abiertos para dispositivos mviles. Algunos de sus miembros son Google,
HTC, Dell, Intel, Motorola, Qualcomm, Texas Instruments, Samsung, LG, T-Mobile, Nvidia
y Wind River Systems.
8 http://www.openhandsetalliance.com/
74
(a) Assignment.
(b) Weight.
(c) Scattering.
(d) Focus.
Figura 3.7.1: Mtricas del tpico Z99 .

Con la mtrica weight (figura 3.7.1b) podemos observar la cantidad de bugs
relacionados con este tpico que es algo que no se puede observar con la mtrica
anterior. Por ejemplo en septiembre de 2010 (versin 35) vemos el pico mas alto.
Esto se debe a que el aumento de bugs reportados pero tambin a la cantidad
de comentarios en los mismos. Por lo tanto nos indica que el trabajo de los
desarrolladores en ese punto fue mucho mas alto. Aunque tambin se puede
interpretar como un gran cmulo de bugs aun no resueltos.
Con esto podemos decir que con assignment podemos observar la presencia
del tema y con weight observamos la presencia de la misma pero en su volumen. Cuando se asemejan las medidas de asignment y weight nos indica que la
cantidad de trabajo esta relacionada en mayor medida con la presencia de ese
tpico.
Con la mtrica scattering (figura 3.7.1c) nos indica la cantidad de informacin promedio que contiene el tpico en cada versin. La medida de umbral
(threshold) tomada fue de 0,1 en lugar de 0,5 como se estil en Thomas et al.
(2010) para poder abarcar mas cantidad de documentos a contemplar. En este
tpico podemos decir que cerca de julio de 2010 (versin 33) este tpico tiene
una alta propagacin en los documentos de esta versin. Lo que por ejemplo
sucede en el periodo octubre de 2010 (versin 35) dado que la cantidad de bugs
en ese punto es grande pero no estuvo tan expandido a lo largo de la versin.
Con respecto a la mtrica focus (figura 3.7.1d) podemos observar cuan fuerte
75
es la presencia del tpico de acuerdo al umbral de presencia de ese tpico sobre

los documentos. Por ejemplo, en el primer pico de enero de 2008 (versin 3),
de puede deber a una fuerte presencia del tpico pero en dnde la cantidad
de documentos es baja. Esto nos dice (algo que no se puede obtener con las
otras mtricas) cuan denso o dominante en promedio es ese tpico en la versin.
Por ejemplo en la fecha alrrededor del julio de 2009 (versin 20) este tpico
desempeo un rol primario en el reporte dado que posee un alto valor de focus.
El tpico Z92 se refiere a problemas relacionados con el modelo de telfono
celular Droid de la marca Motorola9 . En este tpico la curva de las mtricas
assignment (figura 3.7.2a) y weight (figura 3.7.2b) es bastante similar hasta
aproximadamente mayo de 2010 (versin 31). Esto nos indica que hasta esa
fecha la presencia del tpico como la cantidad de bugs reportados o la cantidad de comentarios sobre los mismos es directamente proporcional. El pico que
se observa en noviembre de 2009 (versin 26) se condice con el lanzamiento al
mercado de modelo Droid cuya fecha de lanzamiento fue el 6 de noviembre del
mismo ao. La compaia telefnica que lanzo primero este modelo fue Verizon10
con su campaa publicitaria por televisin lanzada el 17 de octubre de 2009.
Luego podemos observar otro pico en mayo de 2010 (versin 30) en donde Motorola anunci que Android 2.2 (Froyo) estara listo para el Motorola Milestone
a finales de 2010.
Con respecto a la mtrica de scattering (figura 3.7.2c) la dispercin acompaa de manera similar a la presencia del tpico hasta la fecha de mayo de 2010.
En es fecha el tpico alcanza su punto mximo de entropa. Luego su dispersin
disminuye y se mantiene en un rango acotado.
La mtrica focus (firgura 3.7.2d) indica que el tpico fue predominante en
los momentos mas importantes que se mencionaron anteriormente. Es decir que
en la cantidad de bugs reportados del tpico es mas dominante para esas fechas.
9 http://www.motorola.com/
10 http://www.verizon.com/
76
(a) Assignment.
(b) Weight.
(c) Scattering.
(d) Focus.
Figura 3.7.2: Mtricas del tpico Z92 .

El tpico Z22 se refiere a bugs relacionados con los release de los sdk para
Android. El SDK (Software Development Kit) de Android, incluye un conjunto
de herramientas de desarrollo. Comprende un depurador de cdigo, bibliotecas,
un simulador de telfono basado en QEMU, documentacin, ejemplos de cdigo
y tutoriales. Como se observa en la figura 3.7.3 entre las fechas de julio y septiembre de 2008 (versin 10) se observa un gran pico. Esto se debi a la primer
version del SDK (Android 1.0 SDK, release 1) lanzada en el 23 de septiembre de
2008. En este punto verificando los reportes de bugs manera manual se obervan
un gran incremento en el nmero de bugs como tambin de los comentarios.
Luego el siguiente pico mas alto se debe a la siguiente versin SDK de la versin
de Android 1.6, lanzada el 15 de septiembre de 2009.
77
Figura 3.7.3: Mtrica assignment para el tpico Z22 .

El tpico Z86 se refiere esencialmente a la aplicacin Market, el cual es
un programa con un mercado para la descarga y actualizacin de aplicaciones
tanto gratuitas como pagas. En la figura 3.7.4 podemos observar un primer pico
en marzo de 2008 (versin 5). Esto se debe al desarrollo de la misma para el
lanzamiento de su primera versin. Este alto coeficiente de focus indica que tuvo
gran predomio sobre los documentos. Luego el valor de la mtrica crece acorde a
la popularidad de Android con lo cual el mercado de acaplicaciones crece y por
ende la aplicacin Market va adquiriendo mas dominio sobre los bugs reportados.
Su valor mas alto es en abril de 2009 (versin 18), dado que en febrero de ese
ao Android anuncia el soporte para aplicaciones pagas por lo tanto los reportes
de bugs se acumulan gradualmente hasta llegar a su pico en abril de 2009. A
partir de esa fecha el valor de la mtrica cae pero se mantiene con altos y bajos
sobre un valor medio en donde se introducen cambios y caractersticas.
Como dato extra en marzo de 2012, con la fusin de Android Market con
Google Music, el servicio fue renombrado a Google Play, como resultado de la
nueva estrategia de distribucin digital de Google.
78
Figura 3.7.4: Mtrica focus para el tpico Z86 .

El tpico Z20 se refiere a temas relacionados con las versiones de firmware
para dispositivos moviles de Android. Como se observa en la figura 3.7.5 los dos
picos que se encuentran entre las fechas noviembre (versin 25) y enero (versin
26) de 2010 estn relacionacionadas con las versiones de Android 2.0 y 2.01 respectivamente. Con relacin a la versiones lanzadas anteriormente en la versin
2.0 se introdujeron muchas caractersticas nuevas y en la versin 2.0.1 se corrigieron errores en el framework y se modific la API. Tambin lo que increment
en gran medida en estos bugs es la cantidad de desarrolladores que comenzaron
con las issues. sto incrementa considerablemente el nmero de comentarios y
por ende el nmero de documentos generados por la aplicacin. El siguiente
pico entre febrero y marzo de 2001 (versin 40) se debe a la siguiente versin de
Android, la 3.0. Aqu ocurre de manera muy similar, el cambio de numeracin
de la versin implica gandes cambios y por ello aumenta considesarablemente el
valor de esta mtrica.
79
Figura 3.7.5: Mtrica weight para el tpico Z20 .

El tpico Z71 se refiere a bugs reportados sobre actualizaciones de las versiones de Android llamadas Froyo y Gingerbread para los dispositvos Nexus. En la
figura 3.7.6 se destacan dos picos, el primero entre junio y julio de 2010 (versin
33) y el segundo entre enero y febrero de 2010 (versin 39) de se corresponden
a fallos sobre el dispositovo Nexus de la marca HTC. En la versin 33 se corresponden a muchas issues con temas relacionados con el ruteo de mensajes SMS
que afectaron al modelos Nexus One. Con respecto a la versin 39 tambin se
introdujeron cambios sobre la plataforma para Nexus pero fueron cambios menores y agregado de caractersticas nuevas. Tambin hay que destacar el ltimo
pico (versin 41) que se relaciona con la actualizacin para la nueva versin
de Android llamada Gingerbread. En esta se introdujeron cambios importantes
como mejoras de rendimiento para la red 4G, con el teclado, con la recarga de
pginas en el navegador, etc.
80
Figura 3.7.6: Mtrica assignment para el tpico Z71 .
3.8.
Conclusin
En este captulo se han presentado las etapas del tratamiento del reporte de
bugs. Se describi con detalle el conjunto de datos empleado en la aplicacin.
Tambin el tipo de analizador empleado para la extraccin de los bugs desde el
archivo XML. Luego se present el proceso para la generacin de los documentos
y el proceso para la generacin de las versiones. Los pre-procesos aplicados sobre
los documentos antes de la extraccin de los tpicos. Luego se explic el modelo
de tpicos LDA, variante Gibbs, empleado para la extraccin de los tpicos. Se
extrajeron un total de 100 tpicos a partir de un total de 76479 documentos.
Algunos de los tpicos resultaron con trminos bastantes genricos (por ejemplo
Z1 ) con respecto a otros que son mas especficos (por ejemplo Z98 ).
Finalmente, se expusieron las frmulas y definicin de cada una de las mtricas empleadas para la analizar la evolucin de los tpicos. A modo de ejemplo
se aplicaron estas mtricas sobre seis tpicos para entender como varan en el
transcurso de las versiones y como stas se conciden con los eventos que fueron
sucediendo en la vida del SO Android.
Captulo 4
Indexacin y bsqueda
mediante Lucene
4.1.
Utilizacin de ndices con Lucene
Para cada uno de los documentos se indexan mediante Lucene. Dicha librera
provee una manera eficaz para recuperar los datos de dichos ndices y luego
proveer los resultados de las bsquedas.
4.1.1.
Indizacin
Para el proceso de indizacin se utiliza un directorio, un Escritor de ndices,

un Analizador, un Documento y un Campo. Bsicamente es un proceso de anlisis. El Escritor de ndices es el componente central de la indizacin en Lucene.
Pero antes de indizar el documento, ste pasa por el Analizador el cul, como
funcin por defecto, elimina palabras como los conectores, preposiciones, etc.,
adems convierte las palabras a minsculas para que las bsquedas sean ms
exactas. El Documento representa una coleccin de Campos. El Documento a
indizar es separado en campos o metadatos como son el identificador, la fecha
de creacin y el texto.
En el cuadro 4.1 se enumeran y describen los analizadores bsicos que contiene la librera de Lucene internamente, y un ejemplo de cmo se realiza en
cada uno de ellos el anlisis basndose en los trminos que indexa. En la tabla
cada trmino est definido entre los smbolos parntesis cuadrados ([ y ]).
De esta manera podemos ver las diferencias entre cada analizador basndose en
qu trminos son considerados.
Cada Documento contine Campos, en Lucene existen cuatro tipo de campos:
81
CAPTULO 4. INDEXACIN Y BSQUEDA MEDIANTE LUCENE
Analizador
Trminos: The XY&Z

cis xyz@ciaxyz.com
WhitespaceAnalyser
[The] [XY&Z] [cia] [-]

[xyz@ciaxyz.com]
SimpleAnalyzer
[The] [XY] [Z] [cia] [xyz]

[ciaxyz.com]
StopAnalyzer
[XY] [Z] [cia] [xyz]

[ciaxyz.com]
StandardAnalyzer
[The] [XY&Z] [cia] [-]

[xyz@ciaxyz.com]
82
Descripcin
Como su nombre indica,
se divide el texto en
tokens usando el espacio
entre palabras para
dividir los mismos. No
hace ningn otro esfuerzo
para normalizar los
tokens. Tampoco
convierte los tokens a
minsculas.
Primero divide los
caracteres que no poseen
letras, luego convierte a
minsculas cada token.
Trabaja igual que el
SimpleAnalyzer excepto
que remueve las palabras
comunes. Por defecto
remueve palabras como
artculos. Se puede
emplear un archivo con la
lista de palabras a
eliminar.
Es uno de los analizadores
mas sofisticados que
posee Lucene. Posee una
pequea lgica para
reconocer ciertos tipos de
tokens, como por ejemplo,
nombre de companias,
direcciones de correo
electrnico, etc. Tambin
convierte a minscula los
tokens, remueve stop
words y puntuacin.
Cuadro 4.1: Tipos de analizadores de la librera Lucene.
83
Keyword: Se alamacena y se indiza tal cual se introduce, no se analiza, se utiliza para los campos que se deben guardar tal cual y no pueden modificarse,
como por ejemplo una URL.
UnIndexed: Se almacena pero nunca se utiliza en las bsquedas, como por
ejemplo una clave primaria de una base de datos.
Text: El valor se analiza e indiza, el valor original tambin se almacena.
UnStored: Es la opuesta a UnIndexed. Se analiza e indiza, se utiliza para todos
los documentos de texto.
4.1.2.
Bsqueda dentro del ndice
Para llevar a cabo la bsqueda dentro del ndice se utiliza un Buscador

de ndices, un Trmino, una Query, un TermQuery y los Hits. En este caso
el Buscador de ndices es a la bsqueda lo que el Escritor de ndices en la
indizacin. Es el encargado de abrir el ndice y realizar la bsqueda en l. Ofrece
varios mtodos de bsqueda. Lo que hace el buscador es tomar como entrada
la Query y devolver los Hits, que son los documentos recuperados. Luego esos
Hits son enviados al algoritmo de clustering en donde se agrupan de acuerdo a
la variante elegida, pero se trataran en la seccin 4.1.3. El Trmino es la unidad
bsica de la bsqueda y consiste en un par elementos: el nombre del campo y su
valor (Campo, Valor). Por ejemplo el trmino (text:Android) corresponde
a una bsqueda donde se quiere recuperar los documentos mediante el campo
text y que contengan la palabra Android.
Para la indexacin de los documentos se utilizan los siguientes filtros:
Se guarda el Id y la fecha del documento, pero no se analizan. Esto quiere
decir que el identificador del documento se guarda tal cual se encuentra.
El contenido de los documentos se guardan y se analizan. Esto quiere decir
que adems de almacenar los valores en los ndices sern analizados.
Se soportan los siguientes tipos de bsquedas:
Con TODAS las palabras: Busca los documenteos que tengan todas las
palabras. Es decir se utiliza un conector lgico and para relacionar todas
las palabras que se encuentran en este campo. Por ejemplo: Si se ingresa
Google Android, la query resultante para realizar la bsqueda seria: google
and android.
Con la FRASE EXACTA: Busca los documentos que tengan la frase textual en algunos de sus campos. Utilizamos en operador que brinda Lucene para hacer este tipo de bsqueda. Por ejemplo: Si se ingresa user was
84
typing in a web, la query asociada para realizar la bsqueda seria: user

was typing in a web.
Con ALGUNAS de las palabras: Busca los documentos que tengan algunas de las palabras en cualquiera de sus campos. Se utiliza el conector
lgico OR para relacionar las palabras que se encuentran en este campo.
Por ejemplo: Si se ingresa Google Android, la query asociada para realizar
la bsqueda seria: google or android.
SIN las palabras: Busca los documentos que no contengan ninguna de las
palabras especificadas. Utilizamos el operador - que brinda Lucene. Por
ejemplo: Si se ingresa Google Android, la query resultante sera -google and
-android.
Con las palabras en el CAMPO: Busca los documentos que tengan las
palabras en un campo especificado (Id, Date o Text). Por ejemplo: Si se
ingresa Google Android y se elije el campo Text, la query para realizar la
bsqueda seria text:(google android ).
Para realizar todos estos tipos de bsqueda de forma combinada se decidi darle
diferentes ponderaciones a cada una de ellas para formar la query global de la
bsqueda. Entonces se priorizaron en el siguiente orden:
1. Con las palabras en el CAMPO
2. Con la FRASE EXACTA
3. El resto de las bsquedas pertenecen al mismo orden de prioridad otorgado
por defecto por Lucene.
Fueron priorizadas de esta manera para lograr que las partes de la consulta en las
que el usuario brinda informacin ms precisa o con mayor grado de restriccin
tengan mayor relevancia a la hora de listar los documentos recuperados.
4.1.3.
Extensin de las bsquedas
En los ltimos aos el reconocimiento de patrones ha adquirido cierta popularidad gracias a la automatizacin de las soluciones a muchos problemas de
la vida real y en particular, los mtodos de agrupamiento (clustering), debido a
que cada vez es ms necesario tratar grandes volmenes de datos que requieren
herramientas nuevas para descubrir informacin relevante y relacin entre los
datos.
Para la clasificacin de los documentos recuperados por medio de Lucene
luego se emple la librera Carrot2 para clasificarlos. En la interfaz de la aplicacin se permite elegir entre un conjunto de diferentes algoritmos de clustering
85
para poder ver los distintos resultados. Cuando se realiza una bsqueda se obtiene como salida los diferentes clusters que cre el algoritmo con sus palabras
claves. Los algoritmos que se pueden seleccionar son:
K-Means: Busca formar K clusters, formados por documentos. Cada uno de
estos K clusters se representan por el valor medio de los documentos que
pertenecen a dicho cluster. Los documentos se asignan al cluster cuya
distancia del mismo con el centroide es mnima. Se itera hasta lograr un
criterio de convergencia.
Suffix Tree Clustering (STC): Identifica frases comunes de los documentos.
Utiliza un rbol de sufijos como estructura de datos. A diferencia de los
otros es incremental y trata a los documentos como una secuencia ordenada de palabras no como un conjunto de palabras.
Lingo: Construye etiquetas para los clusters basado en la reduccin de plazo
de documentos de la matriz y lo asigna a los documentos de las etiquetas.
4.1.3.1.
Ejemplo de una bsqueda con los trminos de un tpico
A modo de ejemplo se realiz la busqueda de los primeros 5 trminos de

un tpico para observar que los documentos recuperados se condicen en gran
medida con los documentos en los cuales el tpico forma parte de su contenido.
El tpico seleccionado es el Z27 cuyos trminos se exhiben en el cuadro 4.2.
Trmino
file
download
attach
path
apk
Probabilidad
0, 43212
0, 09249
0, 04765
0, 04218
0, 034477
Cuadro 4.2: Los diez trminos mas relevantes del tpico Z27 . Ordenados en
forma decreciente.
El tipo de consulta empleada es la llamada Con algunas palabras 4.1.2 dado
que algunos trminos pueden no estar en el algunos documentos. El algoritmo
empleado es K-Means con un lmite de cantidad de 10 documentos. Lo resultados
obtenidos de los clusters se observan en el cuadro 4.3.

Cluster
Trminos
gdb, prebuilt, arm,

gdbserver, lib
paint, draw, canva,

size
3
4
browser, media,
mine, product, type
keyboard, soft,
input
Documento Id
21166
74019
1778
21964
57160
36942
29401
837
47552
72834
Puntaje
1, 336
1, 214
1, 11
1, 632
1, 233
1, 143
1, 284
1, 143
1, 334
1, 213
86
(Z27 , d)
0
0
0, 00535
0, 9974
0
0, 99386
0, 000012
0, 000245
0, 000395
0, 000015
Cuadro 4.3: Resultados obtenidos de la consulta para los trminos del cuadro
4.2.
Como se puede observar el cluster nmero 2 es el que posee los documentos mas relacionados con el tpico. Los trminos arrojados por el algoritmo de
clustering son los mas relacionados con los documentos que presentan menos
probabilidad para la funcin y con otros trminos incluidos tambin en el tpico como build, international, italiano entre otros. Luego de experimentar con
varios casos se puede concluir que es necesario ajustar los parmetros de la busqueda y aumentar la cantidad de documentos del resultado considerablemente
para obtener un cluster en donde los trminos de alguno de ellos coincidan en
gran medida con los trminos del tpico. Es decir que cuando menos restrictiva
es la bsqueda mejor son los resultados.
4.2.
Conclusin
Se ha utilizado indexacin para la posterior consulta de los trminos o palabras del conjunto extrado por el modelo de tpicos. Luego se pueden realizar
consultas sobre este ndice y analizar la relacin de los documentos recuperados de acuerdo al algoritmo de agrupamiento seleccionado con respecto a los
documentos en que influye cada uno de los tpicos.
Un ejemplo prctico es buscar los trminos de un tpico para obtener los
documentos relacionados con este. Los documentos recuperados no simpre coinciden en un 100 % con los documentos en los cuales el tpico forma parte de
su contenido como se mostr en el ejemplo 4.1.3.1. Sin embargo ajustando los
parmetros de la bsqueda se puede obtener un resultado considerablemente
exacto.
Captulo 5
Aplicacin para la
extraccin y anlisis de
tpicos
En este captulo se presenta la aplicacin implementada para la extraccin
de tpicos, el clculo de mtricas, creacin y bsqueda en el ndice.
5.1.
Descripcin de la aplicacin
En este captulo se presenta la aplicacin desarrollada para la extraccin de

tpicos, el clculo de mtricas, creacin y bsqueda en el ndice. El motivo es
presentar una vista y algunas de sus caractersticas mas relevantes.
La aplicacin esta diseada para que el usuario pueda cargar un conjunto
de datos con la estructura mencionada en el capitulo anterior. Como se observa
en 5.1.1 la pantalla principal consta de 5 solapas. La primera de ellas se divide
en 3 partes principales. La primera parte se encarga de la lectura del archivo
del conjunto de datos mediante el empleo de un parser para arhivos XML.
Se selecciona el archivo con los datos y se elige la alternativa de borrar los
comentarios y bugs que ya se encuentran en la base de datos. Luego se ejecuta
dicho parser y se procede a la lectura de todo el contenido de los bugs mientras
se va informando la cantidad de bugs y comentarios encontrados. Luego en la
segunda parte, se generan los documentos y se crean las versiones. En el caso
de la generacin de las versiones se deben elegir el periodo de tiempo, es decir
la fecha inicial de la primera version y la fecha final de la ltima versin. Luego
se selecciona cada cuanto se fracciona ese periodo, por ejemplo, en la figura se
seleccion que se cree una version cada 3 meses con los cual se crearon un total
87
CAPTULO 5. APLICACIN PARA LA EXTRACCIN Y ANLISIS DE TPICOS 88
Figura 5.1.1: Pantalla inicial de la aplicacin. Primera pestaa.

de 16 versiones. En la tercera y ultima parte se ajustan los parmetros para la
ejecucin del algoritmo de LDA el cual har la extraccin de los tpicos.
En la segunda pestaa 5.1.2 encontramos dos grficos. El grfico cicular
permite observar el porcentaje de componentes que contiene el conjunto de datos. La etiqueta Sin componente son aquellos bugs en donde no se especifico
ningun tipo de componente en ese campo. En el grfico anterior se muestra la
cantidad de bugs abiertos, bugs cerrados y comentarios en cada versin. Adems
se permite la navegacin de cada documento, bug y versin con todos sus atributos. En este punto es necesario aclarar que cuando se esta ejecutando el parsing
sobre el conjunto de datos el grfico de torta es constantemente actualizado. El
otro grfico es actualizado si se crearon las versiones antes del parsing.
Figura 5.1.2: Segunda pestaa.

En la 5.1.3 se tiene una vista de los datos de cada tpico seleccionado. La
primera tabla muestra los trminos que componen al tpico, en la segunda tabla estan las probabilidades de cada trmino para el tpico seleccionado y en
la tercera tabla se muestra la probabilidad asociada de ese tpico en cada documento. Cuando se selecciona un tpico de la lista automticamente se cargan
los datos de las otras dos trablas mencionadas anteriormente con la informacin
relacionada al tpico. Las columnas de las tablas pueden ordenarse de forma
creciente o decreciente para permitir una rpida bsqueda sobre algun dato en
particular.
Figura 5.1.3: Tercera pestaa.

En la figura 5.1.4 es la pestaa en donde se muestran las evoluciones de los
tpicos para una determinada mtrica (por ejemplo, assignment, weight, focus y
scattering) a lo largo de las versiones. En este caso en particular es la evolucin
de la mtrica weight para los tpicos Z27 yZ29 . Se debe aclarar que los tiempos
de refresco de las mtricas son un poco altos dado que se calculan de acuerdo
a los tpicos seleccionados. Tambin se incluye la posibilidad de mostrar las
etiquetas (figura 5.1.4a) o de ocultarlas para una mejor visualizacin (figura
5.1.4b). La librera grfica empleada fue JFreeChart1 . Es una librera para el
lenguaje de programacin Java2 con licencia LGPL3 y permite la creacin de
los grficos de una manera muy sencilla.
1 http://www.jfree.org/jfreechart/
2 http://www.oracle.com/technetwork/java/index.html
3 http://www.gnu.org/licenses/lgpl.html
(a) Ejemplo de la mtrica weight para el tpico Z27 y Z29 exhibiendo las etiquetas.
(b) Ejemplo de la mtrica weight para el tpico Z27 y Z29 ocultando las etiquetas.
Figura 5.1.4: Cuarta pestaa.

Por ltimo en la ultima pestaa 5.1.5 se encuentra lo relacionado con el uso
del ndice. Aqu primero se debe seleccionar el directorio en donde se encuentra
el ndice si ya existe o bien elegir el directorio en donde crearlo. Para ello permite
la seleccin de cuatro tipo de analizadores. En caso de existir previamente el
ndice en el directorio seleccionado se aplica la modalidad incremental. Luego
de encontrarse el ndice correctamente localizado se podrn realizar consultas
sobre los documentos indexados. Hay 5 tipos de consultas que se pueden realizar.
Luego a los resultados de las mismas se les puede poner un lmite de la cantidad
de items obtenidos y adems agrupados de acuerdo al algoritmo de clustering
seleccionado (por ejemplo, K-Means, Suffix Tree Clustering, Lingo y Synthetic).
Figura 5.1.5: Quinta pestaa.
5.2.
Arquitectura
Para mejorar la reutilizacin, extensibilidad, flexibilidad de los elementos de

las aplicacin se aplic el patrn Model View Controller (MVC). La estructura
del sistema desarrollado cuenta con varios mdulos. Uno de los mdulos mas
relevantes para el desarrollado es el de los algoritmos contemplados.
En la figura 5.2.1 se puede observar el diagrama de clases que modela los
algoritmos empleados. La clase AlgorithmManager es la clase encargada de ejecutar las funciones de parsing, generacin de los documentos, generacin de la
versiones, la ejecucin del algoritmo LDA y del algoritmo de clustering empleado en las bsquedas sobre el ndice. Esta clase sigue el patrn Singleton para
tener una nica instancia. As como la aplicacin del patrn llamado Facade. Las
dems clases como SampleLDAGibbs, GenDocs, GenVersions, Parser y Cluster
son llamadas por AlgorithmManager de acuerdo al tipo de funcin que se desea
ejecutar. Esta clase se encarga de otorgarle los datos necesarios al resto para
que puedan llevar a cabo su funcin. De igual manera existe solo una instancia
de cada una de ellas para de esta manera garantizar un punto de acceso global
a cada una de ellas.
Figura 5.2.1: Diagrama de clases de los algoritmos utilizados.

La ejecucin de cada una de las funciones de las clases mencionadas se hacen
por medio de un thread dado que cada una de ellas implementan la interface
Runnable. Hay que tener en cuenta que la ejecucin de cada una de las funcionalidades de las clases suelen tener un tiempo de ejecucin elevado cuando
se procesan muchos datos dado que se accede a la base de datos tanto para la
lectura de los mismos como para la persistencia de los resultados. La ejecucin
del algoritmo de LDA variante Gibbs extrae el texto de los documentos desde la base de datos y los procesa en memoria. Luego que este finaliza persiste
los datos del modelo de tpicos en la base de datos. Cada ejecucin borra los
datos de las ejecuciones anteriores en la base de datos. La clase encargada de
ejecutar el algoritmo de clustering maneja los siguientes tipos de algoritmos: KMeans, Lingo, Suffix Tree Clustering y Synthetic. Estos algoritmos son alicados

mediante la librera Open Source llamada Carrot24 .
Otro mdulo relevante es el de la figura 5.2.2 que contiene las clases encargadas de realizar la creacin del ndice y tambin de realizar las bsquedas
sobre el mismo. La salida del resultado obtenido de una bsqueda es tomada y
se le aplica uno de los algoritmos de clustering ya mencionados. Aqu la lgica
de diseo empleada es similar dada la aplicacin del patrn Facade permitiendo
as estructurar y simplificar la interaccin con los subsistemas de Lucene como
son el indexador y el buscador.
Figura 5.2.2: Diagrama de clases del mdulo lucene.

Como se observa en las figuras 5.2.3 y en 5.2.4 el objetivo fue encapsular
todos los accesos a la base de datos para que sea lo ms independiente del tipo
de base de datos empleada. Para ello se aplicaron dos patrones relacionados
con la persistencia como son los patrones Data Transfer Object (DTO) y Data
Access Object (DAO). La utilizacin de la clase DAOManager es para delimitar
el mbito de la conexin y transacciones que se filtran de la capa de DAO.
Por ejemplo la accin de aplicar algn esquema, borrar ciertas tablas y brindar
una interfaz para obtener cualquier DAO que se requiera para obtener datos
en particular desde cualquier lugar de la aplicacin. Adicionalmente la clase
4 http://project.carrot2.org/

DAOManager tiene gran parte del manejo de excepciones propias de la lgica
de la aplicacin que se repiten en cada DAO en particular.
En la figura 5.2.4 se puede observar cuales son los DTO que contienen slo
los datos que se se transfieren a lo largo en la aplicacin entre los procesos.
Figura 5.2.3: Diagrama de clases del mdulo DAO.
Figura 5.2.4: Diagrama de clases del mdulo DTO.

En la figura 5.2.5 se puede observar que las mtricas fueron implementadas
empleando el patrn Command. De esta manera cada mtrica implementa su
resultado de acuerdo a su funcin. El mtodo getResult posee dos parmetros
que son del tipo VersionDTO y TopicDTO. Es decir que devuelve el resultado
del valor de esa mtrica dentro de una versin para un determinado tpico.
Figura 5.2.5: Diagrama de clases del mdulo de las mtricas.
5.3.
Conclusin
En este captulo se ha presentado la aplicacin utilizada para llevar a cabo la

extraccin de los tpicos y el clculo de mtricas. Con respecto a la arquitectura
esta contiene bsicamente cinco mdulos destacados en el sistema. El primero de
ellos es el que contiene los algortmos esenciales de la aplicacin, principalmente
el algortmo que aplica LDA. El segundo es aquel que se encarga de la creacin
del ndice y de las bsquedas sobre el mismo empleando como motor Lucene.
El tercero y cuarto de los mdulos son los correspondientes a modelar una capa
DAO sobre la base de datos y los DTO correspondientes a los elementos de
transferencia. El quinto mdulo, es aqul que contiene todas las clases necesarias
para llevar a cabo las mtricas y obtener los resultados principales sobre el
conjunto de datos de prueba utilizado.
Captulo 6
Conclusin
En el campo de la minera de repositorios de software se utilizan datos fcilmente accesibles para aumentar la productividad de los desarrolladores y reducir
los costos de los proyectos. Usando todas las fuentes de datos disponibles, tanto la fuentes estructuradas como las no estructuradas, permiten mximizar los
beneficios.
En este trabajo se ha mostrado como se puede realizar un anlisis de alto
nivel de un repositorio de software con datos no estructurados. Con el fin extraer informacin de alto nivel (tpicos) y analizar su evolucin a travs de las
versiones definidas.
La eleccin de los modelos de tpicos, como LDA o LSI y sus repectivas
variantes no ha sido fcil dado que se tuvo que optar entre complijdad temporal
o espacial sin tener un conocimiento exacto de cada una de las mismas. Aqu se
priorizo elegir la variante Gibbs para la extraccin de los tpicos dado que la
complejidad de su implementacin fue relativamente sencilla pero eficaz.
En cuanto a la eleccin del modelo de evolucin adoptado se opt por el
modelo de Hall puesto este requiere menos procesamiento como si sucede con
el modelo Link en el cual despus se deben vincular los tpicos a travs de
las versiones. Adems, en muchos trabajos se adopt el modelo de Hall puesto
que la precisin para el anlisis evolutivo de los tpicos ha presentado mejores
resultados con respecto a otros.
Dotar a los sistemas de recuperacin de la informacin constituye un importante campo de investigacin actualmente en el mbito de mercados en red
con grandes volmenes de datos, juntando profesionales de diversas reas, las
mineras de datos en las tareas de la ingeniera de software y la inteligencia
artificial.
La mayora de estos sistemas de extraccin de la informacin requieren por
parte del usuario tener una nocin del conjunto de datos para ajustar los par99
CAPTULO 6. CONCLUSIN
100
metros requeridos por parte de los modelos involucrados en el proceso. Principalmente debido a que la informacin obtenida puede variar drsticamente.
6.1.
Contribucin
En este trabajo se present una herramienta para extraer y examinar tpicos

sobre el conjunto de datos del sistema de gestin de incidencias (issue tracker)
del sistema operativo Android1 . Se mostraron las tendencias para algunos tpicos relacionados con bugs que poseen trminos mas especficos, especialmente
aquellos tpicos con una varianza estadstica superior al 40 % en sus probabilidades sobre todas las versiones generadas. Esto permiti realizar una inspeccin
sobre algunos bugs (issues) especficos relacionados con el SDK, las versiones de
Android para los modelos de celulares de marca HTC, con la aplicacin Market,
etc. Tambin se encontr que los tpicos evolucionan debido a la gran cantidad
de actividad de cambios subyacente, incluyendo arreglo de bugs, refactoring y
adicin de nuevas funcionalidades. Algunos tpicos contienen trminos muy generales con lo cual es difcil ser mas concreto con las causas de los cambios que
le ocurren en determinadas versiones. Igualmente, puede ser til para ver la
actividad de tpicos mas concretos constranstando una mtrica mas general.
Se observo que las mtricas cambian de manera similar con respecto a las
actividades que se suceden en el repositorio del conjunto de datos. De esta manera se puede afirmar que el modelo de tpicos aplicado es una tcnica efectiva
para descubrir temas y que tambin permite resumir cambios en las actividades
del desarrollo de software.
La herramienta implementada es de utilidad para apoyar a los usuarios en el
anlisis de estos repositorios de software. Tambin se ha mostrado como avanzar
desde el estado del arte usando modelos de la IR para realizar minera en repositorios de software no estructurado hacia la aplicacin de nuevos paradigmas
en tareas de la ingeniera de software; tratando de entender los parmetros y los
supuestos que encierran las nuevas tcnicas.
6.2.
Trabajos futuros
Existen diversas lneas de trabajo en las cuales ahondar. Una de ellas sera
profundizar algunas tareas de la ingeniera de software como la prediccin de
bugs, la bsquedas de colecciones de sistemas de software y medir las tendencias
evolutivas de repositorios an no explorados.
Otra lnea de trabajo sera la bsqueda de trazabilidades, como por ejemplo
1 https://code.google.com/p/android
CAPTULO 6. CONCLUSIN
101
la ya explorada entre requerimientos y cdigo fuente. Podra realizarse entre

correos electrnicos y cdigo fuente, con documentos de cdigo fuente.
Otro tipo de trabajo podra ser la de generar modelos adicionales para la
recuperacin de la informacin, tratando de mejorar algunos como es el caso de
la mejora de Gibbs introducida por (Xiao & Stibor, 2010) en el que mejoran la
estrategia de muestreo de manera significativa.
En el captulo 3 se mencionaron los pasos mas empleados de pre-procesamiento
de los documentos: desglose de trminos, remocin de stop words y la reduccin
de palabras por medio de la tcnica de stemming. Un paso que actualmente no
es tan popular, pero que tambin podra brindar beneficios, es la expansin de
consultas (Carpineto & Romano, 2012), por ejemplo, para arreglar errores de
ortografa, bsqueda de sinnimos, etc. La expasin de consultas, puede ser aplicado a la localizacin de bugs en los conjuntos de datos para reducir el ruido en
los reportes de bugs y tambin para expandir reportes escuetos o muy pequeos
para proveer mas contexto.
Bibliografa
Ahsan, Syed Nadeem, Ferzund, Javed, & Wotawa, Franz. 2009. Automatic software bug triage system (bts) based on latent semantic indexing and support
vector machine. Pages 216221 of: Software engineering advances, 2009. icsea09. fourth international conference on. IEEE. 55
Android. 2010.
Android 2.3 platform an updated sdk tools, android deve-
lopers blog. http://android-developers.blogspot.com.ar/2010/12/android-23platform-and-updated-sdk.html. 71

Android.
2012.
Android
open
source
issue
tracker.
http://code.google.com/p/android/issues/list. 59
Andrzejewski, David, Mulhern, Anne, Liblit, Ben, & Zhu, Xiaojin. 2007. Statistical debugging using latent topic models. Pages 617 of: Machine learning:
Ecml 2007. Springer. 52
Anthes, Gary. 2010. Topic models vs. unstructured data. Communications of
the acm, 53(12), 1618. 27
Antoniol, Giuliano, Hayes, Jane Huffman, Gueheneuc, Y, & Di Penta, Massimiliano. 2008. Reuse or rewrite: Combining textual, static, and dynamic
analyses to assess the cost of keeping a system up-to-date. Pages 147156
of: Software maintenance, 2008. icsm 2008. ieee international conference on.
IEEE. 49
Asuncion, Hazeline U, Asuncion, Arthur U, & Taylor, Richard N. 2010. Software
traceability with topic modeling. Pages 95104 of: Proceedings of the 32nd
acm/ieee international conference on software engineering-volume 1. ACM.
50
Baeza-Yates, Ricardo, Ribeiro-Neto, Berthier, et al. 1999. Modern information
retrieval. Vol. 463. ACM press New York. 36
103
BIBLIOGRAFA
104
Bajracharya, Sushil, & Lopes, Cristina. 2009. Mining search topics from a code
search engine usage log. Pages 111120 of: Mining software repositories, 2009.
msr09. 6th ieee international working conference on. IEEE. 56
Bajracharya, Sushil Krishna, & Lopes, Cristina Videira. 2012. Analyzing and
mining a code search engine usage log. Empirical software engineering, 17(45), 424466. 56
Baldi, Pierre F, Lopes, Cristina V, Linstead, Erik J, & Bajracharya, Sushil K.
2008. A theory of aspects as latent topics. Pages 543562 of: Acm sigplan
notices, vol. 43. ACM. 46, 71, 72
Bavota, Gabriele, De Lucia, Andrea, Marcus, Andrian, & Oliveto, Rocco. 2010.
A two-step technique for extract class refactoring. Pages 151154 of: Proceedings of the ieee/acm international conference on automated software engineering. ACM. 51
Bellon, Stefan, Koschke, Rainer, Antoniol, Giuliano, Krinke, Jens, & Merlo,
Ettore. 2007. Comparison and evaluation of clone detection tools. Software
engineering, ieee transactions on, 33(9), 577591. 55
Bettenburg, Nicolas, Shihab, Emad, & Hassan, Ahmed E. 2009. An empirical
study on the risks of using off-the-shelf techniques for processing mailing
list data. Pages 539542 of: Software maintenance, 2009. icsm 2009. ieee
international conference on. IEEE. 29
Blei, David M, & Lafferty, John D. 2006. Dynamic topic models. Pages 113
120 of: Proceedings of the 23rd international conference on machine learning.
ACM. 43
Blei, David M, Ng, Andrew Y, & Jordan, Michael I. 2003. Latent dirichlet
allocation. the journal of machine learning research, 3, 9931022. 16, 17, 31,
37, 57
Capobianco, Giovanni, De Lucia, Andrea, Oliveto, Rocco, Panichella, Annibale, & Panichella, Sebastiano. 2009. Traceability recovery using numerical
analysis. Pages 195204 of: Reverse engineering, 2009. wcre09. 16th working
conference on. IEEE. 50
Carpineto, Claudio, & Romano, Giovanni. 2012. A survey of automatic query
expansion in information retrieval. Acm computing surveys (csur), 44(1), 1.
101
Casella, George, & George, Edward I. 1992. Explaining the gibbs sampler. The
american statistician, 46(3), 167174. 67
BIBLIOGRAFA
105
Chaudhuri, Surajit, & Dayal, Umeshwar. 1997. An overview of data warehousing

and olap technology. Acm sigmod record, 26(1), 6574. 25
Cleary, Brendan, Exton, Chris, Buckley, Jim, & English, Michael. 2009. An
empirical analysis of information retrieval based concept location techniques
in software comprehension. Empirical software engineering, 14(1), 93130.
45
Comon, Pierre. 1994. Independent component analysis, a new concept? Signal
processing, 36(3), 287314. 36
Dallmeier, Valentin, & Zimmermann, Thomas. 2007. Extraction of bug localization benchmarks from history. Pages 433436 of: Proceedings of the twentysecond ieee/acm international conference on automated software engineering.
ACM. 50
De Boer, Remco C, & van Vliet, Hans. 2008. Architectural knowledge discovery with latent semantic analysis: Constructing a reading guide for software
product audits. Journal of systems and software, 81(9), 14561469. 48
De Lucia, Andrea, Fasano, Fausto, Oliveto, Rocco, & Tortora, Genoveffa. 2004.
Enhancing an artefact management system with traceability recovery features. Pages 306315 of: Software maintenance, 2004. proceedings. 20th ieee
De Lucia, Andrea, Fasano, Fausto, Oliveto, Rocco, & Tortora, Genoveffa. 2006.
Can information retrieval techniques effectively support traceability link recovery? Pages 307316 of: Program comprehension, 2006. icpc 2006. 14th
ieee international conference on. IEEE. 47
Deerwester, Scott C., Dumais, Susan T, Landauer, Thomas K., Furnas, George W., & Harshman, Richard A. 1990. Indexing by latent semantic analysis.
Jasis, 41(6), 391407. 35
Dit, Bogdan, Poshyvanyk, Denys, & Marcus, Andrian. 2008. Measuring the
semantic similarity of comments in bug reports. Proc. of 1st stsm, 8. 56
Fayyad, Usama, Piatetsky-Shapiro, Gregory, & Smyth, Padhraic. 1996. From
data mining to knowledge discovery in databases. Ai magazine, 17(3), 37. 21,
23, 24
Flix, Molina, & Carlos, Luis. 2002. Data mining: torturando a los datos hasta
que confiesen. Coordinador del programa de data mining. 24
Foundation,
Mozilla.
2010.
http://www.bugzilla.org/. 29
The
bugzilla
guide-3.6
release.
BIBLIOGRAFA
106
Fowler, Martin. 2004. Uml distilled: a brief guide to the standard object modeling
language. Addison-Wesley Professional. 30
Gall, CS, Lukins, S, Etzkorn, L, Gholston, Sampson, Farrington, P, Utley, D,
Fortune, Julie, & Virani, Shamsnaz. 2008. Semantic software metrics computed from natural language design specifications. Software, iet, 2(1), 1726.
51
Geeknet. 2010. Sourceforge. 31
Gethers, Malcom, & Poshyvanyk, Denys. 2010. Using relational topic models
to capture coupling among classes in object-oriented software systems. Pages
110 of: Software maintenance (icsm), 2010 ieee international conference on.
IEEE. 52
Godfrey, Michael W, Hassan, Ahmed E, Herbsleb, James, Murphy, Gail C, Robillard, Martin, Devanbu, Prem, Mockus, Audris, Perry, Dewayne E, & Notkin,
David. 2009. Future of mining software archives: A roundtable. Software,
ieee, 26(1), 6770. 15, 27
Google. 2012. Google code. 31
Grant, Scott, & Cordy, James R. 2009. Vector space analysis of software clones.
Pages 233237 of: Program comprehension, 2009. icpc09. ieee 17th international conference on. IEEE. 36, 55
Grant, Scott, & Cordy, James R. 2010. Estimating the optimal number of latent
concepts in source code analysis. Pages 6574 of: Source code analysis and
manipulation (scam), 2010 10th ieee working conference on. IEEE. 56
Grant, Scott, Cordy, James R, & Skillicorn, David. 2008. Automated concept
location using independent component analysis. Pages 138142 of: Reverse
engineering, 2008. wcre08. 15th working conference on. IEEE. 45
Hall, David, Jurafsky, Daniel, & Manning, Christopher D. 2008. Studying the
history of ideas using topic models. Pages 363371 of: Proceedings of the
conference on empirical methods in natural language processing. Association
for Computational Linguistics. 43
Hall, Tracy, Beecham, Sarah, Bowes, David, Gray, David, & Counsell, Steve.
2011. A systematic review of fault prediction performance in software engineering. 14
Hassan, Ahmed E. 2006. Mining software repositories to assist developers and
support managers. Pages 339342 of: Software maintenance, 2006. icsm06.
22nd ieee international conference on. IEEE. 15, 27
BIBLIOGRAFA
107
Hassan, Ahmed E, & Holt, Richard C. 2005. The top ten list: Dynamic fault prediction. Pages 263272 of: Software maintenance, 2005. icsm05. proceedings
of the 21st ieee international conference on. IEEE. 15, 27
Hayes, Jane Huffman, Dekhtyar, Alex, & Sundaram, Senthil Karthikeyan. 2006.
Advancing candidate link generation for requirements tracing: The study of
methods. Software engineering, ieee transactions on, 32(1), 419. 48
Hindle, Abram, Godfrey, Michael W, & Holt, Richard C. 2009a. Whats hot and
whats not: Windowed developer topic analysis. Pages 339348 of: Software
maintenance, 2009. icsm 2009. ieee international conference on. IEEE. 43,
53
Hindle, Abram, Godfrey, Michael W, & Holt, Richard C. 2009b. Windowed
developer topic analysis. 16
Hindle, Abram, Godfrey, Michael W, & Holt, Richard C. 2010. Software process recovery using recovered unified process views. Pages 110 of: Software
maintenance (icsm), 2010 ieee international conference on. IEEE. 16, 53
Hofmann, Thomas. 1999a. Probabilistic latent semantic analysis. Pages 289296
of: Proceedings of the fifteenth conference on uncertainty in artificial intelligence. Morgan Kaufmann Publishers Inc. 36
Hofmann, Thomas. 1999b. Probabilistic latent semantic indexing. Pages 50
57 of: Proceedings of the 22nd annual international acm sigir conference on
research and development in information retrieval. ACM. 37
Hofmann, Thomas. 2001. Unsupervised learning by probabilistic latent semantic
analysis. Machine learning, 42(1-2), 177196. 36
Jagadeesh Chandra Bose, RP, & Suresh, U. 2008. Root cause analysis using
sequence alignment and latent semantic indexing. Pages 367376 of: Software
engineering, 2008. aswec 2008. 19th australian conference on. IEEE. 52
Jiang, Hsin-Yi, Nguyen, Tien N, Chen, Xiang, Jaygarl, Hojun, & Chang, Carl K.
2008. Incremental latent semantic indexing for automatic traceability link
evolution management. Pages 5968 of: Proceedings of the 2008 23rd ieee/acm
international conference on automated software engineering. IEEE Computer
Society. 48
Kagdi, Huzefa, Gethers, Malcom, Poshyvanyk, Denys, & Collard, Michael L.
2010. Blending conceptual and evolutionary couplings to support change
impact analysis in source code. Pages 119128 of: Reverse engineering (wcre),
2010 17th working conference on. IEEE. 51
BIBLIOGRAFA
108
Kamei, Yasutaka, Matsumoto, Shinsuke, Monden, Akito, Matsumoto, K-i,

Adams, Bram, & Hassan, Ahmed E. 2010. Revisiting common bug prediction findings using effort-aware models. Pages 110 of: Software maintenance
(icsm), 2010 ieee international conference on. IEEE. 50
Kan, Stephen H. 2002. Metrics and models in software quality engineering (2nd
edition). Addison-Wesley Professional. 14
Kawaguchi, Shinji, Garg, Pankaj K, Matsushita, Makoto, & Inoue, Katsuro.
2006. Mudablue: An automatic categorization system for open source repositories. Journal of systems and software, 79(7), 939953. 54
Kuhn, Adrian, Ducasse, Stphane, & Girba, Tudor. 2005. Enriching reverse
engineering with semantic clustering. Pages 10pp of: Reverse engineering,
12th working conference on. IEEE. 53, 54
Kuhn, Adrian, Ducasse, Stphane, & Grba, Tudor. 2007. Semantic clustering:
Identifying topics in source code. Information and software technology, 49(3),
230243. 53, 54
Kuhn, Adrian, Loretan, Peter, & Nierstrasz, Oscar. 2008. Consistent layout
for thematic software maps. Pages 209218 of: Reverse engineering, 2008.
wcre08. 15th working conference on. IEEE. 54
Kuhn, Adrian, Erni, David, Loretan, Peter, & Nierstrasz, Oscar. 2010. Software
cartography: Thematic software visualization with consistent layout. Journal
of software maintenance and evolution: Research and practice, 22(3), 191
210. 54
Lehman, Meir M. 1980. Programs, life cycles, and laws of software evolution.
Proceedings of the ieee, 68(9), 10601076. 16, 52
Lethbridge, Timothy C, & Laganiere, Robert. 2001. Object-oriented software
engineering. Mcgrawhill education. 28, 30
Lin, M-YJ, Amor, Robert, & Tempero, Ewan. 2006. A java reuse repository
for eclipse using lsi. Pages 10pp of: Software engineering conference, 2006.
australian. IEEE. 54
Linstead, Erik, & Baldi, Pierre. 2009. Mining the coherence of gnome bug reports
with statistical topic models. Pages 99102 of: Mining software repositories,
2009. msr09. 6th ieee international working conference on. IEEE. 51
Linstead, Erik, Rigor, Paul, Bajracharya, Sushil, Lopes, Cristina, & Baldi, Pierre. 2007a. Mining concepts from code with probabilistic topic models. Pages
BIBLIOGRAFA
109
461464 of: Proceedings of the twenty-second ieee/acm international conference on automated software engineering. ACM. 46
Linstead, Erik, Rigor, Paul, Bajracharya, Sushil, Lopes, Cristina, & Baldi, Pierre. 2007b. Mining eclipse developer contributions via author-topic models.
Pages 3030 of: Mining software repositories, 2007. icse workshops msr07.
fourth international workshop on. IEEE. 46
Linstead, Erik, Lopes, Cristina, & Baldi, Pierre. 2008a. An application of latent
dirichlet allocation to analyzing software evolution. Pages 813818 of: Machine learning and applications, 2008. icmla08. seventh international conference
on. IEEE. 15, 16, 31, 43, 53, 69
Linstead, Erik, Rigor, Paul, Bajracharya, Sushil, Lopes, Cristina, & Baldi, Pierre F. 2008b. Mining internet-scale software repositories. Pages 929936 of:
Advances in neural information processing systems. 54
Linstead, Erik, Bajracharya, Sushil, Ngo, Trung, Rigor, Paul, Lopes, Cristina,
& Baldi, Pierre. 2009. Sourcerer: mining and searching internet-scale software
repositories. Data mining and knowledge discovery, 18(2), 300336. 54
Liu, Dong C, & Nocedal, Jorge. 1989. On the limited memory bfgs method for
large scale optimization. Mathematical programming, 45(1-3), 503528. 63
Liu, Yixun, Poshyvanyk, Denys, Ferenc, Rudolf, Gyimthy, Tibor, & Chrisochoides, Nikos. 2009. Modeling class cohesion as mixtures of latent topics.
Pages 233242 of: Software maintenance, 2009. icsm 2009. ieee international
conference on. IEEE. 14, 15, 31, 51
Lormans, Marco. 2007. Monitoring requirements evolution using views. Pages
349352 of: Software maintenance and reengineering, 2007. csmr07. 11th
european conference on. IEEE. 48
Lormans, Marco, & Van Deursen, Arie. 2006. Can lsi help reconstructing requirements traceability in design and test? Pages 10pp of: Software maintenance and reengineering, 2006. csmr 2006. proceedings of the 10th european
Lormans, Marco, Gross, H-G, van Deursen, Arie, van Solingen, Rini, & Stehouwer, Andr. 2006. Monitoring requirements coverage using reconstructed
views: An industrial case study. Pages 275284 of: Reverse engineering, 2006.
wcre06. 13th working conference on. IEEE. 48
Lucia, Andrea De, Fasano, Fausto, Oliveto, Rocco, & Tortora, Genoveffa. 2007.
Recovering traceability links in software artifact management systems using
BIBLIOGRAFA
110
information retrieval methods. Acm transactions on software engineering and

methodology (tosem), 16(4), 13. 48
Lukins, Stacy K, Kraft, Nicholas A, & Etzkorn, Letha H. 2008. Source code
retrieval for bug localization using latent dirichlet allocation. Pages 155164
of: Reverse engineering, 2008. wcre08. 15th working conference on. IEEE.
49
Lukins, Stacy K, Kraft, Nicholas A, & Etzkorn, Letha H. 2010. Bug localization
using latent dirichlet allocation. Information and software technology, 52(9),
972990. 49
Maletic, Jonathan I, & Marcus, Andrian. 2001. Supporting program comprehension using semantic and structural information. Pages 103112 of: Proceedings
of the 23rd international conference on software engineering. IEEE Computer
Society. 53, 54
Maletic, Jonathan I, & Valluri, Naveen. 1999. Automatic software clustering via
latent semantic analysis. Pages 251254 of: Automated software engineering,
1999. 14th ieee international conference on. IEEE. 53
Marcus, Andrian, & Maletic, Jonathan I. 2001. Identification of high-level concept clones in source code. Pages 107114 of: Automated software engineering,
2001.(ase 2001). proceedings. 16th annual international conference on. IEEE.
55
Marcus, Andrian, & Maletic, Jonathan I. 2003. Recovering documentation-tosource-code traceability links using latent semantic indexing. Pages 125135
of: Software engineering, 2003. proceedings. 25th international conference on.
IEEE. 47
Marcus, Andrian, Sergeyev, Andrey, Rajlich, Vaclav, & Maletic, Jonathan I.
2004. An information retrieval approach to concept location in source code. Pages 214223 of: Reverse engineering, 2004. proceedings. 11th working
Marcus, Andrian, Rajlich, Vaclav, Buchta, Joseph, Petrenko, Maksym, & Sergeyev, Andrey. 2005. Static techniques for concept location in object-oriented
code. Pages 3342 of: Program comprehension, 2005. iwpc 2005. proceedings.
13th international workshop on. IEEE. 45
Marcus, Andrian, Poshyvanyk, Denys, & Ferenc, Rudolf. 2008. Using the conceptual cohesion of classes for fault prediction in object-oriented systems.
Software engineering, ieee transactions on, 34(2), 287300. 51
BIBLIOGRAFA
111
Maskeri, Girish, Sarkar, Santonu, & Heafield, Kenneth. 2008. Mining business
topics in source code using latent dirichlet allocation. Pages 113120 of:
Proceedings of the 1st india software engineering conference. ACM. 15, 31,
46
McCallum, Andrew K. 2002. {MALLET: A Machine Learning for Language
Toolkit}. 63
McMillan, Collin, Poshyvanyk, Denys, & Revelle, Meghan. 2009. Combining
textual and structural analysis of software artifacts for traceability link recovery. Pages 4148 of: Traceability in emerging forms of software engineering,
2009. tefse09. icse workshop on. IEEE. 49
Mei, Qiaozhu, & Zhai, ChengXiang. 2005. Discovering evolutionary theme patterns from text: an exploration of temporal text mining. Pages 198207 of:
Proceedings of the eleventh acm sigkdd international conference on knowledge
discovery in data mining. ACM. 43
Neuhaus, Stephan, & Zimmermann, Thomas. 2010. Security trend analysis with
cve topic models. Pages 111120 of: Software reliability engineering (issre),
2010 ieee 21st international symposium on. IEEE. 17, 29, 53
Nguyen, Anh Tuan, Nguyen, Tung Thanh, Al-Kofahi, Jafar, Nguyen, Hung Viet,
& Nguyen, Tien N. 2011a. A topic-based approach for narrowing the search
space of buggy files from a bug report. Pages 263272 of: Automated software
engineering (ase), 2011 26th ieee/acm international conference on. IEEE. 49
Nguyen, Thanh HD, Adams, Bram, & Hassan, Ahmed E. 2010. A case study
of bias in bug-fix datasets. Pages 259268 of: Wcre, vol. 10. 50
Nguyen, Tung Thanh, Nguyen, Tien N, & Phuong, Tu Minh. 2011b. Topicbased defect prediction: Nier track. Pages 932935 of: Software engineering
(icse), 2011 33rd international conference on. IEEE. 15, 31
Oliveto, Rocco, Gethers, Malcom, Poshyvanyk, Denys, & De Lucia, Andrea.
2010. On the equivalence of information retrieval methods for automated
traceability link recovery. Pages 6871 of: Program comprehension (icpc),
2010 ieee 18th international conference on. IEEE. 50
Orallo, Jos Hernndez, Quintana, Ma Jos Ramrez, & Ramrez, Csar Ferri.
2000. Extraccin automtica de conocimiento en bases de datos e ingeniera
del software. 24
Porter, Martin F. 1980. An algorithm for suffix stripping. Program, 14(3),
130137. 69
BIBLIOGRAFA
112
Poshyvanyk, Denys, & Grechanik, Mark. 2009. Creating and evolving software
by searching, selecting and synthesizing relevant source code. Pages 283286
of: Software engineering-companion volume, 2009. icse-companion 2009. 31st
Poshyvanyk, Denys, & Marcus, Andrian. 2007. Combining formal concept analysis with information retrieval for concept location in source code. Pages 3748
of: Program comprehension, 2007. icpc07. 15th ieee international conference
on. IEEE. 45
Poshyvanyk, Denys, Gueheneuc, Y-G, Marcus, Andrian, Antoniol, Giuliano, &
Rajlich, Vclav. 2006. Combining probabilistic ranking and latent semantic
indexing for feature identification. Pages 137148 of: Program comprehension,
2006. icpc 2006. 14th ieee international conference on. IEEE. 45
Rahman, Foyzur, Bird, Christian, & Devanbu, Premkumar. 2012. Clones: What
is that smell? Empirical software engineering, 17(4-5), 503530. 55
Rajlich, Vclav, & Wilde, Norman. 2002. The role of concepts in program comprehension. Pages 271278 of: Program comprehension, 2002. proceedings.
10th international workshop on. IEEE. 44
Rao, Shivani, & Kak, Avinash. 2011. Retrieval from software libraries for bug
localization: a comparative study of generic and composite text models. Pages 4352 of: Proceedings of the 8th working conference on mining software
repositories. ACM. 49
Revelle, Meghan, & Poshyvanyk, Denys. 2009. An exploratory study on assessing
feature location techniques. Pages 218222 of: Program comprehension, 2009.
icpc09. ieee 17th international conference on. IEEE. 46
Revelle, Meghan, Dit, Bogdan, & Poshyvanyk, Denys. 2010. Using data fusion
and web mining to support feature location in software. Pages 1423 of:
Program comprehension (icpc), 2010 ieee 18th international conference on.
IEEE. 46
Robillard, Martin P, & Murphy, Gail C. 2007. Representing concerns in source
code. Acm transactions on software engineering and methodology (tosem),
16(1), 3. 14
Rosen-Zvi, Michal, Griffiths, Thomas, Steyvers, Mark, & Smyth, Padhraic. 2004.
The author-topic model for authors and documents. Pages 487494 of: Proceedings of the 20th conference on uncertainty in artificial intelligence. AUAI
Press. 46
BIBLIOGRAFA
113
Roy, Chanchal K, Cordy, James R, & Koschke, Rainer. 2009. Comparison and
evaluation of code clone detection techniques and tools: A qualitative approach. Science of computer programming, 74(7), 470495. 55
Salton, Gerard, & McGill, Michael J. 1983. Introduction to modern information
retrieval. 36
Salton, Gerard, Wong, Anita, & Yang, Chung-Shu. 1975. A vector space model
for automatic indexing. Communications of the acm, 18(11), 613620. 35
Savage, Trevor, Dit, Bogdan, Gethers, Malcom, & Poshyvanyk, Denys. 2010. Topic xp: Exploring topics in source code using latent dirichlet allocation. Pages
16 of: Software maintenance (icsm), 2010 ieee international conference on.
IEEE. 47
Serrano, Nicolas, & Ciordia, Ismael. 2005. Bugzilla, itracker, and other bug
trackers. Software, ieee, 22(2), 1113. 29
Shannon, Claude Elwood. 2001. A mathematical theory of communication. Acm
sigmobile mobile computing and communications review, 5(1), 355. 72
Shihab, Emad, Jiang, Zhen Ming, & Hassan, Ahmed E. 2009a. On the use of irc
channels by developers of the gnome gtk+ open source project. In: Proceedings
of the 6th ieee working conference on mining software repositories, vol. 12. 29
Shihab, Emad, Jiang, Zhen Ming, & Hassan, Ahmed E. 2009b. Studying the use
of developer irc meetings in open source projects. Pages 147156 of: Software
maintenance, 2009. icsm 2009. ieee international conference on. IEEE. 29
Shihab, Emad, Bettenburg, Nicolas, Adams, Bram, & Hassan, Ahmed E. 2010a.
On the central role of mailing lists in open source projects: An exploratory
study. Pages 91103 of: New frontiers in artificial intelligence. Springer. 29
Shihab, Emad, Jiang, Zhen Ming, Ibrahim, Walid M, Adams, Bram, & Hassan,
Ahmed E. 2010b. Understanding the impact of code and process metrics on
post-release defects: a case study on the eclipse project. Page 4 of: Proceedings of the 2010 acm-ieee international symposium on empirical software
engineering and measurement. ACM. 50
Shihab, Emad, Kamei, Yasutaka, & Bhattacharya, Pamela. 2012. Mining challenge 2012: The android platform. Pages 112115 of: Mining software repositories (msr), 2012 9th ieee working conference on. IEEE. 17, 59, 67
Slaughter, Sandra A, Harter, Donald E, & Krishnan, Mayuram S. 1998. Evaluating the cost of software quality. Communications of the acm, 41(8), 6773.
14
BIBLIOGRAFA
114
Sofware, Edgewall. 2012. The trac project. http://trac.edgewall.org/. 29

Srivastava, Ashok N, & Sahami, Mehran. 2010. Text mining: classification,
clustering, and applications. CRC Press. 27
Steyvers, Mark, & Griffiths, Tom. 2007. Latent semantic analysis: A road to
meaning, chapter probabilistic topic models. Laurence erlbaum. 27
Thomas, Stephen W. 2011. Mining software repositories using topic models.
Pages 11381139 of: Proceedings of the 33rd international conference on software engineering. ACM. 44
Thomas, Stephen W. 2012 (February). Mining software repositories with topic
model. Technical Report 2012-586. School of Computing, Queens University,
Kingston, Ontario, Canada. Completed: December 2010. 32, 57
Thomas, Stephen W, Adams, Bram, Hassan, Ahmed E, & Blostein, Dorothea.
2010. Validating the use of topic models for software evolution. Pages 55
64 of: Source code analysis and manipulation (scam), 2010 10th ieee working
conference on. IEEE. 16, 43, 53, 70, 74
Thomas, Stephen W, Adams, Bram, Hassan, Ahmed E, & Blostein, Dorothea.
2012. Studying software evolution using topic models. Science of computer
programming. 15, 17, 31, 71, 72
Tian, Kai, Revelle, Meghan, & Poshyvanyk, Denys. 2009. Using latent dirichlet
allocation for automatic categorization of software. Pages 163166 of: Mining
software repositories, 2009. msr09. 6th ieee international working conference
on. IEEE. 54
Tichy, Walter. 2010. An interview with prof. andreas zeller: Mining your way
to software reliability. Ubiquity, 2010(November), 3. 15, 27, 28
jhzi, Bla, Ferenc, Rudolf, Poshyvanyk, Denys, & Gyimthy, Tibor. 2010.
New conceptual coupling and cohesion metrics for object-oriented systems.
Pages 3342 of: Source code analysis and manipulation (scam), 2010 10th
ieee working conference on. IEEE. 51
van der Spek, Pieter, Klusener, Steven, & van de Laar, Pierre. 2008. Towards recovering architectural concepts using latent semantic indexing. Pages 253257
of: Software maintenance and reengineering, 2008. csmr 2008. 12th european
Wallach, Hanna M, Murray, Iain, Salakhutdinov, Ruslan, & Mimno, David.
2009. Evaluation methods for topic models. Pages 11051112 of: Proceedings
of the 26th annual international conference on machine learning. ACM. 67
BIBLIOGRAFA
115
Wang, Xuerui, & McCallum, Andrew. 2006. Topics over time: a non-markov
continuous-time model of topical trends. Pages 424433 of: Proceedings of
the 12th acm sigkdd international conference on knowledge discovery and data
mining. ACM. 43
Weyuker, Elaine J. 1998. Testing component-based software: A cautionary tale.
Software, ieee, 15(5), 5459. 14
Wu, Chen, Chang, Elizabeth, & Aitken, Ashley. 2008. An empirical approach
for semantic web services discovery. Pages 412421 of: Software engineering,
2008. aswec 2008. 19th australian conference on. IEEE. 56
Xiao, Han, & Stibor, Thomas. 2010. Efficient collapsed gibbs sampling for latent
dirichlet allocation. Pages 6378 of: Acml. 101
Zawawy, Hamzeh, Kontogiannis, Kostas, & Mylopoulos, John. 2010. Log filtering and interpretation for root cause analysis. Pages 15 of: Icsm. 52
Zhai, ChengXiang. 2008. Statistical language models for information retrieval.
Synthesis lectures on human language technologies, 1(1), 1141. 27, 32
Zimmermann, Thomas, Zeller, Andreas, Weissgerber, Peter, & Diehl, Stephan.
2005. Mining version histories to guide software changes. Software engineering, ieee transactions on, 31(6), 429445. 15, 27, 28
Apndice A
Historial de versiones de
Android
Este apndice contiene las diferentes versiones de Android lanzadas con sus
respectivas caractersticas para el perodo de tiempo comtemplado en el anlisis
de este trabajo para poder cotejar los resultados obtenidos.
Versin 1.0 (Apple Pie): Lanzamiento el da 23 de septiembre de 2008. El
primer dispositivo Android, el HTC Dream, incorpor las siguientes caractersticas de Android 1.0. Incorpor las siguientes caractersticas:
Android Market, un programa con un mercado para la descarga y
actualizacin de aplicaciones.
Navegador Web para visualizar pginas webs en full HTML y XHTML
mltiples pginas mostradas como ventanas ("tarjetas").
Soporte Cmara sin embargo esta versin carece de la opcin de
cambiar la resolucin de la cmara, balance de blancos, calidad, etc.
Carpo de iconos de aplicaciones dentro de una simple carpeta en la
pantalla de inicio.16 Acceso a servidores de correo electrnico por
web, soporte POP3, IMAP4 y SMTP.14
Sincronizacin de Gmail con la aplicacin de Gmail.
Sincronizacin de Google Contacts aplicacin de personas.
Sincronizacin de Google Calendar con la aplicacin de calendario.
Google Maps con Latitude y Street View para ver mapas e imgenes por satlite, as como para encontrar negocios locales y obtener
direcciones de conduccin usando GPS
117
APNDICE A. HISTORIAL DE VERSIONES DE ANDROID
118
Google Sync, permite la administracin de la sincronizacin OTA de

Gmail, Personas, y Calendario Google Search, permite a los usuarios
buscar en Internet, en aplicaciones del telfono mvil, en contactos,
en calendario, etc.
Mensajera instantnea Google Talk.
Mensajera instantnea, mensajes de texto y MMS.
Reproductor de medios, habilitada administracin, importacin, y reproduccin de archivos multimedia sin embargo, esta versin carece
de soporte de vdeo y estreo por Bluetooth.
Las notificaciones aparecen en la barra de estado, con opciones para
configurar alertas por timbre, LED o vibracin.
Marcacin por voz permite marcar y llamar sin escribir nombre o
nmero.
Fondo de escritorio permite al usuario configurar una imagen de fondo
o una foto detrs de los iconos y widgets de la pantalla de inicio.
Reproductor de vdeo YouTube.
Otras aplicaciones incluyen: Alarma, Calculadora, Marcacin (telfono), Pantalla de inicio (launcher), Imgenes (Galera) y ajustes.
Soporte para Wi-Fi y Bluetooth.
Versin 1.1 (Banana Bread): Lanzamiento el da 9 de febrero de 2008. Fue
lanzada, inicialmente solo para el HTC Dream as que solo sirve para
este telefono. Android 1.1 fue conocido como "Petit Four" internamente,
aunque este nombre no se utiliz oficialmente. La actualizacin resolvi
fallos, cambio la API y agreg una serie de caractersticas:
Detalles y reseas disponibles cuando un usuario busca negocios en
los mapas.
Pantalla en llamada ms larga por defecto cuando estn en uso el
manos libres, adems la habilidad de mostrar/esconder el marcador.
Posibilidad de guardar archivos adjuntos en los mensajes.
Aadido soporte para marquesina en diseos de sistemas.
Versin 1.5 (Cupcake): Lanzamiento el da 30 de abril de 2009. La actualizacin de Android 1.5 Cupcake fue lanzada, basada en ncleo Linux 2.6.27.
La actualizacin incluye varias nuevas caractersticas y correcciones de
interfaz de usuario:
119
Soporte para teclados virtuales de terceros con prediccin de texto y

diccionario de usuarios para palabras personalizadas.
Soporte para Widgets - vistas de miniaturas de las aplicaciones que
pueden ser incrustadas en otras aplicaciones (tal como la pantalla
inicio) y recibir actualizaciones peridicas.
Grabacin y rep en formatos MPEG-4 y 3GP. Auto-sincronizacin y
soporte para Bluetooth estreo aadido (perfiles A2DP y AVRCP)
Caractersticas de Copiar y pegar agregadas al navegador web.
Fotos de los usuarios son mostradas para favoritos en los contactos.
Marcas de fecha/hora mostradas para eventos en registro de llamadas
y acceso con un toque a la tarjeta de un contacto desde un evento
del registro de llamadas.
Pantallas de transiciones animadas.
Agregada opcin de auto-rotacin.
Agregada la animacin de inicio por defecto actual.
Habilidad de subir vdeos a YouTube.
Habilidad de subir fotos a Picasa.
Versin 1.6 (Donut): Lanzamiento el da 15 de septiembre de 2009. Fue lanzado el SDK de Android 1.6 Donut, basado en el ncleo Linux 2.6.29. En
la actualizacin se incluyen numerosas caractersticas nuevas:
Mejora en la bsqueda por entrada de texto y voz para incluir historial de favoritos, contactos y la web.
Habilidad de los desarrolladores de incluir su contenido en los resultados de bsqueda.
Motor multi-lenguaje de Sntesis de habla para permitir a cualquier
aplicacin de Android "hablar" una cadena de texto.
Bsqueda facilitada y habilidad para ver capturas de las aplicaciones
en el Android Market(Google Play).
Galera, cmara y videocmara con mejor integracin, con rpido
acceso a la cmara.
La galera ahora permite a los usuarios seleccionar varias fotos para
eliminarlas.
Actualizacin soporte a tecnologa para CDMA/EVDO, 802.1x, VPNs
y un motor text-to-speech.
120
Soporte para resoluciones de pantalla WVGA.

Mejoras de velocidad en bsqueda y aplicaciones de cmara.
Framework de gestos ampliado y una nueva herramienta de desarrollo
GestureBuilder.
Versin 2.0 (Eclair): Lanzamiento el da 26 de octubre de 2009. El 26 de
octubre de 2009, el SDK de Android 2.0 fue lanzado, basado en el ncleo
de linux 2.6.29. Los cambios incluyen:
Sincronizacin cuenta expandida, permitiendo a los usuarios agregar mltiples cuentas al dispositivo para sincronizacin de correo y
contactos.
Soporte intercambio de correo, con bandeja combinada para buscar
correo desde mltiples cuentas en la pgina.
Soporte Bluetooth 2.1.
Habilidad para tocar un foto de un contacto y seleccionar llamar,
enviar SMS o correo a la persona.
Habilidad para en todos los mensajes SMS y MMS guardados, con
eliminacin de mensajes ms antiguos en una conversacin automticamente cuando un lmite definido se ha alcanzado.
Nuevas caractersticas para la cmara, incluyendo soporte de flash,
zoom digital, modo escena, balance de blancos, efecto de colores y
enfoque macro.
Mejorada velocidad de tipeo en el teclado virtual, con diccionario
inteligente que aprende el uso de palabras e incluye nombres de contactos como sugerencias.
Renovada interfaz de usuario del navegador con imgenes en miniatura de marcador, zoom de toque-doble y soporte para HTML5.
Vista agenda del calendario mejorada, que muestra el estado asistiendo a cada invitado, y la capacidad de invitar a nuevos invitados
a los eventos.
Optimizacin en velocidad de hardware y GUI renovada.
Soporte para ms tamaos de pantalla y resoluciones, con mejor ratio
de contraste.
Mejorado Google Maps 3.1.2.
Clase MotionEvent mejorada para rastrear eventos multi-touch.30.
121
Adicin de fondos de pantalla animados, permitiendo la animacin

de imgenes de fondo de la pantalla inicio para mostrar movimiento.
Versin 2.2 (Froyo): Lanzamiento el da 20 de mayo de 2010. El 20 de mayo
de 2010, El SDK de Android 2.2 Froyo fue lanzado, basado en el ncleo
Linux 2.6.32.Los cambios incluyen:
Optimizaciones en velocidad, memoria y rendimiento.
Mejoras adicionales de rendimiento de aplicacin, implementadas mediante compilacin Just-in-time (JIT).
Integracin del motor de JavaScript V8 de Chrome en el navegador.
Soporte para el servicio Android Cloud to Device Messaging (C2DM),
habilitando notificaciones push Soporte para Microsoft Exchange mejorado, incluyendo polticas de seguridad, auto-descubrimiento, consulta a la Global Access List (GAL), sincronizacin de calendario, y
borrado remoto.
Mejoras en la aplicacin del lanzador con accesos directos de las aplicaciones telfono y navegador web Funcionalidad de anclaje de red
por USB y Wi-Fi hotspot Agregada opcin para deshabilitar acceso
de datos sobre red mvil.
Actualizada la aplicacin Market con caractersticas de grupo y actualizaciones automticas.
Cambio rpido entre mltiples lenguajes de teclado y diccionario.
Discado por voz e intercambio de contactos por Bluetooth Soporte
para docks Bluetooh-habilitado para autos y de escritorio.
Soporte para contraseas numricas y alfanumricas.
Soporte para subida de archivos en la aplicacin del navegador.
Soporte para instalacin de aplicaciones en la memora expandible
Soporte para Adobe Flash.
Soporte para pantallas de alto nmero de PPI (320 ppi), como 4"
720p.
Galera permite a los usuarios ver pilas de imgenes mediante un
gesto de zoom.
Versin .2.3.x (Gingerbread): Lanzamiento el da 6 de diciembre de 2010.
El 6 de diciembre de 2010, el SDK de Android 2.3 Gingerbread fue lanzado,
basado en el ncleo Linux 2.6.35. Los cambios incluyen:
122
Actualizado el diseo de la interfaz de usuario con incrementos en

velocidad y simpleza.
Soporte para tamaos y resoluciones de pantalla extra-grandes (WXGA y mayores).
Soporte nativo para SIP y telefona por internet VoIP.
Entrada de texto del teclado virtual ms rpida e intuitiva, con mejoras en precisin, texto sugerido y entrada por voz.
Mejoras en la funcionalidad de copiar/pegar, permitiendo a los usuarios seleccionar una palabra al presionar-mantener, copiar y pegar.
Soporte para Near Field Communication (NFC), permitiendo al usuario leer la etiqueta NFC incrustada en un pster, sticker o anuncio
publicitario.
Nuevos efectos de audio tales como reverberacin, ecualizador, virtualizacin de audfonos y aumento de bajos.
Nuevo gestor de descargas, que da a los usuarios fcil acceso a cualquier archivo descargado del navegador, correo electrnico u otra aplicacin.
Soporte para mltiples cmaras en el dispositivo, incluyendo cmara
frontal-facial, si est disponible.
Soporte para reproducccin de video por WebM/VP8, codificacin
de audio por AAC.
Mejoras en la administracin de la energa, con un mayor rol activo en aplicaciones de administracin que se mantienen activas en el
dispositivo por mucho tiempo.
Mejorado soporte para el desarrollo de cdigo nativo. Cambio desde
YAFFS a ext4 en dispositivos nuevos.
Mejoras en audio, grficos y entrada para desarrolladores de juegos.
recolector basura concurrente para incrementar el rendimiento.
Soporte nativo para ms sensores (tales como giroscopio y barmetro).
Versin .2.3.4: Lanzamiento el da 28 de abril de 2011. Los cambios
incluyen:
Rebaja de la seguridad de SSL al usar protocolos de cifrado inseguros.
Soporte de chat de video o voz, usando Google Talk.
123
Soporte a la biblioteca Open Accessory. Open Accessory fue introducida en 3.1 (Honeycomb) pero la biblioteca Open Accessory Library
subvenciona en 2.3.4 agregado su soporte cuando un perifrico USB
es conectado con software compatible y una aplicacin compatible en
el dispositivo.
Versin .2.3.5: Lanzamiento el da 25 de julio de 2011. Los cambios incluyen:
Mejoras en el rendimiento por red del Nexus S 4G.
Arreglado una falla de Bluetooth en el Samsung Galaxy S.
Mejoras a la aplicacin de correo electrnico.
Animacin de sombras al deslizar por listas.
Mejoras al software de la cmara.
Mejorada la eficiencia de la batera.
Versin .2.3.6: Lanzamiento el da 2 de septiembre de 2011. Los cambios
incluyen:
Arreglado fallo en la bsqueda por voz.
Versin .2.3.7: Lanzamiento el da 21 de septiembre de 2011. Los cambios incluyen:
Soporte de Google Wallet para el Nexus S 4G.esta versin es exclusiva
para usuarios en canada.
Versin 3.x (Honeycomb): Lanzamiento el da 22 de febrero de 2011. El 22
de febrero de 2011, sale el SDK de Android 3.0 Honeycomb. Fue la primera actualizacin exclusiva para tablet, lo que quiere decir que slo es
apta para tablets y no para telfonos Android. Est basada en el ncleo
de Linux 2.6.36. El primer dispositivo con esta versin fue la tableta Motorola Xoom, lanzado el 24 de febrero de 2011. Las caractersticas de la
actualizacin incluyen:
Soporte optimizado para tablets, con una nueva y "virtual" interfaz
de usuario hologrfica.
Agregada barra de sistema, con caractersticas de acceso rpido a notificaciones, estados y botones de navegacin suavizados, disponible
en la parte inferior de la pantalla.
124
Aadida barra de accin (Action Bar en ingls), entregando acceso a

opciones contextuales, navegacin, widgets u otros tipos de contenido
en la parte superior de la pantalla.
Multitarea simplificada tocando Aplicaciones recientes en la barra
del sistema permite a los usuarios ver instantneas de las tareas en
curso y saltar rpidamente de una aplicacin a otra.
Teclado rediseado, permitiendo una escritura rpida, eficiente y
acertada en pantallas de gran tamao.
Interfaz simplificada y ms intuitiva para copiar/pegar.
Las pestaas mltiples reemplazan las ventanas abiertas en el navegador web, adems de la caracterstica de auto completado texto y
un nuevo modo de "incgnito" permitiendo la navegacin de forma
annima.
Acceso rpido a las caractersticas de la cmara como la exposicin,
foco, flash, zoom, cmara facial-frontal, temporizador u otras.
Habilidad para ver lbumes y otras colecciones de fotos en modo
pantalla completa en galera, con un fcil acceso a vistas previas de
las fotografas.
Nueva interfaz de contactos de dos paneles y desplazamiento rpido
para permitir a los usuarios organizar y reconocer contactos fcilmente.
Nueva interfaz de correo de dos paneles para hacer la visualizacin
y organizacin de mensajes ms eficiente, permitiendo a los usuarios
seleccionar uno o ms mensajes.
Soporte para videochat usando Google Talk.
Aceleracin de hardware.
Soporte para microprocesadores multi-ncleo. Habilidad para encriptar todos los datos del usuario.
Mejoras en el uso de HTTPS con Server Name Indication (SNI).
Filesystem in Userspace (FUSE; kernel module).
Versin 3.1: Lanzamiento el da 10 de mayo de 2011. Los cambios incluyen:
Refinamiento a la interfaz de usuario.
Conectividad para accesorios USB.
Lista expandida de aplicaciones recientes.
125
Widgets redimensionables en la pantalla de inicio.

Soporte para teclados externos y dispositivos punteros.
Soporte para joysticks y gamepads.
Soporte para reproduccin de audio FLAC57.
Bloqueo de Wi-Fi de alto rendimiento, manteniendo conexiones
Wi-Fi de alto rendimiento cuando la pantalla del dispositivo est
apagada.
Soporte para proxy HTTP para cada punto de acceso Wi-Fi
conectado.

Extraction and Analysis System of Topics For Software History Reports

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Extraction and Analysis System of Topics For Software History Reports

Загружено:

Авторское право:

Facultad de Ciencias Exactas

Universidad Nacional del Centro de la Pcia. de Bs. As.

Sistema de Extraccin y Anlisis de Tpicos sobre

Tesista: Martn I. Pacheco

Director: Dra. Daniela Godoy Co-Director: Ing. Alejandro Corbellini

A mi familia por haberme brindado el privilegio de

1.4. Organizacin del trabajo . . . . . . . . . . . . . . . . . . . . . . .

2. Estado del Arte

2.1. Concepto de Descubrimiento de Conocimiento

2.1.1. El proceso de KDD . . . . . . . . . . . . . . . . . . . . . .

2.2. Minera de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.1. Los fundamentos de la Minera de Datos . . . . . . . . . .

2.2.2. Principales caractersticas y objetivos de la Minera de

2.3. Minera de Repositorios de Software . . . . . . . . . . . . . . . .

2.3.1. Los repositorios de software . . . . . . . . . . . . . . . . .

2.3.1.2. Vulnerabilidad y errores de bases de datos . . .

2.3.1.3. Listas de correo y registros (logs) de chats . . .

2.3.1.4. El sistema de control de versiones . . . . . . . .

2.3.1.5. Documenntos de requerimientos y discusiones sobre el diseo . . . . . . . . . . . . . . . . . . . .

2.3.1.6. Registros de ejecucin . . . . . . . . . . . . . . .

2.3.1.7. Repositorios del sistema de software . . . . . . .

2.4. Modelos de Tpicos . . . . . . . . . . . . . . . . . . . . . . . . . .

2.4.1. Terminologa empleada . . . . . . . . . . . . . . . . . . .

2.4.2. Vector Space Model . . . . . . . . . . . . . . . . . . . . .

2.4.3. Latent Semantic Indexing . . . . . . . . . . . . . . . . . .

2.4.4. Independent Component Anlysis . . . . . . . . . . . . . .

2.4.5. Probabilistic Latent Semantic Indexing . . . . . . . . . .

2.4.6. Latent Dirichlet Allocation . . . . . . . . . . . . . . . . .

2.4.6.1. Estimacin de parmetros Dirichlet e inferencia

2.4.7. Sntesis de las semejanzas y diferencias entre PLSA y

2.5. Modelos de evolucin de tpicos . . . . . . . . . . . . . . . . . . .

2.6. Trabajos relacionados . . . . . . . . . . . . . . . . . . . . . . . .

2.6.1. Localizacin de conceptos o caractersticas . . . . . . . . .

2.6.1.1. Tcnicas basadas en LSI . . . . . . . . . . . . . .

2.6.1.2. Tcnicas basadas en LDA . . . . . . . . . . . . .

2.6.2. Recuperacin de la trazabilidad y localizacin de bugs . .

2.6.2.1. Tcnicas basadas en LSI . . . . . . . . . . . . . .

2.6.2.2. Comparacin de estudios . . . . . . . . . . . . .

2.6.3. Mtricas sobre cdigo fuente . . . . . . . . . . . . . . . .

2.6.3.1. Tcnicas basadas en LSI . . . . . . . . . . . . . .

2.6.3.2. Tcnicas basadas en LDA . . . . . . . . . . . . .

2.6.4. Depuracin de estadstica y anlisis de causa principal . .

2.6.5. Evolucin de software y anlisis de tendencias . . . . . . .

2.6.6. Agrupamiento de documentos . . . . . . . . . . . . . . . .

2.6.7. Organizar y buscar en repositorios de software . . . . . .

3.3. Analizador para el conjunto de datos . . . . . . . . . . . . . . . .

3.4. Generacin de documentos y de versiones . . . . . . . . . . . . .

3.5. Extraccin de tpicos

3.5.1. Algoritmo de muestreo Gibbs

3.5.2. Pre-procesamiento de los documentos . . . . . . . . . . .

3.5.2.1. Eliminacin de smbolos de puntuacin . . . . .

3.5.2.2. Desglose de trminos . . . . . . . . . . . . . . .

3.5.2.3. Conversin de maysculas a minsculas . . . . .

3.5.2.4. Eliminacin de stop words . . . . . . . . . . . .

3.5.2.5. Aplicacin de un algoritmo de Stemming (Porter) 69

3.6. Resultados y mtricas para la evolucin de tpicos . . . . . . . .

3.7. Anlisis de la evolucin de tpicos . . . . . . . . . . . . . . . . .

4. Indexacin y bsqueda mediante Lucene

4.1.2. Bsqueda dentro del ndice . . . . . . . . . . . . . . . . .

4.1.3. Extensin de las bsquedas . . . . . . . . . . . . . . . . .

4.1.3.1. Ejemplo de una bsqueda con los trminos de

5. Aplicacin para la extraccin y anlisis de tpicos

5.1. Descripcin de la aplicacin . . . . . . . . . . . . . . . . . . . . .

6.1. Contribucin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

A. Historial de versiones de Android

2.4.2.Representacin grfica del modelo LDA. Las cajas son "placas"