algoritmo multidimensional para la extracci on y...
Post on 28-Dec-2019
13 Views
Preview:
TRANSCRIPT
Algoritmo multidimensional para laextraccion y visualizacion de laarquitectura de un artefacto de
software a partir de su codigo fuente
Raul Fernando Casallas Malaver
Universidad Distrital Francisco Jose de Caldas
Facultad de Ingenierıa, Especializacion en Ingenierıa de Software
Bogota, Colombia
2019
Algoritmo multidimensional para laextraccion y visualizacion de laarquitectura de un artefacto de
software a partir de su codigo fuente
Raul Fernando Casallas Malaver
Trabajo de grado presentado como requisito para optar al tıtulo de:
Especialista en ingenierıa de software
Director(a):
MSc Alejandro Paolo Daza
Revisor:
Ing. John Jairo Londono
Universidad Distrital Francisco Jose de Caldas
Facultad de Ingenierıa, Especializacion en Ingenierıa de Software
Bogota, Colombia
2019
If you’re not willing to look stupid, not-
hing great is ever going to happen to you.
Gregory House (House M.D.)
Agradecimientos
A los profesores Joaquin Javier Mesa y Lilian Bejarano, quienes con su dedicacion, esfuerzo y
combinacion de estilos pedagogicos en el seminario de investigacion desencadenaron reflexio-
nes profundas acerca del caracter de la investigacion en la Ingenierıa, alentaron a seleccionar
un tema complejo y desafiante para el presente trabajo y constantemente impulsaron el es-
fuerzo continuo necesario para llevarlo a cabo.
A mi hijo Sebastian, el mejor amigo de mi nino interior y quien constantemente me mo-
tiva a convertirme en el padre que ve a traves de sus ojos.
Finalmente a quien considero mi ejemplo e inspiracion, mi gran amiga Angelica Veloza,
es difıcil cuantificar las veces que sin darte cuenta me has ayudado a continuar. Gracias por
motivar, apoyar y asesorar esta investigacion.
Finalmente y de manera muy sincera quiero dar una mencion especial a los profesores Ale-
jandro Paolo Daza y John Jairo Londono ya que a pesar de haber sido asignados de manera
extemporanea al proyecto fueron una gran fuente de reflexion, motivacion y apoyo, al punto
que gracias a ellos pude acabar el proyecto en el tiempo establecido y me quedo con una
gran prospectiva de todo el trabajo a futuro.
ix
Resumen
Desde los anos 90 se ha documentado que la comprension de programas o software es un
proceso complejo que desafıa a desarrolladores independientemente de su nivel de experien-
cia, usual pero no exclusivamente en fase de mantenimiento [11].
En terminos generales se acepta que las herramientas visuales permiten mejorar los pro-
cesos cognitivos asociados a la comprension y el analisis de datos, dando pie a un gran
numero de herramientas de computacion visual para areas como la medicina, arquitectura,
etc. Sin embargo no es comun encontrar dichas herramientas en la ingenierıa de software.
Este trabajo hace una caracterizacion de los datos, informacion y conocimiento que se pue-
den extraer a partir del codigo fuente y, por medio de un analisis de las estrategias existentes
para la representacion de conocimiento propone un algoritmo novedoso de visualizacion de
software, que combina estrategias de diferentes areas de conocimiento como la inteligencia
artificial, ingenierıa inversa y visualizacion de software.
Se presentan los resultados preliminares de una implementacion parcial del algoritmo en
escenarios de prueba controlados junto con las perspectivas de trabajo futuro.
Palabras clave: .
Comprension de software, Comprension de programas, Visualizacion de software, Visualiza-
cion de programas, Mantenimiento de software
x
Abstract
Since 90’s it has been documented that understanding programs/software is a complex pro-
cess that challenges developers at any level of experience, usually, but not just in maintenance
phase cite Harris1996.
In general, it is accepted that visual tools can improve the cognitive processes associated
with the understanding and analysis of data, giving rise to a large number of visual com-
puting tools for areas such as medicine, architecture, and so on. However we will not find
tools in software engineering. This project make a caracterization of the data, information
and knowledge that can be extracted from the source code and propose a new algoritm for
software visualization by analize and combine different strategies from knowledge areas such
as artificial itelligence, reverse engineering and software visualization.
This document present the preliminary results of a partial implementation of the algorithm
and the visualization of some test cases together with the perspectives of future work.
Keywords: .
Software comprehension, Program comprehension, Software visualization, Program visuali-
zation, Software maintenance
Contenido
Agradecimientos VII
Resumen IX
Abstract X
I. Descripcion de la investigacion 2
1. Descripcion de la investigacion 3
1.1. Planteamiento y formulacion del problema . . . . . . . . . . . . . . . . . . . 3
1.1.1. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2. Formulacion del problema . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.3. Sistematizacion del problema . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2. Objetivos especıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Justificacion del trabajo/investigacion . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1. Justificacion teorica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2. Justificacion Metodologica . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.3. Justificacion Practica . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Hipotesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Marco referencial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.1. Ciencia cognitiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.1.1. Amplificacion de inteligencia . . . . . . . . . . . . . . . . . 7
1.5.1.2. Visualizacion de informacion . . . . . . . . . . . . . . . . . 7
1.5.2. Comprension de software . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.3. Visualizacion de Software . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6. Metodologıa de la investigacion . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6.1. Tipo de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6.2. Metodo de investigacion . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6.3. Fuentes y tecnicas para la recoleccion de informacion . . . . . . . . . 9
1.6.4. Tratamiento de la informacion . . . . . . . . . . . . . . . . . . . . . . 9
1.7. Organizacion del trabajo de grado . . . . . . . . . . . . . . . . . . . . . . . . 10
xii Contenido
II. Desarrollo de la investigacion 11
2. Estado del arte 12
2.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2. Tecnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1. Analisis visual de similitudes de codigo [7] . . . . . . . . . . . . . . . 13
2.2.1.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1.3. Caracterizacion . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2. H-CURVE [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2.3. Caracterizacion . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.3. Mini mapa de codigo [2] . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3.3. Caracterizacion . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.4. Code Park [16] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.4.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.4.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.4.3. Caracterizacion . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.5. CodeMetropolis [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.5.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.5.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.5.3. Caracterizacion . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.6. Visualizacion en arbol [3] . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.6.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.6.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.6.3. Caracterizacion . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.7. CodeCity [26] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.7.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.7.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.7.3. Caracterizacion . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.8. 212D Visualizacion de grafo de llamadas [6] . . . . . . . . . . . . . . . 20
2.2.8.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.8.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.8.3. Caracterizacion . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.9. The Brain [20] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.9.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.9.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Contenido xiii
2.2.9.3. Caracterizacion . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.10. Flujo de datos entre procedimientos [14] . . . . . . . . . . . . . . . . 22
2.2.10.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.10.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.10.3. Caracterizacion . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.11. ClonEvol [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.11.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.11.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.11.3. Caracterizacion . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.12. Chronos [24] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.12.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.12.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.12.3. Caracterizacion . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.13. StartGate [19] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.13.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.13.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.13.3. Caracterizacion . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.14. code swarm [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.14.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.14.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.14.3. Caracterizacion . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3. Clasificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.1. Extraccion y Transformacion . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.2. Representacion visual . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3. Propuesta 30
3.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2. Analisis practico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.1. Prioridades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.1.1. Primer aspecto que se busca en un artefacto de software . . 32
3.2.1.2. Segundo aspecto que se busca en un artefacto de software . 33
3.2.1.3. Tercer aspecto que se busca en un artefacto de software . . 34
3.2.1.4. Aspectos que se busca en un artefacto de software . . . . . . 35
3.2.1.5. Proceso cognitivo para la comprension de software . . . . . 36
3.3. Modelo de conocimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.1. Aspectos teoricos y practicos . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.1.1. Fuentes de extraccion . . . . . . . . . . . . . . . . . . . . . 37
3.3.1.2. Elementos a extraer . . . . . . . . . . . . . . . . . . . . . . 37
3.3.1.3. Componentes visuales . . . . . . . . . . . . . . . . . . . . . 37
Contenido 1
3.3.2. Modelo conceptual de conocimiento . . . . . . . . . . . . . . . . . . . 39
3.3.2.1. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.2.2. Comportamiento . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.2.3. Evolucion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4. Algoritmo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4.2. Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.5. Propuesta especifica: CodeDecipher . . . . . . . . . . . . . . . . . . . . . . . 43
3.5.1. Clases e Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.5.1.1. Forma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.5.1.2. Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.5.1.3. Tamano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5.2. Paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.5.2.1. Forma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.5.2.2. Tamano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.5.3. Aristas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.5.3.1. Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.5.3.2. Cercanıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.5.4. Evolucion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.5.4.1. Lınea de tiempo . . . . . . . . . . . . . . . . . . . . . . . . 49
3.6. Prototipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.6.1. Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.6.1.1. Clase simple . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.6.1.2. Herencia simple . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.6.2. Pantallas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
III. Cierre de la investigacion 58
4. Resultados y Discusion 59
4.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2. Verificacion, contraste y evaluacion de los objetivos . . . . . . . . . . . . . . 60
4.3. Sıntesis del modelo propuesto . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4. Aportes originales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.5. Trabajos o Publicaciones derivadas . . . . . . . . . . . . . . . . . . . . . . . 62
5. Prospectiva del Trabajo de Grado 63
5.1. Lıneas de Investigacion Futuras . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2. Trabajos de Investigacion Futuros . . . . . . . . . . . . . . . . . . . . . . . . 63
Bibliografıa 64
Parte I.
Descripcion de la investigacion
1. Descripcion de la investigacion
1.1. Planteamiento y formulacion del problema
1.1.1. Planteamiento del problema
Existe un aspecto transversal que impacta de manera significativa los proyectos de ingenierıa
de software y se evidencia cuando arquitectos, analistas y desarrolladores entran o salen del
equipo de trabajo durante la ejecucion del proyecto, o cuando el equipo completo se enfrenta
a un proyecto correspondiente a la fase de mantenimiento de un artefacto desconocido: la
comprension del software.
El proceso de incorporar el conocimiento obtenido a partir del analisis, las decisiones de
arquitectura, los acuerdos en cuanto a patrones de diseno y estandares de desarrollo, o al
menos una mınima abstraccion de este conocimiento que permita comprender el software y
mantenerlo de una manera eficiente es un proceso sumamente empırico que se puede resumir
en lo siguiente:
Contextualizacion: Uno o varios usuarios y explican desde su perspectiva que hace el
software, se obtiene una vision funcional inicial (usualmente incompleta).
Conocimiento de expertos: Un integrante del equipo de trabajo expone los aspectos
mas relevantes del software en una sesion de trabajo, aun con la ayuda de elementos
visuales no es suficiente para transferir una gran cantidad de conocimiento por lo que
se obtiene una vision tecnica inicial (abstracta).
Documentacion: Se brinda acceso al conjunto de artefactos documentales que en el
momento de su elaboracion representaron uno o varios aspectos del software, en el
mejor de los casos (ignorando las posibles omisiones, problemas de calidad, vistas
inadecuadas), se obtiene una comprension de un estado pasado del software.
Experiencia: En la medida que los tres elementos anteriores pueden o no pueden darse
dependiendo del tipo de software, el paso del tiempo, la disponibilidad de las personas,
etc. Se evidencia que la unica fuente objetiva de conocimiento termina siendo el codigo
fuente del software y se espera que al sumar la experiencia al menos los elementos clave
sean comprendidos.
4 1 Descripcion de la investigacion
Los errores en la compresion de software llevan a que el codigo fuente adquiera nuevas capas
de complejidad y a su vez que sea mas difıcil de mantener; Elementos como duplicidad de
codigo, bloques, reglas de negocio, antipatrones de diseno e introduccion de nuevos defectos
desencadenan el fin prematuro del ciclo de vida del software.
En la actualidad existen un sinnumero de estrategias que tratan de utilizar tecnicas de inge-
nierıa inversa, procesamiento de lenguaje natural, minerıa de repositorios de codigo fuente
cuyo fin es extraer informacion en forma de modelos representados segun el estandar UML,
resumenes de codigo en lenguaje natural o listados de reglas de negocio que en muchas oca-
siones dan una version parcial o incompleta del software a comprender, o que realmente no
aportan nada nuevo a lo que se puede evaluar de manera directa observando el codigo fuente
a intervenir.
Si bien se ha establecido que el codigo fuente es una fuente valida de informacion [9], no
es claro cuales son las caracterısticas estructurales, de comportamiento y evolutivas que
se pueden extraer ni el nivel de abstraccion o especificidad adecuado para construir una
visualizacion efectiva y eficaz que mejore el proceso de comprension de software.
1.1.2. Formulacion del problema
¿Que aspectos estructurales, de comportamiento y evolutivos se pueden obtener a partir
del codigo fuente con el fin de construir una representacion visual que mejore el proceso de
comprension del software?
1.1.3. Sistematizacion del problema
¿Que informacion se puede obtener a partir del codigo fuente de un artefacto?
• ¿Que tecnicas se utilizan?
• ¿Como se puede caracterizar dicha informacion?
• ¿A que nivel de abstraccion/especificidad?
¿Que estrategias de visualizacion de codigo fuente existen?
• ¿Que aspectos representan del software?
• ¿Como se pueden caracterizar/clasificar?
¿Como se puede construir una visualizacion que integre aspectos estructurales, de
comportamiento y evolutivos del software para mejorar el proceso de comprension del
software?
• ¿Cuales aspectos son relevantes para la comprension del software?
• ¿Cuales aspectos se pueden representar de manera visual?
• ¿Como se pueden combinar dichas visualizaciones?
1.2 Objetivos 5
¿Como se puede validar el algoritmo?
• ¿Que escenarios de prueba se pueden disenar para evaluar el algoritmo?
• ¿Que criterios se pueden utilizar para valorar la efectividad en la comprension del
software?
1.2. Objetivos
1.2.1. Objetivo general
Disenar un algoritmo para la extraccion y representacion visual del conocimiento a partir de
codigo fuente con el fin de mejorar el proceso de comprension de software.
1.2.2. Objetivos especıficos
Caracterizar los algoritmos de extraccion de conocimiento y las estrategias de visuali-
zacion a partir de codigo fuente existentes por medio de la elaboracion de un estado del
arte que integre las perspectivas de la ingenierıa inversa, visualizacion de software e in-
teligencia artificial con el fin de establecer un marco de trabajo teorico y metodologico
actualizado.
Proponer un algoritmo que combine tecnicas de inteligencia artificial, visualizacion de
software e ingenierıa inversa adecuadas para analizar, interpretar y extraer los datos a
partir del codigo fuente e integra en una visualizacion que integre aspectos estructura-
les, de comportamiento y evolutivos del software.
Validar el algoritmo propuesto por medio de la ejecucion en escenarios de prueba
controlados que permitan valorar su efectividad en al comprension del software
1.3. Justificacion del trabajo/investigacion
El proceso de comprension del software permite al analista, arquitecto o desarrollador en-
tender las caracterısticas clave del software, las decisiones de diseno, la arquitectura y otros
aspectos necesarios para intervenir un determinado artefacto dentro del marco de un pro-
yecto de ingenierıa de software.
1.3.1. Justificacion teorica
Si bien se ha establecido que el codigo fuente de un artefacto de software es una fuente
primaria de informacion y que a partir de el se pueden extraer reglas de negocio, documen-
tacion, resumenes de codigo, aspectos de diseno, etc [1, 11, 15, 21]. No es claro cuanta de
6 1 Descripcion de la investigacion
esta informacion no es trivial (es decir que puede ser deducida con una inspeccion sencilla
al codigo fuente) o realmente sea un aporte al proceso de comprension del software (es decir
que la representacion obtenida no sea mas compleja que el codigo fuente en sı), razon por
la cual esta investigacion es relevante ya que se va a establecer una caracterizacion de los
algoritmos y tecnicas existentes segun la informacion extraıda y el nivel de complejidad de la
representacion generada y el aporte al conocimiento que representa la propuesta del nuevo
algoritmo de extraccion y representacion del conocimiento a partir de codigo fuente.
1.3.2. Justificacion Metodologica
Esta investigacion se justifica desde el punto de vista metodologico ya que la implementa-
cion del algoritmo propuesto y su respectiva ejecucion en escenarios de prueba permitira
establecer un grado de validez preliminar que garantice a otros investigadores la posibilidad
de evaluar las premisas, argumentos, escenarios y conclusiones del estudio realizado y la
comparacion con otras estrategias de extraccion y visualizacion de informacion a partir de
codigo fuente.
1.3.3. Justificacion Practica
Desde una perspectiva practica esta investigacion se fundamenta en la necesidad de obtener
una representacion visual del codigo fuente que sea efectiva y facilite el proceso de com-
prension del software, basandose en la dualidad arte-ciencia de la visualizacion de software
[9], y el uso comun de metaforas y analogıas con el fin de asociar conceptos abstractos
con representaciones mentales. Los resultados seran relevantes ya que al utilizar el algoritmo
propuesto en la industria permitira evaluar y mejorar el proceso de comprension del software.
1.4. Hipotesis
La combinacion de informacion estructural, de comportamiento y evolutiva del codigo fuente
en una representacion visual n-dimensional permitira optimizar el proceso de comprension
del software.
1.5 Marco referencial 7
1.5. Marco referencial
1.5.1. Ciencia cognitiva
A nivel general este proyecto se enmarca dentro de la ciencia cognitiva, ya que involucra
la naturaleza, las tareas y las funciones de la cognicion; la mente y sus procesos. Incluye as-
pectos como: lenguaje, percepcion, memoria, atencion, razonamiento y emocion e involucra
areas como linguıstica, psicologıa, inteligencia artificial, neurociencia y antropologıa.
1.5.1.1. Amplificacion de inteligencia
El uso de herramientas tecnologicas con el fin de aumentar o mejorar los procesos de cogni-
cion y adquisicion de conocimiento ha sido denominado Amplificacion de inteligencia e
involucra el uso de la capacidad de procesamiento de datos con el fin de mejorar la capacidad
humana de enfrentar problemas complejos, llegando a un nivel de comprension basado en
sus necesidades individuales para la toma de decisiones que permitan solucionar problemas.
1.5.1.2. Visualizacion de informacion
En este contexto, se define la Visualizacion de informacion como la transformacion de
datos en representaciones visuales que permitan explorar, analizar u en otras palabras ob-
servar la informacion para la toma de decisiones y la solucion de problemas.
1.5.2. Comprension de software
El area de comprension de software, que en ocasiones varia su definicion por entendimiento
(understanding en ingles) o programas en vez de software involucra el estudio de los procesos
cognitivos que utilizan los desarrolladores o arquitectos con el fin de asimilar las caracterısti-
cas estructurales, de comportamiento y evolucion de un determinado artefacto de codigo
fuente.
En los anos 90, Corbi T. enuncio tres teorıas cognitivas sobre el proceso de comprension o
entendimiento de programas [8]:
De abajo hacia arriba: El desarrollador esencialmente construye multiples abstrac-
ciones por medio de la lectura del codigo fuente asociando categorıas similares mientras
va subiendo de nivel.
De arriba hacia abajo: El desarrollador utiliza su experiencia previa y una compren-
sion de la logica de negocio con el fin de crear hipotesis mentales acerca de como deberıa
8 1 Descripcion de la investigacion
estar construido el software y continua con un proceso de prueba de esta hipotesis, es
decir que verifica en el codigo fuente si fue o no implementado de la manera como
supuso.
Oportunıstica: El desarrollador utiliza una combinacion de las dos teorıas anteriores
alternando entre ellas en momentos de dificultad o verificacion o no de hipotesis.
1.5.3. Visualizacion de Software
La aplicacion de la tecnologıa con el fin de transformar datos obtenidos a partir pero no
exclusivamente, del codigo fuente de un artefacto de software en representaciones visuales
que permitan observar e incrementar los procesos cognitivos con los cuales los desarrolladores
o arquitectos entienden el software enmarca el area de la Visualizacion de Software. Se
ha definido formalmente como: “El arte y la ciencia de generar representaciones visuales de
varios aspectos del software y el proceso de desarrollo” [9], en su libro Stephan Diel hace la
siguiente clasificacion general de los algoritmos de visualizacion de software enfocandose en
el objeto principal de la visualizacion:
Visualizacion estatica: Estas visualizaciones utilizan el codigo fuente como base y
utilizan un analisis sintactico para transformarlo en representaciones visuales enfocadas
en las relaciones estaticas (atributos, metodos, asociaciones, etc.).
Visualizacion dinamica: Estas visualizaciones utilizan un mecanismo de “instrumen-
talizacion” para obtener un log de llamados o en algunos casos acceder directamente
a la asignacion de memoria RAM, en esta categorıa se encuentran animaciones de
algoritmos, analisis de pilas y colas de memoria, etc.
Depuracion visual: Esta visualizacion combina el codigo fuente con elementos de
visualizacion estatica y dinamica con el fin de permitir al usuario detener el programa
en un punto determinado y hacer analisis de asignacion de variables, datos, memoria,
etc.
Arquitectura de software: Se combinan documentacion y codigo fuente con anali-
sis estaticos y dinamicos con el fin de construir metricas de alto nivel que permitan
encontrar problemas en el software.
Evolucion de software: Se utilizan como fuente los logs de los repositorios de codigo,
listas de correo o mensajerıa de los integrantes del equipo de desarrollo y bases da datos
de incidentes y defectos, su objetivo es combinar los aspectos extraıdos con analisis
estatico o dinamico a la dimension temporal.
1.6 Metodologıa de la investigacion 9
1.6. Metodologıa de la investigacion
1.6.1. Tipo de estudio
La presente investigacion pertenece al tipo proyectivo, ya que su objetivo es disenar un nuevo
algoritmo de extraccion y visualizacion de conocimiento a partir del codigo fuente; si bien
existen fundamentos teoricos respecto a la extraccion de conocimiento a partir del codigo
fuente [1, 11, 12, 21, 23, 25], la visualizacion de software en muchos aspectos se considera
un arte [9] y la comprension del software aun es un area en crecimiento [22], por lo que
es necesario clasificar y caracterizar en la bibliografıa cientıfica las estrategias y algoritmos
existentes con el fin de crear una base teorica y metodologica que permita proponer un
algoritmo novedoso que mejore el proceso de comprension de software.
1.6.2. Metodo de investigacion
El metodo de investigacion de la presente propuesta es inductivo debido a que pretende
hacer una revision teorica de las estrategias particulares para la extraccion de conocimiento,
extraccion de informacion a partir de codigo fuente, representacion y visualizacion del cono-
cimiento y en general, visualizacion de software con el fin de unificar criterios, caracterizar y
clasificar estrategias y aplicarlas a un modelo general de extraccion y representacion visual
de conocimiento a partir de codigo fuente.
1.6.3. Fuentes y tecnicas para la recoleccion de informacion
Se utilizaran las siguientes fuentes de recoleccion de informacion:
Libros generales sobre las areas generales del conocimiento relacionadas con el tema
de la investigacion: inteligencia artificial, visualizacion de software, ingenierıa inversa.
Revistas y conferencias especializadas:
• IEEE International Conference on Program Comprehension
• IEEE Working Conference on Software Visualization
• IEEE Computer Science
• ACM/IEEE International Conference on Software Engineering
1.6.4. Tratamiento de la informacion
En la etapa de caracterizacion se espera obtener tablas comparativas de acuerdo a las ca-
racterısticas extraıdas por los algoritmos y a la complejidad de las representaciones que se
generan a partir de dichas caracterısticas, posteriormente se espera que por medio de graficas
10 1 Descripcion de la investigacion
se pueda explicar la propuesta del algoritmo disenado, ası como sus resultados en los casos
de prueba establecidos.
1.7. Organizacion del trabajo de grado
El presente trabajo de grado se organiza de la siguiente manera: la parte I describe los
aspectos motivacionales, metodologicos y los antecedentes de la investigacion, la parte II
expone el desarrollo de la investigacion realizada, la parte III contiene la evaluacion de los
objetivos de investigacion y del algoritmo propuesto y finalmente la parte 5.2 contiene los
anexos producidos dentro del marco de la investigacion realizada.
Parte II.
Desarrollo de la investigacion
2. Estado del arte
2.1. Introduccion
Como se ha mencionado previamente en el marco referencial (seccion 1.5), este proyecto
cubre multiples enfoques que incluyen desde una perspectiva general al menos tres areas de
investigacion: la extraccion de conocimiento a partir de codigo fuente comprendida
como la extraccion de caracterısticas y su posterior procesamiento, calculo y generacion de
conocimiento, la comprension de software como el analisis de los procesos cognitivos para
entender las caracterısticas de un artefacto de software y la visualizacion de software co-
mo la representacion grafica del conocimiento obtenido a partir del codigo fuente que mejora
el proceso de comprension de los elementos estructurales, de comportamiento y evolucion
del software.
Este capitulo se organiza de la siguiente manera, en la seccion 2.2 se hace una revision de
las tecnicas encontradas en la literatura cientıfica, enumerando las caracterısticas principales
y el enfoque dado por sus autores con el fin de establecer en la seccion 2.3 una clasifica-
cion y caracterizacion sobre los elementos que se extraen a partir del codigo fuente y la
correspondiente transformacion en representaciones visuales.
2.2 Tecnicas 13
2.2. Tecnicas
2.2.1. Analisis visual de similitudes de codigo [7]
2.2.1.1. Resumen
Burch, Strotzer y Weiskopf proponen un algoritmo que extrae fragmentos de codigo
fuente y su correspondiente frecuencia con el fin de construir una representacion matricial
triangular en la cual se pueden ver las similaridades bloques de codigo, como se muestra en
la figura 2-1 se combinan elementos como el color, la escala de grises y el grosor de las lıneas
conectoras y el tamano de la fuente.
2.2.1.2. Imagen
Figura 2-1.: Visualizacion propuesta por Burch, Strotzer y Weiskopf [7]
2.2.1.3. Caracterizacion
Nivel Bajo
Extraccion Palabras en codigo fuente
Transformacion Frecuencia
Visualizacion Estructura en arbol de acuerdo a las palabras y su frecuencia
Tabla 2-1.: Caracterizacion de la propuesta de Burch, Strotzer y Weiskopf [7]
14 2 Estado del arte
2.2.2. H-CURVE [4]
2.2.2.1. Resumen
Bae, Ji y Woo proponen un metodo de visualizacion basado en la Curva de Hilbert; su
algoritmo identifica las sentencias en el codigo fuente, clasifica y construye el fractal siguiendo
las reglas de produccion definidas para la curva de Hilbert, el resultado es una visualizacion
que permite analizar la complejidad de los algoritmos, como muestra la figura 2-2.
2.2.2.2. Imagen
Figura 2-2.: Visualizacion propuesta por Bae, Ji y Woo [4]
2.2.2.3. Caracterizacion
Nivel Bajo
Extraccion Sentencias en codigo fuente
Transformacion Orden de complejidad
Visualizacion Estructura fractal que combina la complejidad obtenida con la curva
de Hilbert
Tabla 2-2.: Caracterizacion de la propuesta de Bae, Ji y Woo [4]
2.2 Tecnicas 15
2.2.3. Mini mapa de codigo [2]
2.2.3.1. Resumen
Bacher, Namee y Kelleher hacen una revision a los mini mapas que se incluyen en
algunas herramientas de desarrollo y proponen en [2] una extension que permita a los desa-
rrolladores ver la jerarquıa de la cadena de alcance sobre las variables o atributos definidos
en el codigo fuente, tal como se presenta en la figura 2-3 permite al espectador visualizar la
estructura micro y macro de un artefacto de software.
2.2.3.2. Imagen
Figura 2-3.: Visualizacion propuesta por Bacher, Namee y Kelleher [2]
2.2.3.3. Caracterizacion
Nivel Bajo
Extraccion Unidades de compilacion
Transformacion Ninguna
Visualizacion Panel lateral que permite ver la concentracion en lıneas de codigo
Tabla 2-3.: Caracterizacion de la propuesta de Bacher, Namee y Kelleher [2]
16 2 Estado del arte
2.2.4. Code Park [16]
2.2.4.1. Resumen
Khaloo, Maghoumi, Taranta, Bettner y Laviola proponen en [16] un ambiente tridi-
mensional de navegacion a traves de la estructura estatica del codigo fuente como se muestra
en la figura 2-4, a diferencia de otros autores no se enfoca en una metafora sino que trata de
incluir un acceso directo a ”salones de codigo 2permite la colaboracion entre desarrolladores.
2.2.4.2. Imagen
Figura 2-4.: Visualizacion propuesta por Khaloo, Maghoumi, Taranta, Bettner y Laviola
[16]
2.2.4.3. Caracterizacion
Nivel Alto y Bajo
Extraccion Unidades de compilacion
Transformacion Nombre de las clases, Codigo fuente
Visualizacion Cada clase se convierte en un cubo tridimensional y en su interior se
puede ver el codigo fuente
Tabla 2-4.: Caracterizacion de la propuesta de Khaloo, Maghoumi, Taranta, Bettner y La-
viola [16]
2.2 Tecnicas 17
2.2.5. CodeMetropolis [5]
2.2.5.1. Resumen
Balogh y Beszedes resaltan la necesidad de construir visualizaciones con alto poder ex-
presivo y proponen combinar las necesidades visuales de la comprension de software con el
ambiente popular y conocido del juego Minecraft. CodeMetropolis se presenta en la figura
2-5, se diferencia de [26] en la medida que mejora la calidad de los graficos y agrega todas
las caracteristicas colaborativas previamente incluidas en el juego.
2.2.5.2. Imagen
Figura 2-5.: Visualizacion propuesta por Balogh y Beszedes [5]
2.2.5.3. Caracterizacion
Nivel Alto
Extraccion Paquetes, Clases, Metodos y Atributos
Transformacion Distritos, Edificios, Ventanas, Etiquetas
Visualizacion Se puede navegar a traves de la ciudad construida por medio de los
controles y ver las etiquetas correspondientes a cada elemento
Tabla 2-5.: Caracterizacion de la propuesta de Balogh y Beszedes [5]
18 2 Estado del arte
2.2.6. Visualizacion en arbol [3]
2.2.6.1. Resumen
Bacher, Namee y Kelleher proponen multiples visualizaciones utilizando la estructura
de arbol con el fin de ayudar a los desarrolladores en el analisis de fragmentos de codigo
jerarquicos combinando aspectos relacionados al alcance y la estructura de control, como se
muestra en la figura 2-6, su visualizacion se presenta como un prototipo en construccion en
[3].
2.2.6.2. Imagen
Figura 2-6.: Visualizacion propuesta por Bacher, Namee y Kelleher [3]
2.2.6.3. Caracterizacion
Nivel Bajo
Extraccion Lıneas de codigo
Transformacion Jerarquia de alcance y estructura de control
Visualizacion Un panel lateral presenta la jerarquia y estructura de acuerdo a la
seleccion del usuario
Tabla 2-6.: Caracterizacion de la propuesta de Bacher, Namee y Kelleher [3]
2.2 Tecnicas 19
2.2.7. CodeCity [26]
2.2.7.1. Resumen
Wettel y Lanza desarrollaron la herramienta de visualizacion mas popular: CodeCity;
utilizando una metafora de una ciudad en la cual los paquetes son distritos y las clases
son edificios, ademas permite intuir la cantidad de metodos (altura), atributos (base) y el
numero de lıneas de codigo (color), como muestra la figura 2-7, ademas su trabajo ha sido
complementado con experimentos controlados para demostrar la utilidad de su visualizacion
[26].
2.2.7.2. Imagen
Figura 2-7.: Visualizacion propuesta por Wettel y Lanza [26]
2.2.7.3. Caracterizacion
Nivel Alto
Extraccion Paquetes, Clases, Numero de Metodos, Atributos y Lıneas de codigo
Transformacion Distritos, Edificios
Visualizacion Los paquetes como distritos, clases como edificios cuya altura es el
numero de metodos, su ancho al numero de atributos y el color al
numero de lıneas de codigo
Tabla 2-7.: Caracterizacion de la propuesta de Wettel y Lanza [26]
20 2 Estado del arte
2.2.8. 212D Visualizacion de grafo de llamadas [6]
2.2.8.1. Resumen
Bohnet y Dollner proponen en [6] una combinacion entre la estructura modular con la
traza dinamica del grafo de llamadas con el fin de construir una representacion de alto nivel
que permita a los desarrolladores utilizar una estrategia de arriba a abajo para encontrar
codigo fuente relacionado a una caracterıstica especifica.
2.2.8.2. Imagen
Figura 2-8.: Visualizacion propuesta por Bohnet y Dollner [6]
2.2.8.3. Caracterizacion
Nivel Bajo
Extraccion Funciones
Transformacion Grafo de llamadas
Visualizacion Se presenta el grafo de llamadas construido a partir de la ejecucion
del codigo fuente
Tabla 2-8.: Caracterizacion de la propuesta de Bohnet y Dollner [6]
2.2 Tecnicas 21
2.2.9. The Brain [20]
2.2.9.1. Resumen
Palepu y Jones proponen en [20] una visualizacion en grupos a partir del codigo fuente que
se construye a partir de los flujos de ejecucion, cada grupo representa logica que interactua
comunmente, se inspira en las representacion visual de las redes neuronales en nuestro cerebro
y por eso su nombre The Brain, la figura 2-9 muestra un ejemplo como los elementos se
organizan de tal manera.
2.2.9.2. Imagen
Figura 2-9.: Visualizacion propuesta por Palepu y Jone [20]
2.2.9.3. Caracterizacion
Nivel Alto
Extraccion Clases, Metodos, Lıneas de codigo
Transformacion Grafo
Visualizacion Los nodos representan lıneas de codigo y los vertices relaciones entre
las lıneas de codigo, ya sea por control o flujo de ejecucion
Tabla 2-9.: Caracterizacion de la propuesta de Palepu y Jone [20]
22 2 Estado del arte
2.2.10. Flujo de datos entre procedimientos [14]
2.2.10.1. Resumen
Ishio, Etsuda e Inoue hacen en [14] un analisis de las tecnicas utilizadas para interpretar
el comportamiento de un programa y proponen una visualizacion de nivel intermedio la cual
permite ver el flujo de datos que pasa entre procedimientos y su correspondiente asignacion
local (dentro del contexto de los otros procedimientos), como se muestra en la figura 2-10.
2.2.10.2. Imagen
Figura 2-10.: Visualizacion propuesta por Ishio, Etsuda e Inoue [14]
2.2.10.3. Caracterizacion
Nivel Bajo
Extraccion Funciones
Transformacion Flujo de llamadas
Visualizacion Se presenta el flujo de llamadas considerando los parametros de las
mismas
Tabla 2-10.: Caracterizacion de la propuesta de Ishio, Etsuda e Inoue [14]
2.2 Tecnicas 23
2.2.11. ClonEvol [10]
2.2.11.1. Resumen
Hanjalic presenta ClonEvol en [10], una herramienta que detecta la inclusion de clones
de codigo haciendo un analisis combinado entre la estructura de los archivos y los cambios
almacenados en el sistema de control de versiones por medio de Doxygen y presentando los
resultados en forma de un arbol radial como se muestra en la figura 2-11.
2.2.11.2. Imagen
Figura 2-11.: Visualizacion propuesta por Hanjalic [10]
2.2.11.3. Caracterizacion
Nivel Bajo
Extraccion Lıneas de codigo, logs de sistema de administracion de cambios
Transformacion Clones de codigo
Visualizacion Se presentan relaciones para identificar los clones de codigo a nivel de
lınea, atributo, metodo, clase, archivo y directorio
Tabla 2-11.: Caracterizacion de la propuesta de Hanjalic [10]
24 2 Estado del arte
2.2.12. Chronos [24]
2.2.12.1. Resumen
Servant y Jones presentan en [24] una herramienta visual que permite hacer busquedas,
exploracion y descubrimiento de patrones y eventos en codigo fuente por medio del analisis
de la informacion obtenida a partir de los sistemas de control de versiones y su enfoque
denominado “History Slicing”, la figura 2-12 muestra varios ejemplos de Chronos.
2.2.12.2. Imagen
Figura 2-12.: Visualizacion propuesta por Servant y Jones [24]
2.2.12.3. Caracterizacion
Nivel Bajo
Extraccion Lıneas de codigo, logs de sistema de administracion de cambios
Transformacion Identificacion de patrones en los cambios en el codigo fuente
Visualizacion Permite visualizar patrones de cambio en el codigo fuente
Tabla 2-12.: Caracterizacion de la propuesta de Servant y Jones [24]
2.2 Tecnicas 25
2.2.13. StartGate [19]
2.2.13.1. Resumen
Ogawa y Ma integran el analisis de la informacion obtenida de los sistemas de control
de versiones con informacion de correos electronicos relacionados e informacion publicada
en redes sociales para construir su propuesta presentada en [19]: StarGate, en la figura x se
muestra una vista tıpica de su propuesta.
2.2.13.2. Imagen
Figura 2-13.: Visualizacion propuesta por Ogawa y Ma [19]
2.2.13.3. Caracterizacion
Nivel Alto
Extraccion Logs de sistema de administracion de cambios, correo electronico
Transformacion Asociacion de patrones de cambio con palabras clave en el correo
electronico
Visualizacion Metafora de una galaxia con relaciones entre las unidades de compi-
lacion y las palabras clave de los correos
Tabla 2-13.: Caracterizacion de la propuesta de Ogawa y Ma [19]
26 2 Estado del arte
2.2.14. code swarm [18]
2.2.14.1. Resumen
Ogawa y Ma presentan en [18] code swarm, una de las visualizaciones de software que se
ha hecho mas popular a traves de los anos, utilizando un concepto de visualizacion organica
de informacion lo extienden al analisis de las contribuciones obtenidas de los sistemas de
control de versiones con el fin de construir una visualizacion artıstica en la que se puede
ver la evolucion del codigo fuente relacionada con las contribuciones de los autores, como se
muestra en la figura 2-14.
2.2.14.2. Imagen
Figura 2-14.: Visualizacion propuesta por Ogawa y Ma [18]
2.2.14.3. Caracterizacion
Nivel Alto
Extraccion Logs de sistema de administracion de cambios
Transformacion Grafo de contribuciones al repositorio
Visualizacion Video de la evolucion del grafo de contribuciones
Tabla 2-14.: Caracterizacion de la propuesta de Ogawa y Ma [18]
2.3 Clasificacion 27
2.3. Clasificacion
De acuerdo a los objetivos propuestos 1.2 y la sistematizacion del problema 1.1.3, a conti-
nuacion se hace una caracterizacion de las tecnicas presentadas en la seccion 2.2 con el fin
de identificar los aspectos que se extraen, las transformaciones y la representacion visual
obtenida.
2.3.1. Extraccion y Transformacion
Estrategia Ref Log versiones Fuentes Binario
Analisis visual de si-
militudes de codigo
[7] Texto
H-CURVE [4] Sentencias
Mini mapa de codigo [2] Unidad Compilacion
Code Park [16] Clases/Texto
CodeMetropolis [5] Paquetes, Clases,
Metodos y Atributos
Visualizacion en arbol [3] Sentencias
CodeCity [26] Paquetes, Clases,
Numero de metodos y
atributos
212D Visualizacion de
grafo de llamadas
[6] Funciones Log de ejecucion
The Brain [20] Clases, Metodos,
Lıneas de codigo
Flujo de datos entre
procedimientos
[14] Funciones Log de ejecucion
ClonEvol [10] Patrones Texto
Chronos [24] Contribuciones Texto
StartGate [19] Contribuciones Texto
code swarm [18] Contribuciones Texto
Tabla 2-15.: Caracterizacion de extraccion de conocimiento
28 2 Estado del arte
2.3.2. Representacion visual
Estrategia Ref Nivel Enfoque Estrategia
Analisis visual de simili-
tudes de codigo
[7] Bajo Estructura Representacion en arbol
resultado de consulta de
palabra clave
H-CURVE [4] Bajo Estructura Representacion fractal
de la complejidad de los
metodos
Mini mapa de codigo [2] Bajo Estructura Representacion del texto
con un bajo acercamien-
to y colores
Code Park [16] Alto/Bajo Estructura Navegacion 3D de alto
nivel y 2d de Texto
CodeMetropolis [5] Alto Estructura Representacion 3D que
usa la metafora de la ciu-
dad
Visualizacion en arbol [3] Bajo Estructura Representacion del texto
con un bajo acercamien-
to y colores
CodeCity [26] Bajo Estructura Representacion 3D que
usa la metafora de la ciu-
dad
212D Visualizacion de
grafo de llamadas
[6] Bajo Comportamiento Representacion en gra-
fo de las llamadas entre
metodos
The Brain [20] Alto Estructura Patrones de asociacion
entre sentencias, meto-
dos y clases
Flujo de datos entre pro-
cedimientos
[14] Bajo Comportamiento Representacion del flujo
de parametros entre me-
todos
Tabla 2-16.: Caracterizacion de visualizacion de conocimiento
2.3 Clasificacion 29
Estrategia Ref Nivel Enfoque Estrategia
ClonEvol [10] Alto Evolucion Representacion en arbol radial
de los clones de codigo
Chronos [24] Bajo Evolucion Representacion en cortes sobre
los resultados de la busqueda
de eventos
StartGate [19] Alto Evolucion Representacion 2D que usa la
metafora de la galaxia para
mostrar las contribuciones en
el codigo fuente
code swarm [18] Alto Evolucion Representacion 3D en grafo
para mostrar las contibuciones
en repositorios de codigo
3. Propuesta
3.1. Introduccion
En la practica, el proceso de entender un artefacto desconocido es un proceso empırico en
el cual la experiencia profesional juega un papel fundamental, si bien en la industria del
software existe un proceso de “Entrega” (Basado en el conocimiento de algun experto de
dominio o en el mejor de los casos de artefactos documentales), este proceso es incompleto,
de corto alcance y usualmente transmite el contexto general de la aplicacion, obviando as-
pectos estructurales, de comportamiento y evolutivos de arquitectura que son fundamentales
durante las actividades de mantenimiento [13].
Este no es un aspecto desconocido en la literatura cientıfica, desde la decada de los 90
existen estudios sobre los elementos cognitivos relacionados con las tareas basicas de los
desarrolladores: leer, modificar y escribir codigo desencadena esfuerzos cognitivos que fueron
caracterizados por Ko, Myers, Coblenz y Aung y publicados en el ano 2006 [17]: asociaciones
mentales entre las caracterısticas funcionales con clases, objetos, metodos, atributos, archivos
por medio de busquedas textuales complementadas con analisis sobre las dependencias entre
estos elementos, que a menudo se olvidan en el corto plazo debido a que las herramientas de
desarrollo se enfocan en presentar el codigo fuente.
Si bien el problema es conocido y se ha establecido que las herramientas de visualizacion
pueden mejorar el proceso de comprension de software [9], ninguna propuesta se ha integra-
do en la industria debido a que como se puede evidenciar en el ejercicio de caracterizacion
(2-15, 2-16), los algoritmos se han enfocado en extraer aspectos especıficos del codigo (es-
tructurales, de comportamiento o evolutivo) y su correspondiente representacion visual esta
limitada por dicho aspecto o en algunos casos tiene un enfoque estetico y artıstico que hace
que pierda un enfoque practico.
Este capitulo se encuentra organizado de la siguiente manera: con el fin de no perder un
enfoque practico de la propuesta se hizo un muestreo preliminar por medio de una encuesta
de libre intencion que fue distribuida entre estudiantes y profesionales de areas relacionadas
con el desarrollo de software y sus resultados se presentan en la seccion 3.2, posteriormen-
te se hace un analisis en el cual se relacionan dichos aspectos practicos y, en combinacion
con los aspectos previamente identificados en la literatura cientıfica y presentados en 2 se
3.2 Analisis practico 31
establece un modelo de representacion de conocimiento en 3.3. Teniendo en cuenta dicho
modelo la seccion 3.4 presenta la estructura general del algoritmo resaltando los componen-
tes principales de la propuesta a nivel de arquitectura, en la seccion 3.5 dichos componentes
son detallados estableciendo las relaciones entre la extraccion de aspectos a partir del codigo
fuente, la transformacion al modelo de conocimiento propuesto y los elementos visuales que
representan el modelo construido y finalmente, la seccion 3.6 presenta la implementacion de
la version alfa del algoritmo con algunos escenarios de prueba basicos.
3.2. Analisis practico
Uno de los problemas que ha afectado las herramientas de visualizacion de software exis-
tentes en la literatura cientıfica es la carencia de un enfoque general que sea practico para
un proposito especıfico, con el fin de desarrollar una propuesta con un enfoque practico mas
alla de la experiencia profesional del investigador y de los enfoques cientıficos encontrados
en la literatura se desarrollo una encuesta de libre intencion, la cual se enfoco en encontrar
los aspectos o caracterısticas que los desarrolladores y arquitectos de software buscan en un
artefacto de software desconocido.
El proposito de la encuesta consistio en encontrar los aspectos en el codigo fuente que buscan
los desarrolladores y arquitectos en el momento de enfrentar el problema de la comprension
de software, para esto las preguntas se enfocaron en cuestionar en un orden de prioridad
cuales son las actividades que realizan y los aspectos que se esperan lograr al realizar dichas
actividades. Las preguntas y respuestas completas de la encuesta se pueden encontrar en el
anexo 5.2.
3.2.1. Prioridades
Se cuestiono a los encuestados sobre los tres primeros elementos que consideraban priorita-
rios en el momento de un analisis inicial del codigo fuente, con el fin de representar estos
aspectos de manera que permita visualizar y caracterizar dicha importancia se decidio mos-
trar los resultados como una nube de palabras1.
Las preguntas sobre los aspectos relevantes en el codigo fuente revelaron no solo el “Que”,
sino que adicionalmente y como se podra apreciar en la presentacion de los datos el “Como”
y el “Donde”, aspectos que si bien no hacıan parte de lo que se querıa revelar son interesantes
desde la perspectiva de la presente investigacion.
1Una Nube de palabras es una representacion visual de las palabras, en donde el tamano su tamano es
definido por su frecuencia
32 3 Propuesta
3.2.1.1. Primer aspecto que se busca en un artefacto de software
Figura 3-1.: Primer aspecto que se busca en un artefacto de software
Existen dos aspectos relevantes que saltan a la vista, una perspectiva de comportamiento
en la cual se quieren evidenciar de manera algorıtmica el flujo de ejecucion: Inicio - Pro-
cesamiento - Fin, y una perspectiva estructural que sobresale a partir del interes por la
configuracion y la conexion a la base de datos.
3.2 Analisis practico 33
3.2.1.2. Segundo aspecto que se busca en un artefacto de software
Figura 3-2.: Segundo aspecto que se busca en un artefacto de software
En el segundo aspecto se destaca un enfoque de arriba a abajo ya que se introducen con-
ceptos como arquitectura, estructura, logica, frameworks, entre otros. Aunque se mantienen
elementos previos estructurales y de comportamiento.
34 3 Propuesta
3.2.1.3. Tercer aspecto que se busca en un artefacto de software
Figura 3-3.: Tercer aspecto que se busca en un artefacto de software
En el tercer aspecto se ven dos fuertes tendencias, la primera acerca de la estructura debido
al interes en la conexion con la base de datos cuyo fin es el estudio del modelo relacional y
la segunda respecto a entender la logica de la aplicacion objeto de estudio.
3.2 Analisis practico 35
3.2.1.4. Aspectos que se busca en un artefacto de software
Considerando que el orden en la busqueda de aspectos no hace realmente un aporte al estudio
se decidio combinar estas respuestas con el fin de obtener una vista general de los mismos,
los resultados se muestran en la figura 3-4.
Figura 3-4.: Aspectos que se busca en un artefacto de software
36 3 Propuesta
3.2.1.5. Proceso cognitivo para la comprension de software
Si bien en la practica los encuestados no identifican el proceso de comprension de software;
es decir que lo realizan en su dıa a dıa pero no lo asocian con el concepto se decidio en
el marco de la encuesta y encaminado con las preguntas anteriores preguntar directamente
sobre la secuencia de actividades que realizarıan en el escenario propuesto, los resultados
fueron procesados con el fin de identificar la estrategia y el enfoque, la tabla 3-1 muestra los
resultados de dicho analisis.
Estrategia Estructura Comportamiento Evolucion
Arriba-Abajo 6 8 0
Abajo-Arriba 8 16 1
Sin especificar 0 2 0
Tabla 3-1.: Proceso cognitivo para la comprension de software
Resalta en estos resultados que en la practica no existe un interes real en la evolucion del
software, un aspecto que a juicio del autor es de los mas importantes debido a que se puede
evidenciar si ha existido un seguimiento a los principios de arquitectura. Ası mismo se resalta
el enfoque en el comportamiento de las aplicaciones por medio de la ejecucion como un
elemento con muchas mas importancia sobre la estructura, patrones o diseno arquitectonico
del artefacto objeto de estudio.
3.3. Modelo de conocimiento
3.3.1. Aspectos teoricos y practicos
Sin duda existe una diferencia marcada entre la practicidad de las respuestas a la encuesta
comparada con los enfoques encontrados en la literatura cientıfica, evidenciada en los aspec-
tos que se quieren obtener o visualizar a partir del artefacto de codigo fuente; esto se explica
fundamentalmente por la poca adopcion de las herramientas de visualizacion en la industria
del software local, el inmediatismo que en muchos casos exige la industria y la misma es-
tructura de los equipos de desarrollo que debido a la rotacion deben mostrar resultados en
terminos de valor al cliente omitiendo aspectos como un manejo adecuado de los principios
de arquitectura, la calidad de codigo, buenas practicas, etc.
Las siguientes secciones concilian estas dos visiones con el fin de establecer un marco comun
que permita establecer un modelo de conocimiento extensible desde las perspectivas teoricas
y practicas.
3.3 Modelo de conocimiento 37
3.3.1.1. Fuentes de extraccion
Codigo Fuente: El artefacto objeto de estudios
Documentacion: Externa (Artefactos documentales), e Interna (Documentacion en
el codigo fuente).
Herramientas de comunicacion: Correo electronico, Chat empresarial, log de ser-
vidores de manejo de versiones, etc.
3.3.1.2. Elementos a extraer
Primer nivel: Elementos estructurales como Paquetes, Clases, Atributos, Metodos.
Segundo nivel: Elementos de comportamiento que se extraen a partir de los elementos
de primer nivel o se obtienen por medio de la instrumentalizacion del codigo fuente en
tiempo de ejecucion.
Tercer nivel: Elementos derivados del analisis de los logs de cambios en los servidores
de versiones.
Cuarto nivel: Elementos estructurales, de comportamiento o evolutivos que se ob-
tienen a partir del conocimiento consolidado de los elementos extraıdos de primer,
segundo y tercer nivel, es decir: Metricas como cohesion, acoplamiento, patrones de
diseno, etc.
Quinto nivel: Analisis por correlacion del conocimiento hasta cuarto nivel con fuen-
tes externas de informacion como herramientas de comunicacion, analisis de lenguaje
natural para complementar aspectos del codigo con fuentes externas como bases de
conocimiento o documentacion.
3.3.1.3. Componentes visuales
Conectitud: Tipo de conector entre los elementos
Proximidad: Distancia entre los elementos
Color: Colores utilizados para las formas y los conectores
Forma: Representacion geometrica de los elementos
Tamano: Tamano de los elementos
Orientacion: Angulo respecto a su eje
Fondo: Color principal de la forma
38 3 Propuesta
Transparencia: Permite presentar elementos internos
Movimiento: Permite representar cambios
Texto: Permite consultar informacion asociada a los elementos presentados
3.3 Modelo de conocimiento 39
3.3.2. Modelo conceptual de conocimiento
Con el fin de simplificar el modelo de conocimiento se ha separado en tres, la figura 3-5
presenta las aristas correspondientes a los aspectos estructurales del codigo fuente, la figura
3-6 se enfoca en las aristas que representan el comportamiento y la figura 3-7 se enfoca en
la representacion de los aspectos evolutivos.
3.3.2.1. Estructura
Figura 3-5.: Modelo conceptual de conocimiento: Estructura
40 3 Propuesta
Desde esta perspectiva presentada en la figura 3-5 los vertices corresponden a los elementos
comunes en la programacion orientada a objetos: Paquetes, Clases, Atributos y Metodos y las
aristas corresponden a herencia, pertenencia, tipo, asociaciones, agregacion y composicion.
3.3.2.2. Comportamiento
Figura 3-6.: Modelo conceptual de conocimiento: Comportamiento
Desde esta perspectiva presentada en la figura 3-6 las aristas corresponden a operaciones de
creacion, acceso, modificacion y uso de los parametros de entrada y salida de los metodos.
3.3.2.3. Evolucion
Finalmente, en la perspectiva evolutiva (figura 3-7) las aristas corresponden a las acciones
que puede realizar un autor respecto a un elemento estructural especifico (creacion, modifi-
cacion, eliminacion).
3.4 Algoritmo general 41
Figura 3-7.: Modelo conceptual de conocimiento: Evolucion
3.4. Algoritmo general
3.4.1. Introduccion
con el fin de mejorar la comprension por parte del lector del algoritmo general de extraccion
y generacion de conocimiento a partir de codigo fuente se traen algunos diagramas que
corresponden al ejercicio de arquitectura empresarial realizado dentro del marco de la materia
Ingeniera de Software II, los resultados de dicho ejercicio se encuentran en el Anexo 5.2;
3.4.2. Componentes
El algoritmo esta compuesto por tres componentes cuya estructura y comportamiento a nivel
general es presentado en las figuras 3-8 y 3-9:
El componente de extraccion de conocimiento tiene como funcion principal la construccion
del grafo de conocimiento de acuerdo al modelo previamente establecido en 3.3, sus procesos
principales son realizar un analisis de la gramatica del codigo fuente con el fin de extraer los
aspectos de primer nivel (Paquetes, Clases, Atributos, Metodos, Logs de sistemas de manejo
de versiones) y posteriormente iterar sobre estos elementos con el fin de inferir nuevos datos,
informacion y conocimiento hasta cumplir con todos los extractores configurados, finalmente
este componente debe lanzar las transacciones al motor de base de datos en grafo con la
estructura aplicada al caso particular.
El componente manejador de la base de datos de conocimiento se encarga de administrar las
tareas de almacenamiento y consulta de aristas y vertices del grafo de conocimiento.
42 3 Propuesta
Figura 3-8.: Vista de estructura del algoritmo
El componente visualizador de conocimiento se encarga de crear la escena, las formas, las
fuentes de luz, las geometrıas, la adicion de controles con el fin de permitir las busquedas
por parte del usuario.
3.5 Propuesta especifica: CodeDecipher 43
Figura 3-9.: Vista de comportamiento del algoritmo
3.5. Propuesta especifica: CodeDecipher
CodeDecipher presenta el conocimiento en una estructura de grafo, es decir que sus elemen-
tos principales son vertices y aristas, para diferenciar los elementos y ayudar a la memoria
visual se utilizan los criterios que utiliza el cerebro humano para el reconocimiento de pa-
trones: conectitud, proximidad, color, forma, tamano, orientacion, fondo, transparencia y
movimiento, enumerados por Diehl en [9].
44 3 Propuesta
3.5.1. Clases e Interfaces
Para las clases e interfaces se propone combinar los siguientes elementos visuales:
3.5.1.1. Forma
La forma puede decir de un solo vistazo el nivel de complejidad de la clase, la cantidad de
atributos y metodos se ve reflejada en el numero de filas y columnas que es utilizado por el
motor de renderizacion para construir el poliedro.
Figura 3-10.: Propuesta de representacion de forma en clases e interfaces
En la figura 3-10 se evidencian algunos ejemplos, de izquierda a derecha se puede ver como
aumenta el numero de metodos y del frente hacia atras se puede ver como aumenta el numero
de atributos. Se puede evidenciar por ejemplo al frente y a la derecha una clase con muchos
metodos que se tiene un aspecto estirado en vertical y al fondo a la izquierda una clase con
muchos atributos que tiene un aspecto aplastado.
3.5 Propuesta especifica: CodeDecipher 45
3.5.1.2. Color
Se propone que el color exprese el estado de la clase respecto a la ejecucion de un anali-
zador estatico de codigo y que refleje si se han encontrado hallazgos de nivel informatico,
advertencia o error2, la figura 3-11 muestra algunos ejemplos.
Figura 3-11.: Propuesta de uso de color en clases e interfaces
2Para este caso se toma como referencia los niveles de informe de error de la herramienta CheckStyle:
http://checkstyle.sourceforge.net/
46 3 Propuesta
3.5.1.3. Tamano
Se propone seguir la lınea de otras representaciones en tres dimensiones utilizando el tamano
del poliedro como un indicador de la cantidad de lıneas de codigo que tiene la clase (tomando
esto como una aproximacion a la complejidad o a las diferentes responsabilidades que tiene
la clase), la figura 3-12 muestra algunas variaciones para presentar este elemento visual.
Figura 3-12.: Propuesta de uso de tamano en clases e interfaces
3.5 Propuesta especifica: CodeDecipher 47
3.5.2. Paquetes
Para los paquetes se propone una presentacion basada en la forma, considerando que son
mas importante las aristas:
3.5.2.1. Forma
Se proponer utilizar una forma de anillo concentrico con el fin de presentar el nivel de cada
paquete como se presenta en la figura 3-13.
Figura 3-13.: Propuesta de representacion de paquetes
3.5.2.2. Tamano
Se propone que el tamano sea directamente proporcional a la profundidad del espacio de
nombres del paquete, dicho aspecto tambien es presentado en la figura 3-13.
48 3 Propuesta
3.5.3. Aristas
Para representar las aristas del grafo se propone combinar los siguientes elementos visuales:
3.5.3.1. Color
Se propone utilizar un codigo de color para identificar si las aristas corresponden a elementos
Estructurales (Herencia, Pertenencia, Asociaciones, Agregacion, Composicion), de Com-
portamiento (Creacion, Modificacion, Acceso, Uso, Llamado) o Evolutivos (Acceso).
Figura 3-14.: Propuesta de representacion de aristas
3.5 Propuesta especifica: CodeDecipher 49
3.5.3.2. Cercanıa
Se propone utilizar la cercanıa como elemento visual que represente el nivel de acoplamiento
y complejidad de un elemento estructural, visualmente se podra evidenciar que una alta
concentracion de clases representa un problema de diseno de software.
3.5.4. Evolucion
Para evidenciar la evolucion de software se propone construir una animacion navegable en
el tiempo para evidenciar los cambios realizados, si bien se requerirıa un procesamiento mas
complejo permitirıa representar en el grafo los cambios temporales.
3.5.4.1. Lınea de tiempo
Figura 3-15.: Propuesta de representacion de la evolucion
50 3 Propuesta
3.6. Prototipo
Se realizo una implementacion inicial del algoritmo propuesto utilizando la infraestructura de
Amazon Web Services3 y Neo4j4 como motor de almacenamiento de conocimiento en grafo,
la infraestructura fısica relacionada con los componentes se evidencia en la figura 3-165.
Figura 3-16.: Vista de cooperacion de aplicacion
3https://aws.amazon.com/es/4https://neo4j.com/5Se invita al autor a revisar los diagramas complementarios realizados dentro del marco del ejercicio de
arquitectura empresarial que se encuentran en el Anexo 5.2
3.6 Prototipo 51
3.6.1. Ejemplos
Con la version prototipo construida se efectuaron algunas ejecuciones con codigo fuente de
prueba, fundamentalmente se buscaba validar los escenarios basicos planteados de acuerdo
al las caracterısticas que se estan extrayendo y visualizando.
3.6.1.1. Clase simple
Se creo un proyecto en Java compuesto por una clase sencilla, dicho proyecto se encuentra
publicado en GitHub en https://github.com/rfcasallasm/SimpleClass.git.
Figura 3-17.: Diagrama UMl del ejemplo simple
3.6.1.2. Herencia simple
Se creo un proyecto en Java compuesto por la clase del ejercicio anterior y se configuro una he-
rencia simple, dicho proyecto se encuentra publicado en GitHub en https://github.com/rfcasallasm/SimpleClass2.git.
52 3 Propuesta
Figura 3-18.: Visualizacion del ejemplo simple
3.6.2. Pantallas
A continuacion se presentan algunas capturas de pantalla de la aplicacion, como este es
un proyecto de desarrollo continuo se invita al lector a consultar la ultima version en
https://codedecipher.dev.
Esta pantalla presenta un listado de proyectos junto con las opciones para visualizarlos.
En esta pantalla se crean los nuevos proyectos, para eso se requiere una URL de git (en este
caso se provee una de github) la cual sea accesible en internet, esta pantalla comunica con
3.6 Prototipo 53
Figura 3-19.: Diagrama UMl de la herencia simple
los componentes de extraccion y transformacion de conocimiento.
Esta pantalla presenta el componente de visualizacion del algoritmo, por medio de consultas
directas a la base de datos de conocimiento se extraen los vertices y aristas que se van a
presentar en pantalla.
54 3 Propuesta
Figura 3-20.: Visualizacion de la herencia simple
3.6 Prototipo 55
Figura 3-21.: Captura de pantalla del prototipo: pantalla inicial
56 3 Propuesta
Figura 3-22.: Captura de pantalla del prototipo: creacion de proyectos
3.6 Prototipo 57
Figura 3-23.: Captura de pantalla del prototipo: visualizacion
Parte III.
Cierre de la investigacion
4. Resultados y Discusion
CodeDecipher se presenta como un algoritmo novedoso de extraccion, almacenamiento y
visualizacion de conocimiento a partir de codigo fuente, su planteamiento combina conceptos
de inteligencia artificial, ingenierıa inversa y visualizacion de software por lo cual se cumple
el objetivo general 1.2.
4.1. Conclusiones
Se elaboro un estado del arte sobre las estrategias de extraccion, transformacion y
visualizacion de conocimiento a partir de codigo fuente.
Se hizo el analisis y la caracterizacion de los algoritmos de extraccion de conocimiento y
transformacion en representaciones visuales de conocimiento a partir de codigo fuente,
considerando areas de conocimiento como la ingenierıa inversa, inteligencia artificial,
visualizacion de software, entre otras.
Se hizo un estudio practico por medio de una encuesta de libre intencion con el fin
de evaluar la perspectiva local sobre la comprension de software, las herramientas de
visualizacion y los aspectos que se buscan a partir de un artefacto de codigo fuente.
Se conciliaron los aspectos caracterizados en la literatura cientıfica con los aspectos
practicos con el fin de encontrar un marco de trabajo comun que permitio plantear
una propuesta centrada en las dos perspectivas, ademas se complemento con el ejercicio
de arquitectura empresarial que permito enmarcar la propuesta dentro del proceso de
desarrollo de software.
Se planteo una propuesta novedosa que combina aspectos practicos, cientıficos y artısti-
cos con el fin de mejorar el proceso de comprension de software.
Se implemento una version alfa del algoritmo la cual puede ser complementada para
trabajo futuro y utilizada para realizar experimentacion y validacion practica de la
propuesta.
60 4 Resultados y Discusion
4.2. Verificacion, contraste y evaluacion de los objetivos
Se verifican los objetivos iniciales propuestos frente a los resultados obtenidos y se evidencia
que se cumplieron en su totalidad. A continuacion se resume el contraste de los objetivos
junto con el soporte del cumplimiento:
Objetivo Soporte de Cumplimiento
Caracterizar los algoritmos de extraccion de
conocimiento y las estrategias de visualiza-
cion a partir de codigo fuente existentes por
medio de la elaboracion de un estado del arte
que integre las perspectivas de la ingenierıa
inversa, visualizacion de software e inteligen-
cia artificial con el fin de establecer un marco
de trabajo teorico y metodologico actualiza-
do
Se construyo el estado del arte (Capitulo
2), identificando y caracterizando las estrate-
gias de extraccion y de visualizacion (Seccion
2.3), considerando las diferentes areas de co-
nocimiento relacionadas y complementando
estas estrategias con una perspectiva practi-
ca obtenida a partir de una encuesta de libre
intencion (3.2 y Anexo 5.2), estableciendo un
marco de trabajo comun que concilio los di-
ferentes aspectos (Seccion: 3.3)
Proponer un algoritmo que combine tecni-
cas de inteligencia artificial, visualizacion de
software e ingenierıa inversa adecuadas pa-
ra analizar, interpretar y extraer los datos a
partir del codigo fuente e integra en una vi-
sualizacion que integre aspectos estructura-
les, de comportamiento y evolutivos del soft-
ware
Se propone un algoritmo general (Seccion:
3.4), en el cual se toman a consideracion los
niveles de conocimiento y las posibles tecni-
cas de inteligencia artificial e ingenierıa inver-
sa aplicables para la extraccion y transforma-
cion en el modelo de conocimiento estableci-
do (Seccion 3.3) y posteriormente se plantea
una visualizacion de los elementos conteni-
dos en dicho modelo integrando aspectos es-
tructurales, de comportamiento y evolutivos
(Seccion 3.5)
Validar el algoritmo propuesto por medio de
la ejecucion en escenarios de prueba contro-
lados que permitan valorar su efectividad en
al comprension del software
Se presenta la version alfa de la implementa-
cion del algoritmo (Seccion: 3.6), y algunos
ejemplos de ejecucion controlada, sin embar-
go se establece que validar la efectividad re-
querirıa un tipo de estudio mas amplio el cual
se encuentra por fuera del alcance de los re-
cursos que tiene el proyecto y se plantea como
un elemento futuro
Tabla 4-1.: Cumplimiento de Objetivos
4.3 Sıntesis del modelo propuesto 61
4.3. Sıntesis del modelo propuesto
El planteamiento general del algoritmo se encuentra documentado en la seccion 3.4 de la
propuesta, sin embargo se trae nuevamente el diagrama de comportamiento de aplicacion el
cual sintetiza el modelo como referencia 4-1.
Figura 4-1.: Sıntesis del algoritmo
62 4 Resultados y Discusion
4.4. Aportes originales
La propuesta del algoritmo de extraccion y visualizacion de conocimiento a partir de
codigo fuente es un aporte original debido a que considera los aspectos estructurales,
de comportamiento y evolutivos del software, hasta ahora la mayorıa de propuestas se
enfocan en solo uno de dichos aspectos.
Este documento hace un aproximacion preliminar al proceso de comprension de soft-
ware a nivel local del cual no se encuentran mas referentes.
4.5. Trabajos o Publicaciones derivadas
Artıculos: Al finalizar la implementacion beta de la propuesta planteada se presentara
un articulo a nivel nacional y dentro del marco de la Conferencia de visualizacion de
software que organiza la IEEE el siguiente ano.
5. Prospectiva del Trabajo de Grado
5.1. Lıneas de Investigacion Futuras
Ingenierıa de Software: La visualizacion de software y la comprension de software
usualmente hacen parte de la lınea de investigacion en ingenierıa de software, por su
importancia y relevancia en los costos del desarrollo facilmente pueden convertirse en
lıneas principales.
Visualizacion de conocimiento: La propuesta de visualizacion da pie para utilizarse
en otras estructura de grafo en la cual los vertices tienen una representacion particular
dependiendo del tipo de elemento que representan.
5.2. Trabajos de Investigacion Futuros
Extension: Teniendo en cuenta el caracter generico del algoritmo se pueden agregar
nuevos extractores y su correspondiente adicion visual para representar el resultado
del conocimiento extraıdo.
Validacion: Considerando que para validar el algoritmo propuesto se deben plantear
estudios experimentales en los cuales se haga una metrica sobre el impacto de usar o
no la visualizacion queda completamente abierta toda una lınea de trabajo.
Bibliografıa
[1] Abebe, S. L. ; Tonella, P.: Natural Language Parsing of Program Element Names
for Concept Extraction. En: 2010 IEEE 18th International Conference on Program
Comprehension, 2010. – ISSN 1092–8138, p. 156–159
[2] Bacher, Ivan ; Mac Namee, Brian ; Kelleher, John D.: The Code Mini-Map
Visualisation: Encoding Conceptual Structures Within Source Code. En: 2018 IEEE
Working Conference on Software Visualization (VISSOFT), IEEE, sep 2018. – ISBN
978–1–5386–8292–0, p. 127–131
[3] Bacher, Ivan ; Namee, Brian M. ; Kelleher, John D.: On Using Tree Visualisation
Techniques to Support Source Code Comprehension. En: 2016 IEEE Working Conferen-
ce on Software Visualization (VISSOFT), IEEE, oct 2016. – ISBN 978–1–5090–3850–3,
p. 91–95
[4] Bae, Min-Jung ; Ji, Jeong-Hoon ; Woo, Gyun: H-CURVE: A Simple Visualizing
Method of Source Code. En: 2008 Third International Conference on Convergence
and Hybrid Information Technology, IEEE, nov 2008. – ISBN 978–0–7695–3407–7, p.
775–780
[5] Balogh, Gergo ; Beszedes, Arpad: CodeMetrpolis — A minecraft based collaboration
tool for developers. En: 2013 First IEEE Working Conference on Software Visualization
(VISSOFT), IEEE, sep 2013. – ISBN 978–1–4799–1457–9, p. 1–4
[6] Bohnet, J. ; Dollner, J.: Facilitating Exploration of Unfamiliar Source Code by Pro-
viding 21/2D Visualizations of Dynamic Call Graphs. En: 2007 4th IEEE International
Workshop on Visualizing Software for Understanding and Analysis, IEEE, jun 2007. –
ISBN 1–4244–0599–8, p. 63–66
[7] Burch, Michael ; Strotzer, Julian ; Weiskopf, Daniel: Visual Analysis of Source
Code Similarities. En: 2015 19th International Conference on Information Visualisation,
IEEE, jul 2015. – ISBN 978–1–4673–7568–9, p. 21–27
[8] Corbi, T. A.: Program understanding: Challenge for the 1990s. En: IBM Systems
Journal 28 (1989), Nr. 2, p. 294–306. – ISSN 0018–8670
[9] Diehl, S: Software visualization: visualizing the structure, behaviour, and evolution of
software. (2007)
Bibliografıa 65
[10] Hanjalic, Avdo: ClonEvol: Visualizing software evolution with code clones. En: 2013
First IEEE Working Conference on Software Visualization (VISSOFT), IEEE, sep 2013.
– ISBN 978–1–4799–1457–9, p. 1–4
[11] Harris, David R. ; Yeh, Alexander S. ; Reubenstein, Howard B.: Extracting archi-
tectural features from source code. En: Automated Software Engineering 3 (1996), jun,
Nr. 1-2, p. 109–138. – ISSN 0928–8910
[12] Ichii, Makoto ; Myojin, Tomoyuki ; Nakagawa, Yuichiroh ; Chikahisa, Masaki ;
Ogawa, Hideto: A Rule-based Automated Approach for Extracting Models from Source
Code. En: 2012 19th Working Conference on Reverse Engineering, IEEE, oct 2012. –
ISBN 978–0–7695–4891–3, p. 308–317
[13] IEEE: IEEE Standard for Software Maintenance. IEEE, 1998. – ISBN 0738103365
[14] Ishio, Takashi ; Etsuda, Shogo ; Inoue, Katsuro: A lightweight visualization of inter-
procedural data-flow paths for source code reading. En: 2012 20th IEEE International
Conference on Program Comprehension (ICPC), IEEE, jun 2012. – ISBN 978–1–4673–
1216–5, p. 37–46
[15] Jiomekong, Azanzi ; Camara, Gaoussou: An Approach for Knowledge Extraction
from Source Code (KNESC) of Typed Programming Languages. 2018, p. 122–131
[16] Khaloo, Pooya ; Maghoumi, Mehran ; Taranta, Eugene ; Bettner, David ; Lavio-
la, Joseph: Code Park: A New 3D Code Visualization Tool. En: 2017 IEEE Working
Conference on Software Visualization (VISSOFT), IEEE, sep 2017. – ISBN 978–1–
5386–1003–9, p. 43–53
[17] Ko, Andrew J. ; Myers, Brad A. ; Coblenz, Michael J. ; Aung, Htet H.: An Ex-
ploratory Study of How Developers Seek, Relate, and Collect Relevant Information
during Software Maintenance Tasks. En: IEEE Transactions on Software Engineering
32 (2006), dec, Nr. 12, p. 971–987. – ISSN 0098–5589
[18] Ogawa, M. ; Kwan-Liu Ma: code swarm: A Design Study in Organic Software Visua-
lization. En: IEEE Transactions on Visualization and Computer Graphics 15 (2009),
nov, Nr. 6, p. 1097–1104. – ISSN 1077–2626
[19] Ogawa, Michael ; Ma, Kwan-Liu: StarGate: A Unified, Interactive Visualization of
Software Projects. En: 2008 IEEE Pacific Visualization Symposium, IEEE, mar 2008.
– ISBN 978–1–4244–1966–1, p. 191–198
[20] Palepu, Vijay K. ; Jones, James A.: Visualizing constituent behaviors within execu-
tions. En: 2013 First IEEE Working Conference on Software Visualization (VISSOFT),
IEEE, sep 2013. – ISBN 978–1–4799–1457–9, p. 1–4
66 Bibliografıa
[21] Putrycz, Erik ; Kark, Anatol W.: Recovering Business Rules from Legacy Source
Code for System Modernization. En: Advances in Rule Interchange and Applications.
Berlin, Heidelberg : Springer Berlin Heidelberg, p. 107–118
[22] Robson, D.J. ; Bennett, K.H. ; Cornelius, B.J. ; Munro, M.: Approaches to
program comprehension. En: Journal of Systems and Software 14 (1991), feb, Nr. 2, p.
79–84. – ISSN 01641212
[23] Schafer, T. ; Eichberg, M. ; Haupt, M. ; Mezini, M.: The SEXTANT Software
Exploration Tool. En: IEEE Transactions on Software Engineering 32 (2006), sep, Nr.
9, p. 753–768. – ISSN 0098–5589
[24] Servant, Francisco ; Jones, James A.: Chronos: Visualizing slices of source-code his-
tory. En: 2013 First IEEE Working Conference on Software Visualization (VISSOFT),
IEEE, sep 2013. – ISBN 978–1–4799–1457–9, p. 1–4
[25] Tan, Hee Beng K. ; Kow, Juan T.: An approach for extracting code fragments that
implement functionality from source programs. En: Journal of Software Maintenance
and Evolution: Research and Practice 13 (2001), jan, Nr. 1, p. 53–75. – ISSN 1532–060X
[26] Wettel, Richard ; Lanza, Michele ; Robbes, Romain: Software systems as cities.
En: Proceeding of the 33rd international conference on Software engineering - ICSE ’11.
New York, New York, USA : ACM Press, 2011. – ISBN 9781450304450, p. 551
top related