Algoritmo multidimensional para la extracci on y ...repository.udistrital.edu.co/bitstream/11349/15776/... · para la representaci on de conocimiento propone un algoritmo novedoso

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.3. Mini mapa de codigo [2] . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.3.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.3.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15


2.2.4. Code Park [16] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.4.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.4.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16


2.2.5. CodeMetropolis [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.5.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.5.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17


2.2.6. Visualizacion en arbol [3] . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.6.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.6.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18


2.2.7. CodeCity [26] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.7.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.7.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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.9. The Brain [20] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2.9.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2.9.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Contenido xiii


2.2.10. Flujo de datos entre procedimientos [14] . . . . . . . . . . . . . . . . 22

2.2.10.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.10.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22


2.2.11. ClonEvol [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.11.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.11.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23


2.2.12. Chronos [24] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.12.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.12.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24


2.2.13. StartGate [19] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.13.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.13.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25


2.2.14. code swarm [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.2.14.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.2.14.2. Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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


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


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


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]


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]


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]


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]


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]


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]


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]


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]


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]


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]


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]


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]


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]


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]


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]


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]


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]


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]


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]


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


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

https://github.com/rfcasallasm/SimpleClass.git

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

https://codedecipher.dev

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

Documents

Algoritmo multidimensional para la extracci on y ...repository.udistrital.edu.co/bitstream/11349/15776/... · para la representaci on de conocimiento propone un algoritmo novedoso