Algoritmo multidimensional para la extracción y visualización de la arquitectura de un artefacto de software a partir del código fuente

Texto completo

(1)Algoritmo multidimensional para la extracción y visualización de la arquitectura de un artefacto de software a partir de su código fuente. Raúl Fernando Casallas Malaver. Universidad Distrital Francisco José de Caldas Facultad de Ingenierı́a, Especialización en Ingenierı́a de Software Bogotá, Colombia 2019.

(2)

(3) Algoritmo multidimensional para la extracción y visualización de la arquitectura de un artefacto de software a partir de su código fuente. Raúl 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 Londoño. Universidad Distrital Francisco José de Caldas Facultad de Ingenierı́a, Especialización en Ingenierı́a de Software Bogotá, Colombia 2019.

(4)

(5) If you’re not willing to look stupid, nothing great is ever going to happen to you. Gregory House (House M.D.).

(6)

(7) Agradecimientos A los profesores Joaquin Javier Mesa y Lilian Bejarano, quienes con su dedicación, esfuerzo y combinación de estilos pedagógicos en el seminario de investigación desencadenaron reflexiones profundas acerca del carácter de la investigación en la Ingenierı́a, alentaron a seleccionar un tema complejo y desafiante para el presente trabajo y constantemente impulsaron el esfuerzo continuo necesario para llevarlo a cabo. A mi hijo Sebastian, el mejor amigo de mi niño interior y quien constantemente me motiva a convertirme en el padre que ve a través de sus ojos. Finalmente a quien considero mi ejemplo e inspiración, mi gran amiga Angélica Veloza, es difı́cil cuantificar las veces que sin darte cuenta me has ayudado a continuar. Gracias por motivar, apoyar y asesorar esta investigación. Finalmente y de manera muy sincera quiero dar una mención especial a los profesores Alejandro Paolo Daza y John Jairo Londoño ya que a pesar de haber sido asignados de manera extemporánea al proyecto fueron una gran fuente de reflexión, motivación 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..

(8)

(9) ix. Resumen Desde los años 90 se ha documentado que la comprensión de programas o software es un proceso complejo que desafı́a a desarrolladores independientemente de su nivel de experiencia, usual pero no exclusivamente en fase de mantenimiento [11]. En términos generales se acepta que las herramientas visuales permiten mejorar los procesos cognitivos asociados a la comprensión y el análisis de datos, dando pie a un gran número de herramientas de computación visual para áreas como la medicina, arquitectura, etc. Sin embargo no es común encontrar dichas herramientas en la ingenierı́a de software. Este trabajo hace una caracterización de los datos, información y conocimiento que se pueden extraer a partir del código fuente y, por medio de un análisis de las estrategias existentes para la representación de conocimiento propone un algoritmo novedoso de visualización de software, que combina estrategias de diferentes áreas de conocimiento como la inteligencia artificial, ingenierı́a inversa y visualización de software. Se presentan los resultados preliminares de una implementación parcial del algoritmo en escenarios de prueba controlados junto con las perspectivas de trabajo futuro.. Palabras clave: .. Comprensión de software, Comprensión de programas, Visualización de software, Visualización de programas, Mantenimiento de software.

(10) x. Abstract Since 90’s it has been documented that understanding programs/software is a complex process 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 computing 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 visualization, Software maintenance.

(11) Contenido Agradecimientos. VII. Resumen. IX. Abstract. X. I. Descripción de la investigación 1. Descripción de la investigación 1.1. Planteamiento y formulación del problema . . . . . . . . . . 1.1.1. Planteamiento del problema . . . . . . . . . . . . . . 1.1.2. Formulación del problema . . . . . . . . . . . . . . . 1.1.3. Sistematización del problema . . . . . . . . . . . . . 1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1. Objetivo general . . . . . . . . . . . . . . . . . . . . 1.2.2. Objetivos especı́ficos . . . . . . . . . . . . . . . . . . 1.3. Justificación del trabajo/investigación . . . . . . . . . . . . . 1.3.1. Justificación teórica . . . . . . . . . . . . . . . . . . . 1.3.2. Justificación Metodológica . . . . . . . . . . . . . . . 1.3.3. Justificación Práctica . . . . . . . . . . . . . . . . . . 1.4. Hipótesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5. Marco referencial . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1. Ciencia cognitiva . . . . . . . . . . . . . . . . . . . . 1.5.1.1. Amplificación de inteligencia . . . . . . . . 1.5.1.2. Visualización de información . . . . . . . . 1.5.2. Comprensión de software . . . . . . . . . . . . . . . . 1.5.3. Visualización de Software . . . . . . . . . . . . . . . 1.6. Metodologı́a de la investigación . . . . . . . . . . . . . . . . 1.6.1. Tipo de estudio . . . . . . . . . . . . . . . . . . . . . 1.6.2. Método de investigación . . . . . . . . . . . . . . . . 1.6.3. Fuentes y técnicas para la recolección de información 1.6.4. Tratamiento de la información . . . . . . . . . . . . . 1.7. Organización del trabajo de grado . . . . . . . . . . . . . . .. 2 . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. 3 3 3 4 4 5 5 5 5 5 6 6 6 7 7 7 7 7 8 9 9 9 9 9 10.

(12) Contenido. xii. II. Desarrollo de la investigación. 11. 2. Estado del arte 2.1. Introducción . . . . . . . . . . . . . . . . . . . . . 2.2. Técnicas . . . . . . . . . . . . . . . . . . . . . . . 2.2.1. Análisis visual de similitudes de código [7] 2.2.1.1. Resumen . . . . . . . . . . . . . 2.2.1.2. Imagen . . . . . . . . . . . . . . 2.2.1.3. Caracterización . . . . . . . . . . 2.2.2. H-CURVE [4] . . . . . . . . . . . . . . . . 2.2.2.1. Resumen . . . . . . . . . . . . . 2.2.2.2. Imagen . . . . . . . . . . . . . . 2.2.2.3. Caracterización . . . . . . . . . . 2.2.3. Mini mapa de código [2] . . . . . . . . . . 2.2.3.1. Resumen . . . . . . . . . . . . . 2.2.3.2. Imagen . . . . . . . . . . . . . . 2.2.3.3. Caracterización . . . . . . . . . . 2.2.4. Code Park [16] . . . . . . . . . . . . . . . 2.2.4.1. Resumen . . . . . . . . . . . . . 2.2.4.2. Imagen . . . . . . . . . . . . . . 2.2.4.3. Caracterización . . . . . . . . . . 2.2.5. CodeMetropolis [5] . . . . . . . . . . . . . 2.2.5.1. Resumen . . . . . . . . . . . . . 2.2.5.2. Imagen . . . . . . . . . . . . . . 2.2.5.3. Caracterización . . . . . . . . . . 2.2.6. Visualización en árbol [3] . . . . . . . . . . 2.2.6.1. Resumen . . . . . . . . . . . . . 2.2.6.2. Imagen . . . . . . . . . . . . . . 2.2.6.3. Caracterización . . . . . . . . . . 2.2.7. CodeCity [26] . . . . . . . . . . . . . . . . 2.2.7.1. Resumen . . . . . . . . . . . . . 2.2.7.2. Imagen . . . . . . . . . . . . . . 2.2.7.3. Caracterización . . . . . . . . . . 2.2.8. 2 12 D Visualización de grafo de llamadas [6] 2.2.8.1. Resumen . . . . . . . . . . . . . 2.2.8.2. Imagen . . . . . . . . . . . . . . 2.2.8.3. Caracterización . . . . . . . . . . 2.2.9. The Brain [20] . . . . . . . . . . . . . . . . 2.2.9.1. Resumen . . . . . . . . . . . . . 2.2.9.2. Imagen . . . . . . . . . . . . . .. 12 12 13 13 13 13 13 14 14 14 14 15 15 15 15 16 16 16 16 17 17 17 17 18 18 18 18 19 19 19 19 20 20 20 20 21 21 21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..

(13) Contenido 2.2.9.3. Caracterización . . . . . . 2.2.10. Flujo de datos entre procedimientos 2.2.10.1. Resumen . . . . . . . . . 2.2.10.2. Imagen . . . . . . . . . . 2.2.10.3. Caracterización . . . . . . 2.2.11. ClonEvol [10] . . . . . . . . . . . . 2.2.11.1. Resumen . . . . . . . . . 2.2.11.2. Imagen . . . . . . . . . . 2.2.11.3. Caracterización . . . . . . 2.2.12. Chronos [24] . . . . . . . . . . . . . 2.2.12.1. Resumen . . . . . . . . . 2.2.12.2. Imagen . . . . . . . . . . 2.2.12.3. Caracterización . . . . . . 2.2.13. StartGate [19] . . . . . . . . . . . . 2.2.13.1. Resumen . . . . . . . . . 2.2.13.2. Imagen . . . . . . . . . . 2.2.13.3. Caracterización . . . . . . 2.2.14. code swarm [18] . . . . . . . . . . . 2.2.14.1. Resumen . . . . . . . . . 2.2.14.2. Imagen . . . . . . . . . . 2.2.14.3. Caracterización . . . . . . 2.3. Clasificación . . . . . . . . . . . . . . . . . 2.3.1. Extracción y Transformación . . . . 2.3.2. Representación visual . . . . . . . .. xiii . . . [14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. 3. Propuesta 3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Análisis práctico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1. Prioridades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1.1. Primer aspecto que se busca en un artefacto de software . 3.2.1.2. Segundo aspecto que se busca en un artefacto de software 3.2.1.3. Tercer aspecto que se busca en un artefacto de software . 3.2.1.4. Aspectos que se busca en un artefacto de software . . . . . 3.2.1.5. Proceso cognitivo para la comprensión de software . . . . 3.3. Modelo de conocimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1. Aspectos teóricos y prácticos . . . . . . . . . . . . . . . . . . . . . . 3.3.1.1. Fuentes de extracción . . . . . . . . . . . . . . . . . . . . 3.3.1.2. Elementos a extraer . . . . . . . . . . . . . . . . . . . . . 3.3.1.3. Componentes visuales . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. 21 22 22 22 22 23 23 23 23 24 24 24 24 25 25 25 25 26 26 26 26 27 27 28. . . . . . . . . . . . . .. 30 30 31 31 32 33 34 35 36 36 36 37 37 37.

(14) Contenido. 1. 3.3.2. Modelo conceptual de conocimiento 3.3.2.1. Estructura . . . . . . . . 3.3.2.2. Comportamiento . . . . . 3.3.2.3. Evolución . . . . . . . . . 3.4. Algoritmo general . . . . . . . . . . . . . . 3.4.1. Introducción . . . . . . . . . . . . . 3.4.2. Componentes . . . . . . . . . . . . 3.5. Propuesta especifica: CodeDecipher . . . . 3.5.1. Clases e Interfaces . . . . . . . . . 3.5.1.1. Forma . . . . . . . . . . . 3.5.1.2. Color . . . . . . . . . . . 3.5.1.3. Tamaño . . . . . . . . . . 3.5.2. Paquetes . . . . . . . . . . . . . . . 3.5.2.1. Forma . . . . . . . . . . . 3.5.2.2. Tamaño . . . . . . . . . . 3.5.3. Aristas . . . . . . . . . . . . . . . . 3.5.3.1. Color . . . . . . . . . . . 3.5.3.2. Cercanı́a . . . . . . . . . . 3.5.4. Evolución . . . . . . . . . . . . . . 3.5.4.1. Lı́nea de tiempo . . . . . 3.6. Prototipo . . . . . . . . . . . . . . . . . . 3.6.1. Ejemplos . . . . . . . . . . . . . . . 3.6.1.1. Clase simple . . . . . . . . 3.6.1.2. Herencia simple . . . . . . 3.6.2. Pantallas . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. 39 39 40 40 41 41 41 43 44 44 45 46 47 47 47 48 48 49 49 49 50 51 51 51 52. III. Cierre de la investigación. 58. 4. Resultados y Discusión 4.1. Conclusiones . . . . . . . . . . . . . . . . 4.2. Verificación, contraste y evaluación de los 4.3. Sı́ntesis del modelo propuesto . . . . . . 4.4. Aportes originales . . . . . . . . . . . . . 4.5. Trabajos o Publicaciones derivadas . . .. . . . . .. 59 59 60 61 62 62. 5. Prospectiva del Trabajo de Grado 5.1. Lı́neas de Investigación Futuras . . . . . . . . . . . . . . . . . . . . . . . . . 5.2. Trabajos de Investigación Futuros . . . . . . . . . . . . . . . . . . . . . . . .. 63 63 63. Bibliografı́a. . . . . . . objetivos . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 64.

(15) Parte I. Descripción de la investigación.

(16) 1. Descripción de la investigación 1.1.. Planteamiento y formulación 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 ejecución del proyecto, o cuando el equipo completo se enfrenta a un proyecto correspondiente a la fase de mantenimiento de un artefacto desconocido: la comprensión del software. El proceso de incorporar el conocimiento obtenido a partir del análisis, las decisiones de arquitectura, los acuerdos en cuanto a patrones de diseño y estándares de desarrollo, o al menos una mı́nima abstracción 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: Contextualización: Uno o varios usuarios y explican desde su perspectiva que hace el software, se obtiene una visión funcional inicial (usualmente incompleta). Conocimiento de expertos: Un integrante del equipo de trabajo expone los aspectos más relevantes del software en una sesión 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 visión técnica inicial (abstracta). Documentación: Se brinda acceso al conjunto de artefactos documentales que en el momento de su elaboración 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 comprensión 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 única fuente objetiva de conocimiento termina siendo el código fuente del software y se espera que al sumar la experiencia al menos los elementos clave sean comprendidos..

(17) 4. 1 Descripción de la investigación. Los errores en la compresión de software llevan a que el código fuente adquiera nuevas capas de complejidad y a su vez que sea más difı́cil de mantener; Elementos como duplicidad de código, bloques, reglas de negocio, antipatrones de diseño e introducción de nuevos defectos desencadenan el fin prematuro del ciclo de vida del software. En la actualidad existen un sinnúmero de estrategias que tratan de utilizar técnicas de ingenierı́a inversa, procesamiento de lenguaje natural, minerı́a de repositorios de código fuente cuyo fin es extraer información en forma de modelos representados según el estándar UML, resúmenes de código en lenguaje natural o listados de reglas de negocio que en muchas ocasiones dan una versión 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 código fuente a intervenir. Si bien se ha establecido que el código fuente es una fuente valida de información [9], no es claro cuáles son las caracterı́sticas estructurales, de comportamiento y evolutivas que se pueden extraer ni él nivel de abstracción o especificidad adecuado para construir una visualización efectiva y eficaz que mejore el proceso de comprensión de software.. 1.1.2.. Formulación del problema. ¿Qué aspectos estructurales, de comportamiento y evolutivos se pueden obtener a partir del código fuente con el fin de construir una representación visual que mejore el proceso de comprensión del software?. 1.1.3.. Sistematización del problema. ¿Qué información se puede obtener a partir del código fuente de un artefacto? • ¿Qué técnicas se utilizan? • ¿Como se puede caracterizar dicha información? • ¿A qué nivel de abstracción/especificidad? ¿Qué estrategias de visualización de código fuente existen? • ¿Qué aspectos representan del software? • ¿Como se pueden caracterizar/clasificar? ¿Como se puede construir una visualización que integre aspectos estructurales, de comportamiento y evolutivos del software para mejorar el proceso de comprensión del software? • ¿Cuáles aspectos son relevantes para la comprensión del software? • ¿Cuáles aspectos se pueden representar de manera visual? • ¿Como se pueden combinar dichas visualizaciones?.

(18) 1.2 Objetivos. 5. ¿Como se puede validar el algoritmo? • ¿Qué escenarios de prueba se pueden diseñar para evaluar el algoritmo? • ¿Qué criterios se pueden utilizar para valorar la efectividad en la comprensión del software?. 1.2.. Objetivos. 1.2.1.. Objetivo general. Diseñar un algoritmo para la extracción y representación visual del conocimiento a partir de código fuente con el fin de mejorar el proceso de comprensión de software.. 1.2.2.. Objetivos especı́ficos. Caracterizar los algoritmos de extracción de conocimiento y las estrategias de visualización a partir de código fuente existentes por medio de la elaboración de un estado del arte que integre las perspectivas de la ingenierı́a inversa, visualización de software e inteligencia artificial con el fin de establecer un marco de trabajo teórico y metodológico actualizado. Proponer un algoritmo que combine técnicas de inteligencia artificial, visualización de software e ingenierı́a inversa adecuadas para analizar, interpretar y extraer los datos a partir del código fuente e integra en una visualización que integre aspectos estructurales, de comportamiento y evolutivos del software. Validar el algoritmo propuesto por medio de la ejecución en escenarios de prueba controlados que permitan valorar su efectividad en al comprensión del software. 1.3.. Justificación del trabajo/investigación. El proceso de comprensión del software permite al analista, arquitecto o desarrollador entender las caracterı́sticas clave del software, las decisiones de diseño, la arquitectura y otros aspectos necesarios para intervenir un determinado artefacto dentro del marco de un proyecto de ingenierı́a de software.. 1.3.1.. Justificación teórica. Si bien se ha establecido que el código fuente de un artefacto de software es una fuente primaria de información y que a partir de él se pueden extraer reglas de negocio, documentación, resúmenes de código, aspectos de diseño, etc [1, 11, 15, 21]. No es claro cuanta de.

(19) 6. 1 Descripción de la investigación. esta información no es trivial (es decir que puede ser deducida con una inspección sencilla al código fuente) o realmente sea un aporte al proceso de comprensión del software (es decir que la representación obtenida no sea más compleja que el código fuente en sı́), razón por la cual esta investigación es relevante ya que se va a establecer una caracterización de los algoritmos y técnicas existentes según la información extraı́da y el nivel de complejidad de la representación generada y el aporte al conocimiento que representa la propuesta del nuevo algoritmo de extracción y representación del conocimiento a partir de código fuente.. 1.3.2.. Justificación Metodológica. Esta investigación se justifica desde el punto de vista metodológico ya que la implementación del algoritmo propuesto y su respectiva ejecución 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 comparación con otras estrategias de extracción y visualización de información a partir de código fuente.. 1.3.3.. Justificación Práctica. Desde una perspectiva practica esta investigación se fundamenta en la necesidad de obtener una representación visual del código fuente que sea efectiva y facilite el proceso de comprensión del software, basándose en la dualidad arte-ciencia de la visualización de software [9], y el uso común de metáforas y analogı́as con el fin de asociar conceptos abstractos con representaciones mentales. Los resultados serán relevantes ya que al utilizar el algoritmo propuesto en la industria permitirá evaluar y mejorar el proceso de comprensión del software.. 1.4.. Hipótesis. La combinación de información estructural, de comportamiento y evolutiva del código fuente en una representación visual n-dimensional permitirá optimizar el proceso de comprensión del software..

(20) 1.5 Marco referencial. 1.5.. Marco referencial. 1.5.1.. Ciencia cognitiva. 7. A nivel general este proyecto se enmarca dentro de la ciencia cognitiva, ya que involucra la naturaleza, las tareas y las funciones de la cognición; la mente y sus procesos. Incluye aspectos como: lenguaje, percepción, memoria, atención, razonamiento y emoción e involucra áreas como lingüı́stica, psicologı́a, inteligencia artificial, neurociencia y antropologı́a.. 1.5.1.1.. Amplificación de inteligencia. El uso de herramientas tecnológicas con el fin de aumentar o mejorar los procesos de cognición y adquisición de conocimiento ha sido denominado Amplificación 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 comprensión basado en sus necesidades individuales para la toma de decisiones que permitan solucionar problemas.. 1.5.1.2.. Visualización de información. En este contexto, se define la Visualización de información como la transformación de datos en representaciones visuales que permitan explorar, analizar u en otras palabras observar la información para la toma de decisiones y la solución de problemas.. 1.5.2.. Comprensión de software. El área de comprensión de software, que en ocasiones varia su definición 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ı́sticas estructurales, de comportamiento y evolución de un determinado artefacto de código fuente. En los años 90, Corbi T. enunció tres teorı́as cognitivas sobre el proceso de comprensión o entendimiento de programas [8]: De abajo hacia arriba: El desarrollador esencialmente construye múltiples abstracciones por medio de la lectura del código fuente asociando categorı́as similares mientras va subiendo de nivel. De arriba hacia abajo: El desarrollador utiliza su experiencia previa y una comprensión de la lógica de negocio con el fin de crear hipótesis mentales acerca de como deberı́a.

(21) 8. 1 Descripción de la investigación estar construido el software y continua con un proceso de prueba de esta hipótesis, es decir que verifica en el código fuente si fue o no implementado de la manera como supuso. Oportunı́stica: El desarrollador utiliza una combinación de las dos teorı́as anteriores alternando entre ellas en momentos de dificultad o verificación o no de hipótesis.. 1.5.3.. Visualización de Software. La aplicación de la tecnologı́a con el fin de transformar datos obtenidos a partir pero no exclusivamente, del código 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 área de la Visualización 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 clasificación general de los algoritmos de visualización de software enfocándose en el objeto principal de la visualización: Visualización estática: Estas visualizaciones utilizan el código fuente como base y utilizan un análisis sintáctico para transformarlo en representaciones visuales enfocadas en las relaciones estáticas (atributos, métodos, asociaciones, etc.). Visualización dinámica: Estas visualizaciones utilizan un mecanismo de “instrumentalización” para obtener un log de llamados o en algunos casos acceder directamente a la asignación de memoria RAM, en esta categorı́a se encuentran animaciones de algoritmos, análisis de pilas y colas de memoria, etc. Depuración visual: Esta visualización combina el código fuente con elementos de visualización estática y dinámica con el fin de permitir al usuario detener el programa en un punto determinado y hacer análisis de asignación de variables, datos, memoria, etc. Arquitectura de software: Se combinan documentación y código fuente con análisis estáticos y dinámicos con el fin de construir métricas de alto nivel que permitan encontrar problemas en el software. Evolución de software: Se utilizan como fuente los logs de los repositorios de código, 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 análisis estático o dinámico a la dimensión temporal..

(22) 1.6 Metodologı́a de la investigación. 1.6.. Metodologı́a de la investigación. 1.6.1.. Tipo de estudio. 9. La presente investigación pertenece al tipo proyectivo, ya que su objetivo es diseñar un nuevo algoritmo de extracción y visualización de conocimiento a partir del código fuente; si bien existen fundamentos teóricos respecto a la extracción de conocimiento a partir del código fuente [1, 11, 12, 21, 23, 25], la visualización de software en muchos aspectos se considera un arte [9] y la comprensión del software aun es un área 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 teórica y metodológica que permita proponer un algoritmo novedoso que mejore el proceso de comprensión de software.. 1.6.2.. Método de investigación. El método de investigación de la presente propuesta es inductivo debido a que pretende hacer una revisión teórica de las estrategias particulares para la extracción de conocimiento, extracción de información a partir de código fuente, representación y visualización del conocimiento y en general, visualización de software con el fin de unificar criterios, caracterizar y clasificar estrategias y aplicarlas a un modelo general de extracción y representación visual de conocimiento a partir de código fuente.. 1.6.3.. Fuentes y técnicas para la recolección de información. Se utilizarán las siguientes fuentes de recolección de información: Libros generales sobre las áreas generales del conocimiento relacionadas con el tema de la investigación: inteligencia artificial, visualización 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 información. En la etapa de caracterización se espera obtener tablas comparativas de acuerdo a las caracterı́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 gráficas.

(23) 10. 1 Descripción de la investigación. se pueda explicar la propuesta del algoritmo diseñado, ası́ como sus resultados en los casos de prueba establecidos.. 1.7.. Organización del trabajo de grado. El presente trabajo de grado se organiza de la siguiente manera: la parte I describe los aspectos motivacionales, metodológicos y los antecedentes de la investigación, la parte II expone el desarrollo de la investigación realizada, la parte III contiene la evaluación de los objetivos de investigación y del algoritmo propuesto y finalmente la parte 5.2 contiene los anexos producidos dentro del marco de la investigación realizada..

(24) Parte II. Desarrollo de la investigación.

(25) 2. Estado del arte 2.1.. Introducción. Como se ha mencionado previamente en el marco referencial (sección 1.5), este proyecto cubre múltiples enfoques que incluyen desde una perspectiva general al menos tres áreas de investigación: la extracción de conocimiento a partir de código fuente comprendida como la extracción de caracterı́sticas y su posterior procesamiento, calculo y generación de conocimiento, la comprensión de software como el análisis de los procesos cognitivos para entender las caracterı́sticas de un artefacto de software y la visualización de software como la representación gráfica del conocimiento obtenido a partir del código fuente que mejora el proceso de comprensión de los elementos estructurales, de comportamiento y evolución del software. Este capitulo se organiza de la siguiente manera, en la sección 2.2 se hace una revisión de las técnicas 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 sección 2.3 una clasificación y caracterización sobre los elementos que se extraen a partir del código fuente y la correspondiente transformación en representaciones visuales..

(26) 2.2 Técnicas. 13. 2.2.. Técnicas. 2.2.1.. Análisis visual de similitudes de código [7]. 2.2.1.1.. Resumen. Burch, Strotzer y Weiskopf proponen un algoritmo que extrae fragmentos de código fuente y su correspondiente frecuencia con el fin de construir una representación matricial triangular en la cual se pueden ver las similaridades bloques de código, 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 tamaño de la fuente.. 2.2.1.2.. Imagen. Figura 2-1.: Visualización propuesta por Burch, Strotzer y Weiskopf [7]. 2.2.1.3.. Caracterización. Nivel Extracción Transformación Visualización. Bajo Palabras en código fuente Frecuencia Estructura en árbol de acuerdo a las palabras y su frecuencia. Tabla 2-1.: Caracterización de la propuesta de Burch, Strotzer y Weiskopf [7].

(27) 14. 2 Estado del arte. 2.2.2.. H-CURVE [4]. 2.2.2.1.. Resumen. Bae, Ji y Woo proponen un método de visualización basado en la Curva de Hilbert; su algoritmo identifica las sentencias en el código fuente, clasifica y construye el fractal siguiendo las reglas de producción definidas para la curva de Hilbert, el resultado es una visualización que permite analizar la complejidad de los algoritmos, como muestra la figura 2-2. 2.2.2.2.. Imagen. Figura 2-2.: Visualización propuesta por Bae, Ji y Woo [4]. 2.2.2.3.. Caracterización. Nivel Extracción Transformación Visualización. Bajo Sentencias en código fuente Orden de complejidad Estructura fractal que combina la complejidad obtenida con la curva de Hilbert. Tabla 2-2.: Caracterización de la propuesta de Bae, Ji y Woo [4].

(28) 2.2 Técnicas. 15. 2.2.3.. Mini mapa de código [2]. 2.2.3.1.. Resumen. Bacher, Namee y Kelleher hacen una revisión a los mini mapas que se incluyen en algunas herramientas de desarrollo y proponen en [2] una extensión que permita a los desarrolladores ver la jerarquı́a de la cadena de alcance sobre las variables o atributos definidos en el código 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.: Visualización propuesta por Bacher, Namee y Kelleher [2]. 2.2.3.3.. Caracterización. Nivel Extracción Transformación Visualización. Bajo Unidades de compilación Ninguna Panel lateral que permite ver la concentración en lı́neas de código. Tabla 2-3.: Caracterización de la propuesta de Bacher, Namee y Kelleher [2].

(29) 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 tridimensional de navegación a través de la estructura estática del código fuente como se muestra en la figura 2-4, a diferencia de otros autores no se enfoca en una metáfora sino que trata de incluir un acceso directo a ”salones de código permite la colaboración entre desarrolladores. 2. 2.2.4.2.. Imagen. Figura 2-4.: Visualización propuesta por Khaloo, Maghoumi, Taranta, Bettner y Laviola [16]. 2.2.4.3.. Caracterización. Nivel Extracción Transformación Visualización. Alto y Bajo Unidades de compilación Nombre de las clases, Código fuente Cada clase se convierte en un cubo tridimensional y en su interior se puede ver el código fuente. Tabla 2-4.: Caracterización de la propuesta de Khaloo, Maghoumi, Taranta, Bettner y Laviola [16].

(30) 2.2 Técnicas. 17. 2.2.5.. CodeMetropolis [5]. 2.2.5.1.. Resumen. Balogh y Beszédes resaltan la necesidad de construir visualizaciónes con alto poder expresivo y proponen combinar las necesidades visuales de la comprensión 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.: Visualización propuesta por Balogh y Beszédes [5]. 2.2.5.3.. Caracterización. Nivel Extracción Transformación Visualización. Alto Paquetes, Clases, Métodos y Atributos Distritos, Edificios, Ventanas, Etiquetas 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.: Caracterización de la propuesta de Balogh y Beszédes [5].

(31) 18. 2 Estado del arte. 2.2.6.. Visualización en árbol [3]. 2.2.6.1.. Resumen. Bacher, Namee y Kelleher proponen múltiples visualizaciones utilizando la estructura de árbol con el fin de ayudar a los desarrolladores en el análisis de fragmentos de código jerárquicos combinando aspectos relacionados al alcance y la estructura de control, como se muestra en la figura 2-6, su visualización se presenta como un prototipo en construcción en [3]. 2.2.6.2.. Imagen. Figura 2-6.: Visualización propuesta por Bacher, Namee y Kelleher [3]. 2.2.6.3.. Caracterización. Nivel Extracción Transformación Visualización. Bajo Lı́neas de código Jerarquia de alcance y estructura de control Un panel lateral presenta la jerarquia y estructura de acuerdo a la selección del usuario. Tabla 2-6.: Caracterización de la propuesta de Bacher, Namee y Kelleher [3].

(32) 2.2 Técnicas. 19. 2.2.7.. CodeCity [26]. 2.2.7.1.. Resumen. Wettel y Lanza desarrollarón la herramienta de visualización más popular: CodeCity; utilizando una metáfora de una ciudad en la cual los paquetes son distritos y las clases son edificios, además permite intuir la cantidad de métodos (altura), atributos (base) y el número de lı́neas de código (color), como muestra la figura 2-7, además su trabajo ha sido complementado con experimentos controlados para demostrar la utilidad de su visualización [26]. 2.2.7.2.. Imagen. Figura 2-7.: Visualización propuesta por Wettel y Lanza [26]. 2.2.7.3.. Caracterización. Nivel Extracción Transformación Visualización. Alto Paquetes, Clases, Número de Metodos, Atributos y Lı́neas de código Distritos, Edificios Los paquetes como distritos, clases como edificios cuya altura es el número de metodos, su ancho al número de atributos y el color al número de lı́neas de código. Tabla 2-7.: Caracterización de la propuesta de Wettel y Lanza [26].

(33) 20. 2 Estado del arte. 2.2.8.. 2 12 D Visualización de grafo de llamadas [6]. 2.2.8.1.. Resumen. Bohnet y Döllner proponen en [6] una combinación entre la estructura modular con la traza dinámica del grafo de llamadas con el fin de construir una representación de alto nivel que permita a los desarrolladores utilizar una estrategia de arriba a abajo para encontrar código fuente relacionado a una caracterı́stica especifica. 2.2.8.2.. Imagen. Figura 2-8.: Visualización propuesta por Bohnet y Döllner [6]. 2.2.8.3.. Caracterización. Nivel Extracción Transformación Visualización. Bajo Funciones Grafo de llamadas Se presenta el grafo de llamadas construido a partir de la ejecución del código fuente. Tabla 2-8.: Caracterización de la propuesta de Bohnet y Döllner [6].

(34) 2.2 Técnicas. 21. 2.2.9.. The Brain [20]. 2.2.9.1.. Resumen. Palepu y Jones proponen en [20] una visualización en grupos a partir del código fuente que se construye a partir de los flujos de ejecución, cada grupo representa lógica que interactúa comúnmente, se inspira en las representación 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.: Visualización propuesta por Palepu y Jone [20]. 2.2.9.3.. Caracterización. Nivel Extracción Transformación Visualización. Alto Clases, Métodos, Lı́neas de código Grafo Los nodos representan lı́neas de código y los vértices relaciones entre las lı́neas de código, ya sea por control o flujo de ejecución. Tabla 2-9.: Caracterización de la propuesta de Palepu y Jone [20].

(35) 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 análisis de las técnicas utilizadas para interpretar el comportamiento de un programa y proponen una visualización de nivel intermedio la cual permite ver el flujo de datos que pasa entre procedimientos y su correspondiente asignación local (dentro del contexto de los otros procedimientos), como se muestra en la figura 2-10. 2.2.10.2.. Imagen. Figura 2-10.: Visualización propuesta por Ishio, Etsuda e Inoue [14]. 2.2.10.3.. Caracterización. Nivel Extracción Transformación Visualización. Bajo Funciones Flujo de llamadas Se presenta el flujo de llamadas considerando los parametros de las mismas. Tabla 2-10.: Caracterización de la propuesta de Ishio, Etsuda e Inoue [14].

(36) 2.2 Técnicas. 23. 2.2.11.. ClonEvol [10]. 2.2.11.1.. Resumen. Hanjalić presenta ClonEvol en [10], una herramienta que detecta la inclusión de clones de código haciendo un análisis 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 árbol radial como se muestra en la figura 2-11.. 2.2.11.2.. Imagen. Figura 2-11.: Visualización propuesta por Hanjalić [10]. 2.2.11.3.. Caracterización. Nivel Extracción Transformación Visualización. Bajo Lı́neas de código, logs de sistema de administración de cambios Clones de código Se presentan relaciones para identificar los clones de código a nivel de lı́nea, atributo, metodo, clase, archivo y directorio. Tabla 2-11.: Caracterización de la propuesta de Hanjalić [10].

(37) 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 búsquedas, exploración y descubrimiento de patrones y eventos en código fuente por medio del análisis de la información 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.: Visualización propuesta por Servant y Jones [24]. 2.2.12.3.. Caracterización. Nivel Extracción Transformación Visualización. Bajo Lı́neas de código, logs de sistema de administración de cambios Identificación de patrones en los cambios en el código fuente Permite visualizar patrones de cambio en el código fuente. Tabla 2-12.: Caracterización de la propuesta de Servant y Jones [24].

(38) 2.2 Técnicas. 25. 2.2.13.. StartGate [19]. 2.2.13.1.. Resumen. Ogawa y Ma integran el análisis de la información obtenida de los sistemas de control de versiones con información de correos electrónicos relacionados e información 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.: Visualización propuesta por Ogawa y Ma [19]. 2.2.13.3.. Caracterización. Nivel Extracción Transformación Visualización. Alto Logs de sistema de administración de cambios, correo electrónico Asociación de patrones de cambio con palabras clave en el correo electrónico Metafora de una galaxia con relaciones entre las unidades de compilación y las palabras clave de los correos. Tabla 2-13.: Caracterización de la propuesta de Ogawa y Ma [19].

(39) 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 través de los años, utilizando un concepto de visualización orgánica de información lo extienden al análisis de las contribuciones obtenidas de los sistemas de control de versiones con el fin de construir una visualización artı́stica en la que se puede ver la evolución del código fuente relacionada con las contribuciones de los autores, como se muestra en la figura 2-14. 2.2.14.2.. Imagen. Figura 2-14.: Visualización propuesta por Ogawa y Ma [18]. 2.2.14.3.. Caracterización. Nivel Extracción Transformación Visualización. Alto Logs de sistema de administración de cambios Grafo de contribuciones al repositorio Video de la evolución del grafo de contribuciones. Tabla 2-14.: Caracterización de la propuesta de Ogawa y Ma [18].

(40) 2.3 Clasificación. 2.3.. 27. Clasificación. De acuerdo a los objetivos propuestos 1.2 y la sistematización del problema 1.1.3, a continuación se hace una caracterización de las técnicas presentadas en la sección 2.2 con el fin de identificar los aspectos que se extraen, las transformaciones y la representación visual obtenida.. 2.3.1.. Extracción y Transformación. Estrategia Análisis visual de similitudes de código H-CURVE Mini mapa de código Code Park CodeMetropolis. [4] [2] [16] [5]. Visualización en árbol CodeCity. [3] [26]. 2 21 D Visualización de grafo de llamadas The Brain. [6]. Flujo de datos entre procedimientos ClonEvol Chronos StartGate code swarm. Ref [7]. Log versiones. [20] [14] [10] [24] [19] [18]. Patrones Contribuciones Contribuciones Contribuciones. Fuentes Texto. Binario. Sentencias Unidad Compilación Clases/Texto Paquetes, Clases, Métodos y Atributos Sentencias Paquetes, Clases, Número de metodos y atributos Funciones. Log de ejecución. Clases, Metodos, Lı́neas de código Funciones. Log de ejecución. Texto Texto Texto Texto. Tabla 2-15.: Caracterización de extracción de conocimiento.

(41) 28. 2.3.2.. 2 Estado del arte. Representación visual. Estrategia Análisis visual de similitudes de código. Ref [7]. Nivel Bajo. Enfoque Estructura. H-CURVE. [4]. Bajo. Estructura. Mini mapa de código. [2]. Bajo. Estructura. Code Park. [16]. Alto/Bajo. Estructura. CodeMetropolis. [5]. Alto. Estructura. Visualización en árbol. [3]. Bajo. Estructura. CodeCity. [26]. Bajo. Estructura. 2 12 D Visualización de grafo de llamadas. [6]. Bajo. Comportamiento. The Brain. [20]. Alto. Estructura. Flujo de datos entre procedimientos. [14]. Bajo. Comportamiento. Estrategia Representación en arbol resultado de consulta de palabra clave Representación fractal de la complejidad de los metodos Representación del texto con un bajo acercamiento y colores Navegación 3D de alto nivel y 2d de Texto Representación 3D que usa la metafora de la ciudad Representación del texto con un bajo acercamiento y colores Representacion 3D que usa la metafora de la ciudad Representación en grafo de las llamadas entre métodos Patrones de asociación entre sentencias, metodos y clases Representación del flujo de parametros entre metodos. Tabla 2-16.: Caracterización de visualización de conocimiento.

(42) 2.3 Clasificación. 29. Estrategia ClonEvol. Ref [10]. Nivel Alto. Enfoque Evolución. Chronos. [24]. Bajo. Evolución. StartGate. [19]. Alto. Evolución. code swarm. [18]. Alto. Evolución. Estrategia Representación en arbol radial de los clones de código Representación en cortes sobre los resultados de la búsqueda de eventos Representación 2D que usa la metáfora de la galaxia para mostrar las contribuciones en el código fuente Representación 3D en grafo para mostrar las contibuciones en repositorios de código.

(43) 3. Propuesta 3.1.. Introducción. 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 algún 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 aplicación, obviando aspectos 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 década de los 90 existen estudios sobre los elementos cognitivos relacionados con las tareas básicas de los desarrolladores: leer, modificar y escribir código desencadena esfuerzos cognitivos que fueron caracterizados por Ko, Myers, Coblenz y Aung y publicados en el año 2006 [17]: asociaciones mentales entre las caracterı́sticas funcionales con clases, objetos, métodos, atributos, archivos por medio de búsquedas textuales complementadas con análisis 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 código fuente. Si bien el problema es conocido y se ha establecido que las herramientas de visualización pueden mejorar el proceso de comprensión de software [9], ninguna propuesta se ha integrado en la industria debido a que como se puede evidenciar en el ejercicio de caracterización (2-15, 2-16), los algoritmos se han enfocado en extraer aspectos especı́ficos del código (estructurales, de comportamiento o evolutivo) y su correspondiente representación visual esta limitada por dicho aspecto o en algunos casos tiene un enfoque estético 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 intención que fue distribuida entre estudiantes y profesionales de áreas relacionadas con el desarrollo de software y sus resultados se presentan en la sección 3.2, posteriormente se hace un análisis en el cual se relacionan dichos aspectos prácticos y, en combinación con los aspectos previamente identificados en la literatura cientı́fica y presentados en 2 se.

(44) 3.2 Análisis práctico. 31. establece un modelo de representación de conocimiento en 3.3. Teniendo en cuenta dicho modelo la sección 3.4 presenta la estructura general del algoritmo resaltando los componentes principales de la propuesta a nivel de arquitectura, en la sección 3.5 dichos componentes son detallados estableciendo las relaciones entre la extracción de aspectos a partir del código fuente, la transformación al modelo de conocimiento propuesto y los elementos visuales que representan el modelo construido y finalmente, la sección 3.6 presenta la implementación de la versión alfa del algoritmo con algunos escenarios de prueba básicos.. 3.2.. Análisis práctico. Uno de los problemas que ha afectado las herramientas de visualización de software existentes en la literatura cientı́fica es la carencia de un enfoque general que sea práctico para un propósito especı́fico, con el fin de desarrollar una propuesta con un enfoque práctico mas allá de la experiencia profesional del investigador y de los enfoques cientı́ficos encontrados en la literatura se desarrollo una encuesta de libre intención, 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 propósito de la encuesta consistió en encontrar los aspectos en el código fuente que buscan los desarrolladores y arquitectos en el momento de enfrentar el problema de la comprensión 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 prioritarios en el momento de un análisis inicial del código fuente, con el fin de representar estos aspectos de manera que permita visualizar y caracterizar dicha importancia se decidió mostrar los resultados como una nube de palabras1 . Las preguntas sobre los aspectos relevantes en el código fuente revelaron no solo el “Qué”, sino que adicionalmente y como se podrá apreciar en la presentación de los datos el “Cómo” y el “Dónde”, aspectos que si bien no hacı́an parte de lo que se querı́a revelar son interesantes desde la perspectiva de la presente investigación. 1. Una Nube de palabras es una representación visual de las palabras, en donde el tamaño su tamaño es definido por su frecuencia.

(45) 32 3.2.1.1.. 3 Propuesta 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 ejecución: Inicio - Procesamiento - Fin, y una perspectiva estructural que sobresale a partir del interés por la configuración y la conexión a la base de datos..

(46) 3.2 Análisis práctico 3.2.1.2.. 33. 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 conceptos como arquitectura, estructura, lógica, frameworks, entre otros. Aunque se mantienen elementos previos estructurales y de comportamiento..

(47) 34 3.2.1.3.. 3 Propuesta 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 interés en la conexión con la base de datos cuyo fin es el estudio del modelo relacional y la segunda respecto a entender la lógica de la aplicación objeto de estudio..

(48) 3.2 Análisis práctico 3.2.1.4.. 35. Aspectos que se busca en un artefacto de software. Considerando que el orden en la búsqueda 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.

(49) 36 3.2.1.5.. 3 Propuesta Proceso cognitivo para la comprensión de software. Si bien en la practica los encuestados no identifican el proceso de comprensión 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 análisis.. Estrategia Arriba-Abajo Abajo-Arriba Sin especificar. Estructura 6 8 0. Comportamiento 8 16 2. Evolución 0 1 0. Tabla 3-1.: Proceso cognitivo para la comprensión de software. Resalta en estos resultados que en la practica no existe un interés real en la evolución 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 ejecución como un elemento con muchas más importancia sobre la estructura, patrones o diseño arquitectónico del artefacto objeto de estudio.. 3.3.. Modelo de conocimiento. 3.3.1.. Aspectos teóricos y prácticos. 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 aspectos que se quieren obtener o visualizar a partir del artefacto de código fuente; esto se explica fundamentalmente por la poca adopción de las herramientas de visualización en la industria del software local, el inmediatismo que en muchos casos exige la industria y la misma estructura de los equipos de desarrollo que debido a la rotación deben mostrar resultados en términos de valor al cliente omitiendo aspectos como un manejo adecuado de los principios de arquitectura, la calidad de código, buenas practicas, etc. Las siguientes secciones concilian estas dos visiones con el fin de establecer un marco común que permita establecer un modelo de conocimiento extensible desde las perspectivas teóricas y prácticas..

(50) 3.3 Modelo de conocimiento 3.3.1.1.. 37. Fuentes de extracción. Código Fuente: El artefacto objeto de estudios Documentación: Externa (Artefactos documentales), e Interna (Documentación en el código fuente). Herramientas de comunicación: Correo electrónico, Chat empresarial, log de servidores de manejo de versiones, etc. 3.3.1.2.. Elementos a extraer. Primer nivel: Elementos estructurales como Paquetes, Clases, Atributos, Métodos. Segundo nivel: Elementos de comportamiento que se extraen a partir de los elementos de primer nivel o se obtienen por medio de la instrumentalización del código fuente en tiempo de ejecución. Tercer nivel: Elementos derivados del análisis de los logs de cambios en los servidores de versiones. Cuarto nivel: Elementos estructurales, de comportamiento o evolutivos que se obtienen a partir del conocimiento consolidado de los elementos extraı́dos de primer, segundo y tercer nivel, es decir: Métricas como cohesión, acoplamiento, patrones de diseño, etc. Quinto nivel: Análisis por correlación del conocimiento hasta cuarto nivel con fuentes externas de información como herramientas de comunicación, análisis de lenguaje natural para complementar aspectos del código con fuentes externas como bases de conocimiento o documentación. 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: Representación geométrica de los elementos Tamaño: Tamaño de los elementos Orientación: Ángulo respecto a su eje Fondo: Color principal de la forma.

(51) 38. 3 Propuesta Transparencia: Permite presentar elementos internos Movimiento: Permite representar cambios Texto: Permite consultar información asociada a los elementos presentados.

(52) 3.3 Modelo de conocimiento. 3.3.2.. 39. 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 código fuente, la figura 3-6 se enfoca en las aristas que representan el comportamiento y la figura 3-7 se enfoca en la representación de los aspectos evolutivos.. 3.3.2.1.. Estructura. Figura 3-5.: Modelo conceptual de conocimiento: Estructura.

(53) 40. 3 Propuesta. Desde esta perspectiva presentada en la figura 3-5 los vértices corresponden a los elementos comunes en la programación orientada a objetos: Paquetes, Clases, Atributos y Métodos y las aristas corresponden a herencia, pertenencia, tipo, asociaciones, agregación y composición. 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 creación, acceso, modificación y uso de los parámetros de entrada y salida de los métodos. 3.3.2.3.. Evolución. 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 (creación, modificación, eliminación)..

(54) 3.4 Algoritmo general. 41. Figura 3-7.: Modelo conceptual de conocimiento: Evolución. 3.4.. Algoritmo general. 3.4.1.. Introducción. con el fin de mejorar la comprensión por parte del lector del algoritmo general de extracción y generación de conocimiento a partir de código 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 extracción de conocimiento tiene como función principal la construcción del grafo de conocimiento de acuerdo al modelo previamente establecido en 3.3, sus procesos principales son realizar un análisis de la gramática del código fuente con el fin de extraer los aspectos de primer nivel (Paquetes, Clases, Atributos, Métodos, Logs de sistemas de manejo de versiones) y posteriormente iterar sobre estos elementos con el fin de inferir nuevos datos, información 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 vértices del grafo de conocimiento..

(55) 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 adición de controles con el fin de permitir las búsquedas por parte del usuario..

(56) 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 elementos principales son vértices 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 patrones: conectitud, proximidad, color, forma, tamaño, orientación, fondo, transparencia y movimiento, enumerados por Diehl en [9]..

(57) 44. 3.5.1.. 3 Propuesta. 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 métodos se ve reflejada en el número de filas y columnas que es utilizado por el motor de renderización para construir el poliedro.. Figura 3-10.: Propuesta de representación 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 número de métodos y del frente hacia atrás se puede ver como aumenta el número de atributos. Se puede evidenciar por ejemplo al frente y a la derecha una clase con muchos métodos que se tiene un aspecto estirado en vertical y al fondo a la izquierda una clase con muchos atributos que tiene un aspecto aplastado..

(58) 3.5 Propuesta especifica: CodeDecipher 3.5.1.2.. 45. Color. Se propone que el color exprese el estado de la clase respecto a la ejecución de un analizador estático de código y que refleje si se han encontrado hallazgos de nivel informático, advertencia o error2 , la figura 3-11 muestra algunos ejemplos.. Figura 3-11.: Propuesta de uso de color en clases e interfaces. 2. Para este caso se toma como referencia los niveles de informe de error de la herramienta CheckStyle: http://checkstyle.sourceforge.net/.

(59) 46 3.5.1.3.. 3 Propuesta Tamaño. Se propone seguir la lı́nea de otras representaciones en tres dimensiones utilizando el tamaño del poliedro como un indicador de la cantidad de lı́neas de código que tiene la clase (tomando esto como una aproximación 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 tamaño en clases e interfaces.

(60) 3.5 Propuesta especifica: CodeDecipher. 3.5.2.. 47. Paquetes. Para los paquetes se propone una presentación basada en la forma, considerando que son más importante las aristas: 3.5.2.1.. Forma. Se proponer utilizar una forma de anillo concéntrico con el fin de presentar el nivel de cada paquete como se presenta en la figura 3-13.. Figura 3-13.: Propuesta de representación de paquetes. 3.5.2.2.. Tamaño. Se propone que el tamaño sea directamente proporcional a la profundidad del espacio de nombres del paquete, dicho aspecto también es presentado en la figura 3-13..

(61) 48. 3.5.3.. 3 Propuesta. Aristas. Para representar las aristas del grafo se propone combinar los siguientes elementos visuales:. 3.5.3.1.. Color. Se propone utilizar un código de color para identificar si las aristas corresponden a elementos Estructurales (Herencia, Pertenencia, Asociaciones, Agregación, Composición), de Comportamiento (Creación, Modificación, Acceso, Uso, Llamado) o Evolutivos (Acceso).. Figura 3-14.: Propuesta de representación de aristas.

(62) 3.5 Propuesta especifica: CodeDecipher 3.5.3.2.. 49. 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 concentración de clases representa un problema de diseño de software.. 3.5.4.. Evolución. Para evidenciar la evolución de software se propone construir una animación navegable en el tiempo para evidenciar los cambios realizados, si bien se requerirı́a un procesamiento más complejo permitirı́a representar en el grafo los cambios temporales. 3.5.4.1.. Lı́nea de tiempo. Figura 3-15.: Propuesta de representación de la evolución.

(63) 50. 3.6.. 3 Propuesta. Prototipo. Se realizo una implementación 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 cooperación de aplicación. 3. https://aws.amazon.com/es/ https://neo4j.com/ 5 Se 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 4.

(64) 3.6 Prototipo. 3.6.1.. 51. Ejemplos. Con la versión prototipo construida se efectuaron algunas ejecuciones con código fuente de prueba, fundamentalmente se buscaba validar los escenarios básicos planteados de acuerdo al las caracterı́sticas que se están 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 herencia simple, dicho proyecto se encuentra publicado en GitHub en https://github.com/rfcasallasm/Simp.

(65) 52. 3 Propuesta. Figura 3-18.: Visualización del ejemplo simple. 3.6.2.. Pantallas. A continuación se presentan algunas capturas de pantalla de la aplicación, como este es un proyecto de desarrollo continuo se invita al lector a consultar la ultima versión 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.

(66) 3.6 Prototipo. 53. Figura 3-19.: Diagrama UMl de la herencia simple los componentes de extracción y transformación de conocimiento. Esta pantalla presenta el componente de visualización 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..

(67) 54. 3 Propuesta. Figura 3-20.: Visualización de la herencia simple.

(68) 3.6 Prototipo. Figura 3-21.: Captura de pantalla del prototipo: pantalla inicial. 55.

(69) 56. 3 Propuesta. Figura 3-22.: Captura de pantalla del prototipo: creación de proyectos.

(70) 3.6 Prototipo. 57. Figura 3-23.: Captura de pantalla del prototipo: visualización.

(71) Parte III. Cierre de la investigación.

(72) 4. Resultados y Discusión CodeDecipher se presenta como un algoritmo novedoso de extracción, almacenamiento y visualización de conocimiento a partir de código fuente, su planteamiento combina conceptos de inteligencia artificial, ingenierı́a inversa y visualización 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 extracción, transformación y visualización de conocimiento a partir de código fuente. Se hizo el análisis y la caracterización de los algoritmos de extracción de conocimiento y transformación en representaciones visuales de conocimiento a partir de código fuente, considerando áreas de conocimiento como la ingenierı́a inversa, inteligencia artificial, visualización de software, entre otras. Se hizo un estudio practico por medio de una encuesta de libre intención con el fin de evaluar la perspectiva local sobre la comprensión de software, las herramientas de visualización y los aspectos que se buscan a partir de un artefacto de código fuente. Se conciliaron los aspectos caracterizados en la literatura cientı́fica con los aspectos prácticos con el fin de encontrar un marco de trabajo común que permitió plantear una propuesta centrada en las dos perspectivas, además 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 prácticos, cientı́ficos y artı́sticos con el fin de mejorar el proceso de comprensión de software. Se implemento una versión alfa del algoritmo la cual puede ser complementada para trabajo futuro y utilizada para realizar experimentación y validación practica de la propuesta..

(73) 60. 4.2.. 4 Resultados y Discusión. Verificación, contraste y evaluación de los objetivos. Se verifican los objetivos iniciales propuestos frente a los resultados obtenidos y se evidencia que se cumplieron en su totalidad. A continuación se resume el contraste de los objetivos junto con el soporte del cumplimiento: Objetivo. Soporte de Cumplimiento. Caracterizar los algoritmos de extracción de conocimiento y las estrategias de visualización a partir de código fuente existentes por medio de la elaboración de un estado del arte que integre las perspectivas de la ingenierı́a inversa, visualización de software e inteligencia artificial con el fin de establecer un marco de trabajo teórico y metodológico actualizado. Se construyo el estado del arte (Capitulo 2), identificando y caracterizando las estrategias de extracción y de visualización (Sección 2.3), considerando las diferentes áreas de conocimiento relacionadas y complementando estas estrategias con una perspectiva practica obtenida a partir de una encuesta de libre intención (3.2 y Anexo 5.2), estableciendo un marco de trabajo común que concilio los diferentes aspectos (Sección: 3.3) Se propone un algoritmo general (Sección: 3.4), en el cual se toman a consideración los niveles de conocimiento y las posibles técnicas de inteligencia artificial e ingenierı́a inversa aplicables para la extracción y transformación en el modelo de conocimiento establecido (Sección 3.3) y posteriormente se plantea una visualización de los elementos contenidos en dicho modelo integrando aspectos estructurales, de comportamiento y evolutivos (Sección 3.5) Se presenta la versión alfa de la implementación del algoritmo (Sección: 3.6), y algunos ejemplos de ejecución controlada, sin embargo se establece que validar la efectividad requerirı́a un tipo de estudio más amplio el cual se encuentra por fuera del alcance de los recursos que tiene el proyecto y se plantea como un elemento futuro. Proponer un algoritmo que combine técnicas de inteligencia artificial, visualización de software e ingenierı́a inversa adecuadas para analizar, interpretar y extraer los datos a partir del código fuente e integra en una visualización que integre aspectos estructurales, de comportamiento y evolutivos del software. Validar el algoritmo propuesto por medio de la ejecución en escenarios de prueba controlados que permitan valorar su efectividad en al comprensión del software. Tabla 4-1.: Cumplimiento de Objetivos.

(74) 4.3 Sı́ntesis del modelo propuesto. 4.3.. 61. Sı́ntesis del modelo propuesto. El planteamiento general del algoritmo se encuentra documentado en la sección 3.4 de la propuesta, sin embargo se trae nuevamente el diagrama de comportamiento de aplicación el cual sintetiza el modelo como referencia 4-1.. Figura 4-1.: Sı́ntesis del algoritmo.

(75) 62. 4 Resultados y Discusión. 4.4.. Aportes originales. La propuesta del algoritmo de extracción y visualización de conocimiento a partir de código 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 aproximación preliminar al proceso de comprensión de software a nivel local del cual no se encuentran más referentes.. 4.5.. Trabajos o Publicaciones derivadas. Artı́culos: Al finalizar la implementación beta de la propuesta planteada se presentará un articulo a nivel nacional y dentro del marco de la Conferencia de visualización de software que organiza la IEEE el siguiente año..