Autor Mario Marcelo Berón Universidad Nacional de San Luis. Director Ph.D. Pedro Rangel Santos Henriques Universidade do Minho

Transcripción

1 Universidad Nacional de San Luis Tesis Doctoral Inspección de Programas para Interconectar las Vistas Comportamental y Operacional para la Comprensión de Programas Autor Mario Marcelo Berón Universidad Nacional de San Luis Director Ph.D. Pedro Rangel Santos Henriques Universidade do Minho Co-Director Roberto Uzal Universidad Nacional de San Luis 23 de octubre de 2009

2 Prefacio Esta tesis es el trabajo final de mis estudios de doctorado en el departamento de Informática de la Universidad Nacional de San Luis. La misma sirve como documentación de mi trabajo durante el período de estudio, el cual comprendió desde febrero de 2006 hasta febrero de El desarrollo de esta tesis doctoral fue soportado por el proyecto Alfa-LerNet de la Comunidad Europea y el Proyecto de Ingeniería de Software un Enfoque e-bussiness/e-learning de la Universidad Nacional de San Luis. En este informe se describe el problema de simplificar la comprensión de grandes sistemas. Entender este tipo de aplicaciones no es una tarea simple porque implica explorar y comprender las funcionalidades provistas por el código fuente. En la actualidad existen muchos esquemas de Comprensión de Programas basados en vistas útiles del sistema. Sin embargo, esas estrategias no contemplan una relevante e importante vista tal como: La Relación entre los Dominios del Problema y Programa. Esta clase de prespectiva permite la identificación de las componentes del programa usadas para producir una salida específica. Esta característica posibilita que el usuario se centre solamente en la inspección del código fuente relacionado con la funcionalidad del sistema que se desea cambiar o mejorar. En esta tesis se describen procedimientos cuya principal finalidad consiste en relacionar los Dominios del Problema y Programa. La realización de esa trarea implica la elaboración de criterios de evaluación y estrategias para: Visualizar el software; Interconectar dominios; Extraer información estática y dinámica y Administrar la información. i

3 Para Aida, Marcelo y mis amigos Daniel and Germán ii

4 Reconocimientos Me gustaría dar mis reconocimientos a mi director portugués Dr. Pedro Manuel Rangel Santos Henriques y a la Dra. Maria João Varanda Tinoco Pereira por brindarme su amistad y comprensión en este largo camino. Pedro nunca me dejó solo. Él siempre estuvo preocupado por mi como persona y como estudiante de doctorado. Considerando el primer aspecto, él me presentó su familia y en todo momento, ambos me hicieron sentir mucho cariño y amor. Por esas razones, Pedro no sólo es mi director sino que además de eso es mi cordial amigo. Como estudiante de doctorado, recibí una sólida formación en Comprensión de Programas e Ingeniería de Software. Además, asistí a muchas conferencias nacionales e internacionales y conocí varios importantes centros de investigación. Todavía más maravilloso, viaje por diferentes paises europeos donde me relacioné con muchos profesores importantes y establecí contactos amigables con otros estudiantes de doctorado. Por todos los motivos expuestos, muchas gracias Profesor Pedro por su consideración, dedicación y amistad. De la misma forma que el Prof. Pedro, Maria me integró a su familia y a su grupo de investigación. Ella simpre me ayudó leyendo los artículos científicos y me dió la oportunidad de conocer el Instituto Politécnico de Bragança donde trabajé una semana en mi doctorado dentro de un excelente ambiente de trabajo. Ella tuvo una maravillosa predisposición para analizar mis soluciones a los desafíos presentados en el doctorado y para mostrarme los lugares turísticos de su ciudad nativa. Por todas esas razones muchas gracias Prof. Maria João. Además de mis directores, muchas personas portuguesas me ayudaron de diferentes maneras. En el contexto académico me gustaría dar mis reconocimientos a los Profesores: João Almeida, Luis Soares Barbosa y Alberto Simões por responder a mis preguntas y permitirme asistir a diferentes confenrencias internacionales. Además de ellos, agradezco al Prof. Joaquín Macedo por su atención especial y a los miembros del Grupo de Comunicaciones por su cordialidad. Por otra parte, mis compañeros Ronnie Alves, Pedro Gabriel Ferreira, Rodrigo Baptista, Elisabete Sousa Cunha, Anabela Pereira, Ruben Fonseca, Flavio Xavier Ferreira, Daniela da Cruz y Luis Miguel Ferros contiuamente me guiaron en las actividades cotidianas que necesitaba realizar y que, iii

5 por encontrarme en otro país, no sabía llevarlas a cabo. Además de eso, compartí excelentes monentos de amistad con ellos. Muchas gracias amigos por su hospitalidad y cordialidad. En la otra parte del continente, en Argentina mi tierra natal, mientras desarrollaba mi tesis doctoral, mis amigos pensaban en mi. Ellos me escribieron muchos correos en los cuales compartíamos bromas, noticias, sentimientos, sensaciones, etc. En este sentido, me gustaría agradecer la cordialidad brindada por el Prof. Germán Montejano y el Prof. Daniel Riesco. Ambos profesores me ayudaron a resolver problemas del día a día en mi tierra. Además, me transmitieron su experiencia para llevar a cabo las presentaciones de mi tesis doctoral en conferencias internacionales. Aún más importante, mantuvieron nuestra amistad a pesar del tiempo y la distancia. Roberto, mi codirector, es una buena persona. Él siempre me asistió en las tareas de mi doctorado respondiendo a las preguntas que le formulaba y verificando mis trabajos. Muchas gracias Prof. Roberto. También me gustaría dar mis reconocimientos a Ricardo, Joge, Johi y Luis por las extensas sesiones de chat, por los correos que intercambiamos y por su amistad. Finalmente, y con especial consideración y amor estoy muy agradecido con mi padre y mi madre por su atención, dedicación por cuidarme siempre. Muchas gracias, es maravilloso estar con ustedes. Espero que esta situación continue por mucho tiempo. iv

6 Resumen Entender un sistema, programa o algoritmo es una tarea intensa que requiere mucho esfuerzo físico e intelectual. Sin embargo, este trabajo es muy importante porque permite corregir, mantener y adaptar el software a los nuevos requerimientos impuestos por los avances tecnológicos y los factores sociales. Llevar a cabo esta actividad en la forma tradicional, es decir, a través de la inspección manual de código no es viable porque consume mucho tiempo, grandes inversiones de dinero y material humano. Con el objetivo de evitar estos problemas, la Ingeniería de Software provee teorías y procedimientos que se agrupan en una disciplina denominada Comprensión de Programas. El trabajo realizado en esta tesis doctoral tiene los siguientes objetivos: i) Conceptualizar claramente Comprensión de Programas; ii) Encontrar el denominador común entre las principales áreas que intervienen en la elaboración de productos de comprensión y iii) Definir nuevas estrategias que simplifiquen el estudio de software. El desarrollo de las tareas descriptas en el párrafo precedente implicó un extensivo estudio del estado del arte donde se detectó la ausencia de una definición precisa de Comprensión de Programas. Esta carencia posibilitó la proposición de una nueva conceptualización que se basa en el estudio de Teorías Cognitivas, Visualización de Software y Métodos de Extracción y Organización de la Información. Todas esas disciplinas fueron cuidadosamente analizadas para: i) Extraer las componentes comunes que se deben incluir en los productos de comprensión; ii) Proponer nuevas conceptualizaciones y taxonomías y iii) Definir nuevas estrategias de comprensión. Además, este trabajo permitió detectar que el principal desafío en Comprensión de Programas consiste en relacionar el Dominio del Problema con el Dominio del Programa, es decir interconectar las componentes de software con la salida del sistema. Teniendo en cuenta este problema se diseñaron diferentes estrategias de interconexión de dominios que son soluciones posibles a este problema. Estos procedimientos se combinan con funciones de inspección de código que permiten el acceso rápido y eficiente a cada una de las componentes de sistema de estudio. Finalmente, con el propósito de mostrar la utilidad de las propuestas descriptas en esta tesis, los conceptos y estrategias se implementaron en PICS (Program Inspection and Comprehension System) una herramienta cuya finalidad es la inspección y comprensión de sistemas escritos en lenguaje C.

7 Índice general Índice general 1 Índice de figuras 8 Índice de cuadros 12 I INTRODUCCIÓN Introducción El Problema: Mejorar la Comprensión de Grandes Sistemas La Solución: Aumentar la Funcionalidad de las Herramientas de Comprensión de Programas con Procedimientos para Interconectar Dominios La Tesis Contribuciones Estructura de la Disertanción II COMPRENSIÓN DE PROGRAMAS Conceptualización de Comprensión de Programas Introducción Conceptualización de Comprensión de Programas Modelos Cognitivos en Comprensión de Programas Ingeniería de Software en Comprensión de Programas Visualización de Software

8 ÍNDICE GENERAL Extracción de la Información Administración de la Información Estrategias para Interrelacionar Dominios Conclusión Modelos Cognitivos Introducción Elementos Comunes de los Modelos Cognitivos El Modelo de Letovsky El Modelo de Schneiderman y Mayer El Modelo de Brooks El Modelo de Soloway, Adelson y Ehrlich El Modelo de Pennington El Constructivismo como una Aproximación para Entender Programas Las Ideas de Ausubel y Novak Modelo de Shaochun Xu Discusión acerca de los Modelos Cognitivos Detallando los Conceptos de Comprensión de Programas Representaciones del Dominio del Problema Representación del Dominio del Programa basada en Conceptos de Modelos Cognitivos Conclusión Estado del Arte de las Herramientas de Comprensión Introducción Understand C/C CodeSurfer Imagix 4D CScope SHriMP jgrasp Alma

9 ÍNDICE GENERAL SeeSoft- Una Herramienta para Visualizar Estadísitcas de Software por medio de Líneas de Código Web Application Viewer ORCA: Operation Reaction Code Analyzer Herramienta de Localización de Características Extravis Herramientas de Visualización del Comportamiento de Tiempo de Ejecución de Aplicaciones OS Pequeñas Una Herramienta para Extraer Términos de Dominio desde el Código Fuente Visor de Sequencia Zest Conclusión III CONSTRUCCIÓN DE HERRAMIENTAS DE COMPRENSIÓN DE PROGRAMAS BASADOS EN ESTRATEGIAS PARA INTER- CONECTAR DOMINIOS Visualización de Software Introducción Visualización de la Información Visualización de Software Conceptualización Modelo para Construir Visualizaciones de Software Otras Consideraciones acerca de la Visualización de Software Sistemas de Visualización de Software Ambiente de Visualización Aproximaciones para Visualmente Representar la Información del Sistema Taxonomías de los Sistemas de Visualización de Software Incompletitud de las Taxonomías Corrientes Nuevos Criterios para Mejorar la Caracterización de los PC-SVS Visualización de la Interconexión entre los Dominios del Problema y Programa Otras Consideraciones acerca de la Visualización del Dominio del Programa Conclusión

10 ÍNDICE GENERAL 4 6. Estrategias para Interconcetar Dominios Introducción Interconexión de Dominios por Capas Estrategias para Relacionar los Dominios del Problema y Programa Estrategia de Visualización Simultánea - SVS BORS una Estrategia de Relación Comportamental-Operacional Análisis Comportamental Conclusión Extracción de la Información Introducción Extracción de Información desde el Dominio del Problema Extracción de la Información desde el Dominio del Programa Construcción de Vistas Estáticas del Sistema Construcción de Vistas Dinámicas Otras Consideraciones Extracción de la Información para la Implementación de las Estrategias de Interconexión de los Dominios del Problema y Programa Técnica del Grep Detección de Tipos de Datos Abstractos Análisis Dinámico: Instrumentación de Código Instrumentación de Funciones Instrumentación de Iteraciones Instrumentación de las Sentencias de Selección Conclusión IV PICS UNA HERRAMIENTA DE COMPRENSIÓN DE PRO- GRAMAS PICS: Program Inspection and Comprehension System Introducción Arquitectura de PICS

11 ÍNDICE GENERAL Extracción de la Información Preprocesamiento del Código Fuente Extracción de Información Estática y Dinámica Vistas Interconexión de los Dominios del Problema y Programa SVS BORS Notas y Comentarios Casos de Estudio Introducción La Aplicación xfig Inhibir las Directivas al Preprocesador de C Detectar Tipos no Declarados Extracción de la Información Estática Instrumentación del Código fuente Inserción del Administrador de Funciones de Inspección Compilación del Sistema Ejecución de xfig El Comando Agrep de Linux Inhibir las Directivas al Preprocesador de C Detección de Tipos no Declarados Extracción de Información Estática Instrumentación del Código Fuente Inserción del Administrador de Funciones de Inspección Compilación del Sistema Ejecución de Agrep Notas y Comentarios V CONCLUSIÓN Y TRABAJOS FUTUROS Conclusión 236

12 ÍNDICE GENERAL Modelos Cognitivos Visualización de Software Estrategias para Interconectar Dominios Extracción de la Información Resultados Generales Trabajo Futuro Mejoras en los Prototipos Implementados en PICS Mejoras en las Estrategias de Inspección de Programas Optimizaciones de las Técnicas de Interconexión de Dominios Evaluación de Herramientas de Comprensión de Programas VI APENDICES 247 A. Evaluación de Herramientas de Comprensión de Programas 248 A.1. Introducción A.2. Un Método de Evaluación de Calidad A.2.1. Pasos Requeridos para la Aplicación de QEM A.2.2. Definición de los Criterios Elementales A.2.3. Cálculo de las Preferencias de Calidad Elementales A.2.4. Cálculo de las Preferencias Globales A.3. Criterios para Evaluar un Sistema de Visuazlización de Software A.3.1. Clasificaciones de los Sistemas de Visualización de Software A.3.2. Nuevos Criterios para Mejorar la Caracterización de los SVS-PC A.4. Criterios para Evaluar las Estrategias de Interconexión de Dominios A.5. Criterios para Evaluar las Técnicas de Extracción de la Información A.5.1. Clasificaciones de las Estrategias de Extracción de la Información A.5.2. Notas y Comentarios de la Sección A.6. Resultados de la Investigación y Contribuciones A.6.1. Notas y Comentarios de la Sección A.7. Notas y Comentarios

13 ÍNDICE GENERAL 7 B. Árbol de Requerimientos de QEM no Estándard 262 C. Gramática para entender el Concepto de Chunk 268 D. Esquema de Instrumentación: Ejemplos 270 D.1. Módulo d arcbox.c D.2. Instrumentación del Módulo d arcbox.c D.3. Función elastic moveline del Módulo u elastic.c D.4. Instrumentación de la Función elastic moveline Bibliografía 281

14 Índice de figuras 2.1. Grafo de Dependencias de Módulos Instantánea del Modelo de Letovsky Instantánea del Modelo de Brooks Instánea del Modelo de Soloway Instantánea del Modelo de Pennington Ejemplo del Modelo de Pennington Modelo de Comprensión de Programas Ejemplo de Plan TDA Ambiente provisto por Understand C/C++ - Árbol de Funciones Ambiente provisto por Understand C/C++ - Diagrama de Flujo Grafo de Funciones provisto por CodeSurfer Visualización Variables con CodeSurfer Grafo de Símbolos provista por Imagix 4D Visualización de Variables con Imagix 4D Control de Flujo en Imagix 4D Interfaz de CScope Visualización de Estructuras de Datos en jgrasp Pantalla de Alma - Ejecución de un Programa Pantalla de Alma - Construcción de ASD Instantánea de WAV - Representación Icónica de un Programa Instantánea de WAV - Representación basada en Grafos Vistas proporcionadas por Extravis

15 ÍNDICE DE FIGURAS Una vista proporcionada por Zest Visualización de Software - Modelo Inicial Visualización de Software - Modelo Parcial Visualización de Software - Modelo Total Relación de Inclusión de las Visualizaciones de Software Trazado de Grafo Jerárquico Trazado de Grafo Físico Virtual Trazado de Grafo Planar Diagramas usados para mostrar las propiedades del software Visualización de Software como ciudades Alagae Tree-ring Calidoscopio Modelo de Roman y Cox Taxonomía de Price et. al Criterios del Dominio del Problema Taxonomía Problema-Programa Categoría Contenido Interconexión de Dominios por Capas Sistema Instrumentado y el Monitor Salida de la Ejecución Paralela Lista de Funciones vs. fe-tree Estrategias para Explicar los Aspectos del Sistema Análisis de Trazas de Ejecución Mapa Conceptual de un Editor de Texos Básico El problema de las funciones como parámetros Problema de los Punteros a Problema de los Punteros a Secuencia de Ejecución de Funciones de un Sistema Construcción del Árbol de Ejecución de Funciones

16 ÍNDICE DE FIGURAS Grafo de Tipos para algún sistema Grafo de Tipos para la declaración de las estructuras Instrumentación de Función Posibles Errores Semánticos Estrategia que evita errores semánticos Errores de Instrumentación de Función Instrumentación correcta de funciones Función con puntos de salida implícitos y explícitos Instrumentación de una Iteración For Instrumentación de las Iteraciones - Una Sentencia Compuesta Insertada dentro del Cuerpo de la Iteración Instrumentación de las Iteraciones - Iteraciones encerradas con una Sentencia Compuesta Esquema de Instrumentación de la Sentencia Break Esquema de Instrumentación de la Sentencia Continue - Ejecución Instrumentación de Iteraciones - Instrumentación de la Sentencia Continue Instumentación de Selecciones - Instrumentación de la Sentencia IF-THEN-ELSE Instrumentación de Selecciones - Sentencia IF-THEN-ELSE Modelo de la Sentencia Switch Instrumentación de Selecciones - Sentencia SWITCH Arquitectura de PICS Operación de Abrir Archivo en PICS Procesamiento de las directivas al Preprocesador de C Archivos Comentados por PICS Archivos Comentados por PICS Problema de Tipos de no Declarados Código Fuente Instrumentado Visualizador de Tablas de Símbolos Visualizador de Grafos: Grafo de Funciones Vista Comportamental del Programa de Juegos Grafo de Funciones del Programa de Juegos SVS aplicado al Programa de Juegos

17 ÍNDICE DE FIGURAS Interfaz de la Técnica del Grep Interfaz para la detección de Tipos de Datos Abstractos de BORS BORS aplicado a un Sistema de Evaluación de Algoritmos de Ruteo Interfaz Gráfica de xfig Trozo de Código del archivo makefile de xfig Salida de la Utilidad make Módulo w util.c de xfig cargado en PICS Módulo w util.c con las directivas al preprocesador de C comentadas Tipos no declarados en w-util.c Error sintáctico porque las macros no fueron expandidas en el módulo w-util.c Datos estáticos recuperados desde el módulo w-util.c Instrumentación de Código de w-util.c Declaraciones de las Funciones de Inspección dentro de w-util.c Funciones ejecutadas por xfig cada vez que se invoca Funciones ejecutadas para hacer un círculo Funciones ejecutadas para construir un cuadro Vista del Grafo de Funciones del Módulo w-util.c de xfig Vista de los posibles puntos de entrada del Módulo w-util.c de xfig Vista de una porción del Grafo de Funciones de w-util.c Funciones llamadas directa o indirectamente por la función reset-grid-menus Datos estáticos de w-util.c SVS aplicado a agrep Funciones del Módulo parse.c BORS aplicado a agrep Desde los Programas a Modelos de Programas A.1. Taxonomía para categorizar la Relación entre los Dominios del Problema y Programa 256

18 Índice de cuadros 3.1. Comparación de MC Comparación de MC Comparación de MC A.1. Árbol de Requerimientos para las HPC

19 Parte I INTRODUCCIÓN 13

20 Capítulo 1 Introducción Adelante como don Quijote contra los molinos de viento Pedro Rangel Henriques 1.1. El Problema: Mejorar la Comprensión de Grandes Sistemas La Comprensión de Programas (CP) es una disciplina de la Ingeniería de Software cuyo objetivo es a ayudar al programador a entender programas. La CP es útil para Mantenimiento y Evolución de Software (MES), Ingeniería Reversa (IR), Re-Ingeniería (ReE) y Educación [RD94, MMW02, VMV95]. En las tres primeras disciplinas, ayuda a reducir costos y esfuerzos. En la última, asiste al novicio en el proceso de comprensión de algoritmos. MES es una tarea crítica porque implica tres importantes tareas perfectiva, correctiva y adaptativa [XPH07]. La primera está relacionada con la incorporación de nuevas funcionalidades. La segunda describe el proceso de eliminar errores de programación. La tercera aborda el problema de adaptar el sistema a nuevos contextos, por ejemplo, usar un nuevo formato de archivo, cambiar la organización del código, etc. Esas tres principales actividades consumen mucho tiempo y recursos. Xi y Hassan en [XPH07] muestran que el 39 % de las actividades son perfectivas, 56.7 % son correctivas y 2.2 % se corresponden con tareas adaptativas. Finalmente, el 2.1 % restante representa otras tareas relacionadas con MES. Por otra parte, la historia del MES muestra un incremento lineal, desde 1975 hasta 2005, en los costos de proyectos dedicados a MES [XPH07]. Esta información justifica el interés de la comunidad científica por reducir los esfuerzos dedicados a esas tres principales actividades. 14

21 CAPÍTULO 1. INTRODUCCIÓN 15 Otra área muy importante es IR. Esta disciplina estudia la creación de estrategias de extracción de la información desde diferentes fuentes (como por ejemplo código fuente, archivos makefiles, documentación, etc.), con el propósito de: Elaborar de documentación; Extraer la arquitectura del sistema, etc. IR implica grandes costos y esfuerzos porque generalmente incluye actividades similares a MES. ReI usa técnicas de IR para extraer información y proporciona estrategias para modificar el sistema de acuerdo a los requerimientos del programador. Por esta razón, ReI, de la misma forma que MES e IR, es un área donde se necesitan propuestas para minimizar costos y esfuerzos. En todas las disciplinas (SME, RE y ReI) mencionadas en los párrafos precedentes, el programador debe entender grandes documentos con diferentes formalismos y metodologías. Además, debe vincular la información recuperada con el código fuente y comprender como el sistema lleva a cabo sus funcionalidades en un alto nivel de abstracción. La Comprensión de Programas asiste al programador en esas tres principales áreas. Esta actividad se lleva a cabo por medio de métodos, estrategias y herramientas que disminuyen las tareas operativas y cognitivas del programador [Sto05]. Como un efecto colateral de esta última característica, los costos también se reducen. Actualmente, existen muchas Herramientas de Comprensión de Programas (HCP) con sofisticadas técnicas de exploración de código. Las mismas funcionan adecuadamente, sin embargo ciertas tareas de comprensión son todavía muy complejas. Muchas HCP usan solamente análisis estático para la extracción de información del sistema. Después de eso, esa información se representa visualmente con el objetivo de proveer diferentes vistas. De esta forma, el proceso de comprensión de programas se simplifica porque se puede analizar el sistema desde varios puntos de vista. No obstante, el programador está forzado a encontrar el código fuente usado en ciertas ejecuciones del sistema. Esta última tarea consume tiempo y esfuerzo. Otra clase de herramientas analizan el flujo de ejecución y proveen otro tipo de visualización del sistema. Esas herramientas, conocidas con el nombre de depuradores, frecuentemente proporcionan información de bajo nivel que es útil en estados avanzados de la CP. Por ejemplo, en la comprensión de rutinas específicas del sistema de estudio. Finalmente, otras herramientas combinan técnicas de recuperación de información estática y dinámica, pero su salida consiste de interesantes y complejos análisis de cada clase de información. Generalmente, las HCP no contemplan algunos aspectos importantes de la CP (esta peculiaridad se podrá observar a través del desarrollo de esta tesis doctoral). Un ejemplo de tales aspectos es la relación entre la salida del sistema y las componentes, a nivel programa, usadas para producirla. Esta relación se conoce como: La Interconexión entre los Dominios del Problema y Programa. La característica mencionada previamente simplifica la exploración porque el programador solamente inspecciona las partes del sistema relacionadas con la funcionalidad de estudio. Para ser más claro,

22 CAPÍTULO 1. INTRODUCCIÓN 16 suponga que el programador está interesado en modificar la funcionalidad F del sistema S. Además, el tamaño de S es considerable (40Kloc o más). En este caso, la primer tarea que se debe realizar consiste en encontrar las funciones que implementan F y después de eso se necesitan usar técnicas de inspección para estudiar en detalle aquellas funciones. Es importante notar que la primer tarea consume tiempo y esfuerzo y si la misma se puede evitar entonces se obtendrían muchas ventajas. Una forma de salvar este inconveniente es a través de la elaboración de estrategias que interconecten los Dominios del Problema y Programa. Este tipo de técnicas proveen información de alto nivel que se puede usar para la realización de futuras exploraciones. De esta manera, se alcanza una considerable reducción de esfuerzos humanos y costos, porque el programador se concentra solamente en las actividades de exploración La Solución: Aumentar la Funcionalidad de las Herramientas de Comprensión de Programas con Procedimientos para Interconectar Dominios La primer actividad requerida para resolver el problema presentado en la sección 1.1 está relacionada con la búsqueda de una definición de Comprensión de Programas. En este contexto, se realizaron diferentes investigaciones y no fue posible encontrar una clara conceptualización de esta disciplina. Por este motivo, se estudiaron los Modelos Cognitivos de Comprensión de Programas (MC) y se realizaron algunas comparaciones entre ellos con la finalidad de establecer las bases para la elaboración de una concepción de Comprensión de Programas. Después de llevada a cabo la tarea mencionada en el prárrafo precedente fue posible concluir que: Un programador entiende un programa cuando puede relacionar los Dominios del Problema y Programa. En otras palabras, cuando él puede encontrar las componentes del programa usadas para producir la salida. Esta declaración indica que es posible resolver el problema presentado en la sección 1.1 elaborando estrategias para interconectar los Dominios del Problema y Programa. Para alcanzar este objetivo, se deben realizar tres importantes tareas. La primera de ellas se centra en el diseño de representaciones del Dominio del Problema. Esta actividad es compleja porque el objeto de estudio es dependiente de la aplicación. Además, existen pocos artículos científicos que aborden la temática teniendo en cuenta este enfoque. La segunda de ellas consiste en la construcción de representaciones del programa. En este caso, se pueden hacer diferentes elecciones porque existen

23 CAPÍTULO 1. INTRODUCCIÓN 17 muchas representaciones de programas. Por ejemplo, el Grafo de Comunicaciones de Módulos, el Grafo de Funciones, etc. son posibles representaciones interesantes de un sistema. Finalmente, se debe definir un procedimento de vinculación que posibilite la interconexión de las representaciones del Problema y Programa. Para llevar a cabo los procedimientos mencionados en el párrafo anterior se deben investigar diferentes áreas de la Ingeniería de Software. Por ejemplo, para la elaboración de representaciones del problema se necesitan estudiar estrategias de Modelación Conceptual. Para la construcción de representaciones del programa se emplean técnicas de extracción de información estática y dinámica. Finalmente, para implementar el procedimiento de vinculación es necesario la utilización de algoritmos sofisticados y técnicas de organización de archivos La Tesis La interrelación de dominios es la mejor estrategia para facilitar la comprensión de sistemas, es posible realizar esta afirmación por las razones expuestas a lo largo de esta tesis doctoral. Sin embargo, algunas veces esta tarea es muy compleja de llevar a cabo para ciertos dominios. Un ejemplo de esta declaración es la relación existente entre los Dominios del Problema y Programa. En este contexto, el objetivo es demostrar que: Es posible interconectar ambos dominios (Problema y Programa) usando insturmentaciones de código y esa interconexión simplifica la Comprensión de Programas. Esto se debe a que la relación mencionada previamente permite que el programador encuentre significado y sentido a las actividades del sistema promoviendo la creación de relaciones substanciales y no arbitrarias entre los conceptos. Un importante objetivo secundario es la presentación del estado del arte acerca de: Modelos Cognitivos; Visualización de Software; Aproximaciones para extraer información por medio del análisis estático y dinámico; y Herramientas de Comprensión de Programas. Esta tarea es relevante porque sus resultados ayudan al futuro investigador interesado en esta área Contribuciones A continuación se presentan las constribuciones de este trabajo de doctorado.

24 CAPÍTULO 1. INTRODUCCIÓN 18 Sistematización de los Conceptos de Modelos Cognitivos: se extienden las definiciones de los conceptos de esta área de conocimiento. El objetivo de esta tarea es facilitar la asimilación de los conceptos de MC a los profesionales de Ingeniería de Software y Ciencias de la Computación. Para alcanzar este fin, las definiciones se expresan en términos computacionales comunmente utilizados por los expertos en esas áreas. Definición y Caracterización de los Sistemas de Visualización de Software Orientados a la Comprensión de Programas: en general, los Sistemas de Visualización de Software muestran vistas del Dominio del Programa dejando de lado el Dominio del Problema. Esta peculiaridad dificulta la Comprensión de Programas porque el programador debe relacionar esos dominios sin la asistencia de computadoras y software destinado para tal fin. Este problema se puede solucionar a través de la introducción de los Sistemas de Visualización de Software Orientados a la Comprensión de Programas (PC-Oriented Software Visualization Systems). Estas aplicaciones incluyen, además de las vistas de software tradicionales, tres visualizaciones relevantes, ellas son: Los Dominios del Problema y Programa y La relación existente entre ambos. Elaboración de nuevos criterios para clasificar los Sistemas de Visualización de Software: se pueden encontrar diferentes taxonomías de Sistemas de Visualización de Software. En este contexto, se observó que esas clasificaciones no consideran algunos factores, como por ejemplo la visualización del Dominio del Problema. En esta tesis doctoral, se elige la mejor taxonomía y se completa con nuevos criterios tendientes a lograr una descripción acabada de los Sistemas de Visualización Orientados a la Comprensión. Estrategias para relacionar los Dominios del Problema y Programa: se crearon algunas técnicas para interconectar diferentes dominios. En esas estrategias, se enfatiza la relación entre los Dominios del Problema y Programa. Un test para evaluar las Herramientas de Comprensión de Programas: se propone un test para evaluar las HCP teniendo presente los estudios realizados sobre Modelos Cognitivos, Visualización de Software, Extracción y Administración de la Información y Técnicas de Interconexión de Dominios. PICS una herramienta para inspeccionar y comprender sistemas: las principales aproximaciones descriptas en este trabajo de doctorado están implementadas en PICS. El objetivo de esta herramienta es inspeccionar y comprender sistemas escritos en lenguaje C.

25 CAPÍTULO 1. INTRODUCCIÓN Estructura de la Disertanción La disertación está estructurada en seis partes, a continuación se describen cada una de ellas. Parte I: Introducción: presenta el problema abordado y describe su solución. Además, expone los objetivos y las contribuciones de la tesis. Esta parte esta compuesta por este capítulo. Parte II: Conceptualización de Comprensión de Programas: explica diferentes Conceptualizaciones de Comprensión de Programas y discute las ventajas y desventajas de cada una de ellas. Después de eso, presenta una conceptualización que enfatiza una característica ausente en las Herramientas de Comprensión de Programas (HPC). Esa característica es la relación entre los Dominios del Problema y Programa y la relación existente entre ambos. Esta parte está compuesta por los siguientes capítulos: Capítulo 2: Conceptualización de Comprensión de Programas: define CP y describe el rol de las Ciencias Cognitivas y la Ingeniería de Software en CP. Capítulo 3: Modelos Cognitivos: presenta un resumen de los Modelos Cognitivos actuales. Explica la relevancia de entender esos modelos para implementar HCP. Además, describe una sistematización de los conceptos de MC que es útil para construir estrategias con soporte cognitivo. Capítulo 4: Estado del Arte de las Herramientas de Comprensión de Programas: ilustra las aproximaciones corrientes de Comprensión de Programas a través de la presentación de diferentes HCP. Además, muestra que, generalmente, las estrategias para interconectar los Dominios del Problema y Programa no se consideran en ese tipo de aplicaciones. Parte III: Construcción de Herramientas de Comprensión de Programas Basadas en Estrategias para Interconectar Dominios: describe los pasos necesarios para construir HCP con funcionalidades para interrelacionar dominios. Esta parte esta compuesta por los siguientes capítulos: Capítulo 5: Visualización de Software: conceptualiza Visualización de Software. También describe las principales características de: Los Ambientes de Visualización; Sistemas de Visualización Orientados a la Comprensión de Programas; Aproximaciones para visualizar la información extraída desde los sistemas; etc. Finalmente, expone varias taxonomías de Visualización de Software y completa la más importante con criterios que posibilitan la

26 CAPÍTULO 1. INTRODUCCIÓN 20 categorización de las visualizaciones del Dominio del Problema y su relación con el Dominio del Programa. Capítulo 6: Estrategias para Relacionar Dominios: describe diferentes procedimientos para interconectar dominios enfatizando la relación entre los Dominios del Problema y Programa. Capítulo 7: Extracción de la Información: especifica procedimientos para organizar y extraer información estática del sistema de estudio y define un esquema de Instrumentación de Código que permite la recuperación de información dinámica. Es importante notar que ambos tipos de información son necesarias para la implementación de las estrategias de comprensión elaboradas en esta tesis doctoral. Parte IV: PICS una Herramienta de Comprensión de Programas: las estrategias descriptas en este trabajo de doctorado están implementadas en PICS una herramienta de Comprensión de Programas cuyo objetivo es ayudar al programador a entender programas escritos en lenguaje C. Esta parte consta de los capítulos descriptos a continuación: Capítulo 8: PICS un Sistema de Inspección y Comprensión de Programas: presenta una herramienta que implementa las principales estrategias expuestas en los capítulos precendentes. Capítulo 9: Casos de Estudio: expone los pasos necesarios para aplicar PICS a sistemas reales. Esta tarea se llevó a cabo para xfig, un programa de creación de dibujos, y agrep el comando de búsqueda de cadenas de caracteres en archivos provisto por Linux. Pate V: Conclusión y Trabajo Futuro: presenta un análisis de los resultados obtenidos en la tesis y explica algunas extensiones de las estrategias de desarrolladas. Los capítulos de esta parte se describen en los siguientes ítems. Capítulo 10: Conclusión: expone la conclusión de la tesis doctoral. Capítulo 11: Trabajos Futuros: describe las posibles extensiones de los temas desarrollados en la tesis. El propósito principal es motivar al lector a investigar algunos de esos tópicos. Parte VI: Apéndices: explica los pasos necesarios para la utilización de QEM (Quality Evaluation Method) para evaluar HPC. Asimismo, muestra algunas salidas del esquema instrumentación implementado en PICS. Los apéndices incluídos en esta parte son:

27 CAPÍTULO 1. INTRODUCCIÓN 21 Evaluación de Herramientas de Comprensión de Programas: usa QEM y los criterios definidos para cada área implicada en el desarrollo de HCP con el objetivo de evaluar la calidad y proveer una escala de preferencias de esta clase de aplicaciones. Árbol de Requerimientos no Estándar: muestra el árbol de requerimientos obtenido a partir de la investigación realizada en el contexto de: Modelos Cognitivos; Visualización de Software; Técnicas de Extracción de la Información y Estrategias de Interconexión de Dominios. Este resultado se expone sin adaptarlo a categorías de evaluación estándares. Gramática para Entender el Concepto de Chunk: exhibe una gramática sencilla que es útil para comprender un concepto muy importante en el contexto de los Modelos Cognitivos como lo es el de Chunk. Esquema de Instrumentación: Ejemplos: presenta algunos ejemplos resultantes de la aplicación de esquema del instrumentación a algunos programas reales.

28 Parte II COMPRENSIÓN DE PROGRAMAS 22

29 Capítulo 2 Conceptualización de Comprensión de Programas 2.1. Introducción Nunca consideres el estudio como una obligación, sino como una oportunidad para penetrar en el bello y maravilloso mundo del saber. Albert Einsten En el capítulo 1 se mencionó que el primer paso en la elaboración de una solución al problema de mejorar la comprensión de grandes sistemas se centra en el establecimiento de una definición de Comprensión de Programas (CP). Esta conceptualización es muy importante porque influencia los pasos subsecuentes en el desarrollo de la solución. Con este objetivo en mente, se realizaron diferentes investigaciones vinculadas a los Modelos Cognitivos que permitieron detectar la carencia de una clara y precisa conceptualización de esta disciplina. En este capítulo se discuten varias definiciones de Comprensión de Programas (CP) encontradas en la literatura y se describen sus principales inconvenientes. Después de eso, se presenta una nueva conceptualización y se explican brevemente las líneas de investigación derivadas de ella. Finalmente, en la sección 2.5 se expone la conclusión Conceptualización de Comprensión de Programas Normalmente, la CP se conceptualiza como: 23

30 CAPÍTULO 2. CONCEPTUALIZACIÓN DE COMPRENSIÓN DE PROGRAMAS 24 Comprensión de Programas: Disciplina de la Ingeniería de Software cuyo objetivo es a ayudar al programador a entender programas. Esta conceptualización presenta el inconveniente de usar la palabra Entender para describir Comprensión. De acuerdo a diferentes diccionarios el significado de Comprensión es: Comprensión: Entender profundamente el significado del algo. Y el significado de Entender es: Entender: Es tener una clara idea de algo. El lector puede observar que esos términos tienen el mismo significado, ambos casos implican alcanzar una profunda idea acerca de algo. Para evitar confusiones, la CP se puede conceptualizar como: Compensión de Programas: Disciplina de la Ingeniería de Software cuya finalidad es proveer el soporte adecuado para alcanzar un profundo conocimiento de los Sistemas de Software. Esta definición es más clara que la previa porque evita la ambiguedad producida por el uso de sinónimos. Sin embargo, se necesita más especificación porque alcanzar un profundo conocimiento acerca del software implica un Proceso de Aprendizaje y un Proceso de Ingeniería. Por una parte, el Proceso de Aprendizaje [Raj02] es necesario porque describe cuando y como el programador entiende el software de estudio [Aus91, NG84, O B03, BVDB93, SFM]. Por la otra, el Proceso de Ingeniería permite crear, basado en un proceso específico de aprendizaje, métodos, técnicas y herramientas útiles para comprender programas [Sto05]. Teniendo presente la discusión en los párrafos precedentes, se puede elaborar la siguiente definición de CP: Comprensión de Programas: Disciplina de la Ingeniería de Software que proporciona Modelos, Métodos, Técnicas y Herramientas, basados en un Proceso de Aprendizaje y un Proceso de Ingeniería, con el objetivo de alcanzar un profundo conocimiento de los Sistemas de Software.

31 CAPÍTULO 2. CONCEPTUALIZACIÓN DE COMPRENSIÓN DE PROGRAMAS 25 Esta definición es más completa que las presentadas anteriormente pero deja dos procesos muy importantes sin una clara especificación. En el proceso de aprendizaje utilizado para comprender programas se distinguen dos actores principales y una relación muy importante. Los actores son el programador y el sistema de software y la relación es el programador quiere entender los conceptos utilizados en el sistema de software basado en su trasfondo de conocimientos. Para entender un sistema, el programador necesita herramientas que faciliten la asimilación de los conceptos. Esas herramientas se construyen usando técnicas de ingeniería que están altamente influenciadas por las concepciones de aprendizaje usadas. Por este motivo, el rol de las HCP consiste en actuar como Puente Cognitivo (PC) entre el bagage de conocimientos del programador y los conceptos usados en el software. Los puentes cognitivos facilitan la elaboración de alguna clase de relaciones sustanciales y no arbitrarias denominadas Relaciones Significativas [Aus91] que permiten explicar los conceptos de la mejor manera posible [Aus91, NG84, RW02, Ext02]; cuando el programador alcanza este estado se encuentra en condiciones de modificar el software. Es importante notar que todos esos temas están descriptos en las Teorías de los Modelos Cognitivos (MC) [BVDB93, SFM]. El estudio de MC es importante, porque es un parámetro que permite decidir como se deben ensamblar las componentes del los sistemas de CP de forma tal que asistan adecuadamente al proceso mental del programador. El proceso de Ingeniería de Software (IS) implica el estudio de: Visualización de Software (VS) [SDBP98]; Extracción de la Información (IE) [ASU86, Bac79]; Administración de la Información (AI) [Pfa77, AHU88, Sta80] y Aproximaciones para Relacionar Dominios (ARD) [SDBP98, Bro82]. VS es importante porque permite representar, usando artefactos pictóricos y textuales, la información del sistema. Esta representación es útil para la elaboración de varias vistas que enfatizan diferentes aspectos y por consiguiente proporcionan muchos PC. EI se necesita porque provee la información requerida para implementar los conceptos de MC y para construir estrategias de VS. AI es útil porque permite organizar la información del sistema haciendo eficiente el acceso a los datos. Finalmente, ARD facilita la creación de estrategias cuya finalidad es relacionar diferentes dominios. Esas técnicas fomentan que el programador use los conceptos disponibles en su estructura mental. Teniendo presente la discusión expuesta anteriormente, se puede concluir que:

32 CAPÍTULO 2. CONCEPTUALIZACIÓN DE COMPRENSIÓN DE PROGRAMAS 26 Comprensión de Programas: Disciplina de la Ingeniería de Software destinada a proveer Modelos, Métodos, Técnicas y Herramientas, basadas en un Proceso de Aprendizaje y un Proceso de Ingeniería, con el objetivo de alcanzar un profundo conocimiento acerca de los Sistemas de Software. El Proceso de Aprendizaje implica el estudio de las Ciencias Cognitivas y la relación de sus principales conceptos con la Ingeniería de Software. El Proceso de Ingeniería incluye el estudio de áreas tales como: Visualización de Software; Extracción de la Información; Administración de la Información y Estrategias de Interconexión de Dominios con la finalidad de representar la información del sistema de una manera que enfatize sus principales aspectos Modelos Cognitivos en Comprensión de Programas Un programador entiende un programa cuando encuentra el código usado para producir su salida. Para alcanzar esta meta, construye un modelo mental con la información extraída desde el sistema. Después, ensaya relacionar esta información con los conceptos disponibles en su bagage de conocimientos. A través de este último proceso, puede entender las funcionalidades del sistema e incrementar su trasfondo de conocimientos. El punto importante es que para entender programas se usan tres componentes principales: Conocimiento; Modelo Mental y un Proceso de Asimilación [O B03, Tie89, VMV95]. Las teorías de Modelos Cognitivos describen el rol de cada una de esas componentes y las interacciones realizadas entre ellas para entender programas. Esas descripciones se llevan a cabo usando los conceptos provistos por las Teorías del Aprendizaje. En este contexto, se necesitan responder dos importantes preguntas: Qué es el aprendizaje? Cuáles son las estrategias usadas para aprender? Por una parte, el aprendizaje consiste en relacionar los conceptos previos y los nuevos de una manera sustancial y no arbitraria [Aus91, NG84]. Por la otra, el proceso de aprendizaje se concretiza por medio de estrategias tales como: Bottom-Up (BU), Top-Down (TD) o Híbridas. En la primera, el programador define algunas hipótesis relaciona-

33 CAPÍTULO 2. CONCEPTUALIZACIÓN DE COMPRENSIÓN DE PROGRAMAS 27 das con las tareas realizadas por el sistema. Luego, las verifica usando inspecciones de código, casos de prueba, análisis dinámico, etc. En la segunda, el programador analiza el código fuente usando abstracciones sucesivas. De esta manera, infiere el comportamiento del sistema y sus funcionalidades. La tercera, y quizás la mejor, acepta las aproximaciones TD y BU permitiendo que el programador adapte sus estrategias de aprendizaje de acuerdo a los conceptos disponibles en su estructura mental. Las conceptualizaciones de aprendizaje y las aproximaciones usadas para desarrollar el Proceso de Aprendizaje originan diferentes teorías y modelos en IS. Esas teorías permiten establecer una red conceptual para la construcción de HCP. Por esta razón, las mismas serán discutidas en el capítulo Ingeniería de Software en Comprensión de Programas En la sección 2.1 se declaró que el proceso de IS implica estudios sobre: Visualización de Software; Extracción de la Información; Administración de la Información y Estrategias para Interconectar Dominios. Esta sección describe brevemente esos temas para que el lector obtenga una visión general de las estrategias desarrolladas en este trabajo de doctorado Visualización de Software Este tema estudia criterios y estrategias que se emplean en la creación de vistas de un sistema [WS00]. Sobre esas vistas se eligen los principales atributos, generalmente relacionados con métricas de software, que permiten visualizar muchos aspectos del sistema evitando la sobrecarga de información. Para representar los atributos y construir varias vistas se deben analizar diferentes aproximaciones relacionadas con dos temas muy importantes: Modelación Estructural y Representación Gráfica. Esos tópicos se centran en la organización de la información y su visualización. El principal objetivo en esas áreas es proporcionar en una simple representación gráfica tanta información como sea posible. Por ejemplo, la Figura 2.1 muestra el Grafo de Dependencias de Módulos de un sistema de dos maneras. En la Figura de la izquierda, se exhibe el grafo de dependencias sin atributos. En la Figura de la derecha, se observan las dependencias modeladas como un grafo decorado. Esta estructura representa mucha información porque visualiza tres dependencias principales: funciones (rojo); datos (negro) y tipos (azul). Además, es útil cuantificar cada dependencia usando las propiedades de los objetos gráficos, por ejemplo intensidad del color de los arcos y nodos. El lector puede observar como

34 CAPÍTULO 2. CONCEPTUALIZACIÓN DE COMPRENSIÓN DE PROGRAMAS 28 Figura 2.1: Grafo de Dependencias de Módulos la representación de los atributos influencian la comprensión. Otra línea de investigación consiste en el análisis los criterios de visualización que se emplean en la evaluación de los Sistemas de Visualización de Software. Generalmente, esos criterios sólo contemplan los aspectos del software relacionados con el programa en sí mismo dejando de lado su comportamiento. Por esta razón, es necesario la elaboración de nuevas características que permitan evaluar concienzudamente HCP facilitando, de esta manera, la selección de la mejor HCP para casos de estudio específicos Extracción de la Información En este contexto, el foco está en el uso de estratégias de análisis estático y dinámico con la finalidad de extraer información del sistema. La selección de una estrategia depende de la clase de información que se necesite. Para la recuperación de la información estática se pueden usar técnicas de compilación tradicionales y avanzadas dependiendo del tipo de información que se desea recuperar [ASU86] [Bac79]. Por ejemplo, la detección de las partes del programa que afectan la ejecución de una función se puede llevar a cabo a través del uso de técnicas de slicing [Vis01]. Por otra parte, si el objetivo es conocer cuales son los objetos usados en tiempo de ejecución, es factible instrumentar el código fuente [BHVU06]. Finalmente, es posible simular la ejecución del programa para recuperar la mayor cantidad posible de información (funciones, variables, valores de las variables, etc) [Var03]. El capítulo

35 CAPÍTULO 2. CONCEPTUALIZACIÓN DE COMPRENSIÓN DE PROGRAMAS 29 7 describe las técnicas empleadas en esta tesis doctoral para recuperar la información del sistema Administración de la Información El uso de técnicas de Administración de la Información es necesario porque permite el acceso eficiente a toda la información del sistema [AHU88, Pfa77]. La cantidad de información es el factor determinante para seleccionar la estrategia de organización. Si el volumen de información es muy grande es deseable usar una base de datos [Sta80, Kru94, DB91]. En otro caso, se pueden emplear técnicas de organización de archivos tradicionales Estrategias para Interrelacionar Dominios Para lograr una efectiva Comprensión de Programas, las HCP deben proporcionar muchos Puentes Cognitivos [Aus91, NG84]. Un Puente Cognitivo (PC) es un concepto pedagógico usado para referenciar diferentes formas de representar el conocimiento. Los PC ayudan a entender programas a través de la reducción de la brecha existente entre los conocimientos del programador y los coneptos usados por el sistema. Un PC se plasma en las herramientas de CP pormedio del concepto de Vista. Una Vista es una representación del sistema que enfatiza alguna de sus características. Por ejemplo, un sistema se puede representar por su código fuente u objeto. En este caso, el foco está en la organización del texto del programa. Otra estrategia común para visualizar la información del sistema son los Grafos de Llamadas a Funciones y Dependencia de Módulos. Esas estructuras resaltan las relaciones existentes entre módulos y funciones. Por ejemplo, a través de estas estrategias se pueden detectar facilmente las funciones llamadas por una función específica, las funciones que no son llamadas por ninguna función, el orden de relevancia de los módulos, los módulos más usados del sistema, etc. Es importante notar que cada vista adquiere importancia dependiendo de la característica del sistema que se desee visualizar. La interconexión entre las distintas vistas incrementa las posibilidades de entender el comportamiento del sistema. Esto se debe a que cada una de ellas representa un dominio específico de conocimiento, de esta manera, el programador usa el dominio más conveniente de acuerdo a su estructura mental (Este tema se conoce con el nombre de Interrelación de Dominios (ID)) [Bro82, Bro78]. ID hace referencia a la capacidad de traducir un dominio de aplicación en otro haciendo explícita la relación entre ellos. Por ejemplo, el código fuente es una vista común del sistema. En este caso, el dominio está establecido por el lenguaje de programación usado para implementar el sistema.

36 CAPÍTULO 2. CONCEPTUALIZACIÓN DE COMPRENSIÓN DE PROGRAMAS 30 Este dominio se puede traducir en el dominio de los grafos por medio de una representación clásica: El Grafo de Funciones. En este contexto, la relación entre esos dominios es directa; cada nodo del Grafo de Funciones representa una función en el código fuente y es posible navegar entre esos dominios facilmente. Este es un simple ejemplo de como se pueden combinar las vistas usando ID. Sin embargo, existen muchos desafíos en este campo porque no siempre las relaciones son claras y los procedimientos de navegación son dificiles de implementar. Un ejemplo de esta declaración consiste en encontrar un mapeo entre los Dominios del Problema y Programa. Este mapeo es importante porque visualiza la relación entre la salida del sistema y los elementos usados para constuirla. El capítulo 6 describe el problema de ID y presenta estrategias que relacionan diferentes dominios de aplicación. Además, enfatiza algunas propuestas que logran relacionar los Dominios del Problema y Programa proporcionando de esta forma una contribución importante en el contexto de CP Conclusión En este capítulo se definió Comprensión de Programas (CP) como una disciplina de la IS destinada a ayudar al programador a entender programas. Para llevar a cabo eficientemente esta tarea, esta disciplina hace uso de los conceptos de: Modelos Cognitivos; Visualización de Software; Técnicas de Extracción y Administración de la Información; y Estrategias de Interconexión de Dominios. La primera de ellas es útil para definir estrategias de aprendizaje. La implementación de esas estrategias en HCP es relevante porque simplifican la comprensión de software. La segunda es importante porque los procedimientos de aprendizaje y la información extraída desde el sistema se deben mostrar de una manera adecuada. La tercera se necesita porque los esquemas de aprendizaje y visualización de software se implementan teniendo en cuenta la información recuperada desde el sistema. Se debe hacer una mención especial para las Estrategias de Interconexión de Dominios, particularmente aquellas que vinculan los Dominios del Problema y Programa, porque incorporan nuevas funcionalidades de comprensión que facilitan el entendimiento del comportamiento del sistema. Finalmente, es importante notar que el establecimiento de la nueva conceptualización de CP y sus líneas de investigación derivadas se basan en los estudios sobre Modelos Cognitivos presentados en el capítulo 3.

37 Capítulo 3 Modelos Cognitivos El factor más importante que influencia el aprendizaje es lo que el estudiane ya sabe. Averigua esto y enseña consecuentemente. David Ausubel 3.1. Introducción En el capítulo 2 se presentó una conceptualización de Comprensión de Programas (CP). Esa definición fue el primer paso en la solución del problema de facilitar la comprensión de grandes sistemas (ver capítulo 1). En el mismo capítulo también se declaró que el principal desafío en CP consiste en relacionar los Dominios del Problema y Programa. Esta proposición se justificó usando como base teórica los Modelos Cognitivos. El estudio de los Modelos Cognitivos (MC) es un campo de investigación relevante porque permite conocer como el programador entiende programas. Esta característica es importante debido a que proporciona guías útiles para la elaboración de Herramientas de Comprensión de Programas (HCP) que asistan al programador en el Proceso de Comprensión. Las teorías de MC describen los conceptos escenciales empleados en este proceso y caracterizan el camino seguido por el programador para elaborar su conocimiento. Actualmente, existe un acuerdo en las descripciones de las componentes del programa como se podrá ver a través de este capítulo. Sin embargo, es posible encontrar muchas diferencias en las estrategias empleadas para relacionarlas y construir nuevos conceptos. En este contexo, algunos autores afirman que la forma usada para adquirir conceptos es Top-down, otros creen que el proceso efectivo es Bottom-up o Híbrido. 31

38 CAPÍTULO 3. MODELOS COGNITIVOS 32 El Constructivismo, un campo reciente de la Psicología Cognitiva, propone una nueva manera de conceptualizar el proceso de aprendizaje que se basa en la asociación de los conceptos nuevos y previos de una forma sustancial y no arbitraria. Para alcanzar este objetivo, el sujeto de aprendizaje (programador) elige la estrategia de comprensión más conveniente de acuerdo a su trasfondo conceptual. Este capítulo describe los principales conceptos usados en los MC. Luego, introduce los modelos de cognición más importantes en el campo de la CP. Esos patrones de aprendizaje se ilustran con ejemplos concretos y diagramas que facilitan su análisis comparativo. Como paso siguiente, expone nuevas definiciones de los conceptos básicos de MC que facilitan su implementación en programas de computadoras. Todas las tareas mencionadas previamente tienen como objetivo: i) La elaboración de una conceptualización de CP; ii) La proposicón de estrategias para mejorar la comprensión de programas y iii) La creación de un vocabulario sistemático y uniforme para discutir diferentes MC. Finalmente, se exponen las conclusiones Elementos Comunes de los Modelos Cognitivos Esta sección define los conceptos básicos de MC [SFM97, SFM, VMV95] empleados por los autores para explicar su forma de concebir las estrategias diseñadas para entender programas. Es importante notar que los procedimientos de comprensión corrientes carecen de una descripción sistemática que permita la implementación, sin ambiguedad, de los conceptos de MC en programas de computadoras. El lector podrá encontrar el sustento de esta afirmación en el desarrollo de este capítulo. Un MC está compuesto por tres componentes importantes [Sto05]: 1. Conocimiento: se distinguen dos clases de conocimiento: Interno: se refiere a los conceptos que el programador posee en su estructura de conocimiento. Externo: describe los conceptos utilizados en el sistema. 2. Proceso de Asimilación: especifica la estrategia de aprendizaje usada para entender el sistema (en este capítulo se exponen diferentes formas de llevar a cabo la asimilación). 3. Modelo Mental: es una representación interna del sistema. Está compuesto por elementos Estáticos y Dinámicos.

39 CAPÍTULO 3. MODELOS COGNITIVOS 33 Los elementos estáticos incluyen los siguientes conceptos: Estructuras de Texto: detalla la disposición y orden relativo de los trozos de texto del programa dándole una organización jerárquica. A continuación, se muestran algunos ejemplos de estructuras de texto de un lenguaje de programación. statement1 if <cond> then for(acc1;acc2;acc3) statement else statementn... (a) (b) (c) Las estructuras de textos se pueden componer como se observa en el ejemplo de abajo. min=max_int; for (i=0;i<100;i++) if (min>a[i]) then min=a[i]; Este segmento de código muestra una secuencia compuesta por una asignación y una iteración. Dentro de la iteración, se encuentra una sentencia de selección. La relación entre ellas es la siguiente: La asignación se ejecuta antes que la iteración. Esta última sentencia habilita la ejecución de la sentencia de selección. Finalmente, la asignación (d) dentro de la sentencia de selección se puede o no ejecutar. Chunks: representan estructuras de textos en diferentes niveles de abstracción. Por ejemplo, al segmento de código (d), usado para ejemplificar la composición de estructuras de texto, se le puede asignar el nombre encontrar el menor elemento de un arreglo. Planes: son esquemas con dos ranuras: Tipos y Fillers. El primero simboliza clases de objetos genéricos. El segundo describe operaciones sobre esos objetos. Ambas clases de ranuras son elementos de conocimiento que se usan para validar interpretaciones e inferencias. Se distinguen dos clases de planes, ellos son: Planes de Programación: describen conceptos de programación de alto, bajo o intermedio nivel de abstracción. Incluye roles para objetos de datos, operaciones, tests, etc. Por ejemplo, los marcos (frames) son una simple técnica de representación del conocimiento que constan de ranuras (slots) que se utilizan para describir diferentes características. Esas características se manipulan por operaciones definidas por el programador. Las características se conceptualizan como ranuras Tipo y el código como ranuras Fillers.

40 CAPÍTULO 3. MODELOS COGNITIVOS 34 Los tipos de datos abstractos también son planes. Por ejemplo, la estructura que define los nodos de una lista es una ranura Tipo y los procedimientos que trabajan sobre ellas son las ranuras Fillers. Planes de Dominio: es una clase de plan que describe el conocimiento acerca del Dominio del Problema. La siguiente es una frase clásica usada en este contexto: La Factura de Impuestos tiene tres campos importantes: El nombre del cliente; Descripción y Total. La ranuras Tipo se componen por los datos de la factura y las ranuras Filler consisten de las posibles operaciones realizadas sobre esos datos. Los elementos dinámicos de MM se relacionan con las estrategias usadas por el programador para guiar su proceso de aprendizaje. En este contexto, se distinguen los siguientes elementos: Chunking: es un proceso que permite la creación de nuevos niveles de abstracción de chunks. Observe las siguientes piezas de código: min=max_int; for(i=0;i<n;i++) if (min>a[i]) then min=a[i]; max=-max_int; for(i=0;i<n;i++) if (max<a[i]) then max=a[i]; el programador puede abstraer dos chunks a nivel programa, ellos son: Extraer el mínimo y Extraer el máximo. Ahora suponga que este segmento de código es parte de una función que trabaja sobre un conjunto de clientes. En este caso, el programador puede extraer un chunk a nivel dominio y denominarlo: Límites de compras. Referencias Cruzadas: se usa para identificar la relación entre diferentes dominios. El ejemplo descripto en el ítem previo para los chunks a nivel dominio muestra una referencia cruzada. Esto se debe a que el programador puede relacionar los Dominios del Problema y Programa. Finalmente, los modelos mentales contienen elementos cuya finalidad es facilitar la comprensión: Beacons: son patrones de programación usados por el programador para asignar semántica a los trozos del código fuente. Observe el siguiente código:

41 CAPÍTULO 3. MODELOS COGNITIVOS 35 struct node minimum (struct tree *t) { } return givemeroot(t); además asuma que la función givemeroot tiene O(1). Con esta información, el programador puede entender que la estructura de datos tree es un heap. Reglas del Dominio de Discurso: simbolizan las convenciones de programación. Por ejemplo, en programación estructurada todas las funciones deben tener una única entrada y un único punto de salida. Las siguientes secciones describen los Modelos Cognitivos más conocidos e introducen nuevas formas innovadoras de concebir el proceso de aprendizaje El Modelo de Letovsky El modelo de Letovsky [O B03, VMV95, SFM] tiene tres partes claramente definidas.: Conocimiento, Modelo Mental y Proceso de Asimilación. Conocimiento: se relaciona con el trasfondo de conocimientos del programador (conocimiento interno) y los conceptos implementados en el sistema (conocimiento externo). Los mismos se pueden explicar a través de reglas del dominio de discurso, planes, estructuras de texto, etc. Modelo Mental: tiene tres capas: Especificación: explica los objetivos del sistema (descripción del Dominio del Problema). Implementación: describe como se implementa la especificación usando estructuras de datos y funciones (Dominio del Programa). Anotación: asocia cada objetivo (capa especificación) con su correspondiente pieza de código (capa implementación) (interrelación entre los Dominios del Problema y Programa). Proceso de Asimilación: este proceso puede ser Top-down o Bottom-up. El programador emplea la estrategia que considera produce más conocimiento. Letovsky considera que el programador entiende el sistema cuando puede relacionar los Dominios del Problema y Programa. Para realizar esta actividad, el programador anota, a través de un proceso de asimilación y usando referencias cruzadas, cada funcionalidad del sistema. En este proceso, el

42 CAPÍTULO 3. MODELOS COGNITIVOS 36 Figura 3.1: Instantánea del Modelo de Letovsky

43 CAPÍTULO 3. MODELOS COGNITIVOS 37 programador puede encontrar tareas del sistema que no puede explicar. Estas actividades se registran en la Unidad Bamboleante. La Figura 3.1 muestra el modelo de Letovsky El Modelo de Schneiderman y Mayer La idea detrás de este simple modelo [O B03, SFM, SFM97, BVDB93] se describe en los próximos párrafos. El programador lee el código fuente del sistema y lo re-codifica asignándole semántica a cada parte. Como resultado de esta operación se obtienen representaciones del programa en diferentes niveles de abstracción. En el nivel más abstracto se encuentran los objetivos del sistema, y en el nivel más concreto están los detalles de implementación. Para alcanzar este estado se utilizan los procesos de agrupación (chunking) y referencias cruzadas. Esos procesos usan la base de conocimientos del programador que contiene dos clases de conocimientos: Sintáctico y Semántico. El primero se refiere a las reglas sintácticas de los lenguajes de programación. Por ejemplo, los programas escritos en lenguaje C no pueden tener funciones anidadas, todas las sentencias finalizan con punto y coma, etc. El segundo se relaciona con los conocimientos de programación. Por ejemplo, técnicas de organización de archivos eficientes, estrategias de creación de una base de datos, etc. En esta propuesta, el proceso de comprensión es claramente Bottom-up, comienza a nivel del código fuente y continúa hasta que, por medio de abstracciones sucesivas, se reconstruye el Dominio del Problema El Modelo de Brooks Brooks [Bro78, Bro82, Wal02a] cree que el Proceso de Comprensión de Programas (PCP) consiste en encontrar un mapeo entre cada funcionalidad del sistema y el código usado para implementarla. En otras palabras, Brooks declara que un programador logra comprender un programa si puede relacionar los Dominios del Problema y Programa. En este modelo, el conocimiento se construye usando una aproximación top-down. El programador hace algunas hipótesis acerca de las funcionalidades del sistema y luego las verifica usando dominios intermedios. Esas hipótesis se basan en el conocimiento del Dominio del Problema, la documentación disponible y la información extraída desde las representaciones intermedias. Este proceso de verificación se repite hasta encontrar el código que implementa las hipótesis de estudio. Para Brooks, PCP comienza cuando se observa el comportamiento del sistema. En ese momento, el

44 CAPÍTULO 3. MODELOS COGNITIVOS 38 Figura 3.2: Instantánea del Modelo de Brooks

45 CAPÍTULO 3. MODELOS COGNITIVOS 39 programador hace algunas hipótesis, por ejemplo una funcionalidad típica del sistema es computar el salario de los empleados. En el proceso de verificación, el programador necesita usar otras representaciones del sistema (dominios), por ejemplo Diagramas de Casos de Uso de UML, que posibilitan la validación o rechazo de la hipótesis. Una validación aparece cuando encuentra un caso de uso relacionado con salarios. Pero para encontrar el código fuente que implementa el caso de uso, se requiere inspeccionar el sistema usando otras vistas, por ejemplo un Diagrama de Componentes de UML. Sobre este diagrama, el programador identifica los módulos relacionados con salario. Pero esto no es suficiente, ya que la información debe ser más fidedigna para lograr una relación entre el código y el comportamiento del sistema. Por esta razón, el programador puede usar el Grafo de Funciones y emplear los operadores de grafos para extraer algunas conclusiones, tales como: una componente conectada está formada por funciones que implementan el módulo salario. Finalmente, el programador encuentra los objetos del Dominio del Programa que implementan las funcionalidades del sistema de estudio: las funciones computarsalario, computarimpuestos son funciones directamente relacionadas con la funcionalidad bajo análisis. La descripción de este caso práctico (ver Figura 3.2) es simple porque, en el proceso de validación de hipótesis, pueden aparecer nuevas hipótesis. En este caso, para validar esas nuevas suposiciones, se aplica la misma aproximación que la utilizada para las validaciones iniciales. El punto importante es que el programador encuentra el código que implementa la funcionalidad bajo estudio. En otras palabras, alcanza una relación directa entre los Dominios del Problema y Programa El Modelo de Soloway, Adelson y Ehrlich Este modelo [O B03, SFM, SFM97, Tie89, VMV95] usa cuatro componentes: Representaciones externas (documentación); Representaciones internas (modelo mental); Trasfondo de conocimientos del programador y Reglas del dominio de discurso. El programador intenta relacionar esas componentes usando un proceso de comprensión top-down. Para entender el sistema, el programador usa tres clases de planes: Estratégico; Táctico y de Implementación. El primero describe la estrategia global del programa; esta clase de plan está relacionada con las tareas llevadas a cabo por el sistema para alcanzar sus objetivos. El segundo caracteriza las estrategias locales del programa. El último se interesa con la implementación del plan táctico. Finalmente, esos planes se confrontan con las reglas del dominio de discurso con el propósito de validar las supociones o detectar inconsistencias. Esta actividad puede crear otros planes que son analizados siguiendo las mismas estrategia que las usadas para los planes iniciales. La Figura 3.3 ilustra el

46 CAPÍTULO 3. MODELOS COGNITIVOS 40 proceso de comprensión de Soloway. Suponga que una funcionalidad del sistema es imprimir la lista de empleados de alguna compañia. Un plan estratégico es obtener la lista de empleados, ordenarla e imprimirla. El plan táctico es leer la lista de empleados usando un simple algoritmo secuencial, aplicar el algoritmo quick sort y luego imprimir el resultado. Finalmente, el plan de implementación está relacionado con el algoritmo específico usado para implementar los procedimientos para: Lectura de empleados; Quick sort; Imprimir. Soloway et. al., hacen una diferencia entre Comprensión y Entendimiento. Por una parte, ellos creen que la comprensión se lleva a cabo en un alto nivel de abstracción. En otras palabras, esta tarea se realiza analizando los objetivos del sistema y sus relaciones. Por la otra, el entendimiento se concretiza en niveles más bajos analizando las componentes del programa de alto y bajo nivel y sus relaciones El Modelo de Pennington Pennington [SFM, SFM97] propone una estrategia de aprendizaje bottom-up. Esta aproximación usa dos modelos para describir el proceso de comprensión: El Modelo del Programa (MP) y El Modelo de Situación (MS). MP se emplea cuando es la primera vez que el programador tiene contacto con el código fuente. Este modelo se construye por medio de la realización de agrupaciones (chunking) usando un procedimiento de referencias cruzadas que consiste en mapear el código del programa en un plan de programación de más alto nivel que posibilita entender el código fuente. Por ejemplo, cuando el programador encuentra una iteración y en su cuerpo un procedimiento de swap, tiene argumentos para suponer que el código es un procedimiento de ordenamiento. Es importante notar que es posible que esos planes generen otros planes, los cuales serán asimilados por el programador y luego incorporados en su trasfondo de conocimientos. MS requiere conocimiento acerca del Dominio del Problema. MS se construye a través de procesos de agrupación (chunking) y de referencias cruzadas. Estos últimos mapean el código del programa en planes de dominio que describen el código fuente usando vocabulario del Dominio del Problema. Por ejemplo, el mismo caso presentado en el ejemplo anterior para planes de programación se puede expresar en términos de planes de dominios, como: este grupo de sentencias ordena los empleados de esta compañia. Finalmente, se usa otro proceso de referencia cruzada para mapear los planes de programación del MP en planes de dominio del MS y viceversa (ver Figura 3.4). Es importante destacar que todo el conocimiento obtenido cuando se construyen los modelos MP y MS se pueden usar para refinar esos modelos.

47 CAPÍTULO 3. MODELOS COGNITIVOS 41 Figura 3.3: Instánea del Modelo de Soloway

48 CAPÍTULO 3. MODELOS COGNITIVOS 42 Figura 3.4: Instantánea del Modelo de Pennington

49 CAPÍTULO 3. MODELOS COGNITIVOS 43 Figura 3.5: Ejemplo del Modelo de Pennington

50 CAPÍTULO 3. MODELOS COGNITIVOS 44 Suponga que un progamador quiere comprender las funcionalidad Ventas por Empleados disponible en un sistema de ventas. Observando el código fuente, logra detectar un conjunto de funciones que se pueden agrupar en dos chunks (recuerde que un chunk son grupos de estructuras de texto): buscarempleado y registrarventa. Luego de un breve análisis lógico de esas partes del programa, puede crear el siguiente plan de programación: 1. Encontrar un empleado desde la base de datos de empleados 2. Registrar el total de ventas realizadas por el empleado Para verificar que el plan de programación tiene relación con el Dominio del Problema, el programador intenta elaborar MS analizando la documentación o a través del uso del sistema. Suponga que luego de este proceso, encuentra que el objetivo Ventas por cada miembro de la Compañia está asociado con el plan de dominio Adicionar Ventas (una operación disponible en el menú del sistema). Cuando activa esta opción, el sistema requiere el ingreso de una identificación del vendedor que le permite aceptar o rechazar la operación. Un caso de aceptación se produce cuando la identificación ingresada se corresponde un miembro de la empresa y por consiguiente se computan las ventas realizadas por el empleado y se almacena el resultado. En otra situación, el sistema informa que la clave es incorrecta. Teniendo presente este escenario de ejecución, el plan de dominio se puede describir de la siguiente manera: Para asociar ventas con empleados se necesita verificar si la identificación ingresada se corresponde con un empleado de la compañia. Si esta operación se completa con éxito, entonces el sistema registra el monto de ventas y regresa al menú principal. En otro caso, se reporta un error. La última tarea realizada en este modelo consiste en relacionar los planes de dominio con los de programación. Para el ejemplo descripto en los párrafos previos esto se lleva a cabo asociando las funciones correspondientes a los chunks: buscarempleado y registrarventa con la semántica relacionada al plan de dominio elaborado en MS El Constructivismo como una Aproximación para Entender Programas El Constructivismo es un área de la Psicología Cognitiva cuyo objetivo es el estudio del proceso de producción del conocimiento. Actualmente, esta disciplina es importante para la CP porque no determina la estrategia de aprendizaje. Esta característica es la principal discrepancia con las otras propuestas presentadas en las secciones prévias.

51 CAPÍTULO 3. MODELOS COGNITIVOS 45 Por una parte, el Constructivismo sostiene que el proceso de aprendizaje no es estrictamente topdown, ni bottom-up ni híbrido, sino que consiste de combinaciones seleccionadas por el sujeto de aprendizaje de acuerdo a su trasfondo de conocimientos. Por la otra, y de la misma forma que otros MC, el Constructivismo reconoce las siguientes componentes del proceso de aprendizaje: Conocimiento Previo: este tipo de conocimiento está almacenado en la mente del sujeto de aprendizaje en una estructura denominada Estructura Cognitiva. En esta estructura se integran los nuevos conceptos cuando se alcanza un aprendizaje significativo. Nuevo Conocimiento: está compuesto por el conocimiento que el programador desea aprender. En el caso de CP, el mismo se recupera desde el programa de estudio. Proceso de Asimilación: puede ser top-down, bottom-up o híbrido. El sujeto de conocimiento selecciona la estrategia que le permite producir más conocimiento. Modelo Mental: es una representación mental del programa. Cuando esta representación del programa se liga con la estructura de conocimiento, el sujeto de aprendizaje alcanza un verdadero aprendizaje. En otro caso, las relaciones son arbitrarias y se pueden olvidar fácilmente. Los autores expresan la interrelación entre esas componentes de muchas maneras. En las próximas subsecciones se describen los conceptos básicos y se considera su relevancia para la CP Las Ideas de Ausubel y Novak Davil Ausubel es el creador de la Teoría del Aprendizaje Significativo. Esta teoría conceptualiza al aprendizaje como: Aprendizaje: Habilidad de relacionar los nuevos conocimientos con los previos en una forma sustancial y no arbitraria. Esta clase de relación se denomina Relación Significativa. Cuando el sujeto de aprendizaje logra este tipo de relaciones puede detallar el tema aprendido de diferentes maneras y trasladar una aplicación de esos conceptos a otras situaciones similares. Para alcanzar un Aprendizaje Signiticativo se deben reunir las siguientes condiciones: El contenido debe ser claro y estar logicamente organizado. El sujeto de aprendizaje debe predisponer a adquirir el conocimiento de una forma significativa.

52 CAPÍTULO 3. MODELOS COGNITIVOS 46 El aprendizaje se puede llevar a cabo por recepción o por descubrimiento. En el primero, el estudiante recibe la información en su estado final y debe relacionar los conceptos de una forma significativa. En el segundo, está obligado a crear su estrategia para descubrir y relacionar los conceptos relevantes. Es importante destacar que en ambas aproximaciones se utiliza un Proceso de Asimilación. Para Ausubel la asimilación puede ser: Infra-ordenada: aparece cuando las relaciones de conceptos se realizan usando un proceso de subordinación. Supra-ordenada: en este caso los conceptos se sintetizan en otro más genérico. Combinatorio: se construye cuando se relacionan dos o más conceptos, en el mismo nivel de abstracción. A medida que el estudiante va aprendiendo contenidos incorpora los nuevos conceptos en su estructura cogitativa. En este proceso, los conceptos se refinan produciendo distinciones más específicas por medio de un proceso de Diferenciación Progresiva. También, en esas circunstancias, es común encontrar conceptos contradictorios o incompatibles; esta situación se conoce como Disonancia Cognitiva. Cuando el estudiante puede unificar esos conceptos alcanza una Reconciliación Integradora y de esta manera recupera su armonía conceptual. El Modelo Mental se concibe como una subestructura de conocimiento que puede o no estar vinculado con la estructura cogitativa principal (base de conocimiento); en efecto, depende de la clase de relación (significativa o no) alcanzada por el estudiante. Ausubel usa la noción de Puente Cognitivo para simbolizar los artefactos usados para facilitar el aprendizaje significativo. Elegir un método y un formalismo para construir esa clase de objetos es complejo y depende del tema a enseñar. En este contexto, Novak, otro precursor de la Teoría del Aprendizaje Significativo, propone como herramienta didáctica, para alcanzar relaciones significativas, los Mapas Conceptuales. Un Mapa Conceptual muestra los conceptos principales y sus relaciones. En los Mapas Conceptuales, los conceptos están conectados a través de flechas rotuladas que describen la relación entre ellos. Novak afirma que los Mapas Conceptuales promueven el aprendizaje significativo porque fuerzan al estudiante a extraer y relacionar los conceptos usados en el tema de estudio. Con esta propuesta, los conceptos y sus relaciones se deben mostrar graficamente lo cual permite la dectección de incosistencias conceptuales y por consiguiente la búsqueda de posibles soluciones.

53 CAPÍTULO 3. MODELOS COGNITIVOS Modelo de Shaochun Xu Este modelo describe el proceso de aprendizaje como la aplicación sucesiva de dos subprocesos: Asimilación y Acomodación. El primero estudia el método seguido para entender el nuevo conocimiento. El segundo hace referencia a las estrategias usadas en la diferenciación progresiva de conceptos. Xu distingue dos tipos de Asimilación: Absorpción: describe la internalización del conocimiento. Denial: expresa el rechazo de conocimiento. El proceso de Acomodación se realiza después de la Asimilación. Xu clasifica la acomodación como: Reorganizaciones: se refiere a la diferenciación progresiva de conceptos producida por el uso y aplicación de los nuevos conocimientos. Expulsiones: se asocia con el rechazo de alguna parte del nuevo conocimiento. El programador puede alcanzar diferentes niveles de Asimilación y Acomodación. Para categorizar esos niveles el modelo de Xu usa la taxonomía de Bloom; esta clasificación distingue seis niveles de aprendizaje: Conocimiento; Comprensión; Aplicación; Análisis; Síntesis y Evaluación. Cada nivel describe la clase de aprendizaje adquirida por el programador. En otras palabras, este modelo provee una explicación simple y práctica del proceso de aprendizaje. Además, el modelo permite evaluar el grado de aprendizaje adquirido de acuerdo a seis categorías altamente relacionadas con la CP como lo son las descriptas por Bloom. Aplicar esta propuesta es simple, el evaluador diseña un conjunto de preguntas relacionadas con las cuatro actividades mentales principales: Absorpción; Denial; Reorganización y Expulsión (Xu en [Xu05] propone algunas encuestas interesantes). Después de eso y de acuerdo con las respuestas obtenidas, se extraen y clasifican las acciones mentales considerando la taxonomía de Bloom. Sobre esos resultados, es posible realizar algunos análisis matemáticos para cuantificar el grado de aprendizaje. Un ejemplo detallado de esta aproximación se puede encontrar en [Xu05] Discusión acerca de los Modelos Cognitivos A través del estudio de los MC se pueden extraer guías interesantes para desarrollar métodos, estrategias y herramientas que simplifiquen la CP. El primer paso para llevar a cabo esta tarea consiste en la definición criterios de comparación que posibiliten la extracción de los conceptos y procedimientos

54 CAPÍTULO 3. MODELOS COGNITIVOS 48 más relevantes usados en la descripción de los MC. Esta tarea es vital porque es la base para la elaboración de estrategias de CP. El segundo paso, abordado en la próxima sección, se interesa con la sistematización de los conceptos, este trabajo tiene como objetivo la elaboración de técnicas que faciliten la implementación de estategias de cognición en HCP. Para el primer paso, se proponen los siguientes criterios: Factor de Cognición: se refiere a las circunstancias que posibilitan la comprensión del sistema de estudio. Conceptos Usados: conocer los conceptos empleados en las descripciones de los MC permite identificar las principales componentes de software que se deben incorporar en las propuestas de CP. Modelo Mental: hace referencia a las distintas representaciones del programa que el programador utiliza en el proceso de comprensión. Tipo de Proceso de Asimilación: este criterio es crucial porque describe la aproximación usada para aprender. Propuesta de Puente Cognitivo: los Puentes Cognitivos permiten crear estrategias que asisten al estudiante en el proceso de asimilación. Esta aproximación se usa comunmente en situaciones tradicionales de aprendizaje. No obstante, se pueden adaptar para comprender programas. Componentes Internas de Conocimiento: es importante percibir cuales son las componentes internas usadas para entender conceptos. Esto se debe a que ellas permiten construir las componentes de software que posibiliten la recuperación de los conceptos más relevantes para comprender alguna temática. Fuente de Conocimiento Externa: este criterio permite la deteción de las fuentes de conocimiento externo para la recuperación de información valuable que se utilizará para la construcción de estrategias de CP. Comprensión/Entendimiento: existen divergencias en la jerga de Ingeniería de Software con respecto a las concepciones de Comprensión y Entendimiento. Analizar las opiniones de importantes investigadores acerca de esta temática es relevante porque posibilita esclarecer este conflicto. Representación del Nuevo Conocimiento: este criterio es interesante porque permite consensuar la clase de representaciones del conocimiento que serían factibles de utilizar en las propuestas de CP.

55 CAPÍTULO 3. MODELOS COGNITIVOS 49 Las Tablas 3.1, 3.2 y 3.3 muestran el análisis realizado usando esos criterios.

56 CAPÍTULO 3. MODELOS COGNITIVOS 50 Modelos Cognitivos para la Comprensión de Programas Letovsky Schneiderman Factor de Cognición Alcanzar una relación entre los Dominios del Problema y Alcanzar una relación entre los Dominios del Problema y Programa. Conceptos Usados Reglas del discurso, planes, estructuras de texto, referencias cruzadas. Modelo Mental Tres capas: Especificación; Implementación; Anotación y una Unidad Baboleante. Programa. Chunking y referencias cruzadas. Base de Conocimiento; memoria a corto término; memoria de trabajo. Tipo de Proceso de Asimilación Top-down or Bottom-up. Top-down o Bottom-up. Propuestas de Puentes Cognitivos No especificada. No especificada. Componentes Internas de Conocimiento No especificada. Base de Conocimiento. Fuentes de Conocimiento Externo Documentación del sistema; Código fuente y Representaciones externas. Especificación del Problema y código fuente. Comprensión/Entendimiento No hay diferencia. No hay diferencia. Representación del nuevo conocimiento Documentación provista por la capa Anotación y la información disponible en la unidad bamboleante. Especificación del Problema refinada y Especificación del código fuente. Cuadro 3.1: Comparación de MC

57 CAPÍTULO 3. MODELOS COGNITIVOS 51 Modelos Cognitivos para la Comprensiónde Programas Brooks Soloway Factor de Cognición Alcanzar una relación entre los Dominios del Problema y Programa. Alcanzar una relación entre los Dominios del Problema y Programa. Conceptos Usados Beacons, Referencias Cruzadas, Esquemas de Dominio. Modelo Mental Diferentes representaciones del sistema en distintos niveles de abstracción. Programa. Tipo de Proceso de Asimilación Top-down. Top-down. Propuestas de Puentes Cognitivos Interconectar diferentes dominios. Planes Estratégicos y de Implementación; Referencias Cruzadas; Chunking; Beacons y Reglas del Dominio. Representaciones del sistema en tres niveles de abstracción diferentes: Dominio; Dominio/Programa; Construir tres clases de planes: Estratégico; Táctico; y de Implementación. Componente Internas de Conocimiento No está especificado. Jerarquía de objetivos y planes. Documentación del Sistema. Fuentes de Conocimiento Externas Especificaciones del Sistema; Documentación; Representaciones del Sistema; Formalismos de Dominio. Comprensión/Entendimiento No hay diferencia. No hay diferencia. Representación del Nuevo Conocimiento Nueva Documentación. Nueva Documentación. Cuadro 3.2: Comparación de MC

58 CAPÍTULO 3. MODELOS COGNITIVOS 52 Modelos Cognitivos para la Comprensión de Programas Pennington Xu Factor de Cognición Alcanzar una relación entre los Dominios del Problema y Programa. Alcanzar una relación entre los Dominios del Problema y Programa. Conceptos Usados Modelo de Situación y Programa, Chunking, Referencias Cruzadas. Modelo Mental Consiste de representaciones en dos niveles de abstracción diferences: Programa y Dominio. No está especificada. No está especificado. Tipo de Proceso de Asimilación Bottom-up. Seleccionada por el programador de acuerdo a su trasfondo de conocimientos. Propuestas de Puentes Cognitivos No está especificado. No está especificado. Componentes Internas de Conocimiento No está especificado. No está especificado. Fuentes de Conocimiento Externo Documentación y Representaciones del Sistema; Especificación del Dominio. Comprensión/Entendimiento La Comprensión se lleva a cabo en niveles de abstracción altos y el Entendimiento se realiza a nivel de código. Representación del Nuevo Conocimiento Nueva documentación. En este reporte se detalla la relación entre el modelo del Programa y el de Situación. Código Fuente y Documentación del Sistema. No hay diferencia. Nueva documentación. Además, una tabla con diferentes tareas del sistema caracterizada a través de cuatro categorías: Absorpción; Denial; Reorganización; y Expulsión. Finalmente, una evaluación de cada tarea del sistema usando la taxonomía de Bloom. Cuadro 3.3: Comparación de MC

59 CAPÍTULO 3. MODELOS COGNITIVOS 53 Figura 3.6: Modelo de Comprensión de Programas A través de la observación de los resultados obtenidos fue posible extraer las siguientes conclusiones: Todos los autores afirman que para entender programas se deben relacionar los Dominios del Problema y Programa: esta declaración indica que una estrategia de CP debe contener una: Representación del problema Representación del programa Estrategia de vinculación Esta propuesta se puede expresar graficamente como muestra el Modelo de CP de la Figura 3.6. No hay un acuerdo acerca de la estrategia usada para llevar a cabo el proceso de asimilación: se puede hacer esta afirmación porque este proceso es dependiente del programador. Si existe conocimiento acerca del Dominio del Problema entonces se usará una estrategia Top-down. En otro caso, una técnica Bottom-up o Híbrida probablemente sea la mejor elección. Las componentes de conocimiento interno están subespecificadas: el proceso interno es complejo e implica muchas componentes cuya interpretación es subjetiva. Sin embargo, es posible extraer algunas sugerencias interesantes. Las mismas se mencionan a continuación:

60 CAPÍTULO 3. MODELOS COGNITIVOS 54 Es útil proporcionar una componente que almacene los conceptos frecuentemente usados. Esta característica permite recuperar rápidamente los conceptos utilizados por el sistema que han sido asimilados por el programador. Usualmente algunos conceptos no se entienden. Tener una unidad bamboleante es importante para recordarlos y en los próximos pasos resolver los conflictos. Existen pocas propuestas de puentes cognitivos: en este contexto, la aproximación de Brooks es una excelente idea para construir muchos puentes cognitivos porque promueve la elaboración de varias representaciones interconectadas del sistema; de esta forma, el programador puede seleccionar la más apropiada de acuerdo a su estructura mental. Esta peculiaridad simplifica la CP porque promueve la elaboración de relaciones significativas. Las principales fuentes de conocimiento externo no están especificadas: normalmente, las descripciones de MC hacen referencia a la documentación del sistema, pero no mencionan Qué entienden por documentación?. En este contexto, algunas fuentes de información interesante son: Descripciones informales escritas en libros; Descripciones usando métodos formales; Especificaciones semi-formales usando métodos rigurosos por ejemplo el Proceso Unificado con lenguaje UML; Documentos elaborados a través de entrevistas de usuario; Experiencia usando el sistema; Comentarios hechos en el código fuente; El código fuente en sí mismo, etc. Es necesario seleccionar los conceptos y procedimientos más importantes de MC: esto es relevante porque permite sistematizar los conceptos y procedimientos más usados. Esta tarea es escencial para la elaboración de estrategias de soporte cognitivo que sea factibles de usar en HCP Detallando los Conceptos de Comprensión de Programas La sección 3.2 presentó los elementos comunes de los Modelos Cognitivos. A medida que se investigaba sobre esta temática se observó que la conceptualización de esos elementos es ambigua. Esto se debe a su generalidad y a que muchas veces describen el mismo objeto. Por ejemplo, el siguiente código: min=max_int; for (i=0;i<100;i++) if (min>a[i]) then min=a[i];

61 CAPÍTULO 3. MODELOS COGNITIVOS 55 se puede interpretar como el chunk encontrar el mínimo en un arreglo o como un beacon con el mismo nombre. Para crear una estrategia automatizada o semi-automatizada que use esos conceptos se deben concebir sus definiciones desde una perspectiva diferente. En la sección 3.2 los chunks se definieron como abstracciones de las estructuras de texto. Es posible especializar esta definición teniendo presente los conceptos usados en programación. Todos los programas están compuestos por las siguientes estructuras de control: secuencia; selección; iteración y por procedimientos y funciones. Teniendo presente esas componentes la definición de chunk se puede expresar de la siguiente manera: Chunk 1 : es un concepto cuyo objetivo principal es describir grupos de estructuras de textos en diferentes niveles de abstracción. Los chunks se clasifican como sigue: chunk sec (Sentencias, N, Desc): esta formado por un conjunto de N sentencias genéricas y una descripción. En este contexto, por sentencia genérica se entiende una expresión, asignación, llamada a función y sentencia de entrada salida. La descripción Desc explica la funcionalidad de este grupo de sentencias. El parámetro N se instancia con un valor dependiente del nivel de complejidad deseado. Normalmente, este valor será determinado por el programador. El siguiente trozo de código: a=temp; a=b; b=temp;... c[k]=a[i]+b[j]; i=i+1; j=j+2; se representa usando dos chunk sec de la siguiente manera: el primer chunk se denota como: chunk sec ({a = temp; a = b; b = temp}, 3, < intercambio entre a y b >). el segundo se define como: 1 Para la definición del concepto de chunk se utilizó una gramática que se encuentra especificada en el Apéndice C

62 CAPÍTULO 3. MODELOS COGNITIVOS 56 chunk sec ({c[k] = a[i] + b[j]; i = i + 1; j = j + 2}, 3, < sumar los elementos a un arreglo >). chunk sel (Cond, P arte V ariante, Desc): describe las sentencias de selección y consta de tres partes bien definidas: Cond: es un Chunk sec (Sentencias, N, Desc) donde Sentencias describe la condición de la selección y Desc explica la semántica correspondiente. Parte-Variante: es una secuencia de secuencias de Chunks que describen las diferentes partes de la sentencia de selección. Desc: contiene la semántica asociada a la sentencia de selección. La siguiente sentencia de selección: if (f(x)==0) { a=temp; a=b; b=temp; } else {... c[k]=a[i]+b[j]; i=i+1; j=j+2; } se especifica usando chunks de la siguiente forma: chunk sel (chunk seq ({f(x) == 0}, 1, < descripción de la condición >), < chunk seq ({a = temp; a = b; b = temp}, 3, < intercambio entre a y b >), chunk seq ({c[k] = a[i] + b[j]; i = i + 1; j = j + 2}, 3, < incorporar un elem. en un array >) >, < este if es útil para... >) chunk iter (Acc1, Acc2, Acc3, Desc): se utiliza para describir las sentencias de iteración y consta de las siguientes partes:

63 CAPÍTULO 3. MODELOS COGNITIVOS 57 Acc1 : se define como una secuencia de Chunk que especifican las acciones de inicialización de los objetos de datos utilizados en la condición de la iteración. Acc2 : se define como un Chunk seq (Sentencias, N, Desc) que representa la condición. Acc3 : es una secuencia de Chunk que representa el cuerpo de la iteración. Desc: describe la semántica de la iteración. La siguiente sentencia for: for (i=0; i < N; i++) a[i]= a[i]+1; se traduce en un chunk iter como se muestra a continuación: chunk iter (< chunk seq ({i = 0}, 1 < inicialización >) >, chunk seq ({i < N}; 1; < control de la Iteración >), < chunk sec ({a[i] = a[i] + 1}, 1, < incrementa el valor de una componente >) >, < incrementa en uno las componentes de un arreglo >) chunk rutina (Nombre, Cuerpo, Desc): este tipo de chunk tiene como objetivo la descripción de procedimientos y funciones y está compuesto por: Nombre: se corresponde con el nombre del procedimiento o función. Cuerpo: se define como una secuencia de Chunk que representa las sentencias de la función o procedimiento. Desc: es una descripción semántica del funcionamiento de la función o procedimiento. La función presentada a continuación: void swap (int * a, int *b) { int temp; temp=*a; *a=*b; *b= temp; return; }

64 CAPÍTULO 3. MODELOS COGNITIVOS 58 se describe utilizando un chunk rutina como sigue: chunk rutina (swap, < chunk seq ({temp = a; a = b; b = temp; return; }, 4, < intercambio de valores >) >, < intercambia los valores de dos variables >) Esas clases de chunks se utlizan para transformar las estructuras de texto en estructuras de chunks. Estas últimas estructuras son importantes porque permiten crear especificaciones de programas de alto nivel. Los planes de programación son grupos de chunks. Con esta clase de objetos se pueden hacer algunas descripciones más cercanas al Dominio del Problema. En la sección 3.2 se definió este concepto como un objeto compuesto por dos tipos de ranuras: Tipos y Fillers. Los Tipos se usan para representar los objetos de datos. Los Fillers describen segmentos de código, valores de variables, etc. que se utilizan para manipular los tipos. Teniendo presente esas ideas se pueden distinguir diferentes clases de planes. Los Tipos de Datos Abstractos (TDA) consisten de datos y operaciones definidas sobre ellos. Este concepto está directamente relacionado con los planes de programación. En este caso, la ranura Tipo está compuesta por los datos del TDA y la ranura Filler consiste de las operaciones que manipulan los datos del TDA. Esta clase de plan se denomina P lan T DA. Entre los TDA se pueden encontrar algunas relaciones. Por ejemplo, El Tipo A es un Tipo B, o El Tipo A está compuesto del Tipo B, etc. Si se considera los TDA y sus relaciones entonces la ranura Tipo esta compuesta por todos los TDA y sus operaciones, y la ranura Filler consta de todas las operaciones que trabajan sobre las distintas relaciones definidas entre los TDA. Esta clase de plan se conoce como P lan T DAmap. No todas la funciones y datos son miembros de algún TDA. Esas funciones y datos son específicos del sistema bajo estudio. En este contexto, la ranura Tipo está compuesta por las variables del sistema y la ranura Filler consiste de las funciones específicas del sistema. Esta clase de plan se conoce como P lan sistema. A continuación se presentan las definiciones de cada concepto. plan T DA (nombre, (dato set, chunk rutina set), desc): este plan se usa para describir un TDA. Donde: nombre: describe el nombre del TDA. dato set: representa los datos usados en la definición del TDA. chunk rutina set: es un conjunto de chunk rutina que describe cada operación.

65 CAPÍTULO 3. MODELOS COGNITIVOS 59 struct stack { int a[tam]; int top; } void push (struct stack *s, int e) { /* operation for push */ } int pop(struct stack *s) { /*operations for pop*/ } void initstack(struct stack *s) { /* operation for initstack */ } int empty(struct stack *s) { /* operation for empty */~ } plan ADT ( stack ( { struct stack } ) { chunck(push, <push e into top of s > chunck(pop, <delete of element of the top of s> chunck(initstack,<set with an initial value the variables of stack>) chunck(empty,<detect if the stack is empty>) chunck(full,<dectect if the stack is full>) } ) <implement a static stack> int full(struct stack *s) { /* operation for full */ } Figura 3.7: Ejemplo de Plan TDA Desc: se usa para describir la funcionalidad del TDA. La Figura 3.7 muestra un ejemplo de este concepto. plan T DAmap (plan T DA set, R set, chunk rutina set, Desc): esta clase de plan se utiliza para representar el mapa de tipos de TDA del sistema. Donde: plan T DA set: representa el conjunto de TDAs usados por el sistema. R-set: es un conjunto de relaciones entre los elementos de plan T DA set especificadas como (nombre, conjunto de nuplas). chunk rutina set: agrupa las operaciones que manipulan los elementos de una relación. Se especifica como (nombre, operación).

66 CAPÍTULO 3. MODELOS COGNITIVOS 60 Desc: es una descripción de la funcionalidad de este plan. plan sistema (dato set, chunk rutina set, Desc): esta clase de plan se usa para describir todas las funciones y datos que no pertenecen a ningún plan T DAmap. Donde: dato set: agrupa el conjunto de datos no contemplados en ningún TDA. chunk rutina set: describe el conjunto de funciones no incluídas en ningún TDA. Desc: este campo es una descripción de las funcionalidades de este plan Representaciones del Dominio del Problema En esta sección, se mencionan algunos esquemas de especificación del comportamiento del sistema. Esta tarea se lleva a cabo porque, este tipo de especificaciones son necesarias para la definición de estrategias que permitan relacionar los Dominios del Problema y Programa. A través de las investigaciones realizadas en el contexto de los MC fue posible verificar que: Un programador entiende el Dominio del Problema cuando establece relaciones substanciales y no arbitrarias entre los conceptos. Los Mapas Conceptuales se pueden emplear para describir el Dominio Problema porque fomentan el aprendizaje por medio de la exteriorización de los conceptos usados en el sistema y sus relaciones. El proceso de construir un mapa conceptual del Dominio del Problema de un sistema es dependiente del programador, él puede estudiar la documentación o ejecutar el sistema utilizando todas las opciones relacionadas con la funcionalidad bajo análisis. El punto importante es que el resultado final (Mapa Conceptual) cubra la mayoría los conceptos utilizados en el sistema y las relaciones existentes entre ellos. Otro esquema para modelar el comportamiento del sistema consiste en la utilización de técnicas de modelación comportamental provistas por UML. Estas estrategias posibilitan el empleo de muchos diagramas que hacen factible la creación de varias vistas del sistema facilitando de este modo la comprensión. Por ejemplo, el Modelo de Dominio es la versión equivalente a los Mapas Conceptuales. La principal ventaja de esta aproximación radica en el uso de un lenguaje estándar entendido por toda la comunidad de Ingeniería de Software. Otras alternativas atractivas son los Diagramas de Casos de Uso, Interacción, Máquinas de Estado, etc. Todas esas estrategias están bien descriptas en libros del Proceso Unificado y UML [BRJ05, BJJ04]. Los Métodos Formales también se pueden usar para representar el Dominio del Problema [VDGJR02].

67 CAPÍTULO 3. MODELOS COGNITIVOS 61 Esto se debe a la posibilidad de expresar las propiedades y los conceptos del sistema usando lenguajes de especificación formal, por ejemplo se puede especificar un Modelo de Dominio empleando este tipo de lenguajes. Una ventaja de esta aproximación es la posibilidad de elaborar casos de prueba que verifiquen la correctitud de la especificación del sistema con el propósito de detectar errores e inconsistencias en el modelo mental del programador. Como contrapartida se encuentra la dificultad de definir procedimientos que vinculen la especificación con el comportamiento del sistema. Finalmente, es importante notar que la selección del mejor esquema depende de: i) La clase de sistema; ii) El procedimiento empleado para interconectar los Dominios del Problema y Programa y iii) La experiencia del programador Representación del Dominio del Programa basada en Conceptos de Modelos Cognitivos A partir de los estudios realizados en este capítulo es posible construir representaciones del Dominio del Programa basadas en los conceptos de planes y chunk los cuales fueron sistematizados en la sección Esta aproximación tiene dos características importantes: Provee una descripción de alto nivel del programa: si el programa se traduce en chunks/planes entonces el tamaño del programa se reduce y el campo < Desc > (descripción) de cada chunk/plan provee información semántica acerca de cada trozo de código. Cuando todas las descripciones están disponibles la estructura del programa proporciona información acerca de las funcionalidades del programa. Permite implementar estrategias de inspección Top-down y Bottom-up: los chunks/planes están compuestos por otros chunks/planes. Si cada chunk/plan tiene funciones de navegación asociadas entonces cada usuario puede ver el programa desde las estructuras de alto nivel hasta el código fuente y vice-versa Conclusión En el capítulo 1 se declaró que la comprensión de grandes sistemas se puede mejorar a través de la interconexión de los Dominios del Problema y Programa. Esta afirmación se derivó desde el estudio de los Modelos Cognitivos donde se detectó que la comunidad científica sostiene que:

68 CAPÍTULO 3. MODELOS COGNITIVOS 62 Un programador entiende un programa cuando puede relacionar los Dominios del Problema y Programa. El capítulo 2 conceptualizó la Comprensión de Programas como una disciplina de la Ingeniería de Software compuesta por un proceso de Aprendizaje y otro de Ingeniería. El primero ayuda a entender el camino seguido por el programador para entender programas y permite llevar a cabo dos importantes tareas: Identificar cuales son las características que debe poseer una Herramienta de Comprensión de Programas con soporte cognitivo. Proponer estrategias que simplifiquen la Comprensión de Programas. El segundo se interesa con todos los procedimientos computacionales que implementan las estrategias derivadas desde disciplinas tales como: Modelos Cognitivos; Visualización de Software y Extracción y Administración de la Información. Este capítulo presentó un estudio de los Modelos Cognitivos (MC) que permitió vislumbrar el trasfondo teórico de las declaraciones realizadas en los capítulos 1 y 2. Esta tarea se llevó a cabo describiendo las principales propuestas de MC y exponiendo, para cada una de ellas, algunos ejemplos y representaciones gráficas que explican como el programador entiende programas. Este estudio permitió extraer las siguientes conclusiones: El programador entiende un programa cuando puede relacionar los Dominios del Problema y Programa: después del estudio de los Modelos Cognitivos fue posible entender que muchos autores sostienen esta aseveración (ver tablas 3.1, 3.2 y 3.3). Esta observación fue útil porque permite identificar los pasos necesarios para construir HCP. Esta guía consiste en la definición de representaciones de los Dominios del Problema y Programa y en la elaboración un proceso de vinculación de ambas representaciones. Es posible encontrar muchas ambiguedades en los Conceptos Comunes a los MC: esto se debe a que los temas de MC intentan explicar factores humanos y los mismos son dificiles de expresar usando terminología de Ingeniería de Software. La Interconección de Dominios es una forma interesante de asistir a la comprensión: la idea declarada por Brooks fomenta el aprendizaje porque permite estudiar el sistema de acuerdo a la estructura mental del programador.

69 CAPÍTULO 3. MODELOS COGNITIVOS 63 La aproximación usada para entender programas es dependiente del usuario: claramente no hay un acuerdo acerca de este tema. Algunos autores afirman que este proceso es Top-down, otros declaran que es Bottom-up. Además, los autores presentan estudios empíricos para validar sus resultados. Este es un argumento que permite pensar que la propuesta más apropiada para entender programas es Híbrida tal como lo afirma el Constructivismo. Existen pocas propuestas de Puentes Cognitivos: la bibliografía de MC no describe apropiadamente este tema. Para finalizar este capítulo se presentan en forma sintética las contribuciones realizadas: Criterios para comparar MC. Sistematización de los Conceptos Comunes (una extensión directa y a su vez una propuesta práctica para implementar y entender los MC). Un esquema para construir estrategias para interconectar los Dominios del Problema y Programa. Algunas guías útiles para construir HCP. En los próximos capítulos se describirán: el Estado del Arte de las Herramientas de Comprensión de Programas; Técnicas de Visualización de Software y algunas Estrategias de Extracción de la Información. Además, se definirán varias aproximaciones para Interconectar los Dominios del Problema y Programa. Particularmente, el énfasis estará en aquellos esquemas que aplican los conceptos descriptos en las teorías de los Modelos Cognitivos.

70 Capítulo 4 Estado del Arte de las Herramientas de Comprensión 4.1. Introducción La verdadera medida de la grandeza de un hombre es cómo trata a quien no puede beneficiarlo en nada. Ann Landers Las Herramientas de Comprensión de Programas (HCP) son sistemas de software cuya finalidad es ayudar al programador a entender programas. Un Sistema de Software se considera una HCP si tiene implementado las siguientes características: Estrategias de Cognición; Técnicas de Visualización de Software; Métodos de Extracción y Administración de la Información y Técnicas de Interconexión de Dominios. Existen muchas HCP diseñadas para el análisis y exploración de diferentes clases de software. Por ejemplo, programas imperativos, programas orientados a objeto, aplicaciones web, etc. El estudio de esas HCP es importante porque permite comparar sus propuestas y encontrar sus debilidades. Esta última peculiaridad posibilita la introducción de nuevas técnicas que cubren los requerimientos no contemplados en las HCP actuales. Este capítulo describe un grupo de HCP a través de la presentación de sus interfaces y aproximaciones para entender el software. El principal objetivo es mostrar que las HCP tienen pocas estrategias para interconectar los Dominios del Problema y Programa. Por esta razón, la creación de técnicas que posibiliten alcanzar esta relación es una alternativa de valor para mejorar la Comprensión de 64

71 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 65 Programas (CP). Finalmente, en la conclusión se describen algunas observaciones generales considerando las cuatro grandes áreas de la CP: Modelos Cognitivos; Visualización de Software; Extracción y Organización de la Información y Estrategias de Interconexión Understand C/C++ Understand C/C++ [UT07] es una HCP cuya finalidad es inspeccionar programas escritos en lenguaje C/C++; su principal desventaja se menciona a continuación: Understand C/C++ posibilita el análisis de las características estáticas de un sistema, dejando de lado las propiedades dinámicas. Por esta razón, no posee estrategias para interconectar los Dominios del Problema y Programa. Las características centrales de esta herramienta son: Vistas: presenta vistas tales como árboles de archivos, árboles de funciones, árboles de clases, diagramas de declaración, etc. Cada una de estas estructuras de datos están relacionadas con los principales aspectos de los lenguajes imperativos y orientados a objetos. Navegación: asocia eventos a las componentes usadas por cada vista. Esos eventos permiten encontrar eficientemente la pieza de código bajo análisis. Analizar Diferentes Dialectos de C: explora programas escritos en diferentes dialectos de C. Por ejemplo, ANSI-C, K&R C y C++. Ver Información de Entidades: recupera todos los atributos de entidades tales como funciones, variables, tipos, etc. Por ejemplo, para cada función es posible visualizar sus parámetros, valor de retorno, puntos de invocación, etc. Búsqueda de Entidades: posibilita la búsqueda diferentes objetos usando expresiones regulares o concordancia de cadenas de caracteres. Crear Reportes HTML: exporta la documentación extraída desde el sistema a HTML facilitando la navegación dentro ella. Computar Métricas: define muchas métricas que son útiles para evaluar y entender el sistema de estudio. Por ejemplo: Complejidad Ciclomática; Nivel de Anidamiento Máximo de Estructuras de Control; Número de Archivos; Número de Funciones; Número de Sentencias Declarativas; Número de Sentencias Ejecutables; Número de Comentarios; Número de Líneas en Blanco; etc.

72 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 66 Incorporación de Plugins: permite incorporar comandos escritos en Perl, C o C++. De esta forma, es posible la extracción de información más completa y precisa que la proporcionada por los comandos estándares de Understand C/C++. Exportar Vistas Gráficas: proporciona otra forma de crear documentación del sistema. Las Figuras 4.1 y 4.2 muestran dos pantallas completas de Understand C/C++ que ejemplifican sus interfaces y vistas CodeSurfer CodeSufer [GS07] es una herramienta de análisis estático diseñada con el propósito de soportar estrategias de CP basadas sobre la representación del Grafo de Dependencia del Sistema y Programa [AZ05]. Al igual que Understand C/C++ esta herramienta posee el siguiente problema: Si bien CodeSurfer tiene implementadas estrategias sofisticadas para explorar el Dominio del Programa no posee técnicas de análisis dinámico; por consiguiente no interconecta los Dominios del Problema y Programa. Esta característica dificulta la de detección de las componentes del programa usadas en tiempo de ejecución para producir una salida específica del sistema de estudio. CodeSurfer tiene una aproximación interesante para llevar a cabo el análisis estático porque modela las dependencias usando dos representaciones primarias muy importantes: El Grafo de Dependencia del Programa (GDP) y El Grafo de Dependencia del Sistema (GDS) [AT01]. GDP representa cada módulo del sistema y resalta las diferentes relaciones entre sus componentes (variables, tipos, funciones, tipos, etc.). GDS proporciona una representación completa del sistema a partir de los GDPs. Para la construcción de GDS y GDP se necesita la generación de muchas representaciones intermedias, por ejemplo: ASA (Árbol de Sintáxis Abstracta); Tabla de Símbolos e Información de Tipos; Grafo de Control de Flujo; Grafos de Punteros a; Definiciones de Variables; Multigrafos de LLamadas; GDPs con referencia a variables no locales; etc. [AT01]. Todas esas estructuras se pueden visualizar a través de numerosos visores (presentadores de vistas) tales como: Project Viewer; File Viewer; Call Graph Viewer; Property Sheets; Finder; Set Calcualtor. CodeSurfer implementa mecanismos de consulta del Grafo de Dependencias; por ejemplo: Información de Usos de Variable; Predecesores/Sucesores; Slicing; Chopping; Red/Black Separation [AT01]. También, incluye las siguientes facilidades: Detección de Fallas usando Técnicas de Model Checking;

73 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 67 Figura 4.1: Ambiente provisto por Understand C/C++ - Árbol de Funciones

74 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 68 Figura 4.2: Ambiente provisto por Understand C/C++ - Diagrama de Flujo

75 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 69 Figura 4.3: Grafo de Funciones provisto por CodeSurfer Importación/Exportación de Formatos; Calculadora que Manipula Punteros; etc. [AZ05]. Las Figuras 4.3 y 4.4 muestran una pantalla con un árbol de llamadas y la interfaz para visualizar los atributos de las variables respectivamente Imagix 4D Imagix 4D [IT07] es una herramienta que facilita el proceso de Ingeniería Reversa Estática. Por esta razón, es importante notar que: Imagix 4D no tiene estrategias para interconectar el Dominio del Problema con el Dominio del Programa porque solamente explora el Dominio del Programa. Esta herramienta provee diferentes estrategias que ayudan en tareas tales como: Comprensión de Software; Documentación de Sistemas; Verificación; Reuso; etc. Todas esas tácticas se construyen a partir de la información extraída desde diferentes fuentes, por ejemplo: Código Fuente; Profiles; makefiles; etc.

76 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 70 Figura 4.4: Visualización Variables con CodeSurfer Imagix 4D también asiste al programador en el proceso de CP a través de: Fácil Navegación entre diferentes Entidades del Sistema; Detección de Componentes Reusables; Ayudas en la Tarea de Verficiación de Software; Generación Documentación; etc. Imagix 4D provee vistas tradicionales muy importantes, tales como: Diagramas de Flujo, Grafo de Funciones; Grafo de Dependencia de Módulos; Diagramas UML (tradicionales y decorados con otras clases de relaciones tales como dependencias de módulos). Adicionalmente, tiene implementado muchas métricas que permiten entener el software por medio de estrategias cuantitativas que se basan en la representación textual y gráfica de los datos. Finalmente, es importante notar que se pueden mostrar muchas vistas usando gráficos en 3D. Las Figuras 4.5, 4.6 y 4.7 muestran algunas vistas provistas por esta herramienta CScope CScope [CT07] es una herramienta cuyo objetivo es facilitar la navegación de programas escritos en lenguaje C. Es importante notar que:

77 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 71 Figura 4.5: Grafo de Símbolos provista por Imagix 4D

78 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 72 Figura 4.6: Visualización de Variables con Imagix 4D

79 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 73 Figura 4.7: Control de Flujo en Imagix 4D

80 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 74 Figura 4.8: Interfaz de CScope Las funcionalidades provistas por esta herramienta son más básicas que las proporcionadas por las aplicaciones presentadas en las secciones previas. Esto se debe a que: i) La interfaz de usuario no dispone de vistas gráficas y ii) Los objetos del programa que recupera son grafos de funciones y componentes atómicas. CScope implementa solamente técnicas de recuperación de información estática. En consecuencia, no tiene estrategias para interconectar los Dominios del Problema y Programa. Para sustentar la afirmación presentada previamente en los párrafos siguientes se presenta una descripción sintética de la herramienta. La interfaz ofrecida es básica y consiste solamente de pantallas de texto con operaciones búsqueda disponibles para el usuario. Por ejemplo, esta herramienta permite encontrar: Cualquier símbolo definido en programas C ; Las funciones llamadas por alguna función; Las funciones que llaman a alguna función específica; Cadenas de caracteres; Patrones usando expresiones regulares; Archivos; etc. El modo de operación de CScope es simple: el usuario selecciona los archivos que quiere examinar escribiendo sus nombres en el archivo CScope.files. Después de eso, invoca a CScope y todas sus funcionalidades se pueden aplicar sobre los archivos de estudio. Para finalizar esta sección, es importante remarcar que esta herramienta se puede combinar con editores de textos tales como: Vi; Vim; Emacs; etc. La Figura 4.8 muestra la interfaz de CScope.

81 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN SHriMP SHriMP (Simple Hierarchical Multi-Perspective) [WS00] [ST07] es un ambiente de visualización de grandes volumenes de información independiente del dominio. Su principal desventaja se presenta a continuación: De la misma forma que las herramientas de análisis estático presentadas en las secciones previas, esta aplicación no posee estrategias para interconectar los Dominios del Problema y Programa. SHriMP provee estrategias interesantes para visualizar la información del sistema, en los siguientes ítems se describen cada una de ellas. Vista Primaria: representa las jerarquías del sistema. Por ejemplo, los módulos se pueden dividir en archivos, los archivos en funciones, variables y bloques. Para alcanzar este objetivo se utilizan Grafos Anidados. Sobre esta estructura, es posible la aplicación de operaciones de zoom tales como: Geométrico; Semántico y Ojos de Pez. Esas características facilitan la exploración de software porque proporcionan mecanismos simples y útiles para visualizar las propiedades de cada objeto del programa. Vistas Subsidiarias: presenta prespectivas con las siguientes operaciones: Búsquedas: facilita la búsqueda de componentes y relaciones particulares [WS00]. Seguimiento de Relaciones: provee mecanismos que simplifican la exploración de relaciones. Es importante destacar que SHriMP combina todas esas vistas (primarias y subsidiarias) para posibilitar el análisis de software desde múltiples perspectivas. En este contexto, SHriMP provee un mapa del sistema que muestra todas sus componentes y las relaciones existentes entre ellas en un alto nivel de abstracción (vistas primarias). El programador utiliza este mapa para explorar la perspectiva que desea utilizando las vistas subsidiarias. Finalmente, SHriMP provee mecanismos de integración con otras herramientas, por ejemplo, con Eclipse utilizando el plugin Creole jgrasp jgrasp [jt07] es un ambiente de programación que posee funcionalidades de CP, depuración y de análisis de programas escritos en C, C++, Ada, Java y VHDL.

82 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 76 jgraph es otra clase de HCP porque posee mecanismos para interconectar los Dominios del Problema y Programa, a través de la combinación de información estática y dinámica, para ciertos casos de estudio. Por ejemplo, cuando el Dominio del Problema consiste en la implementación de tipos de datos abstractos, jgraph muestra la salida del programa, los datos y partes del programa empleados para producirla. Para aplicaciones más grandes, actúa como un depurador. Su principal desventaja es la imposibilidad de proveer vistas, tales como las presentadas para los tipos de datos abstractos básicos, para aplicaciones grandes. En términos generales, jgrasp genera automaticamente tres vistas importantes: Diagramas de Estrucutras de Control: muestra la estructura de cada componente del programa. Esta información se visualiza junto con el código fuente en una representación gráfica compacta. Diagramas de Clase de UML: tiene como propósito simplificar la comprensión de las componentes de Software Orientado a Objeto 1 y sus dependencias. Visores de Vistas Dinámicas: visualizan la dinámica de los datos utilizando funciones de depuración o visualización de información relacionada con algún objeto. Además de esas interesantes vistas, jgrasp tiene un Object Workbench y un Depurador. La primer componente permite que el usuario cree objetos e invoque sus métodos. La segunda implementa funcionalidades de depuración tradicionales. Esas componentes trabajan en conjunción con las tres vistas (Diagramas de Estructuras de Control, Diagramas de Clase UML, Visores de Vistas Dinámicas) proporcionadas por jgrasp. Finalmente, es importante destacar que las representaciones gráficas de estructuras de datos como las usadas para representar: Pilas; Colas; Listas Enlazadas; Árboles Binarios; Tablas de Dispersión; etc. disinguen a jgrasp de otras herramientas; porque para estos casos específicos se alcanza una relación entre el Dominio del Problema y el Dominio del Programa. La Figura 4.9 muestra la interfaz de visualización de las estructuras de datos. 1 Estos sistemas deben estar escritos en lenguaje Java

83 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 77 Figura 4.9: Visualización de Estructuras de Datos en jgrasp

84 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN Alma Alma [HVDC07] es un sistema que visualiza y anima programas escritos en cualquier lenguaje de programación. Alma es una herramienta con propósitos educacionales que relaciona los Dominios del Problema y Programa para casos de estudio específicos. La relación alcanzada puede ser fuerte o débil dependiendo del método usado para especificar el Dominio del Problema y de la especialización del front end. No obstante, la principal dificultad es que no escala bien para aplicaciones grandes. Desafortunadamente, la solución de este inconveniente es muy compleja y requiere de mucho tiempo y esfuerzo. Para llevar a cabo la tarea mencionada previamente (relacionar los Dominios del Problema y Programa), Alma necesita: una Representación del Dominio del Problema; un Front-end y un Back-end. El primero no es genérico y se debe especificar para cada caso. El segundo también se debe especializar para cada lenguaje de programación porque tiene como finalidad la construcción de un Árbol de Sintáxis Decorado (ASD) que representa el programa. El tercero es independiente del lenguaje de programación y el mismo para todos los Front-end. Alma funciona de la siguiente manera: el back-end recibe como entrada el ASD generado por el front-end y aplica un conjunto de reglas de visualización y de re-escritura que producen alguna visualización del comportamiento del programa. Alma se puede usar para: Enseñar: Programación a través de análisis de programas y algoritmos. Matemáticas pormedio de la visualización detallada del proceso de cómputo utilizado en el programa. Analizar: Documentos. Respuestas dadas por los programadores a algunos problemas. Uno de los objetivos de Alma es facilitar la interacción usuario-máquina, por esta razón su interfaz es clara y consistente, interactiva, tolerante al programador, fácil de adaptar al nivel de conocimiento del

85 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 79 Figura 4.10: Pantalla de Alma - Ejecución de un Programa programador y atractiva, etc. Las Figuras 4.10 y 4.11 muestran dos pantallas con Alma funcionando para algunos programas específicos SeeSoft- Una Herramienta para Visualizar Estadísitcas de Software por medio de Líneas de Código SeeSoft [BE96] asiste al programador en el proceso de CP a través de la representación del código fuente como líneas. Esta representación consiste en la traducción de cada línea del programa en otra (gráfica) muy pequeña y fina que normalmente se pondera con atributos que proporcionan información acerca del objeto de estudio. Es importante notar que: SeeSoft construye sus vistas usando información estática y dinámica con el objetivo de mostrar y ponderar solamente los aspectos del Dominio del Programa.

86 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 80 Figura 4.11: Pantalla de Alma - Construcción de ASD

87 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 81 La información expuesta por SeeSoft se extrae desde varias fuentes. Por ejemplo: Sistemas de control de versiones; Análisis estático y dinámico; etc. La representación usada por SeeSoft se basa sobre cuatro ideas básicas: Representación Reducida: tiene como objetivo presentar una vista general del código fuente. Manipulación directa: se utiliza para detectar patrones en el código fuente. Colores para representar métricas: cubre métricas tales como Edad, Programador, Tipo de línea, Número de ejecución de cada línea, etc. Disponibilidad para leer el código fuente: se necesita para entender la funcionalidad de sistema. SeeSoft se ha aplicado exitosamente en tareas tales como descubrir código no usado, administración de proyectos, optimización de la ejecución de código, etc. Finalmente, es importante resaltar que SeeSoft es una herramienta antigua pero su estrategia de visualización es interesante, porque muestra como, a través de una representación de código simple e ingeniosa, se puede visualizar mucha información Web Application Viewer Web Application Viewer (WAV) Aplicaciones Web (AW). [FHP06, OHP07] es una herramienta cuya meta es comprender WAV es una herramienta de Comprensión de Programas que permite alcanzar una relación directa entre el Dominio del Problema y el Dominio del Programa. Este objetivo se logra a través de la definición de estrategias de interconexión dominios que se basan en la utilización de información estática y dinámica del sistema. La información estática recuperada por WAV se relaciona con: Tipo de Archivo: detecta si el archivo analizado es de Texto plano, PHP, Java, HTML, etc. Contenido del Archivo: resalta la sintáxis de cada construcción del lenguaje. Dependencias: muestra las dependencias entre los archivos de las AW.

88 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 82 Estructura: divide cada sentencia en bloques (correspondientes a las construcciones del lenguaje). Además de las características presentadas previamente, WAV recupera información dinámica usando un esquema de Instrumentación de Código. Para llevar a cabo esta tarea, se insertan, en el código fuente, algunas funciones de inspección que muestran información de las componente del programa usadas por alguna funcionalidad específica. WAV combina esas clases de información a través de: BORS (Behavioral-Operational Relation Strategy), una estrategia que permite: Detectar las componentes del programa utilizadas para alguna funcionalidad específica. Recuperar los atributos estáticos de las componentes usadas en tiempo de ejecución a través del empleo de funciones de exploración de código. WAV muestra la relación entre diferentes dominios usando un esquema de visualización basado en íconos, diseñados con la finalidad de representar fielmente cada componente del programa, y las relaciones definidas entre ellos que indican como se ensamblan cada pieza de código. Además, esta aproximación provee interesantes funciones de navegación que facilitan la inspección del sistema. Por ejemplo, la estructura del programa se representa por íconos con varias figuras dentro de ellos. Esas imágenes están relacionadas con las componentes del programa; por ejemplo si el ícono representa una sentencia if los símbolos ubicados en su interior representan las sentencias utilizadas en la parte then y else. Para acceder a esos elementos, el programador sólo necesita seleccionar el objeto deseado (dentro del ícono) y WAV muestra el contenido (código fuente) asociado con ellos. Antes de finalizar esta sección, es importante notar que una característica relevante de WAV es la posibilidad de analizar diferentes lenguajes de programación. Esto es necesario porque generalmente las AW están escritas usando lenguajes tales como: HTML; PHP; Java; etc. Esta peculiaridad introduce complejidades cuando se analiza el código fuente porque se necesita contruir un analizador sintáctico que reconozca varios lenguajes de programación. Para resolver este inconveniente, los diseñadores de WAV representaron el código de la AW como un ASD (Árbol de Sintáxis Decorado) y luego aplicaron sucesivos recorridos sobre esa estructura. A nivel comentario, es posible decir que la estrategia BORS, implementada en esta herramienta, es una extensión de la técnica descripta en esta tesis de doctorado para el paradigma de programación imperativo (Lenguaje C). Las Figuras 4.12 y 4.13 muestran algunas vistas provistas por WAV. El lector interesado en obtener información más detallada de WAV puede estudiar [FHP06] para analizar la implementación y [OHP07] para conocer la especificación y el esquema de visualización.

89 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 83 Figura 4.12: Instantánea de WAV - Representación Icónica de un Programa

90 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 84 Figura 4.13: Instantánea de WAV - Representación basada en Grafos

91 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN ORCA: Operation Reaction Code Analyzer ORCA [SST08] es una herramienta que proporciona los mecanismos necesarios para entender la funcionalidad de las interfaces gráficas de usuario implementadas en lenguaje Java. ORCA es una herramienta interesente porque, al igual que WAV, logra relacionar los Dominios del Problema y Programa a través de: i) La combinación de información estática y dinámica y ii) La utilización de un ambiente que visualiza diapositivas cuyo contenido son imágenes de la salida del sistema junto con el correspondiente código fuente. La herramienta se implementa como un módulo que consta de: Todos los requerimientos necesarios para su incorporación en Eclipse. Estrategias para la recuperación de información estática y dinámica necesaria para interconectar los Dominios del Problema y Programa. La información visualizada por esta herramienta consiste de: Líneas de Código Fuente Ejecutadas: representadas como líneas resaltadas en la definición de la clase. Llamadas a Métodos: exhibidas como un grafo dirigido. Jerarquía de Clases: visualizadas como un árbol que representa la relación padre-hijo en la jerarquía de clases. En esta herramienta, la relación entre los Dominios del Problema y Programa se puede observar de dos maneras: En vida: mientras el usuario trabaja con la interfaz de usuario, la herramienta visualiza la correspondencia pantalla-código fuente. Post Mortem: las operaciones realizadas en tiempo de ejecución se almacenan en un archivo. La información contenida en este archivo se usa para analizar las tareas realizadas por el sistema después de su ejecución.

92 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN Herramienta de Localización de Características Esta herramienta tiene como meta simplificar la comprensión de sistemas escritos en lenguaje C/C++ [BVJ08]. La estrategia usada para realizar esta tarea se basa en el análisis de las trazas de ejecución y en la estructuración jerárquica de las unidades de implementación del sistema. Esta herramienta intenta alcanzar cierta relación entre los Dominios del Problema y Programa porque analiza información estática y dinámica con la finalidad de extraer algunas características del sistema. No obstante, el programador debe construir la relación real entre ambos dominios porque la aplicación sólo lo asiste a través de la presentación de vistas muy útiles para alcanzar este objetivo. Esta herramienta tiene varias vistas que permiten focalizar la atención sobre diferentes aspectos de las trazas de ejecución, algunas de ellas son: Vista centrada en tiempo: emplea Diagramas de Secuencia de UML para la exploración de las características temporales de las trazas de ejecución. En esta estrategia, el tiempo se muestra sobre la abcisa x y en la abcisa y, en cada fila, la función. La actividad de la función se codifica usando colores que permiten visualizar el sistema en dos niveles de granularidad grueso y fino. El primero se utiliza para detectar las fases de la característica bajo estudio. El segundo permite el análisis de la secuencia de llamadas a funciones. Vista Basada en las Colaboraciones: tiene como objetivo entender los aspectos estructurales de la interacción de funciones. En otras palabras, muestra como la función de estudio colabora con otras funciones y su correspondiente pila de llamadas. Vista Focalizada en el Código: es útil para inspeccionar el código fuente porque permite el acceso rápido al código de la función que se desea estudiar. Esta información se decora con otros datos interesantes tales como: Costo de ejecución; Funciones invocadas dinamicamente; etc. Es importante remarcar que todas las vistas están sincronizadas para propósitos de inspección. Para construir esas vistas, la herramienta extrae información desde el código fuente usando un Extractor de Hechos que recupera información relacionada con las funciones usadas en tiempo de ejecución. Esta tarea se lleva a cabo usando un método no intrusivo evitando, de esta manera, modificar el código fuente. Desafortunadamente, los autores no describen la técnica usada para la recuperación de la información dinámica.

93 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN Extravis Extravis [CHZ + 07, CZH + 08] visualiza las trazas de ejecución de programas Java con el propósito de facilitar la CP durante varias tareas de Mantenimiento de Software. Extravis es una herramienta de exploración que solamente visualiza la información dinámica del sistema a través de la utilización de vistas innovadoras. Por esta razón, no alcanza una relación entre los Dominios del Problema y Programa. Para cada traza de ejecución, esta herramienta presenta dos vistas sincronizadas: Vista Circular: muestra la descomposición estructural del sistema. Vista de Secuencia Masiva: provee una descripción navegable y cronologicamente ordenada de las invocaciones realizadas entre las diferentes componentes del sistema. Las vistas tienen métodos de interacción que permiten propagar los cambios de una vista a la otra. El metamodelo usado por Extravis se fundamenta en la descomposición estructural del sistema y en la relacción de invocación. El mismo contiene: Información Estructural: visualiza la estructura de un sistema en términos de paquetes o capas arquitecurales. Relaciones de LLamadas Básicas: provee una serie de relaciones de llamadas extraídas desde las trazas de ejecución. Además, dispone de enlaces entre la vista actual y el código fuente que facilitan la exploración. Relaciones de LLamado Detalladas: relaciona los identificadores de los objetos, los valores de los parámetros y retorno de las funciones. La Figura 4.15 muestra una instantánea de las vistas descriptas en los párrafos precedentes. Extravis fue aplicado a: Cromod (un sistema industrial escrito en Java que regula las condiciones ambientales de invernaderos); JHotDraw (un marco de trabajo para editar gráficos); JPacman (un ejemplo académico del juego Packman desarrollado en la Universidad Tecnológica de Delft). El lector interesado en obtener más información de esta aplicación puede examinar [CHZ + 07].

94 CAPI TULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIO N 88 Figura 4.14: Vistas proporcionadas por Extravis Herramientas de Visualizacio n del Comportamiento de Tiempo de Ejecucio n de Aplicaciones OS Pequen as Este conjunto de herramientas tiene como finalidad el estudio de sistemas escritos en nesc [DH08], un dialecto del lenguage C basado en componentes. Con nesc, las aplicaciones se construyen a trave s de la composicio n de componentes especı ficos de la aplicacio n con componentes de propo sito general provistas por el sistema operativo (en [DH08] es posible obtener ma s informacio n acerca de nesc). Este conjunto de herramientas proporciona un ambiente de visualizacio n que asiste al programador en la dificil tarea de encontrar una relacio n entre los Dominios del Problema y Programa. Esta tarea se realiza a trave s de la inspeccio n de la informacio n dina mica recuperada desde el sistema. Estas aplicaciones constan de las siguientes componentes: Una Librerı a de Ana lisis e Instrumentacio n de nesc: se implementa usando una librerı a escrita en lenguaje Java que permite analizar e instrumentar programas escritos en nesc. Esta librerı a construye un ASA (A rbol de Sinta xis Abstracta) de cada mo dulo nesc que posibilita la

95 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 89 manipulación de cada componente del programa por medio de recorridos. Es importante notar que una de las funciones principales realizadas por los recorridos consiste en la instrumentación del código fuente. Selector de Prueba: realiza las siguientes tareas: Analiza, usando la librería A&I (Análisis e Instrumentación) 2, una configuración de alto nivel. El resultado de esta fase es una lista de componentes y sus comandos asociados. Elimina las componentes genéricas 3 y produce código fuente instanciado el cual se instrumenta con el propósito de capturar las trazas de ejecución. Servicio de Registración de Eventos: define los comandos requeridos para el almacenamiento de la entrada y salida de eventos. La componente usa dos buffers para trabajar con las trazas, cuando los eventos se registran se almacenan en el primer buffer y cuando este buffer está lleno el Servicio de Registración usa el segundo buffer mientras vacía el primero. Extractor/Recolector de Trazas: tiene como objetivo el análisis de las trazas de ejecución para la construcción del correspondiente Diagrama de Secuencia. El análisis implica la asociación de módulos con sus recpectivos nombres y acciones con sus signaturas. Generador del Grafo de LLamadas: se usa para visualizar el grafo de llamadas estático. Para llevar a cabo esta tarea, la componente recibe como entrada una configuración de alto nivel de la aplicación y produce como salida una lista de acciones. El programador selecciona las acciones que quiere visualizar y el grafo se muestra enfatizando esas acciones. La información exhibida incluye las acciones seleccionadas, acciones que invocan las acciones seleccionadas y acciones invocadas por las acciones seleccionadas. Generador de Diagrama de Secuencia: correspondiente Diagrama de Secuencia. se usa para construir, desde una traza de ejecución, el 2 La instrumentación se lleva a cabo insertando eventos en el comienzo y fin de cada comando nesc. Esta estrategia produce como salida: componentes y sus acciones asociadas 3 El programador selecciona las componentes genéricas.

96 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN Una Herramienta para Extraer Términos de Dominio desde el Código Fuente Esta sección describe una aproximación que analiza la información informal provista por los comentarios e identificadores del programa [HM08]. Esta herramienta solamente extrae información informal desde el código fuente, por esta razón no produce ninguna relación entre los Dominios del Problema y Programa. Es importante notar que la estrategia utilizada por la aplicación es diferente a las presentadas en las secciones previas porque enfatiza el análisis de la información informal. La herramienta es simple, consiste de un analizador sintáctico con las acciones semánticas necesarias para la extracción de información informal desde el código fuente de programas Java y C++. Luego, esta información se procesa con la finalidad de filtrar términos que son irrelevantes para el dominio de estudio. La entrada del proceso de recuperación de la información es un conjunto de Términos de Dominio. Un Término de Dominio se refiere a los conceptos existentes en el Dominio del Problema cuyas funcionalidades se pueden describir usando Conceptos de Dominio. Construir un conjunto de Términos de Dominios no es una tarea fácil. Porque, los programadores pueden referenciar al mismo término usando nombres diferentes en distintos sistemas. Por esta razón, los autores definen el concepto de Acuerdo Lexicográfico (AL) (ver [HM08]) que se usa para verificar el grado de concordancia en el significado de los Términos de Dominio encontrados en el código fuente (el lector interesado puede estudiar [HM08] para obtener un análisis más detallado de esta herramienta). Esta tarea es útil porque ayuda a construir un conjunto de Términos de Dominio Estándar para algunos dominios específicos. El problema con esta técnica es que la selección de Términos de Dominio es un proceso manual y debe ser realizado por un programador experto en el dominio de estudio Visor de Sequencia Zest Zest [BMSG07] es un plug-in escrito en lenguaje Java que visualiza trazas de ejecución usando Diagramas de Secuencia. Zest está escrito en lenguaje Java y puede extraer Diagramas de Secuencia desde programas implementados en Java, C/C++, Perl o trazas de ejecución de programas instrumentados.

97 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 91 Zest es una herramienta de visualización de información dinámica. Por este motivo, no puede relacionar los Dominios del Problema y Programa. No obstante, asiste al programador en el proceso de encontrar este tipo de relación por medio de la presentación de Diagramas de Secuencia. Esta herramienta se diseño considerando los criterios de presentación e interacción descriptos a continuación: Presentación: describe la estrategia empleada en la visualización de los diagramas y las facilidades provistas para la presentación de varias vistas. Este criterio se explica usando los siguientes subcriterios: Trazado: se refiere a la estrategia empleada para dibujar el diagrama. Multiples Vistas Enlazadas: se utiliza para navegar y observar, desde diferentes puntos de vista, las características del sistema. Iluminación: simplifica las búsquedas y facilita la focalización en partes específicas de un Diagrama de Secuencia. Ocultar: se usa para controlar la complejidad del Diagrama de Secuencia. Atributos Visuales: codifican información adicional. Rótulos: se emplea para escribir comentarios o colocar información relevante sobre el Diagrama de Secuencia. Animación: permite visualizar el orden de ejecución de los eventos. Interacción: hace referencia a las características que facilitan la interacción usuario-herramienta. Esta propiedad se define por medio de las siguientes subcaracterísticas: Selección: implementa mecanismos para la manipulación de los objetos. Navegación: simplifica el acceso a las distintas componentes del sistema. Foco: ayuda a los programadores a concentrarse sobre la parte de la traza que consideran importante. Zooming and Scrolling: permite visualizar toda la información almacenada en una sola ventana. Consultas y Slicing: identifica y filtra información.

98 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 92 Figura 4.15: Una vista proporcionada por Zest Agrupación: une componentes o partes del sistema. Anotación: posibilita el ingreso de comentarios relacionados con el trabajo realizado. Almacenamiento de Vistas: registra el trabajo realizado sobre las vistas con la finalidad de facilitar su recuperación en sesiones futuras. Las características mencionadas previamente cubren los siguientes criterios de soporte cognitivo: Presentación en forma intuitiva, Multiples perspectivas, Facilidades de navegación, Filtro y niveles de abstracción.

99 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN Conclusión En el capítulo 1 se declaró que la comprensión del funcionamiento de un sistema grande es una tarea compleja que demanda esfuerzo, dedicación y consume muchos recursos económicos. También, se mencionó que las estrategias de comprensión provistas por las herramientas de ingeniería no son lo suficientemente adecuadas para mejorar el proceso comprensión. Por esta razón, se concluyó que la elaboración de nuevas estrategias de entendimiento es una tarea muy importante porque: i) Disminuye el consumo de recursos y ii) Aumenta las probabilidades de llevar adelante existosamente los proyectos de software. En el capítulo 2 se presentó una conceptualización de Comprensión de Programas que define a este campo de investigación como una disciplina de la Ingeniería de Software que provee métodos, estrategias y herramientas que ayudan al programador a entender programas. En el capítulo 3 fue posible concluir que la mejor forma de asistir al programador en el proceso de comprensión consiste en interconectar diferentes dominios. Particularmente, se destacó la interconexión entre dos dominios muy importantes ellos son: Los Dominios del Problema y Programa. Este capítulo muestra que la característica mencionada en el párrafo precedente está casi ausente en las Herramientas de Comprensión de Programas. Esto se debe a que las mismas tienen como objetivo principal la inspección el Dominio del Programa y generalmente no consideran el Dominio del Problema. Por esa razón, las herramientas estudiadas tienen funciones de exploración muy útiles para acceder a cada componente del programa y pocas para trabajar con el Dominio del Problema. Además de la conclusión principal mencionada previamente, otras importantes consideraciones se pueden realizar teniendo presente las principales áreas de CP descriptas en la introducción de este capítulo, a continuación se mencionan cada una de ellas: Todas las HCP intentan facilitar el aprendizaje. Sin embargo, en sus descripciones se encuentran escasas referencias a los a los conceptos de Modelos Cognitivos. Son casos excepcionales, SHriMP, porque sus estrategias de inspección usan en un marco de trabajo basado en el análisis de los factores cognitivos empleados por el programador para entender programas, y las herramientas que intentan relacionar los Dominios del Problema y Programa tales como: jgrasp; Alma; WAV; ORCA, etc. Las visualizaciones provistas por cada herramienta se analizaron sin inconvenientes. Esto se debió a la posibilidad de obtener una versión ejecutable de ellas o bien a la lectura de artículos que las describen. Con las versiones ejecutables, se implementaron casos de prueba simples que permitieron observar la salida de esas aplicaciones y extraer algunas conclusiones.

100 CAPÍTULO 4. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE COMPRENSIÓN 94 Normalmente, los procedimientos de visualización están basados en: Grafos (Grafo de Llamadas a Funciones, Grafo de Dependencias de Módulos, Árbol de Funciones, Treemaps, Diagramas de Flujo, etc.); Representaciones Textuales (Métricas, Inspección de Variables, Énfasis en algunos lugares del código fuente, etc.) y otra clase de estrategias tales como las visualizaciones presentadas por Seesoft. Los métodos de extracción y administarción de la información son dificiles de identificar porque las descripciones de las herramientas están centradas en las funcionalidades desde el punto de vista del usuario. No obstante, fue posible observar que se utilizan técnicas de compilación avanzadas (como por ejemplo slicing) para la recuperación de información estática. En el caso de la extracción de la información dinámica se emplean técnicas tales como: Depuración Tradicional; Simulación o más recientemente Instrumentación de Código.

101 Parte III CONSTRUCCIÓN DE HERRAMIENTAS DE COMPRENSIÓN DE PROGRAMAS BASADOS EN ESTRATEGIAS PARA INTERCONECTAR DOMINIOS 95

102 Capítulo 5 Visualización de Software 5.1. Introducción Si quieres ver un árbol, ve al valle, si quieres ver el valle, ve a una montaña, si quieres ver la montaña, sube a las nubes, pero si quieres ver todo, cierra los ojos y sólo piensa. Anónimo Los capítulos precedentes muestran que la vinculación de los Dominios del Problema y Programa es una muy buena estrategia para facilitar la comprensión de sistemas grandes. Además, mencionan que la elaboración de estrategias de comprensión requiere del conocimiento de temas relacionados con las Ciencias Cognitivas y diferentes áreas de la Ingeniería de Software. Por las consideraciones descriptas previamente se estudiaron los Modelos Cognitivos. Esta tarea permitió la identificación de: las estrategias usadas por el programador para entender programas; las componentes utilizadas en el proceso de aprendizaje y los elementos necesarios para relacionar diferentes dominios (principalmente los Dominios del Problema y Programa). Ahora, el estudio se centra en el análisis de las características que deben tener los Sistemas de Visualización Software para asistir al programador en el proceso de Comprensión de Programas (CP). Esta tarea (el segundo paso para alcanzar la solución) se llevó a cabo explorando el campo de la Visualización de Software (VS). Las temáticas de Ingeniría de Software restantes (Estrategias de Interconexión de Dominios, Extracción de la Información, etc.) serán abordadas en los próximos capítulos. La Visualización de Software es un área importante de la Ingeniería de Software cuyo objetivo 96

103 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 97 principal es representar visualmente el software. Esta área adquiere relevancia en CP porque establece las guías necesarias para construir interfaces de usuarios que simplifiquen la comprensión. Con las técnicas de VS se pueden construir diferentes vistas del sistema. Una vista es una forma de visualizar las componentes del sistema y sus relaciones que permite mostrar alguno de sus aspectos. Comunmente, las Herramientas de Comprensión de Programas (HCP) tienen implementadas muchas vistas, sin embargo es un desafío seleccionar la más adecuada para una situación específica. La elaboración de visualizaciones de software directamente orientadas a CP es una tarea muy compleja porque las componentes y sus relaciones se deben presentar en forma clara, ordenada, consistente, etc. Además, esta clase de visualizaciones debe contemplar el uso de estrategias que exhiban la relación entre los Dominios del Problema y Programa. Es importante tener presente que este tipo de estrategias debe proporcionar tres vistas principales: la salida del sistema; las componentes del programa empleadas para producir la salida y la relación existente entre ambas. El estudio de las herramientas presentadas en el capítulo 4 indica que solamente unos pocos sistemas pueden alcanzar esta importante relación. En esos sistemas, las estrategias de visualización de la interconexión entre los Dominios del Problema y Programa no están especificadas en su totalidad. Este problema disminuye la utilidad de las HCP porque es el usuario quién debe identificar las componentes del sistema empleadas en una tarea específica. Por consiguiente, la inspección y asignación de semántica a las componentes del programa continuan siendo tareas que consumen mucho tiempo, esfuerzo humano y costos. Este capítulo está organizado como sigue. La sección 5.2 conceptualiza Visualización de la Información con el objetivo de introducir al lector en la temática. La sección 5.3 discute varias conceptualizaciones de Visualización de Softwate (VS) y presenta una nueva definición; además, describe un modelo para construir VS y explica algunos conceptos importantes de visualización. La sección 5.4 caracteriza los sistemas de VS. La sección 5.6 expone los requerimientos necesarios para visualizar la interconexión entre los Dominios del Problema y Programa. La sección 5.5 realiza un estudio de las taxonomías actuales de VS y propone nuevos criterios que describen con más detalle las HPCs. Finalmente, la sección 5.7 presenta la conclusión de este capítulo Visualización de la Información La Visualización de la Información (VI) [Che06] es un área de la Ingeniería de Software (IS) cuyo objetivo es el estudio de métodos y formas de representar la información que resalta los principales aspectos del los datos. VI se puede aplicar en muchos campos de las Ciencias de la Computación por ejemplo: Recuperación de la Información; World Web Wide; Librerías Digitales; Interacción

104 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 98 Hombre-Máquina; CP; etc. Para construir representaciones de la información, se necesitan considerar factores cognitivos y estrategias de representación. El primero está relacionado con las Teorías del Aprendizaje, la consideración de esas teorías para la elaboración de visualizaciones es importante porque ayuda a entender el modelo mental, construido por el programador, de la aplicación. El segundo está asociado con la Modelación Estructural (ME) y la Representación Gráfica (RG). Por una parte, ME [LELP06] resuelve el problema de extraer y simplificar las relaciones entre los datos recolectados. Las estrategias comunes están vinculadas con temas tales como: Grafos; Minería de datos; Complejos algoritmos de similaridad entre estructuras de datos; etc. Por la otra, RG se centra en encontrar la mejor representación gráfica [PFVI01, LELP06] para las estructuras de datos utilizadas en el análisis estructural. Las RGs más usuales usan diferentes técnicas basadas en atrefactos visuales bien conocidos que representan la información contenida en ME; algunos artefactos que se ubican en esta categoría son: Textuales; Trazado de Grafos; Modelación 2D y 3D; Mundos Virtuales; etc Visualización de Software Esta sección presenta varias definiciones y conceptos de Visualización de Software (VS) que son importantes para la elaboración de: Modelos; Taxonomías; Clases de visualizaciones; etc Conceptualización Algunos autores definen Visualización de Software como: Visualización de Software: Es el uso de artefactos de tipografía, diseño gráfico, animación y cinematrograífa con interacción de computadoras modernas y tecnologías de gráficos de computadoras para facilitar el entendimiento humano y el uso efectivo de software de computadoras. John Stasko Software Visualization: Programming as Multimedia Experience Esta completa definición presenta el problema de afirmar que la Visualización de Software representa, usando elementos multimediales, el software. Sin embargo, este objeto de estudio tiene muchos aspectos para representar y es imposible considerar todas sus características cuando se construye una

105 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 99 VS. Por ejemplo, se puede mostrar un programa específico usando el Grafo de Funciones, Grafo de Comunicación de Módulos, Grafo de Dependencia de Módulos, Grafo de Tipos, Grafo Conceptual, etc. También, es posible caracterizar cada componente de esas visualizaciones usando innumerables atributos. Por ejemplo, se pueden anotar los nodos del Grafo de Funciones con el nombre de la función, el tiempo de ejecución, el número de líneas de código, el número de veces que la función fue invocada, etc. El mismo problema aparece para los arcos, en ellos es factible visualizar la interconexión de datos, la interconexión real (invocación directa) o virtual (cuando las funciones se llaman a través de punteros ) de funciones, etc. Además de las características mencionadas previamente, se encuentran otras relacionadas con los aspectos de problema de estudio. Por ejemplo, visualización de subsistemas, Dominio del Problema, etc. todas esas clases de tareas tienen el inconveniente expuesto con anterioridad. El lector puede observar que con el objeto Grafo de Funciones se logran visualizar muchos aspectos. Por esa razón, la construcción de una visualización completa de software es muy compleja. El espectro presentado en los párrafos precedentes permite inferir que: Una Visualización de Software se debe usar para observar las propiedades del sistema de estudio relevantes para un problema particular. Gomez Henriques y su grupo de investigación sostienen que la VS es un arte, tal como se describe a continuación: Visualización de Software: Es el arte de dar a los programas un aspecto distinto al de su código fuente. Gomez Henriques Software Visualization: An Overview Esta simple definición presenta un punto controversial porque considera a la VS como un arte y esta clase de caracterizaciones no es bien aceptada en el campo de la ciencia. Además de eso, describe a la VS como un medio para representar el software y no algunos aspectos del software. Finalmente, ambas definiciones presentan los siguientes problemas: No consideran explicitamente la interacción con otras áreas del conocimiento. Por ejemplo, es claro que para diseñar artefactos visuales se necesitan expertos en Diseño Gráfico; y para constuir VS fáciles de entender y útiles para aprender se deben consultar a profesionales de Psicología Cognitiva.

106 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 100 La literatura declara que las visualizaciones tienen como objetivo ayudar a entender los sistemas de software. Esta afirmación es realista porque ellas actúan como puentes cognitivos dando otras alternativas, distintas al código fuente, para relacionar los conceptos del nuevo sistema con el trasfondo de conocimientos del programador. Sin embargo, las conceptualizaciones de VS no tienen presente que, además de la visualización de las componentes de software (Dominio del Programa), se deben mostrar algunas caracterizaciones de la salida del sistema (Dominio del Problema). Y todavía más importante, se necesitan vincular ambas visualizaciones para observar la relación entre ambos dominios. Esta relación es relevante porque permite que el programador encuentre significado y sentido a cada una de las funcionalidades del software (ver capítulo 3). En este contexto, los estudios realizados muestran que esta escencial relación algunas veces es alcanzada por los Sistemas de Animación [Var03] mientras que las otros tipos de aplicaciones solamente muestran vistas del Dominio del Programa. Esto sucede porque generalmente la primer clase de sistema se construye con propósitos educacionales. En otras palabras, enseñan como trabaja un algoritmo específico, mientras que la segunda clase se refiere a las aplicaciones cuyo objetivo es el estudio de grandes sistemas comerciales y científicos. La discusión precedente no declara que las Animaciones de Sistemas son más simples de construir que las aplicaciones orientadas a inspeccionar y entender grandes sistemas. Por el contrario, la misma remarca la ausencia de sistemas de visualización con funcionalidades de CP para entender cualquier clase de programas. Teniendo presente las debilidades descriptas en los párrafos precedentes, se elaboró la siguiente definición de VS:

107 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 101 Figura 5.1: Visualización de Software - Modelo Inicial Visualización de Software: Disciplina de la Ingeniería de Software destinada a mapear algunos aspectos del software en una o más representaciones multimediales. Para alcanzar este objetivo se necesita la interacción con otras áreas del conocimiento tales como: Diseño Gráfico: para crear diseños que representen fidedignamente las componentes de software que se desean visualizar. Psicología Cognitiva: para elaborar estrategias de visualización que faciliten el aprendizaje. Otras disciplinas directamente relacionadas con la elaboración de efectos multimediales. Si la VS está orientada a CP entonces el principal desafío consiste en proporcionar vistas que exhiban la relación entre los Dominios del Problema y Programa Modelo para Construir Visualizaciones de Software La subsección 5.3 declara que la Visualización de Software es un subcampo de VI cuya principal tarea que consiste en mapear ciertos aspectos del software en uno o más representaciones gráficas (see Figure 5.1). Los aspectos del software se extraen usando técnicas de extracción de la información (ver capítulo 7) y generalmente se expresan a través de atributos y relaciones (observe la Figura 5.2). Para construir una representación gráfica que muestre tales atributos y relaciones es importante usar un modelo de VS (MVS). De la misma forma que el modelo de VI, MVS está compuesto por dos componentes: Modelo Estructural y Representación Gráfica. El primero se centra en el estudio de las estructuras de datos empleadas en la construcción de una eficiente (esta característica se refiere a las complejidades temporal y espacial) representación de los aspectos del software. La segunda se relaciona con los

108 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 102 Figura 5.2: Visualización de Software - Modelo Parcial artefactos visuales usados en la visualización de la información. La Figura 5.3 exhibe el espectro general. En otras palabras, el mapeo real entre los aspectos del software y la representación gráfica (atributos y relaciones vs. estructuras de datos y atrefactos visuales) se traduce en un mapeo virtual siguiendo el camino indicado en la Figura 5.3. Esta transposición de dominios (real-virtual) no es la última tarea porque el programador debe manipular las entidades virtuales. Por esta razón, además de las operaciones de las estructuras de datos correspondientes a ME, se necesita la definición de los procedimientos vinculados con la visualización en sí misma y sus componentes. La situación descripta en el párrafo precedente será ilustrada usando un simple ejemplo con el propósito de facilitar la lectura y la comprensión. Suponga que el aspecto que se desea visualizar es la interconexión de funciones de un sistema. Esta relación se visualiza claramente a través del uso de grafos. Al haber realizado la asociación de la interconexión de funciones con el artefacto visual grafo se llevó a cabo el mapeo inicial indicado en la Figura 5.1. El próximo paso consiste en la extracción de las entidades, sus atributos y relaciones. En este caso, las entidades son las funciones del sistema y la relación es llamador-llamado. Para las entidades y sus relaciones es factible la consideración de muchos atributos. Por ejemplo, para las funciones sería interesante conocer: Número de Líneas de Código; Tiempo de Ejecución; Número de datos de entrada; etc. Para la relación, algunas características importantes de identificar son: La Clase de Invocación (directa o a través de punteros); El Número de Invocaciones Estáticas; etc. En este punto, los elementos del modelo cubiertos están descriptos en la Figura 5.2. En los pasos siguientes se especifica MVS.

109 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 103 Figura 5.3: Visualización de Software - Modelo Total Modelo Estructural: los grafos son la estructura más natural para modelar esta clase de situaciones; por esta razón, el uso de este modelo matemático es una buena elección. La próxima decisión consiste en la selección de la representación computacional más adecuada. En este caso, se deben tener presente algunas características tales como: Cardinalidad del conjunto de funciones y arcos; Capacidad de memoria; etc. Después de eso, se decide cuales representaciones de grafos serían factibles de usar. Por ejemplo, si el conjunto de funciones tiene pocos elementos una matriz de adyacencia es suficiente. En otro caso, es necesario el análisis de otra propuesta que reduzca la complejidad espacial. Representación Gráfica: este tema se relaciona con las representaciones de grafos, nodos y arcos. En primer lugar, es importante considerar las propiedades del grafo. Generalmente, la relación llamador-llamado es jerárquica. Por lo tanto, es buena idea que el dibujo del grafo exteriorize esta propiedad. Existen otras propiedades de grafos tales como nodos aislados, componentes conexas, etc. que por simplicidad no se consideran en este ejemplo. Los nodos se usan para representar las funciones. En este momento, es importante decidir la representación gráfica para esas entidades. Un factor que determina esta decisión es el número de atributos que el diseñador de la visualización desea exhibir porque la representación gráfica debe poseer tantas propiedades como atributos de software a representar. Para este ejemplo, un simple círculo es suficiente. La próxima tarea consiste en mapear los atributos del círculo con los atributos de la entidad. A continuación se presenta un posible mapeo: El color representa el tiempo de ejecución.

110 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 104 El ancho del borde muestra el número de líneas de código. Un texto fuera del círculo muestra el número de datos de entrada. Un texto dentro del círculo visualiza el nombre de la función. La misma aproximación se debe usar para los arcos. En este caso, la representación de esta entidad consiste de una línea. Los siguientes ítems describen el mapeo: El ancho de línea muestra el número de invocaciones estáticas. La clase de línea (sólida, punteada, etc.) indica el tipo de invocación sólida (una función llama explicitamente a otra) y punteada (la función invoca a otra a través de punteros). Finalmente, es importante definir algunas operaciones de visualización. Por ejemplo: Zoom in; Zoom out; Cortar y Pegar; Acceder a las componentes del programa; Clases de búsqueda; Operadores de grafos tales como: Vecinos Derechos; Vecinos Izquierdos; Minimales; Maximales; etc Otras Consideraciones acerca de la Visualización de Software Un factor que influye en la elaboración de VS el tamaño del sistema de estudio porque esta característica fuerza al desarrollador a instanciar el modelo de VS con las componentes adecuadas de acuerdo al objeto de estudio. Por ejemplo, es más simple diseñar una visualización para un programa que implementa una calculadora básica de cuatro funciones que otras que permiten visualizar un sistema de dibujo complejo. La razón de esta afirmación se clarifica tomando como objeto de análisis el Grafo de Funciones. El número de funciones del primer sistema (calculadora) será más pequeño que el correspondiente al segundo sistema. Por lo tanto, su modelo de VS utilizará una represetnación de grafo simple y el algoritmo de trazado del grafo no debería ser muy robusto. Además, las operaciones tales como: Filtro; Zoom; Buscar; etc. no serán necesarias porque todo el grafo de funciones se puede visualizar sin problemas. Las consideraciones opuestas aparecen en el segundo sistema. Teniendo presente esta observación es posible distinguir tres clases de VS: Algoritmos; Programas o Sistemas. En la Visualización de Algoritmos, el foco está en la enseñanza de algoritmos y estructuras de datos. Esta clase de VS está orientada al estudiante y es óptima en un contexto de enseñanza-aprendizaje. La Visualización de Programas se centra en: i) Descubrir las funcionalidades del programa; ii) Visualizar la relación entre sus componentes y iii) Estudiar el comportamiento del programa. Finalmente, la Visualización de Sistemas analiza grandes programas compuestos por diferentes módulos.

111 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 105 La discusión precedente posibilita el establecimiento de una relación de inclusión entre esas clases de visualizaciones la cual se muestra en la Figura 5.4. Esté gráfico declara que toda técnica aplicada en un conjunto se puede usar en su superconjunto. El productor de la herramienta de la VS debe analizar si las técnicas usadas sobre un nivel son útiles sobre otro (más alto o más bajo) nivel [DH08]. Figura 5.4: Relación de Inclusión de las Visualizaciones de Software VS está relacionada con otros conceptos de programación tales como: Programación Visual (PV) y Programación por Ejemplo (PE). PV es un paradigma de programación donde los programas se especifican usando gráficos. Comunmente, esos elementos representan construcciones básicas de algún lenguaje de programación. PE es otra forma de llevar a cabo la programación. En este caso, el programador especifica la entrada y la salida del programa y la computadora construye el sistema a través de un proceso de inferencia. Esta breve de discusión permite distinguir claramente los conceptos usados en VS. Visualización de Sistemas, Visualización de Programas y Visualización de Algoritmos son temas de VS centrados en la representación de la información del sistema. Programación Visual y Programación por Ejemplo usan técnicas de VS, pero están vinculados con la programación en sí misma Sistemas de Visualización de Software Un Sistema de Visualización de Software (SVS) es una aplicación cuyo objetivo es proveer diferentes perspectivas visuales del software. Los SVS están normalmente compuestos por los siguientes subsistemas: Ambiente de Visualización; Administrador de la Información y Extracción de la Información. El primero contiene diferentes estrategias visuales que muestran la información. El segundo está re-

112 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 106 lacionado con el acceso eficiente a los datos requeridos para la generación de las visualizaciones. El tercero es usualmente una componente compartida por otra clase de sistemas tales como las Herramientas de Comprensión de Programas (HCP) y su función consiste en la recuperación de la información desde el software. En este trabajo, el interés se centra en los Sistemas de Visualización de Software Orientados a la CP (PC-SVS) esta clase de aplicaciones son una subclase de los SVS que normalmente se integra con HCP. La principal diferencia entre SVS y los PC-SVS es que los primeros solamente se preocupan con la visualización de software, en otras palabras con el Dominio del Programa, mientras que los segundos consideran la visualización de los Dominios del Problema y Programa y la relación existente entre ambos. Esta distinción es substancial porque fuerza al diseñador a: i) Crear representaciones para otros objetos además del software y ii) Pensar estrategias de visualización de la relación entre la especificación del problema y la representación del software. El lector puede percibir que la consideración expuesta previamente se basa en la concepción de CP descripta en los capítulos 1 hasta 4. En las secciones siguientes se describen los Ambientes de Visualización y se deja para los capítulos siguientes la caracterización del Extractor y Administrador de la Información Ambiente de Visualización Un Ambiente de Visualizaicón (AV) es una componente de los SVS o PC-SVS que contiene los elementos necesarios para simplificar la manipulación de los objetos que forman parte de la visualización. Las principales funcionalidades y componentes de AV se refieren a: AV en sí mismo y las Vistas. Las próximas subsecciones describen cada uno de ellos. Caracterización de los Ambientes de Visualización Las principales partes de un AV [SDBP98] son: Encabezado: muestra el nombre de la aplicación, la identificación de la componente de software, etc. Título: presenta el tema de estudio. Objetivo: explica la finalidad de la visualización.

113 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 107 Descripción de Artefacto: describe las caracterísitcas principales de los artefactos usados en la visualización. Área Historia: almacena la historia de las operaciones de usuario. Área de Comando: provee un acceso fácil y eficiente a las operaciones de los artefactos usados en la visualización. Área de Visualización: se refiere a la parte de la interfaz gráfica donde se ubican los artefactos. Área de Intercambio: algunas veces un artefacto puede mostrar muchos atributos, sin embargo, observarlos en su totalidad en una simple visualización no es buena idea porque promueve la desorientación. Una aproximación interesante para solucionar este inconveniente consiste en proporcionar diferentes visualizaciones del mismo artefacto pero con un número limitado de atributos y proveer un mecanismo de navegación entre esas visualizaciones. Este mecanismo se puede implementar usando un área de intercambio que permita un acceso fácil y rápido a las diferentes perspectivas del mismo objeto. Es importante destacar que el Área de Intercambio también facilita el estudio del software cuando el usuario trabaja con dos o más artefactos al mismo tiempo. Área de Mapeo: generalmente, los artefactos de visualización ocupan más espacio que el proporcionado por la pantalla. En esas situaciones, es posible tener una vista parcial de la representación del sistema. Este problema produce desorientación porque se pierde el contexto. Para apaliar esta dificultad, es útil proveer un Área de Mapeo que contenga una vista global del artefacto. Esta área se puede mostrar como una pequeña ventana en alguna esquina del objeto contenedor. Layout and Look: considera atributos tales como: Color; Tamaño; Posición; etc. Esas cualidades son muy dependientes de la clase de objetos usados para mostrar atrefactos; sin embargo es importante considerar su utilidad para representar las características del sistema. Anotación: se usa para hacer comentarios acerca de alguna de las características del/los objeto/s observado/s en la visualización. Base de Conocimiento: se emplea para mostrar los conceptos recientemente usados, o para extraer la terminología relacionada con un trabajo específico. En términos cognitivos, asiste al proceso de recuperación de conceptos desde la estructura mental del programador. Clase de Proceso de Asimilación: posibilita conocer la estrategia de aprendizaje usada y provee funciones que simplifican la operación del proceso de asimilación corriente. Por ejemplo, si la

114 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 108 estrategia de aprendizaje es Top-down entonces la herramienta debe proporcionar funciones de navegación desde los aspectos más abstractos hasta los más específicos. Área de Leyenda: facilita la identificación de los atributos de los artefactos más importantes empleados en la visualización. Pie: es beneficioso exhibir alguna información en esta parte. Por ejemplo: Cantidad de vistas abiertas; Coordenadas del ratón; Información de estado en general; etc. Para finalizar esta subsección es importante notar que: La información provista por las componentes del AV no deben sobrecargar la percepción del usuario. Si el número de componentes del AV es muy grande entonces el diseñador debe eliminar o filtrar alguna de ellas. Además de las funcionalidades descriptas previamente, los AV tienen funciones similares a las de las clásicas interfaces de usuario (abrir, guardar, guardar como, redimensionar, etc.) porque tienen como objetivo la operación de PC-SVS en sí mismo y no la manipulación de artefactos. Caracterización de las Vistas Las Vistas son una componente fundamental de los AV. Como se declaró en la introducción de este capítulo, una Vista es una forma de visualizar las componentes del sistema y sus relaciones que permite mostrar alguno de sus aspectos. Las vistas pueden ser Estáticas, Dinámicas o Híbridas. Una vista estática muestra la información sin efectos de animación, en otras palabras las características estáticas del sistema o problema; un ejemplo de este tipo de vistas es el Grafo de Funciones. Las vistas dinámicas visualizan el flujo de ejecución del programa o animaciones del Dominio del Problema. El árbol de ejecución de funciones y el proceso usado para construirlo forman parte de esta clase de prespectivas. Las vistas híbridas son una combinación de las vistas estáticas y dinámicas. Esta clase de vistas son interesantes porque la combinación adecuada de la información posibilita la identificación de las partes del sistema usadas para un propósito específico. Por ejemplo, conocer cuales funciones del Grafo de Funciones se utilizaron para un escenario de ejecución particular simplifica la inspección del sistema. Otra forma de conceptualizar las vistas es considerar su contenido. En este caso, es posible obtener vistas de: Datos; Código o Funcionalidades; las cuales se pueden concretizar con versiones estáticas,

115 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 109 dinámicas o híbridas. El diseñador de la visualización decide el método de combinación de acuerdo a las características del objeto de estudio. Es importante notar que la elaboración de vistas implica responder preguntas tales como: Por qué se necesita la visuazliación? Quién usará la visualización? Qué representa la fuente de datos? Cómo se representan los datos? Dónde se representa la visualización? Artefactos Las vistas están compuestas por Artefactos. Un Artefacto es un concepto de VS que referencia un objeto usado en una visualización. Los artefactos se pueden clasificar teniendo presente su complejidad o la aproximación usada para mostrar la información. La primer clase contiene artefactos simples o compuestos. El primero se refiere a elementos visuales con un número pequeño de atributos atómicos para representar las características del software. Los artefactos compuestos son colecciones de artefactos simples. La segunda clase está integrada por artefactos textuales, gráficos o de video. Los artefactos (simples o compuestos) tienen un conjunto de funciones básicas que facilitan la interacción con el usuario, a continuación se describen cada uno de ellos. Zoom: se emplea para explorar en detalle algunas partes del sistema. La operación de zoom tiene las siguientes variantes: Geométrico: consiste en aumentar la visión en un lugar específico de la vista. En otras palabras, esta clase de acercamiento magnifica un área de la pantalla. Semántico: recupera un conjunto de componentes relacionadas y oculta otros elementos. Ojos de Pez: es igual que el acercamiento geométrico pero preserva información contextual. Buscar: permite la recuperación de objetos desde un conjunto de objetos. Se distinguen los siguientes tipos de búsquedas: Tradicional: recibe como entrada una clave y retorna como salida el/los objeto/s que posee/n el mismo valor de clave recibido como argumento, o un valor lógico que indica éxito o fracaso. Se destacan dos tipos de búsquedas tradicionales: Concordancia de Modelos: se describe el objeto usando algún formalismo, por ejemplo expresiones regulares, y el procedimiento retorna los objetos que concuerdan con la especificación. Fonética: al mismo tiempo que se especifica la clave se muestran los objetos cuyo valor concuerda parcial o totalmente con la clave ingresada.

116 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 110 Avanzada: referencia a búsquedas más sofisticadas que la tradicional. En los próximos ítems se explican algunas de ellas. Artefacto: encuentra los artefactos usados en la visualización cuyos valores de atributo concuerdan con los provistos por el programador. Relacional: extrae los objetos con características que se especifican usando condiciones. Esta operación es similar a las consultas a una base de datos. Filtro: oculta aquellos objetos que el usuario considera que no están relacionados con una tarea o característica específica del sistema. Esta operación tiene como finalidad reducir la desorientación. Mover y Pegar: se utiliza para organizar la información provista por la visualización. Agrupar y Colapsar: esta operación es apropiada en la construcción de estrategias para agrupar, ocultar y mostrar artefactos cuando el usuario lo considera necesario. Asociación de Eventos: vincula eventos a artefactos visuales. Navegación: esta operación es muy importante para la CP. Por un lado, el programador la usa para inspeccionar la parte del sistema que considera relacionada con la funcionalidad de estudio. Por el otro, es una aproximación práctica e interesante para implementar estrategias de aprendizaje. Es posible distinguir tres clases de navegación teniendo presente diferentes dominios y niveles de abstracción, a continuación se explican cada una de ellas. Arbitraria: permite navegar la información sin un patrón específico. Intra-Dominio: los únicos elementos disponibles para navegar están en el mismo dominio y en el mismo nivel de abstracción. Inter-Dominio: los elementos disponibles para la navegación están en diferentes dominios y en diferentes niveles de abstracción. Personalización de Atributos: los artefactos pueden tener muchos atributos. Comunmente, no es posible mostrar todas las características de los artefactos en una visualización porque causa desorientación. Una propuesta para solucionar este problema consiste en solamente mostrar un número fijo de atributos y proveer formas de indicar cuales de ellos se deben visualizar. Esta última técnica se puede combinar con las funcionalidades del Área de Mapeo descripta en la sección

117 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 111 Recuperación de la Historia: ayuda a reconstruir y analizar los pasos seguidos por el programador para alcanzar el actual espacio de búsqueda Aproximaciones para Visualmente Representar la Información del Sistema Los artefactos frecuentemente usados para visualizar software son textuales, diagramas y grafos [SvG05, KM07]. Cada uno de ellos se aplican a diferentes tareas de CP; por ejemplo, las visualizaciones textuales son interesantes para mostrar el código fuente; las basadas en grafos se usan comunmente para visualizar abstracciones del sistema tales como la relación entre funciones, comunicaciones de módulos, etc. Los diagramas se emplean frecuentemente en la exhibición de valores de métricas. Esta sección presenta las características más abstractas, relacionadas con los artefactos mencionados previamente, que el programador necesita definir cuando diseña un esquema de visualización. Propuestas Textuales La primer vista usada para entender un sistema es su código fuente; por esta razón, las visualizaciones textuales [SWM, BE96] son importantes para la CP. Cuando se construyen visualizaciones textuales se deben considerar tres componentes principales y sus atributos. Esos elementos se describen a continuación: Palabras: los atributos más importantes de esta clase de elementos son: Fuentes; Estilo; Tamaño; Color; etc. Normalmente, los editores de textos usan esas características para presentar el código fuente resaltando las palabras claves y algunas construcciones del lenguaje de programación. Líneas: en este caso, las caracterísitcas consideradas son: Tamaño; Espacio e Iluminación. Comunmente, esos atributos se utilizan para: Indicar la línea corriente; Limitar el número de caracteres y Aliviar la lectura. Código: se refiere a la estrategia usada para mostrar las componentes del lenguaje de programación tales como: Cadenas de caracteres; Literales; Declaraciones; Expresiones; Estructuras de control; Datos; Procedimientos y Funciones; Comentarios; Indentación; etc. La definición de las características de visualización del código fuente implica el estudio profundo de las construcciones del lenguaje (sintáxis y semántica). Afortunadamente, en [SDBP98] se puede encontrar un excelente ejemplo para el caso del lenguaje C.

118 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 112 Representación Gráfica basada en Grafos Una estructura de datos típica para visualizar la información de los sistemas son los grafos [SWM]. Un grafo es una dupla G=(N,R) donde N es un conjunto de nodos y R es una relación definida sobre N, R N N. Los elementos de R son llamados arcos o aristas. La producción de una visualización basada en esta estructura de datos requiere la caracterización de: el Grafo; los Nodos y los Arcos. Grafo: en este contexto adquiere relevancia el trazado del grafo porque tiene propiedades que permiten caracterizar apropiadamente ciertos elementos del programa. Habitualmente, los trazados jerárquicos se usan para visualizar las componentes de software y sus relaciones. En este caso, las componentes dibujadas en la parte superior representan entradas al programa y las componentes sobre la parte inferior simbolizan salidas del programa. Los nodos aislados son funciones no usadas o funciones llamadas a través de punteros. Los trazados jerárquicos (ver Figura 5.5) no son los únicos, se pueden encontrar otras propuestas muy interesantes. Por ejemplo, el Trazado Físico Virtual (ver Figura 5.6) es atractivo porque permite la identificación de las componentes del sistema más requeridas. Los Trazados Planares (ver Figura 5.7) se emplean para visualizar sin superposición de objetos gráficos las entidades del sistema y la relaciones existentes entre ellas. Las razones expuestas previamente permiten percibir la importancia del trazado de grafos para la visualización de propiedades del sistema. Nodos: los nodos tienen los siguientes atributos: Forma; Color; Tamaño e Información mostrada dentro del nodo. Forma: generalmente se usan para distinguir las componentes de software exhibidas. Por ejemplo, un círculo puede representar a una función y un cuadrado a un módulo, o alternativamente se define un ícono específico que represente alguna de esas componentes del sistema. Si la forma del nodo tiene borde entonces es posible definir los siguientes atributos: Clase de Borde: se dibuja frecuentemente usando lineas sólidas o punteadas y se suele utilizar en la representación de entidades reales o virtuales. Ancho del Borde: se usa para enfatizar alguna propiedad. Por ejemplo, importancia de una función para un sistema, función invocada más veces en tiempo de ejecución, etc.

119 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 113 Figura 5.5: Trazado de Grafo Jerárquico Color: es otra posibilidad para mostrar la información. En este caso, es importante mencionar el atributo: Intensidad del Color. Esta característica se usa comunmente para resaltar la importancia de la entidad y su grado de utilización. Tamaño: normalmente se emplea para visualizar la importancia de la entidad. Atributos dentro del nodo: visualiza información específica del dominio. Arcos: para representar visualmente los arcos se deben considerar dos clases de grafos: Dirigidos y No dirigidos. En ambos casos, es posible usar la misma estrategia que la empleada para el borde de los nodos. Sin embargo, en los grafos dirigidos aparece otra componente: La cabeza de la flecha. Este elemento se puede representar siguiendo una estrategia similar a la

120 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 114 Figura 5.6: Trazado de Grafo Físico Virtual usada con los nodos; en otras palabras, atributos tales como: Forma; Color y Tamaño se deben instanciar con las propiedades de las componentes de software representadas por este artefacto visual. Diagramas En [MFM03] se presenta un estudio interesante acerca de VS que usan diagramas. Este trabajo se fundamenta en las ideas de plasmadas en Seesoft [BE96] pero enfatiza el uso de diagramas 3D como estrategia para mostrar varios atributos de software en una simple visualización. Este objetivo se lleva a cabo seleccionando diferentes atributos de los diagramas y mapeandolos en algunas caracterísiticas del software.

121 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 115 Figura 5.7: Trazado de Grafo Planar Otro aspecto importante está relacionado con el interés del autor por cubrir la taxonomía de Price (dicha clasificación se explicará en las próximas secciones). Esta tarea es útil porque fuerza al diseñador a pensar e implementar visualizaciones con funcionalidades de CP tales como: Navegación; Filtro; Estrategias de magnificación; etc. El problema principal de esta propuesta es que solamente considera el Dominio del Programa, de este modo el proceso de CP queda incompleto. Sin embargo, esta estrategia es relevante porque muestra como se pueden usar las propiedades de los diagramas para producir visualizaciones de software elegantes y completas. La Figura 5.8 muestra ejemplos del uso de diagramas para visualizar las propiedades del software. En este caso, el color representa la estructura de control y el alto representa el nivel de anidamiento encontrado en cada archivo. Para concluir esta subsección es interesante notar que el problema de construir VS usando diagramas tiene los siguientes desafíos: Seleccionar un diagrama que represente apropiadamente la información deseada. Extraer los atributos del diagrama y mapearlos con los aspectos del software que el diseñador quiere mostrar. Mostrar muchas características del software evitando la sobrecarga de información.

122 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 116 Figura 5.8: Diagramas usados para mostrar las propiedades del software Otros Esquemas Esta subsección agrupa aquellas representaciones visuales creadas sin un patrón específico. Usualmente, estas formas de visualizar software se construyen de una forma ad-hoc o siguiendo nuevos e innovativos diseños cuya utilidad se debe demostrar. En este contexto, los trabajos de Wettel et. al. presentan una forma innovadora de visualizar los sistemas orientados a objetos [WL07]. Los artefactos usados para llevar a cabo esta tarea consisten en lugares de ciudades representados en tres dimensiones (ver Figura 5.9). En este trabajo, los autores intentan usar la tercera dimensión para reducir la desorientación. En [SDBP98] es posible encontrar artefactos basados en grillas que representan vistas 2D de ar-

123 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 117 Figura 5.9: Visualización de Software como ciudades tefactos 3D o son formas creativas de exhibir estructuras de datos bien conocidas. La Figura 5.10 muestra una visualización de árbol atípica. En esta aproximación, el árbol se dibuja llenando un hexágono de izquierda a derecha, porque el propósito es mostrar las características generales tales como: Alto y Ancho. Es importante destacar que esta propuesta preserva mucho espacio de pantalla. La Figura 5.11 muestra una representación conocida con el nombre de Tree-ring. Esta estrategia muestra la historia del uso de memoria de los programas. En este caso, las bandas externas describen las actividades más antiguas y las más recientes se dibujan en los anillos internos. La Figura 5.12 muestra un Calidoscopio que exhibe el tiempo de ejecución de aplicaciones paralelas. Figura 5.10: Alagae

124 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 118 Figura 5.11: Tree-ring Figura 5.12: Calidoscopio 5.5. Taxonomías de los Sistemas de Visualización de Software Actualmente, existen muchas taxonomías de VS que son útiles para evaluar los esquemas usados por las herramientas de VS. Cada taxonomía enfatiza diferentes aspectos de la VS, por ejemplo las caracterísitcas específicas del software, actividades humanas, etc. En esta sección, se presenta un estudio de las taxonomías corrientes de VS. Luego, se detectan los ítems no considerados en todas ellas y se proponen nuevos criterios que contemplen las características ausentes en esas clasificaciones. Brown en [Bro88] introduce una clasificación de la visualización centrada en las animaciones. Él describe su propuesta usando tres abcisas principales: Contenido; Persistencia y Transformación. La primera analiza las estrategias empleadas para representar el programa. Esta característica está di-

125 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 119 vidida en Directa, en la cual el código fuente se representa directamente usando artefactos gráficos, y Sintética, en este caso se muestra una abstracción del código fuente. La segunda se refiere a si el contenido que se visualiza está Actualizado, o bien lo que se observa es una Historia de lo que sucedió. Finalmente, la tercera describe la forma de llevar a cabo la animación. En este contexto se distinguen dos extremos principales Discreta e Incremental, ambos criterios explican la forma de alternancia de las figuras de la animación. En el caso discreto la imagen de la pantalla se suplanta por la nueva y en el caso incremental la transición es suave. Myers, un pionero en VS, presenta en [Mye90] una taxonomía con dos abcisas principales: La clase de objeto que el sistema de visualización intenta ilustrar y El tipo de información visualizada. La primera componente consite de código, algoritmos o programas, y la segunda se centra en la información estática y dinámica. La combinación de esas abcisas produce las siguientes clases de visualizaciones: Código-estático: visualizaciones tales como diagramas de flujo y la técnica de Seesoft [BE96] usan esta aproximación. Código-dinámico: se relaciona con las animaciones de software y las estrategias de visualización del flujo de ejecución del programa. Dato-estático: las estrategias de visualización de código estáticas se aplican a esta categoría. La principal idea consiste en presentar en una forma agradable los objetos de datos del sistema y sus valores. Dato-dinámico: esta clase de visualización consta de animaciones que visualizan las variables y sus valores en tiempo de ejecución. Algoritmo-estático: estudia la generación de instantáneas (vistas estáticas) de algoritmos. Algoritmo-dinámico: consiste en la construcción de animaciones de algoritmos que presentan una vista dinámica integral de cada componente usada en tiempo de ejecución. Roman and Cox [RC93] proponen clasificar a los SVS usando cinco criterios basados en el modelo de VS mostrado en la Figura Alcance: se relaciona con los aspectos del programa que se desean visualizar, por ejemplo: una instancia particular del sistema, funcionamiento global, etc. Nivel de Abstracción: describe el grado de sofisticación de la visualización.

126 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 120 Figura 5.13: Modelo de Roman y Cox Método de Especificación: explica los mecanismos usados por el animador para construir la visualización. Interface: expone las facilidades provistas por el sistema de VS para presentar y manipular la visualización. Presentación: se interesa en la efectividad de la presentación de la información. En otras palabras, este ítem analiza el desempeño de la visualización para transmitir información. Es importante notar que cada criterio se explica en a tavés de varios subcriterios que facilitan la comprensión de esta clasificación. El lector interesado en esta taxonomía puede estudiar [RC93] para obtener más detalles. Price et. al. en [PSB92] y [PBS93] presentan una taxonomía completa y multidimensional de la VS (ver Figura 5.14). Este trabajo describe los sistemas de VS usando seis caraterísticas: Alcance: define las características generales de la VS. Por ejemplo, si la visualización se realizó para un ejemplo o para alguna clase de sistema, clase de programas, concurrencias, etc. Esas características se explican por medio de subcaracterísticas cuya descripción se puede leer en [PSB92] y [PBS93]. Contenido: hace referencia a la información proporcionada por la visualización. Se ubican en esta categoría las visualizaciones de: Programa o Algoritmo; Código o Dato, etc. Forma: caracteriza los elementos usados en la visualización. Entre ellos se pueden mencionar: Medio; Elementos gráficos; Colores; Vistas; etc. Los artículos [PSB92] y [PBS93] proporcionan una descripción precisa de este ítem. Método: estudia las estrategias empleadas para especificar la visualización. Por ejemplo: Fija; Personalizada; Estilo de especificación; etc. Para obtener más información se recomienda leer [PSB92] y [PBS93].

127 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 121 Figura 5.14: Taxonomía de Price et. al.

128 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 122 Interacción: detalla las técnicas usadas para interactuar y controlar la visualización. Entre las estrategias más comunes se encuentran: Navegación; Simplificación de la información; Mapeo de control temporal; etc. (Ver [PSB92] y [PBS93] para obtener más detalles). Efectividad: explica los parámetros requeridos para evaluar la calidad de la visualización. Esta característica considera los siguientes criterios: Apropiación y claridad; Evaluación experimental; Uso de producción (ver [PSB92] y [PBS93]). Storey y su grupo de investigación en [SvG05] proponen una clasificación, basada en la taxonomía de Price, pero orientada a la conciencia de las actividades humanas. En este trabajo, los autores presentan cinco características principales: Intento: describe el propósito de la visualización a través de: Rol; Tiempo; Soporte Cognitivo. Información: se refiere a la fuente de información usada por las herramientas. Este ítem está compuesto por las siguientes subcategorías: Administración de los Cambios; Código del Programa; Documentación; Comunicación Informal; Dato Derivado. Presentación: especifica como la información se presenta al usuario final. Este criterio tiene las siguientes divisiones: Clase de Vistas; Técnicas. Interacción: caracteriza las facilidades de interacción provistas por la herramienta. Esta cualidad contiene las siguientes alternativas: Batch/Live; Personalización; Mecanismo de Consulta; Navegación de Vistas. Efectividad: explica la probabilidad de implementar la herramienta. Tiene como subcriterios: Estado; Costo; y Evaluación. El lector interesado en conocer la totalidad de los detalles de cada subcategoría debe analizar cuidadosamente [SvG05] Incompletitud de las Taxonomías Corrientes En la subsección 5.5, se describieron las principales taxonomías de los Sistemas de Visualización de Software (SVS). En términos generales, esas clasificaciones describen las características principales de los SVS. Sin embargo, como ha sido mencionado varias veces en el desarrollo de este trabajo de doctorado, las taxonomías dejan de lado aspectos de CP muy importantes, como por ejemplo: La visualización del Dominio del Problema y la relación existente con el Dominio del Programa.

129 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 123 El proceso de Comprensión de Programas se basa sobre Modelos Cognitivos y cuando el programador quiere comprender un programa dos dominios del conocimiento son escenciales: el Dominio del Programa y el Dominio del Problema. El Dominio del Programa analiza pasos tecnológicos como el lenguaje de programación (sentencias, funciones, módulos) y como se ejecuta el programa para producir una salida; mientras que el Dominio del Problema estudia los efectos de la ejecución del programa (el resultado final producido y el impacto a nivel del problema que se resolvió). La principal desventaja con las taxonomías corrientes es que las mismas no están basadas en una concepción de Comprensión de Programas porque sólo consideran el Dominio del Programa. Por esta razón, se pierden muchos aspectos sustanciales que determinan la calidad del SVS. El capítulo 3 declaró que: La CP se simplifica si se representan e interconectan los Dominios del Problema y Programa. Esta declaración es el punto de partida para afirmar que las clasificaciones actuales no tienen en cuenta algunas características escenciales que los Sistemas de Visualización de Software Orientados a la Comprensión de Programas deben poseer. Las investigaciones en VS realizadas en [BHU07] revelan que las taxonomías de SVS describen muy bien el Dominio del Programa, pero no sucede lo mismo con el Dominio del Problema, ni la relación existente entre ellos. Preguntas tales como: Cómo se puede caracterizar el Dominio del Problema? Cuál es la mejor forma de describir la relación entre los Dominios del Problema y Programa? Por qué los factores cognitivos no se mencionan en esas taxonomías? Las características de los SVS están bien organizadas?, etc. motivan la elaboración de una clasificación de los SVS cuya finalidad es caracterizar apropiadamente a los SVS orientados a la Comprensión de Programas Nuevos Criterios para Mejorar la Caracterización de los PC-SVS El Dominio del Problema es una característica relevante porque distingue a los SVS con funciones explícitas de CP de los comunes. Sin embargo esta particularidad está ausente en todas, o casi todas, las clasificaciones de los SVS. En esta sección, se describen algunos criterios que resuelven los inconvenientes presentados por las taxonomías corrientes. Como se mostró en la sección estas características están centradas en la visualización del Dominio del Problema y su relación con el Dominio del Programa. Las siguientes subsecciones explican cada uno de los nuevos criterios.

130 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 124 Visualización del Dominio del Problema El Dominio del Problema se puede describir a través de las siguientes categorías principales: Alcance; Método de Especificación; Clase de Creación; Nivel de Abstracción; Contenido; Interfaz y Modelos Cognitivos. El lector puede observar que muchos de los nombres de criterios mencionados previamente son los mismos que los utilizados para el Dominio del Programa. Sin embargo, sus significados son muy diferentes. Esta afirmación será sustentada en los siguientes ítems. Alcance: especifica las característcas del Dominio del Problema que se visualizarán. En este caso, se distinguen las siguientes categorías: Estímulo/Respuesta: el sistema se muestra como una caja negra, solamente se detallan sus entradas y salidas. Esta tarea se realiza para un ejemplo o todo el sistema. Conceptos/Relaciones: se usan modelos tales como los Mapas Conceptuales descriptos por Novak, Modelo de dominio, etc. para representar el/los concepto/s usado/s en el Dominio del Problema y las relaciones existentes entre ellos. Subsistema/Relaciones: si es posible identificar algunas componentes de alto nivel entonces exteriorizar la relación existente entre ellas es una estrategia atractiva de visualización del comportamiento del sistema. Comportamiento: se refiere al sistema en tiempo de ejecución. Método de Especificación: especificar el Dominio del Problema es una tarea dificil. Aún más problemático es encontrar una especificación fácil de vincular con las componentes del Dominio del Programa. Este criterio focaliza en el análisis de varias estrategias para resolver este problema. La principal idea es verificar: 1. El nivel de legibilidad de la especificación. 2. El tipo de visualización, en este caso es importante destacar que una visualización conceptual disminuye la brecha entre dominios. 3. El nivel de estandarización de las especificaciones. Esta característica es importante porque facilita la integración con otros Proyectos de Ingeniería de Software. Teniendo presente los ítems descriptos previamente, se encontraron las siguientes clases de especificaciones:

131 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 125 Ad-hoc: el método de especificación fue creado por el programador o no hay método. Riguroso: técnicas con procedimientos y notaciones bien definidos están en este grupo. Ellas no son considerados formales porque no todos los mecanismos tienen una demostración matemática. Un ejemplo de esta categoría son los diagramas de UML. Formal: las especificaciones realizadas con los lenguajes formales o modelos matemáticos son apropiados para describir las características del problema. No obstante, presentan el inconveniente de dificultar la interconexión con las componentes del programa. Clase de Creación: se refiere a la estrategia usada para crear la visualización. Esta característica está compuesta de las siguientes subcaracterísticas: Manual; Semiautomática; y Automática. Nivel de Abstracción: expone el nivel de detalle empleado para visualizar las características del Dominio del Problema. Las subcategorías relacionadas con este criterio son: Directa; Estructural; Sintetizado. Interfaz: se puede describir a través de los siguientes aspectos: Clase de Interfaz: describe el tipo de artefacto utilizado para exhibir la información. Los mismos pueden ser: Textuales; Gráficos o Híbridos. Tipo de interacción: se centra en la estrategia de interacción hombre-máquina implementada en el sistema de visualización. En este contexto se distinguen dos tipos de intracción: Clásica e Innovativa. La primera se asocia con los mecanismos tradicionales de interacción. Por ejemplo controles a través del teclado o ratón, imágenes; etc. La segunda tiene como objetivo cubrir nuevas propuestas de interacción. Vocabulario: la visualización se puede basar en diferentes vocabularios como por ejemplo: Textuales; Icónicos; Híbridos; etc. El punto importante es que el léxico usado debe ser apropiado para el problema de estudio y totalmente interpretado por el programador. El primer criterio es dependiente de la aplicación. El segundo permite analizar si el vocabulario está correctamente definido estudiando el mapeo entre los objetos visuales y sus significados. En este contexto, tres clases de mapeos se pueden establecer: No hay mapeo: no hay una asociación explícita entre los artefactos visuales y sus significados. Mapeo Parcial: algunos artefactos visuales tienen un significado explícito. Mapeo Completo: todos los artefactos tienen definido un significado.

132 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 126 Obviamente se prefiere la tercer clase de mapeo porque disminuye las dificultades de cognición. Modelos Cognitivos: otra de las características importantes que influencian la utilidad de los sistemas de visualización son los Factores Cognitivos. En este ámbito, se detectó que existen criterios útiles para evaluar HCP [Wal02b, Sto98, Sto06, Sto05]. Sin embargo, algunos aspectos no son considerados. A continuación se mencionan cada uno de ellos: Componentes de los MC: los MC están compuestos por cuatro elementos principales: Conocimiento Interno y Externo; Modelo Mental; Proceso de Asimilación y Unidad Bamboleante. Usualmente, esos elementos están ocultos en los SVS y no se utilizan para ayudar al usuario en el proceso de comprensión. De esta manera, las probabilidades de perder información conceptual importante se incrementan. Para evitar este inconveniente, se debe usar una estrategia de representación de esas componentes que sea simple de usar y de administrar con el propósito de eliminar la pérdida de tiempo cognitivo introducido por el aprendizaje requerido para la manipulación de esos elementos. Estrategias de Aprendizaje: otro criterio importante estudia las estrategias de aprendizaje implementadas en los SVS. En este ámbito, se consideran tres aproximaciones bien conocidas: Top-Down; Bottom-Up e Híbrida las cuales se explicaron en detalle en [BHU07]. Además, se puede observar un análisis más profundo, desde el punto de vista de las herramientas de exploración, de esos criterios en [Sto98]. La Figura 5.15 muestra como se organizan los criterios descriptos en los párrafos precedentes Visualización de la Interconexión entre los Dominios del Problema y Programa Otra característica interesante de visualizar es la relación entre los Dominios del Problema y Programa. En este contexto, el principal reclamo se centra en la visualización de los elementos del programa usados para construir cada parte de la salida del sistema. El lector puede observar algunos criterios del Dominio del Problema, tales como: Método de Especificación; Clase de Creación; Nivel de Abstracción; etc. que se pueden utilizar para describir esta relación. No obstante, es muy factible encontrar algunas propiedades específicas que merecen alguna discusión.

133 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 127 Figura 5.15: Criterios del Dominio del Problema

134 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 128 En primer lugar, se necesita redefinir la categoría Alcance porque la interconexión entre los Dominios del Problema y Programa se explica mejor usando los siguientes criterios: Ejemplo: referencia a las visualizaciones que sólo exhiben un escenario de ejecución particular. Por ejemplo, visualizar las funciones usadas por una ejecución del sistema. Parcial: describe a la posibilidad de visualizar, para algún o todos las componentes del Dominio del Problema, los elementos del programa relacionados con ellos y vice-versa. Por ejemplo, si el programa de estudio construye un grafo entonces se puede construir una visualización parcial que muestre las funciones usadas para construir el grafo, los nodos y arcos. Para ser más claro, esta clase de visualización vincula cada componente del Dominio del Problema con las funciones específicas del Dominio del Programa usadas para construirlo. Total: el objetivo de esta visualización es mostrar para cada componente del Dominio del Problema todos los elementos del Dominio del Programa relacionados con ella. Tomando como ejemplo un sistema que construye grafos, un posible resultado de esta clase de visualización es: Para cada grafo, las funciones y datos usados para construirlo. Para los nodos y arcos, las funciones y datos directamente relacionados con cada uno de ellos. Otra característica interesante de observar es en que momento la estrategia interconecta los dominios. En este contexto, se pueden identificar dos clases de aproximaciones: En Vida o Post Mortem. En la primera, las componentes del programa se visualizan mientras el programa se está ejecutando. La segunda realiza la misma tarea pero después de la ejecución del sistema. En el capítulo 6 se describen dos estrategias de interconexión de dominios. La primera, SVS, sigue una estrategia que usa la aproximación En Vida. En la segunda, BORS, la relación se establece después de la ejecución del programa; en otras palabras, BORS usa la aproximación Post Mortem. Finalmente, es relevante indicar si la visualización muestra: Código; Dato o Ambos Otras Consideraciones acerca de la Visualización del Dominio del Programa Las visualizaciones del Dominio del Programa han sido bien descriptas en la literatura. No obstante, se pueden elaborar algunos comentarios que clarifiquen ciertos aspectos de ellas.

135 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 129 Figura 5.16: Taxonomía Problema-Programa La taxonomía de Price describe la categoría Contenido usando cuatro subcategorias: Visualización de Programa o Algoritmo; Visualización de Código; Visualización de Datos; Tiempo de Compilación/Ejecución; Fidelidad y Completitud. Esas subcategorías son importantes pero minimizan el problema presentado por el tamaño del sistema (el lector puede observar que solamente una subcategoría contempla esta característica, ella es: Programa/Algoritmo). Esta característica restringe las estrategias usadas para visualizar Código y Datos por los motivos expuestos en la sección Por esta razón, es importante distinguir para qué categoría de software (Sistema, Programa o Algoritmo) se muestran los datos o código. Otra componente que aparece cuando se visualizan los programas o sistemas son los Módulos. Ellos son importantes porque, permiten la elaboración de vistas de alto nivel que eliminan la sobrecarga de información y por consiguiente facilitan la comprensión. Finalmente, es interesante que la taxonomía registre si la información visualizada es estática o dinámica. La Figura 5.17 muestra la categoría Contenido y sus subcategorías.

136 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE 130 Figura 5.17: Categoría Contenido

137 CAPÍTULO 5. VISUALIZACIÓN DE SOFTWARE Conclusión En este capítulo se abordó el tema de Visualización de Software con el objetivo de proporcionar las guías necesarias para elaborar estrategias de visualización que faciliten la comprensión de grandes sistemas. Para alcanzar este objetivo, se estableció una conceptualización de esta disciplina y a partir de ella se propuso un modelo para la elaboración de visualizaciones de software. Este modelo sugiere la reconstrucción virtual de la relación real existente entre el software y la representación gráfica seleccionada para la construcción de la visualización. Luego de realizada la tarea mencionada en el párrafo precedente, se caracterizaron los Sistemas de Visualización de Software y se analizaron todas las taxonomías actuales, con el objetivo de comprobar si las principales características de comprensión estaban consideradas. El resultado obtenido fue que si bien había muchas clasificaciones importantes ninguna de ellas incluía la visualización de las características del Dominio del Problema. Este resultado permitió la detección de un nuevo tipo de sistemas de visualización denominado: Sistemas de Visualización de Software Orientados a la Comprensión de Programas (PC-SVS). PC-SVS difieren de los sistemas de visualización tradicionales porque presentan una vista integral de los sistemas es decir visualizan los Dominios del Problema y Programa y la relación existente entre ellos. Esta nueva clase de sistema originó la elaboración de nuevos criterios que fueron incorporados a la taxonomía de los sistemas de visualización tradicionales más completa. Estos criterios permitieron: i) La caracterización del Dominio del Problema y su relación existente con el Dominio del Programa, y ii) Completar y depurar algunas conceptualizaciones presentadas por las taxonomías actuales. Finalmente es importante notar que este último resultado es una contribución de esta tesis doctoral.

138 Capítulo 6 Estrategias para Interconcetar Dominios 6.1. Introducción En cuanto haya más camino por recorrer caminamos. Pedro Rangel Henriques El capítulo 1 declara que uno de los problemas relevantes en Comprensión de Programas (CP) consiste en la elaboración de estrategias que permitan entender el funcionamiento de grandes sistemas de software. El capítulo 2 da el primer paso para encontrar la solución estableciendo una conceptualización de CP; esta tarea fue relevante porque menciona cuales son las principales disciplinas implicadas en el desarrollo de aplicaciones de CP. El capítulo 3 justifica esta conceptualización y declara que la Interconexión de Dominios es la mejor forma de facilitar CP porque permite: i) Implementar diferentes estrategias de aprendizaje; ii) Seleccionar la estrategia más apropiada de acuerdo al trasfondo de conocimientos del programador y iii) Encontrar significado y sentido a las actividades del sistema. El mismo capítulo afirma que el desafío principal consiste interconectar los Dominios del Problema y Programa porque implica la detección de las componentes del programa que fueron usadas para producir el comportamiento observado (esta relación se conoce con el nombre de Comportamental- Operacional). El captítulo 4 confirma, a través de un extensivo estudio del estado del arte, que las Herramientas de Comprensión de Programas (HCP) tienen pocas estrategias para interconectar los Dominios del Problema y Programa. El próximo paso en la solución del problema descripto en los párrafos precedentes (y también en el capítulo 1) consistió en la identificación y descripción de las principales características de los PC-SVS que ayudan al programador a entender programas (ver capítulo 5). 132

139 CAPÍTULO 6. ESTRATEGIAS PARA INTERCONCETAR DOMINIOS 133 Ahora es el momento de estudiar y elaborar Estrategias para Interconectar Diferentes Dominios. Esta tarea es relevante porque: Define las estrategias directamente relacionadas con la solución del problema. Es un parámetro necesario para el diseño e implementación de las estrategias de extracción de la información, porque identifica las componentes que se deben extraer desde el programa para que la interconexión de dominios se pueda realizar. El trabajo presentado en este capítulo está dividido en dos partes. La primera presenta una aproximación para relacionar vistas tradicionales. La segunda describe técnicas para alcanzar la relación Comportamental-Operacional mencionada previamente en esta introducción. Finalmente, se elaboran las conclusiones Interconexión de Dominios por Capas Cada dominio del sistema se visualiza a través de vistas las cuales se pueden organizar según su nivel de abstracción. Esta organización produce una jerarquía de perspectivas del sistema que es la base de una aproximación denominada Interconexión de Dominios por Capas (ver Figura 6.1). En esta estrategia se distinguen las siguientes componentes: Perspectivas: representa algunas características del sistema bajo análisis. Operaciones: se distinguen tres tipos de operaciones: Trabajo con Perspectivas: se centra en las operaciones definidas para la manipulación de la perspectiva. Por ejemplo, si las características del sistema están representadas por medio de grafos se deben definir las siguientes operaciones: Right; Left; Path; etc. Manejo de la Relación de perspectivas en un mismo nivel de abstracción: tiene como objetivo encontrar las relaciones relevantes entre varias perspectivas en el mismo nivel de abstracción. Por ejemplo, si se usa el Grafo de Funciones y el Grafo de Tipos para representar el sistema, una operación que vincule funciones con datos relaciona ambas vistas. Manejo de la Relación de prespectivas en diferentes niveles de abstracción: permite relacionar perspectivas en diferentes niveles de abstracción. El Grafo de Comunicaciones de Módulos y el Grafo de Funciones son posibles representaciones de un sistema. La primera

140 CAPÍTULO 6. ESTRATEGIAS PARA INTERCONCETAR DOMINIOS 134 Figura 6.1: Interconexión de Dominios por Capas

141 CAPÍTULO 6. ESTRATEGIAS PARA INTERCONCETAR DOMINIOS 135 de ellas está en un nivel de abstracción más alto que la segunda; por esta razón, una operación que recupere las funciones definidas por un módulo específico es una forma de interconectar ambas perspectivas. Es importante recordar que la definición de perspectivas es dependiente del programador porque es él quien decide que aspectos se deben inspeccionar. Además, la relación entre las vistas a igual o diferente nivel de abstracción depende de la información disponible y el formalismo usado para representar cada vista. Para simplificar la implementación de esta aproximación cada perspectiva y sus operaciones deben estar bien definidas. Esto quiere decir, que es muy aconsejable el uso de librerías estándares y tipos de datos abstractos (en el caso de lenguajes imperativos) para la implementación de la Interconexión de Dominios por Capas. Para ilustrar esta técnica, se presenta un ejemplo que usa vistas tradicionales. El Grafo de Dependencias de Módulos a Nivel Funciones es una vista clásica en CP que muestra como los módulos del sistema están conectados por medio de funciones. Otra representación posible de un módulo es: El Grafo de Funciones. Esta vista visualiza la relación llamador-llamado y se emplea generalmente como una perspectiva de segundo nivel. Finalmente, cada función se representa a través de su código fuente y objeto. Esas dos últimas vistas se encuentran en el nivel más bajo de la jerarquía. Operaciones tales como Zoom, Búsquedas, Filtros son necesarias sobre cada nivel para facilitar la inspección cuando la cantidad de información es muy grande. Además, operaciones que permitan recuperar: Las funciones definidas en un módulo específico; El código fuente correspondiente a las funciones representadas en el Grafo de Funciones; etc. permiten relacionar dominios en diferentes niveles de abstracción. Es importante notar que para incorporar, en este esquema, otras vistas similares a las presentadas en el ejemplo anterior, se deben considerar el nivel de abstracción y las operaciones que se definen sobre ellas. Requerimientos de Implementación Basicamente, la construcción de vistas se basa en la información recuperada desde el sistema y las operaciones aplicadas sobre ellas. En este sentido, los siguientes requerimientos son necesarios: API estándard: es importante disponer de funciones estándares para incorporar, remover o modificar perspectivas y operaciones en el mismo o diferente nivel de abstracción. Un Modelo para Trabajar con Vistas: usar aproximaciones ad-hoc no es buena idea. Una de las razones que sustentan esta afirmación es la dificultad integración de este tipo de soluciones con otras herramientas de ingeniería. Por este motivo, el uso de formalismos con operaciones bien definidas evita este problema y reduce costos y esfuerzos.

142 CAPÍTULO 6. ESTRATEGIAS PARA INTERCONCETAR DOMINIOS 136 Diseñar un Repositorio de Vistas: esta componente es necesaria para propósitos de administración y para proveer acceso eficiente a cada uno de los atributos de las vistas Estrategias para Relacionar los Dominios del Problema y Programa El principal objetivo de esta sección es el desarrollo y descripción de estrategias que permitan mostrar las componentes del programa que fueron usadas para producir su comportamiento (su efecto, o sea su resultado). Para alcanzar este objetivo, se proponen técnicas que utilizan información estática y dinámica, organizan esa información y aplican un proceso de vinculación que visualiza la relación entre el Dominio del Problema y el Dominio del Programa. Esas estrategias se explican en las siguientes subsecciones Estrategia de Visualización Simultánea - SVS Una propuesta interesante para recuperar, y luego si es necesario visualizar, las componentes usadas en tiempo de ejecución consiste en instrumentar el sistema. Para llevar a cabo esta tarea, es importante decidir: Qué componentes del programa y qué atributos de ellas se desean visualizar? y Cómo se debe llevar a cabo la instrumentación para producir el comportamiento deseado? Teniendo presente el primer ítem, el sistema se puede conceptualizar como una gran máquina de estados. En esta máquina, los estados están compuestos por las variables globales y aquellas declaradas en la función main, y sus transiciones están definidas por las funciones. El segundo ítem considera la recuperación de estos datos. Un punto interesante para llevar a cabo esta tarea es el comienzo y fin de cada función, porque en esos lugares se pueden conocer el estado actual y el próximo. Las sentencias insertadas son funciones de inspección (o también conocidas como inspectores) que procesan y muestran esta información. Los inspectores se implementan en otro sistema independiente, denominado Monitor, para simplificar su reuso. Ahora, suponga que un programa y un monitor, como los que se muestran en la Figura 6.2, se compilan formando un único sistema cuya característica es permitir la ejecución paralela de las funciones del sistema de estudio y de los inspectores. Si las primitivas de comunicación están correctamente implementadas, la salida de este nuevo sistema será como se ilustra en la Figura 6.3. El lector puede

143 CAPÍTULO 6. ESTRATEGIAS PARA INTERCONCETAR DOMINIOS 137 observar, la relación directa entre el Dominio del Problema (calculadora básica) y el Dominio del Programa (funciones usadas para computar las operaciones básicas). Requerimientos de Implementación La implementación de este esquema requiere: La definición de un esquema de Instrumentación de Código. La elaboración de mecanismos que combinen información estática y dinámica con el propósito de recuperar información más precisa acerca de los objetos del programa usados en tiempo de ejecución. Por ejemplo: Para una función sus parámetros y tipo de retorno; Para una variable su tipo; etc. Uso de un API estándar para acceder a las componentes del programa BORS una Estrategia de Relación Comportamental-Operacional Para relacionar las vistas comportamental y operacional se debe usar la información de los objetos del Dominio del Problema y el flujo de ejecución del programa (Dominio del Programa). El primer tipo de información se obtiene a través de la observación de la salida del sistema y la aplicación de algunas estrategias para recuperar los atributos de los objetos. El segundo se extrae usando una aproximación similar a la descripta en la sección Mezclando el conocimiento acerca de los Dominios del Problema y Programa, se desarrolló una estrategia que alcanza una estrecha relación entre el comportamiento del sistema y su operación interna. Antes de describir la nueva estrategia es importante reflexionar sobre algunos aspectos relacionados con la representación de la información dinámica porque esta característica es muy importante para la reconstrucción de la relación entre los Dominios del Problema y Programa. La estrategia SVS (definida en la sección 6.3.1), registra las funciones de tiempo de ejecución usando una lista. Si bien esta estructura de datos es adecuada para el propósito de SVS no sucede lo mismo cuando el objetivo es la elaboración de otras estrategias. Esto se debe a que desde una lista de funciones no se puede extraer más información que posibilite la obtención de nuevos conocimientos vinculados con las funciones usadas por el sistema. Por esta razón, surge la necesidad de cambiar la forma de representar la información dinámica con la finalidad de proporcionar datos con más semántica. En los próximos párrafos se justifica este requisito. Las funciones de tiempo de ejecución se pueden representar como un árbol que refleja la relación llamador-llamado. Esta forma de ver a las funciones es mejor que una simple lista porque permite

144 CAPÍTULO 6. ESTRATEGIAS PARA INTERCONCETAR DOMINIOS 138 SYSTEM MONITOR int add (int x, int y) void INPUT_INSPECTOR(char *s) { { int r; printf("begin: %s",s); INPUT_INSPECTOR("add"); } r=x+y; OUTPUT_INSPECTOR("add"); void OUTPUT_INSPECTOR(char *s) return r; { } printf("end: %s",s); } int subtract(int x, int y) { int r; INPUT_INSPECTOR("substract"); r=x-y; OUTPUT_INSPECTOR("substract"); return x-y; }... int main() { int op; INPUT_INSPECTOR("main"); do { printf("1. Add\n"); printf("2. Substract\n"); printf("option:\"); scanf("%d",&op); printf("x:"); scanf("%d",&x); printf("y:"); scanf("%d",&y); switch (op) { case 1: add(x,y); case 2: substract(x,y);... } } while (op!=0) OUTPUT_INSPECTOR("main"); return; } Figura 6.2: Sistema Instrumentado y el Monitor

145 CAPÍTULO 6. ESTRATEGIAS PARA INTERCONCETAR DOMINIOS 139 SYSTEM OUTPUT MONITOR OUTPUT 1) Begin main 1. Add 2. Substract Option: 2) /* op=1 */ X: 1 Y: 2 3) Begin: add 3 End add 4) 1. Add 2. Substract Option: 5) /* op=2 */ X: 1 Y: 2 6) Begin: substract -1 End: substract 7) 1. Add 2. Substraction Option: 8) /* op=0 */ End: main Figura 6.3: Salida de la Ejecución Paralela

146 CAPÍTULO 6. ESTRATEGIAS PARA INTERCONCETAR DOMINIOS 140 Figura 6.4: Lista de Funciones vs. fe-tree identificar la funcionalidad de cada una de las funciones. Por ejemplo, si F es una función del sistema, entonces su funcionalidad se puede inferir a través del análisis de las funciones llamadas directa o indirectamente por ella. Es importante notar que esta información se almacena en un subárbol cuya raíz es la función F. Asuma que A,B,C,D,E,F,G son funciones usadas por un sistema hipotético para producir su salida; observando la Figura 6.4 de la izquierda, no es posible identificar la descripción de las funciones. En cambio, si se usa un árbol, como el que se muestra sobre la derecha en la Figura 6.4, para representar la misma información, el problema se resuelve exitosamente. Observe la Figura 6.4 de la derecha donde se puede entender claramente como se obtienen las explicaciones para cada función. Por ejemplo, la descripción de la función A consite de las funciones B y C, y la explicación de la función D está compuesta por las funciones E y F. Finalmente, la función G no se puede expresar en términos de otra función. En este ejemplo los nombres de las funciones no tienen significado. Por esta razón, se pierde mucha semántica. No obstante, las reglas de programación mencionan la necesidad de colocar nombres

147 CAPÍTULO 6. ESTRATEGIAS PARA INTERCONCETAR DOMINIOS 141 con significado a las componentes del programa y generalmente esos nombres están directametne relacionados con los objetos del Dominio del Problema. De este modo, la información provista contiene más semántica porque: La estructura de datos árbol proporciona información de la relación llamador-llamado. Los nombres semánticos proporcionan pistas de la tareas realizadas por las funciones. La combinación de la información mencionada en los ítems anteriores proveen una explicación parcial de la funcionalidad del sistema de estudio. Esta característica justifica la preferencia de representar a las funciones de tiempo de ejecución como un árbol en lugar de una lista. Este árbol se denomina fe-tree (Function Execution Tree) y se define a continuación: Definición: Un fe-tree es un árbol de aridad r donde: 1. La raíz del fe-tree es la primera función ejecutada por el sistema (normalmente llamada main). 2. Para cada nodo (función) n, sus descendientes son las funciones invocadas directamente por n en tiempo de ejecución. Con el fe-tree, cualquier función del sistema se puede explicar y es posible conocer los diferentes contextos donde las funciones se invocaron. Por esta razón, el fe-tree se usa para inspeccionar los aspectos del sistema considerados importantes. Esos aspectos están constituídos por un conjunto de funciones y sus explicaciones están compuestas por la descripción de cada función componente. Si se usa un fe-tree para inspeccionar aspectos, se puede recuperar los contextos de las funciones y reducir el fe-tree a un subárbol. El contexto de las funciones es relevante para la inspección de código porque el programador conoce los lugares exactos donde se usó la función. La reducción del fe-tree se necesita porque disminuye significativamente la cantidad de información. En los siguientes párrafos se describe, BORS (Behavioral-Operational Relation Strategy), una estrategia que relaciona las vistas comportamental (lo que resulta de la ejecución del programa ) y operacional (como funciona el programa). Esta estrategia se basa en la observación de los objetos del Dominio del Problema y la información de tiempo de ejecución. BORS tiene tres pasos claramente definidos: Detectar las funciones relacionadas con cada objeto del Dominio del Problema: consiste en descrubrir los objetos del Dominio del Problema y sus interfaces. La primer tarea se lleva

148 CAPÍTULO 6. ESTRATEGIAS PARA INTERCONCETAR DOMINIOS 142 Figura 6.5: Estrategias para Explicar los Aspectos del Sistema a cabo observando la salida del sistema. La segunda puede ser tan simple como leer el código fuente o tan compleja como aplicar estrategias de detección de tipos de datos abstractos. Todas las funciones seleccionadas en este paso se almacenan en una lista. Construir un fe-tree con las funciones usadas en tiempo de ejecución: usa la información de tiempo de ejecución para construir el fe-tree. Esta información se recupera empleando una aproximación similar a la explicada en la sección Explicar las funciones encontradas en el paso 1 usando el árbol construído en el paso 2: este paso se implementa aplicando un recorrido por niveles sobre el fe-tree. Cuando el nombre del nodo visitado concuerda con algún nombre en la lista de funciones construída en el paso 1, BORS reporta el camino desde la raíz hasta el nodo corriente y el subárbol correspondiente. La Figura 6.5 ilustra este procedimiento. Sobre la izquierda está el fe-tree correspondiente a la ejecución de un sistema hipotético. Sobre la derecha, se encuentra la lista que contiene las funciones seleccionadas por el programador. En esa Figura, el lector puede observar la explicación y el contexto para cada función.

149 CAPÍTULO 6. ESTRATEGIAS PARA INTERCONCETAR DOMINIOS 143 Requerimientos de Implementación Para implementar BORS se necesita: Definir estrategias que asocien los objetos del Dominio del Problema con funciones: esta tarea tiene dos pasos importantes: Seleccionar los objetos del Dominio del Problema. Detectar sus interfaces. En el primer ítem, el programador decide cuales objetos del Dominio del Problema quiere estudiar. Este paso es obviamente observacional. En el segundo, se asocian las funciones del sistema con cada objeto seleccionado en el primer paso. En este caso, se pueden utilizar estrategias tales como: Técnicas de búsqueda; Detección de tipos de datos abstractos; Agrupación de funciones; etc. Crear un Esquema de Instrumentación de Código: este ítem es importante porque permite recuperar información dinámica del sistema. Proponer técnicas para resumir información: la información recuperada por las técnicas de análisis dinámico suele ser enorme. Para facilitar el procesamiento de información, se necesita la aplicación de estrategias que posibiliten la extracción de la información más relevante sin perder demasiada semántica. Implementar un procedimiento para construir un fe-tree: el fe-tree es una estructura de datos escencial para el funcionamiento de BORS. El esquema usado para extraer la información dinámica debe proveer todos los datos necesarios para construir esta estructura Análisis Comportamental Otra aproximación interesante para alcanzar una relación comportamental-operacional consiste en: i) Reproducir cada comportamiento del sistema; ii) Registrar las operaciones realizadas y iii) Procesar la información con el objetivo de recuperar conocimiento. Por una parte, es posible la utilización de una aproximación similar a la descripta en la subsección para recuperar las operaciones del sistema. Por la otra, el programador debe ejecutar el sistema y usar todas sus funcionalidades. Para cada funcionalidad, se registra cada traza de ejecución y se asigna a cada una de ellas un nombre semántico (ver Figura 6.6). Cuando se realizan todas las

150 CAPÍTULO 6. ESTRATEGIAS PARA INTERCONCETAR DOMINIOS 144 Figura 6.6: Análisis de Trazas de Ejecución tareas explicadas previamente se aplican técnicas de análisis del flujo de ejecución de las funciones que posibiliten la extracción de la información más relevante. Con el procedimiento descripto previamente, el programador tiene solamente las funcionalidades del sistema aisladas con las componentes del programa asociadas. El lector puede observar que esta es una clase de relación entre los Dominios del Problema y Programa. Sin embargo, es posible mejorar esta correspondencia a través de la introducción de representaciones del Dominio del Problema, como por ejemplo los Mapas Conceptuales decorados con las funciones del sistema que implementan cada concepto. Para clarificar esta idea, asuma que el sistema de estudio es un editor de textos básico y que su mapa conceptual es el que se muestra en la Figura 6.7. Después (antes o al mismo tiempo) de la construcción de la representación el programador puede ejecutar el sistema instrumentado para concretizar cada concepto. En otras palabras, el programador usa el sistema para: Escribir; Abrir archivos; etc. Para cada operación, se registran las trazas de ejecución y esta información se asocia a cada concepto. El resultado es una representación del Dominio del Problema decorada con las componentes del programa empleadas para llevar a cabo cada concepto. El lector puede percibir que la relación comportamental-operacional es más fuerte que la previa. El mismo procedimiento se puede aplicar usando herramientas estándares de ingeniería tal como los Diagramas de Caso de Uso de UML o el Modelos de Dominio. La ventaja de esta aproximación es que los resultados obtenidos se integran con más facilidad a los proyectos de desarrollo de software. Requerimientos de Implementación La implementación de este esquema basicamente requiere de:

151 CAPÍTULO 6. ESTRATEGIAS PARA INTERCONCETAR DOMINIOS 145 Figura 6.7: Mapa Conceptual de un Editor de Texos Básico Técnicas de recuperación de las trazas de ejecución. Estrategias de extracción de información estática que brinden información más precisa de los datos reportados por el análisis dinámico. Una herramienta de Modelación Conceptual. Esta aplicación se puede implementar como parte de una HCP, en este caso tal vez sea posible asociar los elementos conceptuales con las componentes del programa automáticamente. No obstante, existen interesantes aplicaciones de modelación conceptual que son fáciles de usar y entender. Si se selecciona esta última opción es importante elegir una herramienta cuya salida se integre facilmente con otras aplicaciones Conclusión En este punto del desarrollo de esta tesis doctoral se está en condiciones de elaborar vistas que simplifiquen la comprensión de sistemas. Esta afirmación se fundamenta en las temáticas abordadas en los capítulos 2 hasta el 5 donde se describen las condiciones cognitivas y de visualización necesarias alcanzar este objetivo. En este capítulo se estudió el tema de la Interconexión de Dominios como una estrategia relevante e innovadora que vincula diferentes aspectos del sistema y aumenta las posibilidades de comprensión. Esta temática se desarrolló de la siguiente manera: Se presentó una técnica denominada Interconexión de Dominios por Capas cuyo objetivo es

152 CAPÍTULO 6. ESTRATEGIAS PARA INTERCONCETAR DOMINIOS 146 facilitar la inspección de software a través de la vinculación de perspectivas tradicionales. Se describieron tres estrategias para interconectar los Dominios del Problema y Programa que se basan en la combinación de información estática y dinámica del sistema. A continuación se resumen las principales características de cada una de ellas. SVS (Simultaneous Visualization Strategy) es una estrategia que recupera la relación entre los Dominios del Problema y Programa por medio de la utilización de: Un proceso de instrumentación de código. La ejecución paralela del sistema de estudio y un monitor que informa las componentes del programa utilizadas para producir la salida. BORS (Behavioral-Operational Relation Strategy), realiza una tarea similar a SVS pero después de la ejecución del sistema. BORS emplea los mismos recursos que SVS aunque de una manera diferente porque requiere que el programador ejecute el sistema para un escenario específico. Luego de realizada esa tarea, analiza la información estática y dinámica utilizando ciertas estructuras de datos que proporcionan información de las relaciones existentes entre las componentes del sistema. Finalmente, el Análisis Comportamental permite relacionar los Dominios del Problema y Programa por medio de la elaboración de representaciones conceptuales decoradas con la información dinámica recuperada por las técnicas de análisis dinámico. Para finalizar, es importante notar que las estrategias presentadas en este capítulo dan una respuesta concreta al problema presentado en el capitulo 1 mostrando que es posible relacionar dominios estándares y complejos usando análisis estático tradicional e instrumentaciones de código.

153 Capítulo 7 Extracción de la Información 7.1. Introducción Método, Constancia, Disciplina, Confianza y Coraje son características escenciales para alcanzar objetivos Mario El camino seguido para resolver el problema de facilitar la comprensión de grandes sistemas, declarado en el capítulo 1, consistió en: Definir una conceptualización de Comprensión de Programas (CP) con la finalidad de detectar las áreas directamente relacionadas con el desarrollo de aplicaciones de comprensión. Proponer un modelo, basado en conceptos de Modelos Cognitivos, para la construcción de aplicaciones de CP. Identificar las estrategias no implementadas en las Herramientas de Comprensión de Programas (HCP) actuales. Estudiar varias formas de visualizar la información extraída desde el software. Elaborar estrategias para interconectar dominios tradicionales e innovadores. Este capítulo presenta un conjunto de técnicas de extracción de la información estática y dinámica necesaria para la implementación de las estrategias de cognición, visualización e interconexión de dominios definidas en esta tesis doctoral. Para la extracción de la información estática se usaron técnicas 147

154 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 148 de compilación tradicionales [ASU86, Bac79]. Para la recuperación de la información dinámica se definió una estrategia de instrumentación de código [EKS01]. De esta forma, se completa el último paso para resolver el problema mencionado al inicio de esta introducción (ver capítulo 1) [LF94] Extracción de Información desde el Dominio del Problema Es siempre posible extraer información detallada desde el Dominio del Programa porque sigue reglas clarametne definidas. Desafortunadamente, no sucede lo mismo con el Dominio del Problema porque la información relevante y su organización depende de la aplicación. Para eliminar esta dificultad, las aproximaciones de Ingeniería de Software (IS) exploran varias fuentes de información informal (como por ejemplo: Documentación del Sistema; Comentarios de Programas; Análisis de Entrevistas; etc.) utilizando Técnicas de Extracción de la Información Informal con el propósito de deducir algunas características del sistema. La principal desventaja de esos métodos es que no proporcionan un mecanismo automatizado que relacione los Dominios del Problema y Programa. De esta manera, el programador debe vincular los conceptos del Dominio del Problema con las componentes del programa consumiendo recursos que dificultan el normal progreso de los proyectos de software. El capítulo 6 menciona al Análisis Comportamental (AC) como una posibilidad para interconectar ambos dominios. En esta estrategia, el usuario ejecuta el sistema con el objetivo de alcanzar una relación entre el comportamiento del programa y su operación de una forma semiautomatizada. Para aplicar AC se deben considerar los siguientes aspectos: La definición del formalismo para especificar el comportamiento del sistema. La información que se debe extraer desde el sistema. Considerando el primer ítem se puede afirmar que los Mapas Conceptuales [NG84, Aus91] o Modelos de Dominio son herramientas muy apropiadas para especificar el Dominio del Problema (ver el capítulo 6 para obtener más detalle sobre esta temática). Teniendo presente el segundo se puede decir que una técnica de Instrumentación de Código, como la definida en la en este capítulo, permite recuperar las funciones (y, si se especializan las estrategias, sus atributos) usadas en tiempo de ejecución [ZAS05]. De esta manera, existe un enlace explícito entre los Dominios del Problema y Programa, porque un conjunto de funciones se puede asociar con cada concepto. Es importante destacar que las Técnicas de Extracción de la Información Informal son útiles para complementar el AC porque proporcionan información con más semántica. Esta característica posibi-

155 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 149 lita que el programador ejecute el sistema conociendo sus funcionalidades facilitando, de esta manera, AC. En otro caso, debe aprender a manejar el sistema desde el inicio (sin conocimiento previo) lo cual consume mucho tiempo y esfuerzo Extracción de la Información desde el Dominio del Programa En esta sección, se exponen algunas estrategias de extracción de la información para: La construcción de vistas del sistema tradicionales como las que se mencionaron en el capítulo 5. La recuperación de la información necesaria para la implementación de las estrategias de Interconexión de Dominios descriptas en los capítulos 5 y 6. En las siguientes subsecciones se especifican las estrategias de extración de la información estática y dinámica para cada uno de los casos mencionados previamente [BWC05] Construcción de Vistas Estáticas del Sistema Esta sección describe los pasos requeridos para construir vistas estáticas que facilitan la inspección del sistema de estudio. El objetivo principal es especificar y presentar un panorama general de los factores que se deben tener presente para la implementación de vistas estáticas. Grafo de Funciones El Grafo de Funciones (GF) es una representación tradicional de programas provistas por muchas HCP, porque: El mapeo entre los objetos del programa y los del grafo es directo. Provee una forma fácil de inspeccionar el sistema de estudio. GF se define como: GF = (P, E)

156 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 150 donde: P = {x / x es una función del sitema} y E = {(x, y) / x P y P x llama a y} GF se conceptualiza facilmente pero generalmente su construcción es compleja. Los próximos párrafos describen los pasos y problemas asociados con la cosntrucción del GF. Además, se explican algunas estrategias para resolver las dificultades. Caso Normal: en esta situación no se encuentran construcciones obscuras del lenguaje de programación que dificulten la obtención de la relación llamador-llamado. En estas circunstancias, GF se construye, a través de técnicas de análisis estático [WM96], de la siguiente manera: Se recuperan las definiciones 1 (llamador) e invocaciones (llamado) de las funciones. Se salvan los pares (llamador, llamado) en una estructura de datos (que se usa para representar GF) que provea una complejidad temporal y espacial aceptable. Es importante notar que los pasos mencionados en los ítems previos se deben realizar para cada módulo del sistema. Manipulación de Funciones Complejas: desafortunadamente, los lenguajes de programación tienen algunos mecanismos complejos de invocación de funciones que dificultan la extracción de GF. Cuando una función tiene otras funciones como sus parámetros, la estrategia de análisis estático se debe especializar para evitar la pérdida de algunas instancias de la relación llamador-llamado. La situación se ilustra claramente en la Figura 7.1 donde existe una conexión entre la función f y g pero no es posible su detección si la estrategia de análisis estático no inspecciona los parámetros de la función llamador y sus posibles invocaciones. Además, existe una conexión incorrecta entre las funciones f y w porque w no es una función del sistema. Este último problema se puede evitar pasando dos veces un analizador sintáctico al código fuente. En la primer pasada, se recuperan todas las funciones del sistema y almacenan en una estructura de datos. En la segunda, se analiza la relación llamador-llamado verificando si los nodos (funciones) y arcos (llamadas) realmente representan funciones e invocaciones entre ellas. Esta tarea se lleva a cabo consultando la estructura de datos construida en la primer pasada. 1 Con recuperar las definiciones se hace referencia a analizar la definición de la función y recuperar su nombre.

157 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 151 Figura 7.1: El problema de las funciones como parámetros El problema puede ser aún más dificil, considere el caso cuando los parámetros de la función son punteros a funciones como se muestra en la Figura 7.2. En esas situaciones, el análisis estático, además de considerar la inspección de parámetros, necesita analizar las posibles invocaciones a funciones por medio de punteros. En otras palabras, es necesario ingresar en el complejo mundo del análisis de los punteros a. La situación descripta en los párrafos precedentes puede ser todavía más problemática si las funciones referenciadas por punteros tienen, a su vez, funciones o punteros a funciones como sus parámetros (ver Figura int f(int x, inf (*g)(char,float)) {... (*g)(valuechar, valuefloat);... } 7.3 para entender claramente la complejidad que introducen los Figura 7.2: Problema de los Punteros a

158 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 152 int f(int x, inf (*g)(char,float (*p)(int,int))) {... (*g)(valuechar, valuefloat); /* Sentencias necesarias para invocar a la función referenciada por p*/... } Figura 7.3: Problema de los Punteros a punteros). El análisis presentado previamente permite concluir que esta clase de estudio es muy importante pero al mismo tiempo muy complejo. La conclusión principal es que el análisis estático debe ser tan completo como sea posible evitando complejidades excesivas. Esto se debe a que esta aproximación es muy útil para analizar el Dominio del Programa pero no proporciona ventajas significativas para elaborar estrategias destinadas a alcanzar el objetivo primordial, el cual es: Interconectar los Dominios del Problema y Programa. Grafo de Dependencia de Módulos El Grafo de Dependencia de Módulos (GDM) es otra vista del sistema interesante. La interdependencia de módulos se puede establecer de tres maneras: Funciones, Tipos y Datos. La siguiente definición formaliza esta afirmación usando la Teoría de Grafos [GY99]. GDM=(P,E 1, E 2, E 3 ) donde: P = {x / x es un módulo del sistema} y E 1 = {(x, y)/x P y P x y x usa una función definida en y} E 2 = {(x, y)/x P y P x y x usa un tipo definido en y} E 3 = {(x, y)/x P y P x y x usa un dato definido en y} En los párrafos siguientes se describen, en términos generales, algunas estrategias para construir los diferentes tipos de GDM.

159 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 153 Dependencia de Módulos a través de Funciones: GDM a nivel de funciones se puede construir a partir de GF 2 utilizando el procedimiento que se describe a continuación. 1. Para cada arco de GF se recupera los módulos correspondientes al nodo fuente y destino, sean mf y md esos módulos. 2. Si mf y md no están en GDM entonces se insertan en el grafo. 3. Se crea un arco desde mf a md (note que se respeta la orientación proporcionada por GF) y se inserta en GDM. Grafo de Dependencia de Módulos a través de Tipos: la construcción de GDM a nivel tipos se puede realizar de la siguiente manera: 1. Para cada módulo m del sistema se realizan las siguientes acciones a) Se crea un nodo para m y se inserta en GDM. b) Se recuperan todas las definiciones de tipos encontradas en m y se registran en una estructura de datos como una dupla (m, tipo). 2. Para cada módulo m del sistema se realizan las siguientes actividades: a) Para cada tipo no definido en m se accede a la estructura de datos construida en el paso 1.b y se recupera el módulo asociado, sea ma ese módulo. b) Se crea un arco desde m a ma y se inserta en GDM. Grafo de Dependencia de Módulos a través de Datos: se utiliza la misma estrategia que la empleada para construir GDM a nivel tipos. Grafo de Tipos El Grafo de Tipos (GT) se construye a través del análisis de las construcciones struct y typedef porque son los mecanismos usuales que provee el lenguaje de programación para definir tipos y relaciones asociadas a ellos [J.08]. El GT se define a continuación: GT = (P, E) 2 En este caso, cada nodo de GF debe contener un atributo que indique el nombre del módulo donde la función fue definida.

160 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 154 donde: P = {x / x es un tipo} y E = {(x, y) /x P y P el tipo x se utiliza en la definición del tipo y} Para llevar a cabo esta tarea se deben considerar los siguientes puntos: 1. Los nombres de las construcciones typedef y struct son los nodos de GT. 2. Si el objeto bajo análisis (tipo) es un typedef entonces se seleccionan los tipos definidos por el programador 3 y se crean arcos desde ellos al tipo analizado 4. En otro caso, la definición typedef relaciona tipos primitivos con uno definido por el programador. Esta última clase de conexión no se registra en GT. 3. Si el objeto bajo análisis es una construcción struct entonces se debe analizar cada componente. En este caso, pueden aparecer las siguientes situaciones: a) Si el tipo de la componente es un tipo primitivo, entonces la dependencia de tipos no se registra. b) Si el tipo de la componente fue definido por el programador entonces se deben conectar los tipos base y el corriente Construcción de Vistas Dinámicas Otra forma de caracterizar a los sistemas es por medio de la información usada en tiempo de ejecución. Una forma de llevar a cabo esta tarea consiste en insertar dentro del código fuente funciones que permitan conocer las operaciones internas realizadas por el sistema de estudio. Estas funciones se deben incorporar en lugares estratégicos dependiendo del tipo de caracterización que se desee hacer del sistema. Para ejemplificar la contrucción de esta clase de vistas se asumirá que: i) El sistema de estudio se modifica insertando funciones al inicio y al final de cada una de sus funciones y ii) Es posible controlar la cantidad de veces que se registran las funciones. En las secciones siguientes, se describen un conjunto de vistas dinámicas que se emplearán en esta tesis doctoral para la implementación de las estrategias de Interconexión de los Dominios del Problema y Programa. 3 Hace referencia a los tipos definidos por el programador encontrados en la definición typedef. 4 Tipo analizado se refiere al tipo que define el typedef bajo análisis.

161 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 155 INPUT k INPUT f OUTPUT f INPUT g OUTPUT g INPUT h OUTPUT h OUTPUT k Figura 7.4: Secuencia de Ejecución de Funciones de un Sistema Árbol de Ejecución de Funciones Como se describió en el capítulo 6 las funciones se pueden representar utilizando el Árbol de Ejecución de Funciones (en el capítulo 6 se encuentra la definición de esta estructura de datos). La información que se necesita para el proceso de construcción consiste en la detección del inicio y fin de cada una de las funciones invocadas por el sistema para un propósito particular. Si el sistema se modifica como se describió en la introducción de esta sección, el resultado producido por las funciones de inspección para un sistema específico contendrá una secuencia de cadenas de caracteres similar al mostrado en la Figura 7.4. Con esta información disponible, el procedimiento para la construcción del Árbol de Ejecución utiliza una pila y procede como sigue: 1. Se inicializa la pila P en vacío 2. Si la cadena de entrada es INPUT nombre se realizan las siguiente operaciones: Se crea un nodo cuyo nombre está dado por la cadena nombre, sea n ese nodo. Se conecta n con el nodo que se encuentra en el tope de la pila. Note que si la pila está vacía el nodo actual es la raíz del árbol. Insertar n en la pila 3. Si la cadena de entrada es OUTPUT nombre se elimina el tope de la pila. 4. Si la pila no está vacía ir al paso 2. La Figura 7.5 muestra el árbol de ejecución correspondiente a la traza de ejecución 7.4 construído utilizando las operaciones detalladas con anterioridad.

162 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 156 Figura 7.5: Construcción del Árbol de Ejecución de Funciones El lector puede observar que el proceso de construcción es sencillo, sin embargo la complejidad radica en las modificaciones que se deben hacer sobre el sistema para obtener la información dinámica necesaria para la construcción del árbol. Dichos problemas serán estudiados en la sección 7.5. Grafo de LLamadas a Funciones Dinámico Esta vista se construye utilizando la misma información que la empleada para la construcción del Árbol de Ejecución. El procedimiento de construcción utiliza una pila y se describe a continuación: 1. Se inicializa la pila P en vacío 2. Si la información recibida es INPUT nombre se realizan las siguientes operaciones: Se busca un nodo en el grafo cuyo nombre sea nombre Si el resultado de la búsqueda es exitoso entonces sea n dicho nodo. Conectar n con el nodo que se encuentra en el tope de la pila. Insertar n en la pila Si la búsqueda no fue exitosa entonces: Crear un nodo cuyo nombre esta dado por la cadena nombre, sea n ese nodo.

163 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 157 Conectar n con el nodo que se encuentra en el tope de la pila 5. Insertar n en la pila 3. Cuando se recibe la cadena OUTPUT nombre se elimina el tope de la pila. 4. Si la pila no está vacía ir al paso 2. El lector puede observar que el procedimiento de construcción del grafo es sencillo pero, al igual que el caso del Árbol de Ejecución de Funciones, la complejidad radica en las modificaciones que se deben realizar en el sistema para recuperar la información necesaria para construir esta estructura de datos. Grafo de Comunicaciones de Módulos Dinámico Si la información dinámica además de reportar las funciones ejecutadas por el sistema informa los módulos a los cuales dichas funciones pertencen, entonces el procedimiento de construcción de esta vista es sencillo. Si se desea construir un Árbol de Módulos usados en Tiempo de Ejecución, entonces se emplea la misma estrategia que la utlizada para el Árbol de Ejecución de Funciones con la variante que los nombres de los nodos se corresponden con los módulos del sistema. Si se desea construir un Grafo de Comunicaciones de Módulos, entonces se emplea la misma estrategia que la utilizada para construir el Grafo de Funciones Dinámico 6 con la variante que los nombres de los nodos se corresponden con los módulos del sistema Otras Consideraciones A continuación se mencionan algunas consideraciones importantes que se deben tener en cuenta cuando se construyen vistas como las expuestas en las secciones previas. Es posible usar Técnicas de Análisis Dinámico para resolver los problemas presentados por las invocaciones a funciones por medio punteros cuando se desea construir el Grafo de Funciones [Lie07, WB07]. La idea consiste en insertar sentencias útiles al comienzo y fin de cada función 5 Note que si la pila está vacía el nodo corriente es el acceso a la estructura. 6 Es importante notar que la aplicación de esta aproximación puede generar muchos loops en el Grafo de Comunicaciones de Módulos debido a que es altamente probable que las funciones definidas en un módulo específico se invoquen entre si. En este caso esos arcos se pueden ignorar.

164 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 158 que permitan conocer las funciones usadas en tiempo de ejecución. Esta propuesta disminuye la cantidad de arcos no recuperados por las Técnicas de Análisis Estático porque la estrategia reportará todas las funciones usadas por el sistema y por consiguiente se podrá completar el Grafo de Funciones. Esta aproximación es interesante porque se puede usar para implementar las estrategias de interconexión de dominios definidas en el capítulo 6. Además, es simple y se puede modificar para extraer más información de los objetos de software (ver sección 7.5). La desventaja principal de esta técnica es que solamente se reconocen algunas invocaciones de funciones por medio de punteros a porque la recuperación depende de los casos de prueba realizados al sistema. A modo de ejemplo, el lector puede observar que la conexión perdida en la Figura 7.1 se recupera usando este esquema. Si el sistema se ejecuta, las sentencias ubicadas al comienzo y fin de cada función indicarán cuales son las funciones usadas y sus relaciones. Particularmente, se detectará la conexión entre las funciones f y g. Porsuspuesto, existen más consideraciones relacionadas con el uso real de este esquema, pero debido a su importancia en el contexto de este trabajo de doctorado, la descripción completa de la estrategia y los casos específicos relacionados con ella serán detallados en las próximas secciones. La combinación de las estrategias estáticas y dinámicas presentadas en este capítulo posibilita la creación de las siguientes vistas híbridas: Grafo de Dependencias de Módulos decorado con los módulos utilizados en tiempo de ejecución. Grafo de Funciones decorado con las funciones usadas en tiempo de ejecución. Grafo de Tipos anotado con los tipos usados en tiempo de ejecución. Decorar todos los grafos descriptos en este capítulo con valores de métricas: Importancia del Objeto, Consumo de Memoria, Tiempo Computacional, etc. etc Extracción de la Información para la Implementación de las Estrategias de Interconexión de los Dominios del Problema y Programa Algunas técnicas definidas en el capítulo 6 ensayan construir la relación entre los Dominios del Problema y Programa después de la ejecución del sistema.

165 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 159 La idea principal consiste en abastecer a las estrategias de extracción de información dinámica con la información estática necesaria para que las mismas puedan realizar su trabajo. Este es el caso de la estrategia BORS, definida en el capítulo 6, esta técnica requiere los nombres de las funciones que se desean explicar para la aplicación de un conjunto de procedimientos (ver Capitulo 6) que relacionan los Dominios del Problema y Programa. En esta sección, se describen dos propuestas para extraer información estática para el análisis post mortem realizado por BORS. La primera, la Técnica del Grep, busca información por concordancia sintáctica. La segunda, es una estrategia que intenta recuperar tipos de datos abstractos Técnica del Grep La Técnica del Grep 7 es una aproximación simple y muy útil para recuperar los nombres de los objetos de software. Para llevar a cabo esta tarea, el programador debe ejecutar el comando grep con el nombre del objeto y los archivos que desea inspeccionar. El resultado será un conjunto de cadenas de caracteres donde cada cadena contiene el nombre del objeto de entrada como una subcadena. Esta estrategia se puede usar para el análisis post mortem a nivel funciones siguiendo los pasos mencionados a continuación: 1. Se deben almacenar en un archivo todas las funciones del sistema. 2. El usuario debe observar el comportamiento del sistema y seleccionar los objetos del Dominio del Problema que quiere estudiar. 3. Se debe invocar el comando grep con el nombre de los objetos indicados en el paso 2 y el archivo creado en el paso El resultado obtenido en el paso 3 es un conjunto de funciones que se utilizan como entrada a la estrategia BORS definida en el capítulo 6. Es importante notar que esta propuesta presenta el problema de recuperar información no relacionada con los objetos del problema de estudio. Esto se debe a que el proceso de búsqueda se lleva a cabo por concordancia sintáctica y por consiguiente se pierde mucha información semántica. 7 El comando grep es provisto por Sistemas Operativos tales como: Unix, Linux, etc.

166 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN Detección de Tipos de Datos Abstractos La estrategia de extracción de Tipos de Datos Abstractos Definidos por el Usuario (TDAU) descripta en esta sección recupera todas las definiciones struct y typedef encontradas en el sistema y luego asocia funciones con cada una de ellas [GKS95, CCMT93]. Para extraer esta información, la estrategia usa una tabla de símbolos construída por medio del análisis estático. Con esta información, la estrategia construye un Grafo de Tipos (GT) del sistema como el definido en la sección procedimiento para extraer los TDAU y aplica un La estrategia analiza cada signatura de función, usa GT y se basa en el análisis de como el programador construye un sistema usando el concepto de TDA. Antes de describir este procedimiento, se introducirán algunas definiciones necesarias para explicar la técnica. Definición 1 : Sea t un tipo y GT=(P,E) 8 el grafo de tipos del sistema de estudio entonces el ideal izquierdo de t denotado por Id GT,t se define como sigue: Id GT,t = {k/k P somep ath(k, t)} 9 Definición 2 : Sea S un conjunto de tipos y GT=(P,E) el grafo de tipos del sistema de estudio, S P. El ideal izquierdo de S, denotado como IdS GT,S se define como sigue: IdS GT,S = w S Id GT,w Definición 3 : Sea t un tipo y GT=(P,E) el grafo de tipos del sistema de estudio, t es un tipo maximal si N Rt = 0, donde N Rt denota los vecinos derechos del nodo t en GT=(P,E). En otras palabras un tipo t es maximal en GT=(P,E) si no tiene vecinos derechos o equivalentemente si su grado de salida es 0. Definición 4 : Sea t un tipo y GT=(P,E) el grafo de tipos del sistema de estudio, t es un Tipo Dominante (TD) en GT=(P,E) si t es maximal. 8 P representa el conjunto de nodos de GT=(P,E) y E una relación definida sobre los elementos de P. 9 La función somepath(k,t) determina la existencia de un paso entre los nodos k y t.

167 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 161 Definición 5 : Sea t r f(p 1,..., p n ) una función del sistema de estudio. El conjunto de tipos usados por la función f, denotado f t, está formado por el tipo de retorno (t r ) y los tipos de sus parámetros denotados como t pi, 1 i n. Definición 6 : Sea t r f(p 1,..., p n ) una función del sistema de estudio, y sea f t el conjunto de tipos usados por f. El subgrafo de GT=(P,E) inducido por la función f denotado GT f = GT ft. GT f se define como sigue: GT f = (P, E ) con: P = P GT IdSGT,ft E = E GT {(x,y)/ x P y P (x,y) E T G } donde el operador W s denota la restricción de W al conjunto S. La Figura 7.6 muestra un GT=(P,E) para algún sistema. Este grafo tiene tres tipos maximales {t1,t8,t9}. El ID GTt1 es {t1,t2,t3,t4,t5}. El Id GT,S donde S={t1,t9} es P GT {t8}. Si se analizan dos funciones f y g y los tipos usados por f son {t1,t2,t3,t4} y los empleados por g son {t9,t6,t7}, entonces GT f = (P, E ) donde P ={t1,t2,t3,t4} y E = {(t4,t1),(t3,t1),(t2,t1)} y GT g = (P, E) donde P ={t9,t6,t7} y E = {(t6,t9),(t7,t6)}. Los tipos dominantes para f y g son t1 y t9 respectivamente. Ahora es el momento de retornar al problema de asociar funciones con datos para la extracción de los TDAs. Las funciones tienen los siguientes puntos de análisis: 1. Los tipos de los parámetros. 2. El tipo de retorno.

168 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 162 Figura 7.6: Grafo de Tipos para algún sistema 3. Uso de variables globales y locales. cada elemento se analiza usando el GT=(P,E). Sea f la función bajo análisis, la estrategia contempla los siguientes casos: 1. f t no contiene TDAU y f usa sólo tipos primitivos. En este caso, la estrategia no puede decidir el TDAU correcto, porque la función no provee información. 2. f t no contiene TDAU pero f : a) Accede a variables globales cuyos tipos han sido definidos por el programador. En este caso, la función se puede pensar como una función con parámetros como se muestra a continuación: struct node n; int f (char *a, int b) { int f (struct node *n, char a, int b) { //alguna referencia a la //variable global n... n->a=a; } } b) Accede a variables locales cuyos tipos han sido definidos por el programador y no usa variables globales. Esta situación se trata de la misma forma que el ítem 1.

169 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 163 int f (char *a, int b) { int f (struct node n, char a, int b) { struct node n; n->a=a; } } c) Accede a variables locales y globales cuyos tipos han sido definidos por el programador. Este caso es una combinación de los presentados en los ítems 1 y 2. Todas las situaciones planteadas previamente se consideran en 3 o f t t 10 rf es un single que consta de un TDAU. En este caso la función se asocia a ese TDAU. 4. f t t 11 rf consta de dos o más TDAU. En esta situación la estrategia realiza las siguientes operaciones: 12 a) Construye GT f b) Computa TD. Si TD es un single entonces la función se asocia con el elemento contenido en TD. En otro caso, no es posible establecer una ligadura de tipos. 5. f t es un single que consta de f 13 tr. En este caso se deben considerar las siguiente alternativas: a) El elemento de f t es un tipo primitivo y f no accede a variables globales. En esta circunstancia, no se puede realizar ninguna asociación de tipos. b) El elemento de f t es un TDAU entonces f se asocia con el elemento de f t. c) El elemento de f t es un tipo primitivo pero f usa variables globales, locales o ambas. Este es un caso particular de la situación descripta en 2. En los párrafos siguientes se muestra el funcionamiento de la estrategia usando un simple ejemplo. Considere las siguientes estructuras: 10 t rf denota el tipo de retorno de la función f. 11 t rf denota el tipo de retorno de la función f. 12 La construcción de GT f se realiza considerando solamente los TDAU encontrados en f t t rf. Los tipos restantes (es decir los primitivos) se descartan. 13 En otras palabras el único TDAU de f t es el tipo de retorno de la función.

170 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 164 struct F { struct E { /*Algunas declaraciones para F*/ /*Algunas declaraciones para E*/ } } struct D { struct C { /*Algunas declaraciones para D*/ /* Algunas declaraciones para C */ struct F *f; } struct E *e; } struct B { struct A { /*Algunas declaraciones para B*/ /*Algunas declaraciones para A*/ } struct B *b; struct C c; } la Figura 7.7 muestra el grafo de tipos correspondiente a esas declaraciones. Figura 7.7: Grafo de Tipos para la declaración de las estructuras Sean los siguientes prototipos de funciones: struct A func1 (struct B) { cuerpo de func1} struct C func2 (int a) {cuerpo de func2} void func3 (struct A a, struct D d) {cuerpo de func3} void func4() {struct A a; cuerpo de func4}

171 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 165 func1 usa los TDAU A y B pero A es el tipo de retorno de func1. En este caso la estrategia asocia func1 al tipo B usando el paso 3. func2 usa sólo un TDAU entonces la estrategia asocia este tipo usando el paso 5. func3 usa dos TDAU A y D. Esta situación se considera en el paso 4. Por definición 5, el conjunto de tipos de func3 está formado por los tipos {A,D}, el GT func3 = (P, E) donde P={A,D} y E={} y por definición 1 el conjunto TD es {A,D}. Como TD tiene dos elementos la estrategia no puede decidir el tipo para esta función. func4 no tiene parámetros esta situación se considera en el paso 5. En este caso func4 se analiza como si su definición fuese void func4(struct A a), esta situación se describe en la fase 3. Por consiguiente, el tipo seleccionado para func4 es A Análisis Dinámico: Instrumentación de Código En esta sección, se define una técnica para la recuperación de información relacionada con el flujo de ejecución del programa denominada Instrumentación de Código [WQPC05]. Esta técnica consiste en la inserción automática, dentro del código fuente, de sentencias que permiten conocer alguna característica del comportamiento interno del sistema. En las siguientes subsecciones se explicará la técnica de instrumentación y su utilidad Instrumentación de Funciones La estrategia usada para instrumentar las funciones del sistema consite en insertar funciones de inspección dentro del código fuente. Esas funciones tienen como finalidad capturar el flujo de ejecución del programa y otra información que el usuario desee conocer. Para llevar a cabo esta tarea se deben tomar dos decisiones importantes: Cuáles son los puntos de verificación? Qué información se debe recuperar para conocer el flujo de ejecución del programa a nivel funciones? Por una parte y después del análisis y elaboración de las estrategias para interconectar los Dominios del Problema y Programa, fue posible identificar que los puntos de interés para realizar los chequeos

172 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 166 int f (int x, int y) int f (int x, int y) { { float z,y; float z,y; /* declaraciones */ /* declaraciones */... INPUT_INSPECTOR("f"); /* acciones */... return value... } /* acciones */ OUTPUT_INSPECTOR("f"); return (value); } (a) (b) Figura 7.8: Instrumentación de Función son el comienzo y fin de cada función. Esto se debe a que permiten detectar el inicio y fin de las funciones invocadas y esta información, correspondiente al Dominio del Programa, se puede vincular con la representación del Dominio del Problema usando las estrategias definidas en el capítulo 6. En este contexto, cada vez que el sistema comienza su ejecución invoca sus funciones y la primer y última sentencia ejecutada por ellas son las funciones de inspección. Esas funciones pueden inicialmente imprimir el nombre de la función ejecutada y otra información que el usuario quiera conocer, como por ejemplo parámetros, variables globales, etc. Aunque las funciones de inspección insertadas en el final no son estrictamente necesarias, son incluídas en el código fuente porque proporcionan la información requerida para construir algunas estructuras de datos interesantes empleadas por las estrategias que relacionar los Dominios del Problema y Programa descriptas en el capítulo 6. La Figura 7.8.a muestra una definición de función, y la Figura 7.8.b ilustra la trasformación de código después de la inserción de las funciones de inspección. Para instrumentar correctamente las funciones del sistema, el esquema de instrumentación debe considerar los casos que se describen a continuación: Las funciones pueden tener dos o más puntos de salida: la Figura 7.8 describe la mejor situación cuando las funciones tienen un único punto de entrada y un punto de salida. Sin embargo, en sistemas reales, las funciones no siempre poseen esta característica 14. Por ejemplo, las funciones pueden tener dos o más sentencias return, en esos casos la función de inspección 14 Esta característica aparece cuando las sentencias return se encuentran dentro de selecciones e iteraciones o cuando se usan sentencias goto. La instrumentación de sentencias return dentro de selecciones se explica en los ítems siguientes mientras que el caso de las itereraciones y goto no son relevantes porque promueven malas prácticas de programación.

173 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 167 int f (int x, int y) int f (int x, int y) { { /* declaraciones de f*/ /* declaraciones de f*/ /* acciones de f */ /*acciones de f */ if (condición) if (condición) return x+y; OUTPUT_INSPECTOR("f");... return x+y;... } } Figura 7.9: Posibles Errores Semánticos de salida se debe insertar en los lugares donde se encuentran las sentencias return siguiendo un esquema similar al mostrado en la Figura 7.8. Las funciones pueden tener puntos de salida dentro de selecciones e iteraciones: el punto de salida de una función se puede encontrar dentro de selecciones e iteraciones 15. En esas situaciones, el esquema de instrumentación no debe cambiar la semántica del programa ni introducir errores sintácticos. La Figura 7.9.a muestra una función con un punto de salida dentro de una sentencia de selección y la Figura 7.9.b ilustra la transformación como se indicó al comienzo de esta sección. El lector puede percibir que se cambió la semántica de la función. La función f de la izquierda retorna el valor x+y cuando la condición condición es verdadera, pero la función f de la derecha imprime f cuando el valor de la condición condición es verdadera y siempre retorna x+y. Este problema se resuelve transformando la sentencia return en una sentencia compuesta con las acciones necesarias para informar la finalización de la función de estudio (ver Figura 7.10). Esta solución no resuelve todo el problema, se pueden encontrar otras dificultades. La estrategia de instrumentación contempla esos inconvenientes pero los mismos serán explicados en los próximos párrafos y en las subsecciones que describen otras sentencias importantes. Las funciones no tienen un punto de salida explícito: los procedimientos son implementados como funciones en lenguajes tales como C. En esos casos, las funciones no tienen un sentencia return explícita, por esta razón la estrategia de instrumentación debe detectar esas situaciones e insertar las funciones de inspección al final de esas funciones. 15 El uso de sentencias return dentro de las iteraciones no es considerado una buena práctica de programación, por consiguiente es un caso de poco interés desde el punto de vista de las instrumentaciones de código.

174 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 168 int f (int x, int y) int f (int x, int y) { { /* declaraciones de f*/ /* declaraciones de f */ /* acciones de f*/ /* acciones de f */ if (condición) if (condición) return x+y; {... OUTPUT_INSPECTOR("f"); return x+y; }... } } Figura 7.10: Estrategia que evita errores semánticos Si los puntos de salida no están correctamente instrumentados el flujo de control del programa puede no ser correcto: suponga las definiciones exhibidas en la Figura La estrategia de instrumentación transforma las definiciones de la izquierda en las definiciones de la derecha. Si la función f se invoca, el flujo de ejecución recuperado será: Begin f End f Begin g End g El lector puede observar que esta información es incorrecta porque indica que la función g fue llamada después que la función f finalizó su ejecución. Para resolver este problema, se debe especializar la técnica de instrumentación en los puntos de salida. Esta tarea se lleva a cabo transformando la sentencia return en una sentencia compuesta siguiendo los pasos descriptos a continuación: 1. Declarar una variable cuyo tipo es el tipo de retorno de la función. 2. Generar una sentencia de asignación. Esta sentencia tiene en su parte izquierda (lvalue) la variable definida en el paso previo y su parte derecha (rvalue) es la expresión encontrada en la sentencia return. 3. Insertar una función de inspección de salida antes de la sentencia return.

175 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 169 int g (float y) int g (float y) { { //declaraciones de g //declaraciones de g... INPUT_INSPECTOR("g"); //acciones de g //acciones de g return value;... } OUTPUT_INSPECTOR("g"); return value; int f (float x) } { //declaraciones de f int f (float x)... { //acciones de f //declaraciones de f... INPUT_INSPECTOR("f"); return (g(x*2))... } //acciones de f... OUTPUT_INSPECTOR("f"); return(g(x*2)) } Figura 7.11: Errores de Instrumentación de Función

176 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN Cambiar la expresión dentro de la sentencia return por la variable definida en el primer paso. La Figura 7.12 muestra la instrumentación producida por la aplicación de los pasos previos. Cuando la función instrumentada f (definida a la derecha en la Figura 7.12) se invoca la traza de ejecución es: Begin f Begin g Stop g Stop f y este resultado es correcto. La función puede tener puntos de salida explícitos e implícitos: este caso fue extraído a través de la experiencia en instrumentar varios sistemas. La Figura 7.13 muestra una función típica de C con diferentes puntos de salida. La estrategia de instrumentación instrumentará correctamente la sentencia return usada por f. No obstante, si condición1 y condición2 son falsas la función finalizará su ejecución sin una sentencia return explícita. Esta dificultad hará que la técnica de instrumentación no proporcione la información necesaria para las estrategias de interrelación de dominios (ver capítulo 6) porque no registra la finalización de la función. La solución de este problema consiste en insertar siempre una función de inspección de salida al final de cada función Instrumentación de Iteraciones En la práctica, la estrategia de instrumentación de las funciones tiene un problema: el número de funciones registradas puede ser muy grande. Trabajar con todas las invocaciones no es apropiado porque: i) Dificulta la comprensión [Abd05, BMSG07] debido a la sobrecarga de información y ii) La implementación de algoritmos eficientes es muy complicada por la gran cantidad de datos que se manipulan. Este problema emerge cuando las funciones se invocan dentro de las iteraciones. Esta es la razón principal para controlar el número de veces que se deben mostrar las funciones encontradas dentro de este tipo de construcciones de los lenguajes de programación [KGG05, CM07]. Para resolver el problema descripto en el párrafo precedente, se distinguen tres puntos principales en las iteraciones, identificados en la Figura 7.14 por los números 1, 2 y 3. En 1 y 3, se inserta una función de control que inserta/suprime un valor en/desde una pila. En 2, se coloca otra función de

177 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 171 int g (float y) int g(float y) { { /*declaraciones de g*/ INPUT_INSPECTOR("g");... /* declaraciones de g*/ /*acciones de g*/ /* acciones de g*/ return value... } { int nruter; nruter=value; OUTPUT_INSPECTOR("g"); return nruter; } } int f (float x) int f (float x) { { /*declaraciones de f*/ /*declaraciones de f*/... INPUT_INSPECTOR("f"); /*acciones de f*/ /* acciones de f*/ return g(x*2) { } int nruter; nruter=g(x*2); OUTPUT_INSPECTOR("f"); return nruter; } } Figura 7.12: Instrumentación correcta de funciones

178 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 172 void f (int x,...) {... if condición1 return ;... if condición2 return ;... } Figura 7.13: Función con puntos de salida implícitos y explícitos for(inicialización, condición, acción) { acciones 1 for(inicialización; condición; acción) { acciones 2 } 3 } Figura 7.14: Instrumentación de una Iteración For

179 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 173 for(acc1, acc2, acc3) showfunction(valor) showfunction(valor) sentencia; for(acc1, acc2, acc3) for(acc1, acc2, acc3) sentencia; { dec(); showfunction(valor); (a) (b) (c) sentencia; dec(); } showfunction(valor); Figura 7.15: Instrumentación de las Iteraciones - Una Sentencia Compuesta Insertada dentro del Cuerpo de la Iteración control que decrementa el valor encontrado en el tope de la pila. Si este valor es cero, las funciones de inspección de entrada (ubicada en 1 en la Figura 7.14) y salida (ubicada en 2 en la Figura 7.14) no muestran la información asociada a la función. Los párrafos previos presentan una idea genérica de como llevar a cabo la instrumentación de las sentencias de iteración. No obstante, se deben considerar diferentes casos: La iteración puede contener solamente una sentencia dentro de su cuerpo: en esta situación se coloca el cuerpo de la iteración dentro de una sentencia compuesta junto con una invocación a la función dec(). La Figura 7.15.a muestra una sentencia for, y la Figura 7.15.b ilustra el esquema de instrumentación inicial descripto en el comienzo de esta sección aplicado a esta construcción. Claramente, la iteración no está controlada porque ejecuta la sentencia sentencia hasta que acc2 sea falsa. Particularmente, si sentencia es una llamado a una función, las funciones de inspección registrarán muchas veces el comienzo y fin de esa función. La Figura 7.15.c ilustra la forma correcta. En dicha figura se cambió la sentencia sentencia por una sentencia compuesta que contiene sentencia y una invocación a dec(). El lector puede observar que la estrategia para controlar las iteraciones trabaja correctamente. En primer lugar, la función showfunction(valor) coloca en la pila el número de veces que el usuario desea ver las funciones invocadas dentro del la iteración. Después de eso, el cuerpo se ejecuta y la función dec() decrementa el número que se encuentra en el tope de la pila. Cuando este valor llega a cero la función de inspección no muestra la información recuperada. Finalmente, la función showfunction(valor), situada al final de la iteración, elimina el elemento del tope la pila. Las iteraciones pueden encontrarse dentro de selecciones u otras iteraciones: en este caso la sentencia de iteración se coloca dentro de una sentencia compuesta y se aplica el esquema descripto en el ítem previo. La Figura 7.16.a ilustra la situación descripta. La Figura 7.16.b

180 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 174 if condición if condición if condición for (acc1; acc2; acc3) showfunction(valor); { acciones; for(acc1; acc2; acc3) showfunction(valor); { for(acc1; acc2; acc3) acciones; { decvalue(); acciones; } decvalue(); showfunction(valor); } showfunction(valor); } (a) (b) (c) Figura 7.16: Instrumentación de las Iteraciones - Iteraciones encerradas con una Sentencia Compuesta muestra como una forma incorrecta de instrumentar las iteraciones cambia la semántica del programa (realice una comparación entre los códigos presentados en las Figuras 7.16.a y 7.16.b). Finalmente, la Figura 7.16.c revela la forma correcta de llevar a cabo esta tarea (realice una comparación entre los códigos presentados en las Figuras 7.16.b y 7.16.c). El cuerpo de la iteración puede tener sentencias de salto incondicional: dentro de las iteraciones se pueden usar cierta clase de sentencias especiales tales como: break, continue, return y goto. En los próximos párrafos, se describen los pasos requeridos para la instrumentación correcta de las iteraciones cuando en su cuerpo se encuentran este tipo de sentencias. break: el objetivo de la sentencia break es pasar el flujo de control a la primera sentencia después de la iteración. Este efecto no modifica la estrategia de control de las iteraciones porque la próxima sentencia después de la ejecución del break es una función showfunction(valor) que realiza una operación pop sobre la pila de control. De esta manera, se recupera el número de veces que la iteración previa debe mostrar las funciones invocadas en su interior. Este efecto mantiene la intención del esquema de instrumentación de las iteraciones (ver Figura 7.17). continue: un caso diferente aparece con la sentencia continue. El objetivo de esta primitiva es producir un salto incondicional a la condición de la iteración. Esta situación viola la estrategia de control de las iteraciones porque algunas funciones se pueden mostrar muchas veces. La Figura 7.18 muestra el problema expuesto previamente. En la primera iteración, la función f se ejecuta y sus funciones de inspección reportan su nombre porque el valor sobre la pila es mayor que 0. Si el valor de cond es verdadero entonces la función g se ejecuta y sus funciones de inspección hacen la misma tarea que

181 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 175 Figura 7.17: Esquema de Instrumentación de la Sentencia Break Figura 7.18: Esquema de Instrumentación de la Sentencia Continue - Ejecución

182 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 176 for (acc1, acc2, acc3) { { showfunction(valor);... for(acc1, acc2, acc3) continue; { } { dec(); continue; }... dec(); } showfunction(valor); } Figura 7.19: Instrumentación de Iteraciones - Instrumentación de la Sentencia Continue para la función f. Después de la ejecución de g, la sentencia continue produce un salto inconcidional a la condición de la iteración sin decrementar el valor del tope de la pila (Observe la pila (1) de la Figura 7.18). La misma tarea se realiza mientras el resultado de la evaluación de la condición sea verdadero (observe (2), (3) y (4)). En ese momento, las funciones dentro de la iteración ya fueron mostradas cuarto veces en lugar de dos. Después de eso, todos los procesos continuan como se describieron previamente. Para solucionar este problema, es necesario el cambio de la sentencia continue por una sentencia compuesta que contenga: 1. Una invocación a la función dec() que decremente el número que se encuentra en el tope de la pila (ver Figura 7.19). 2. La correspondiente sentencia continue. El lector puede transformar, usando este esquema, el ejemplo presentado en la Figura 7.18 y luego ejecutar el código para verificar que esta estrategia funciona correctamente. return: cuando la sentencia return 16 está dentro de una iteración se debe sustituir con una sentencia compuesta que realize las siguientes operaciones: Suprimir todos los elementos de la pila. Aplicar la transformación expuesta en la sección para la sentencia return. 16 El uso de sentencias return dentro de las iteraciones no es considerada una buena práctica de programación y por consiguiente es de poco interés desde el punto de vista de las instrumentaciones de código.

183 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 177 goto: generalmente las sentencias goto promueven malas prácticas de programación, por esta razón no se consideran en este esquema de instrumentación Instrumentación de las Sentencias de Selección La instrumentación de funciones y la estrategia de control de las iteraciones son importantes porque proveen información de alto nivel y reducen el volumen de los datos. Sin embargo, algunas veces es útil obtener más información que solamente el nombre de las funciones. Por ejemplo, conocer la parte de las sentencia de selección (then o else) que se ejecutó puede ser una ayuda para comprender el comportamiento de funciones específicas. Por esta razón, esta sección tiene como objetivo la descripción de una estrategia para instrumentar esta clase de sentencias. Instrumentación de la Sentecia IF-THEN-ELSE La finalidad de la instrumentación de la sentencia if es conocer cual de sus partes (then o else) se ejecutó [Ake05]. Para alcanzar el objetivo mencionado con anterioridad, es necesario el uso de otras funciones de inspección que se deben insertar correctamente en ambas partes de la sentencia if cuyo patrón se muestra a continuación: IF condición THEN sentencias ELSE sentencias La idea se presenta en la Figura El lector puede observar que las sentencias correspondientes a la parte then se colocan dentro de una sentencia compuesta, lo mismo sucede con las sentencias de la parte else. El uso de la sentencia compuesta evita dos problemas: i) Introducir errores sintácticos y ii) Cambiar la semántica del programa. De la misma forma que las sentencias descriptas en las secciones previas, la sentencia if puede estar dentro de iteraciones. Por esta razón, se debe controlar la cantidad de información que recuperan las funciones de inspección. En este caso se puede usar un esquema similar al definido para las iteraciones. Es importante notar que es útil que esta clase de sentencias se muestren una o más veces porque permiten identificar con más certeza que parte se ejecutó. La utilización de una misma pila para controlar las iteraciones y las sentencias de selección puede causar algunos problemas. Observe la Figura 7.21.b y asuma que se usa la aproximación para controlar las iteraciones descripta en la sección Si la acción de la función IF INSPECTOR(parámetro) está controlada por los valores que se encuentran en la pila de las iteraciones, entonces las funciones

184 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 178 if (condición) then { IF_INSPECTOR(CONDICIÓN-VERDADERA); sentencias; } else { IF_INSPECTOR(CONDICIÓN-FALSA); sentencias; } Figura 7.20: Instumentación de Selecciones - Instrumentación de la Sentencia IF-THEN-ELSE de inspección correspondientes a la primer sentencia if no mostrarán información. Por otra parte, la función de inspección de la sentencia if dentro de la iteración imprimirá los datos recibidos como sus parámetros mientras el valor del tope de la pila sea mayor o igual que cero. Una posible forma de solucionar este problema es usar otra pila. Esta estructura de datos contiene un número mayor que cero que posibilita: 1. La impresión de la información correspondiente a las selecciones ubicadas fuera de las iteraciones. 2. Controlar el número de veces que se debe mostrar la información de la sentencia if dentro de una iteración. Para realizar esta tarea, se puede usar la misma aproximación que la empleada para las iteraciones (ver sección 7.5.2). Instrumentación de la Sentencia SWITCH El objetivo del esquema de instrumentación de la sentencia SWITCH es mostrar que opciones fueron ejecutadas [Ake05]. La Figura 7.23 ilustra la estrategia usada para instrumentar esta sentencia teniendo en cuenta el modelo presentado en la Figura La idea consiste en insertar al comienzo de cada opción de la sentencia SWITCH una función de inspección que informe la opción que se ejecutó. Es importante notar que es posible usar la misma aproximación que la empleada para la sentencia if cuando este tipo de construcción se encuentra dentro de otra sentencia de selección o bien en el interior de una iteración.

185 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 179 if (cond-1) { sentencias; if (cond-1) else { sentencias; IF_INSPECTOR(cond-1-VERDADERA); for(acc1; acc2; acc3) sentencias; { } if (cond-2) else sentencias; { else IF_INSPECTOR(cond-1-FALSA); sentencias; sentencias; } } } { showfunction(valor); for(acc1; acc2; acc3) { { if (cond-2) { IF_INSPECTOR(cond-2-VERDADERA); sentencias; } else { IF_INSPECTOR(cond-2-FALSA); sentencias; } } dec(); } showfunction(valor); } (a) (b) Figura 7.21: Instrumentación de Selecciones - Sentencia IF-THEN-ELSE

186 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN Conclusión SWITCH (IDENTIFICADOR){ CASE IDENTIFIER-1: sentencias; CASE IDENTIFIER-2: sentencias;... CASE IDENTIFIER-N: sentencias; DEFAULT: sentencias; } Figura 7.22: Modelo de la Sentencia Switch SWITCH (IDENTIFICADOR) { CASE IDENTIFIER-1: SWITCH_INSPECTOR(IDENTIFICADOR-1); sentencias; CASE IDENTIFIER-2: SWITCH_INSPECTOR(IDENTIFICADOR-2); sentencias;... CASE IDENTIFIER-N: SWITCH_INSPECTOR(IDENTIFICADOR-N); sentencias; DEFAULT: SWITCH_INSPECTOR(DEFECTO); sentencias; } Figura 7.23: Instrumentación de Selecciones - Sentencia SWITCH Este capítulo describió diferentes formas de extraer información comportamental/operacional, estática/dinámica desde un sistema. Esta tarea se realizó considerando los requerimientos para la implementación de estrategias de: Modelos Cognitivos; Visualización de Software e Interconexión de Dominios. En primer lugar, se analizaron algunos procedimientos para recuperar información desde el Dominio del Problema. En este punto, fue posible concluir que no hay métodos automáticos para alcanzar este objetivo porque esta tarea implica observar el comportamiento del sistema y extraer los principales conceptos y las relaciones existentes entre ellos. No obstante, se pueden usar algunas técnicas tales como el Análisis Comportamental para asistir al usuario en este trabajo. Como paso siguiente, se describieron algunos procedimientos de extracción de la información para construir interesantes vistas del sistema. Este trabajo permitió percibir que algunas vistas son simples de conceptualizar pero sus implementaciones son muy dificiles de llevar a cabo debido al uso de técnicas de análisis estático complejas. Por esta razón, se optó por extraer tanta información estática como sea posible usando análisis estático tradicional y emplear el análisis dinámico para descubrir

187 CAPÍTULO 7. EXTRACCIÓN DE LA INFORMACIÓN 181 conexiones complejas tales como las funciones invocadas a través de punteros a. El análisis dinámico se llevó a cabo usando Instrumentación de Código [AAG]. La idea de esta técnica es: seleccionar puntos útiles de verificación del sistema e insertar las sentencias que recuperen información de tiempo de ejecución. Con este objetivo en mente, se explicó la instrumentación de varias construcciones del lenguaje de programación. El resultado final fue un conjunto de modelos que se pueden implementar en herramientas de comprensión por medio de técnicas de análisis sintáctico. Como una observación final, los procedimientos explicados en este capítulo recuperan la información necesaria para la implementación de las estrategias de interconexión de dominios y otras vistas descriptas en los capítulos previos. El lector interesado en ver los resultados de esta tarea puede revisar el capítulo 8 de este trabajo de doctorado.

188 Parte IV PICS UNA HERRAMIENTA DE COMPRENSIÓN DE PROGRAMAS 182

189 Capítulo 8 PICS: Program Inspection and Comprehension System 8.1. Introducción La experiencia es algo que obtienes justo después que la necesitas. Oliver W. Phillips Las estrategias más importantes descriptas en de este trabajo están implementadas en PICS una herramienta cuyo objetivo es inpeccionar y comprender sistemas escritos en lenguaje C. PICS provee muchas vistas y estrategias de inspección. Las primeras se usan para representar la información del sistema a través de diferentes dominios y las segundas se emplean para interconectarlas. Combinando ambas características, se pueden construir muchas relaciones en el mismo o diferentes niveles de abstracción. Por ejemplo, las funciones del sistema se vinculan por medio de su relación llamador-llamado (Grafo de Funciones); los módulos se conectan usando la intercomunicación entre las funciones (Grafo de Comunicaciones de Módulos), etc. Todas las vistas y relaciones provistas por PICS son interesantes y útiles para entender programas. Sin embargo, la más relevante es aquella que permite vincular los Dominios del Problema y Programa. PICS lleva a cabo esta tarea por medio de las estrategias SVS y BORS descriptas en el capítulo 6. Este capítulo está organizado como sigue. La sección 8.2 describe la arquitectura de PICS. La sección 8.3 muestra la interfaz para la extracción de la información estática y dinámica del sistema. La sección 8.4 describe las vistas del sistema provistas por PICS. La sección 8.5 explica las interfaces de BORS y SVS. Finalmente, la sección 8.6 presenta las notas y comentarios de este capítulo. 183

190 CAPÍTULO 8. PICS: PROGRAM INSPECTION AND COMPREHENSION SYSTEM Arquitectura de PICS La Figura 8.1 muestra la arquitectura de PICS. Como es posible observar, PICS tiene tres grandes subsistemas: Extracción de la Información(EI); Visualización de Software (VS) y Estrategias de Comprensión de Programas (ECP). EI recibe como entrada los módulos del sistema de estudio y aplica técnicas de compilación tradicional para la extracción de información estática. Esta tarea se lleva a cabo empleando el Extractor de Información Estática. En el caso de la información dinámica, instrumenta el código fuente utilizando el Extractor de Información Dinámica. Tanto la información dinámica como la estática se almacenan en un Repositorio de Información (RI). VS usa la información disponible en RI para la construcción de diferentes vistas basadas en texto y grafos con diferentes funciones de navegación. Además, interactúa con otras herramientas tales como Graphviz y GTK-library para la producción de salidas gráficas y la implementación de las funciones de navegación (cada una de ellas se explican en la sección 8.4). ECP implementa la relación entre los dominios del Problema y Programa a través de las estrategias SVS y BORS descriptas en el capítulo Extracción de la Información La extracción de la información estática y dinámica se realiza presionando el botón Cargar Módulos C (el segundo botón en la barra de herramientas) cuya utilidad consiste en: i) Permitir la identificación y selección del archivo a analizar (ver Figura 8.2) y ii) Aplicar los pasos que se describen en las subsecciones siguientes Preprocesamiento del Código Fuente Después de cargar el código fuente, se pueden realizar dos actividades: i) Preprocesar el código fuente o ii) Comentar las directivas al Preprocesador de C. La primera es la solución más directa para evitar el problema presentado por el uso de dos lenguajes (el lenguaje C propiamente dicho y el lenguaje del Preprocesador) para implementar programas. Sin embargo, esta aproximación presenta algunos inconvenientes: Se incorpora información innecesaria: el preprocesamiento agrega miles de líneas de código e introduce declaraciones de tipos complicadas que oscurecen la tarea de Comprensión de Programas.

191 CAPÍTULO 8. PICS: PROGRAM INSPECTION AND COMPREHENSION SYSTEM 185 Figura 8.1: Arquitectura de PICS

192 CAPÍTULO 8. PICS: PROGRAM INSPECTION AND COMPREHENSION SYSTEM 186 Figura 8.2: Operación de Abrir Archivo en PICS

193 CAPÍTULO 8. PICS: PROGRAM INSPECTION AND COMPREHENSION SYSTEM 187 Figura 8.3: Procesamiento de las directivas al Preprocesador de C Problemas para construir la versión ejecutable del sistema: preprocesar archivos pequeños es una tarea simple. El programador solamente necesita invocar al compilador usando la opción -E. No sucede lo mismo con los grandes sistemas porque son compilados con muchas opciones para producir el código final. PICS resuelve el primer problema transformando todas las directivas #include correspondientes a las librerías de C en comentarios. Las directivas #include definidas por el programador no son comentadas porque se deben preprocesar para eliminar las definiciones de macros e incorporar, en el módulo analizado, toda la información disponible en el archivo de cabecera. Después de eso, el programa o módulo se puede preprocesar porque sólo se expandirán los archivos de encabezado definidos por el programador. Finalmente, las directivas #include modificadas se restauran a su estado original con la finalidad de producir la versión ejecutable del sistema. (la Figura 8.3 muestra el proceso descripto en este párrafo). Desafortunadamente, PICS no resuelve el segundo inconveniente, porque generalmente el procedimiento de compilación de grandes sistemas se especifica usando herramientas tales como make. Esas clases de aplicaciones tienen sus propios lenguajes de programación y mecanismos de compilación y por lo tanto se necesita la construcción de un procesador de lenguajes específico para extraer y transformar sus comandos. Por esta razón, esta dificultad no será considerado en este capítulo. La segunda aproximación, comentar las directivas al preprocesador de C, consiste en transformar el código fuente en otro equivalente pero con todas las directivas comentadas. De esta manera, se evita el análisis requerido para la interpretación de los procedimientos utilizados por en las herramientas de compilación. Para llevar a cabo este trabajo, PICS elimina los comentarios del programa y luego comenta las directivas al preprocesador. Las Figuras 8.4 y 8.5 ilustran esta propuesta aplicada al código fuente mostrado en la Figura 8.2. Esta estrategia es simple de usar pero necesita la intervención del programador para resolver los siguientes problemas:

194 CAPÍTULO 8. PICS: PROGRAM INSPECTION AND COMPREHENSION SYSTEM 188 Figura 8.4: Archivos Comentados por PICS

195 CAPÍTULO 8. PICS: PROGRAM INSPECTION AND COMPREHENSION SYSTEM 189 Figura 8.5: Archivos Comentados por PICS

196 CAPÍTULO 8. PICS: PROGRAM INSPECTION AND COMPREHENSION SYSTEM 190 Programas Generados con el Preprocesador de C: en este caso el proceso necesita la intervención del programador porque las sentencias escritas pueden no seguir la sintáxis propia del lenguaje de programación. Por ejemplo, se pueden encontrar sentencias if con dos o más cuerpos dentro de una de sus partes. Un posible motivo para que esto ocurra puede ser la necesidad de especializar el programa para distintas arquitecturas de computadoras. Definiciones de Macro no Expandidas: al igual que en el primer ítem se requiere, aunque no siempre, alguna intervención del programador porque las invocaciones de las macros pueden no seguir la sintáxis del lenguaje de programación. Esta situación generalmente se encuentra en las condiciones de las sentencias if. En este contexto, es común ver en los sistemas sentencias if cuyas condiciones no están encerradas entre paréntesis porque son macros que al momento de expandirse escriben el código como corresponde. Tipos no declarados: las directivas al preprocesador de C y definiciones de macro no son el único problema. Esto se debe a que los sistemas usan librerías que definen tipos cuyas declaraciones no se pueden encontrar en el código fuente y por consiguiente detienen el análisis sintáctico. Para solucionar este problema, PICS detiene el preprocesamiento y permite que que el programador tome algunas decisiones. Por ejemplo, si el identificador es un tipo entonces puede incorporarlo en un archivo de tipos no estándares. Si este no es el caso, es posible comentar, usando un formato provisto por PICS, la línea de código bajo análisis. Finalmente, en el peor caso, el programador debe indicar manualmente las líneas de código que se deben inhibir. La Figura 8.6 muestra la interfaz de PICS para resolver el problema de los tipos no declarados Extracción de Información Estática y Dinámica Después de la fase de preprocesamiento descripta en la sección es posible extraer la información requerida. PICS lleva a cabo esta tarea en dos pasos, el primero extrae la información estática y el segundo instrumenta el código fuente con la finalidad de recuperar la información dinámica. Para la información estática, PICS tiene implementado un analizador sintáctico de ANSI C con las acciones semánticas apropiadas para la recuperación de: Funciones; Variables y Tipos; etc. Esta funcionalidad se ejecuta simplemente presionando el botón Contruir Tabla de Símbolos que se encuentra en la barra de herramientas. Si este proceso se ejecutó correctamente entonces la información estática se muestra sobre la hoja de Datos de PICS. Para la información dinámica, se emplea el mismo analizador sintáctico de ANSI C pero con otras acciones semánticas que permiten cambiar el código fuente siguiendo los pasos indicados en el capítulo

197 CAPÍTULO 8. PICS: PROGRAM INSPECTION AND COMPREHENSION SYSTEM 191 Figura 8.6: Problema de Tipos de no Declarados

198 CAPÍTULO 8. PICS: PROGRAM INSPECTION AND COMPREHENSION SYSTEM 192 Figura 8.7: Código Fuente Instrumentado 7 (ver Figura 8.7). Luego de realizar las tareas mencionadas en los párrafos precedentes, se ejecuta el programa instrumentado para recuperar la información dinámica. Esta información será usada por las estrategias para interconectar dominios y para relacionar el Dominio del Problema con el Dominio del Programa Vistas Los datos registrados en el proceso de extracción de la información proporcionan la base para la construcción de diferentes vistas del sistema. Esas vistas se construyen pormedio de la utilización de

199 CAPÍTULO 8. PICS: PROGRAM INSPECTION AND COMPREHENSION SYSTEM 193 artefactos de textos y grafos. Las vistas disponibles en PICS son: Editor de Textos: se utiliza para para visualizar y editar código C. Este editor ilumina cada palabra clave y tiene las siguientes funcionalidades: Buscar; Reemplazar; Copiar; Pegar; etc. Las Figuras presentadas en las secciones precedentes muestran ejemplos de visualizaciones de programas C que usan este tipo de vistas. Visualizador de la Tabla de Símbolos: es posible visualizar y acceder rapidamente a cada componente del programa usando el visualizador de tabla de símbolos. Todos los símbolos del programa junto con toda la información extraída correspondiente a sus atributos se insertan en una tabla. El programador puede navegar el código fuente, visualizando la línea donde se encuentra el símbolo consultado, usando funcionalidades de búsqueda fonética. La Figura 8.8 muestra el Visualizador de Tabla de Símbolos. Grafo de Funciones: este grafo muestra la relación llamador-llamado entre las funciones. Grafo de Dependencia de Módulos: se usa para mostrar la relación de inclusión entre los módulos. En el caso de PICS, este grafo se utiliza para exhibir la relación de dependencia entre los encabezados (.h) y los archivos C. Grafo de Comunicaciones de Módulos: se emplea para visualizar como se conectan los módulos del sistema por medio de funciones. Grafo de Tipos: exhibe las dependencias de tipos encontradas en el sistema. Árbol de Ejecución de Funciones: las funciones usadas por el sistema para alguna actividad específica se pueden visualizar por medio de esta vista. Además, es posible recuperar e inspeccionar el código fuente y el correspondiente al lenguaje ensamblador de cada una de ellas. Todos los grafos se pueden visualizar utilizando el Visualizador de Grafos (ver Figura 8.9). Esta componente (incluída en el subsistema SV) tiene implementadas las siguientes operaciones: Vecinos Derechos; Vecinos Izquierdos; Ideal Izquierdo; Ideal Derecho; Filtros; Funciones que influencian la ejecución de otras; etc. Finalmente, sobre esta vista es posible observar una ejecución animada a nivel de módulos y funciones. Es importante notar que esta perspectiva es híbrida porque utiliza información estática (Grafo de Funciones) y dinámica (Flujo de Ejecución de Funciones) para visualizar algunos aspectos del sistema.

200 CAPÍTULO 8. PICS: PROGRAM INSPECTION AND COMPREHENSION SYSTEM 194 Figura 8.8: Visualizador de Tablas de Símbolos

201 CAPÍTULO 8. PICS: PROGRAM INSPECTION AND COMPREHENSION SYSTEM 195 Figura 8.9: Visualizador de Grafos: Grafo de Funciones

202 CAPÍTULO 8. PICS: PROGRAM INSPECTION AND COMPREHENSION SYSTEM Interconexión de los Dominios del Problema y Programa Esta sección tiene como objetivo describir los pasos necesarios para la aplicación de SVS y BORS a los sistemas que se desean comprender. Como se declaró en los capítulos precedentes el principal desafío en Comprensión de Programas consiste en relacionar los Dominios del Problema y Programa. El concepto de Dominio del Problema se refiere a la salida del sistema y sus funcionalidades. El concepto de Dominio del Programa hace alución a las componentes del programa tales como: Funciones; Módulos; Variables; etc. Con la interconexión de estos dominios se desea responder la siguiente pregunta: Cuáles son los elementos del Dominio del Programa usados para producir una salida específica correspondiente al Dominio del Problema? Las estrategias descriptas en el capítulo 6 responden esta pregunta de dos maneras: En vida, mientras el sistema se está ejecutando (SVS). Post Mortem, cuando el sistema finalizó su ejecución (BORS). Para alcanzar este objetivo, SVS y BORS necesitan que se instrumente el código fuente. Por esta razón, la primer tarea que se realiza es preprocesar el código fuente siguiendo los pasos descriptos en las secciones y Después de eso, el sistema se compila y ejecuta. Como SVS es una estrategia En Vida el programador ve las funciones usadas por el sistema durante su ejecución. Como un efecto colateral esas funciones se registran en un archivo; esta información será interpretada por BORS, después de la ejecución, para producir las correspondientes explicaciones (ver capítulo 6) SVS La Figura 8.10 presenta una instantánea de la ejecución de un programa de juguete elaborado por estudiantes de Ingeniería de Software de la Universidad de Minho. Este programa implementa divertidos juegos de computadoras y su salida consiste de diferentes opciones que posibilitan comenzar, operar y finalizar los juegos. La Figura 8.10 muestra la Vista Comportamental (Dominio del Problema) del sistema. La Figura 8.11 ilustra el Grafo de Funciones (información estática) y

203 CAPÍTULO 8. PICS: PROGRAM INSPECTION AND COMPREHENSION SYSTEM 197 Figura 8.10: Vista Comportamental del Programa de Juegos

204 CAPÍTULO 8. PICS: PROGRAM INSPECTION AND COMPREHENSION SYSTEM 198 Figura 8.11: Grafo de Funciones del Programa de Juegos la Figura 8.12 exhibe la ejecución del sistema instrumentado con SVS en su interior. La relación entre el comportamiento (problema) y la operación (programa) es directa. Para el menú inicial, las funciones usadas son: main; intro; y login. Las otras funciones utilizadas por el sistema se registran en el momento que el programador selecciona las alternativas de cada juego. Es importante notar que se pueden usar otras vistas complementarias para inspeccionar el sistema. Por ejemplo, es una alternativa interesante usar el Grafo de Funciones como un mapa del programa y las funcionalidades de inspección textuales para explorar el código fuente.

205 CAPÍTULO 8. PICS: PROGRAM INSPECTION AND COMPREHENSION SYSTEM 199 Figura 8.12: SVS aplicado al Programa de Juegos

206 CAPÍTULO 8. PICS: PROGRAM INSPECTION AND COMPREHENSION SYSTEM BORS El primer paso requerido para la aplicación de BORS consiste en observar la salida del sistema e identificar los objetos que se desean inspeccionar. Una vez realizada esta tarea se deben recuperar las funciones relacionadas con dichos objetos. Para alcanzar este objetivo se pueden usar dos técnicas, la primera de ellas, la Técnica del Grep 1, se utiliza para recuperar las funciones relacionadas por nombre con los objetos de estudio. El resultado de esta actividad es un conjunto de nombres funciones con la palabra buscada como su subcadena. Luego, esas funciones forman parte de la entrada a BORS 2 para la construcción de la relación Comportamental-Operacional. La Figura 8.13 muestra la interfaz de la Técnica del Grep. La segunda aproximación aplica la estrategia para detectar tipos de datos abstractos definida en el capítulo 7. En este caso, el programador selecciona el nombre del tipo y luego las funciones recuperadas se pasan directamente a BORS para construir las explicaciones correspondientes (la Figura 8.14 muestra la interfaz usada para llevar a cabo esta tarea). Después de realizados los procedimientos descriptos en los párrafos precedentes, se debe construir el fe-tree (recuerde que se asume que el sistema instrumentado fue ejecutado con anterioridad). Esta tarea se realiza presionando el botón Construir Árbol de Ejecución de Funciones ubicado en la barra de menú. Finalmente, se invoca la estrategia BORS presionando el botón Ejecutar BORS. La Figura 8.15 muestra la salida producida por BORS para un programa de evaluación de algoritmos de ruteo. El lector puede observar que la relación entre los Dominios del Problema y Programa consiste en indicar para el grafo, nodos y arcos las funciones usadas por el sistema para su construcción Notas y Comentarios La implementación de PICS fue una tarea dificil porque las estrategias y funcionalidades expuestas en este trabajo son simples de explicar pero muy complicadas de implementar. Esta característica hace que el código fuente de PICS sea enorme debido a la utilización de sofisticadas técnicas de programación que reducen las complejidades temporales y espaciales de los algoritmos. Sin embargo, este prototipo de PICS peresenta una nueva y relevante alternativa para mejorar la CP porque tiene estrategias no contempladas en las HCPs actuales. Obviamente, PICS (por ahora) no puede competir con las herramientas de comprensión profesionales porque esas aplicaciones fueron 1 Esta técnica consiste en el uso del comando grep, proporcionado por las distribuciones del Sistema Operativo Linux, para recuperar las líneas de un archivo que contienen un patrón de caracteres específico. 2 La estrategia BORS fue explicada en el capítulo 6

207 CAPÍTULO 8. PICS: PROGRAM INSPECTION AND COMPREHENSION SYSTEM 201 Figura 8.13: Interfaz de la Técnica del Grep

208 CAPÍTULO 8. PICS: PROGRAM INSPECTION AND COMPREHENSION SYSTEM 202 Figura 8.14: Interfaz para la detección de Tipos de Datos Abstractos de BORS

209 CAPÍTULO 8. PICS: PROGRAM INSPECTION AND COMPREHENSION SYSTEM 203 Figura 8.15: BORS aplicado a un Sistema de Evaluación de Algoritmos de Ruteo

210 CAPÍTULO 8. PICS: PROGRAM INSPECTION AND COMPREHENSION SYSTEM 204 desarrolladas por equipos de programación y no por un único desarrollador. No obstante, las estrategias para interconectar los Dominios del Problema y Programa expuestas en esta tesis doctoral e implementadas en PICS son una alternativa de valor que se puede incorporar en las herramientas profesionales.

211 Capítulo 9 Casos de Estudio No basta saber, se debe también aplicar; no es suficiente querer, se debe también hacer. Joham Wolfang Von Goethe 9.1. Introducción Este capítulo presenta algunos casos de estudios que ilustran como se usan las funcionalidades de PICS. Particularmente, se enfatiza los resultados obtenidos con las estrategias (SVS y BORS) para interconectar los Dominios del Problema y Programa. Los sistemas seleccionados son xfig y agrep. El primero es una aplicación, cuyo objetivo es construir figuras gráficas, que es interesante porque es compleja, grande, y tiene muchas alternativas que permiten verificar las aproximaciones usadas para la recuperación de la información estática y dinámica. El segundo es un comando bien conocido del Sistema Operativo Linux. Este comando fue elegido porque es un programa comunmente usado por los operadores de Linux aunque es mucho más pequeño que xfig. Es importante notar que ambos sistemas son ampliamente utilizados en la vida cotidiana por los programadores y usuarios en general. Por esta razón, los mismos son casos de estudio interesantes para mostrar que los resultados descriptos en esta tesis doctoral no sólo son teóricos sino que se pueden validar a través del análisis de sistemas reales. 205

212 CAPÍTULO 9. CASOS DE ESTUDIO La Aplicación xfig En esta sección se usará PICS para analizar y explorar un programa que permite realizar dibujos. Esta aplicación se denomina xfig y se ejecuta sobre el Sistema X Windows de Linux. En términos generales, las tareas que se pueden hacer con este sistema son las siguientes: Dibujar círculos, cuadros, líneas, etc. Importar y exportar imágenes en diferentes formatos. Crear, suprimir, mover y modificar objetos. Seleccionar cada uno de los atributos de los objetos de diferentes maneras. Almacenar las figuras en un formato propio (.fig) o convertirlas a formatos tales como PostScript, GIF, JPEG, HP, etc. Imprimir las imágenes con extensión.fig. u otros formatos tales como PostScript, GIF, JPEG, HP, etc. etc. Es importante mencionar que todas las operaciones se pueden ejecutar utilizando el ratón o las teclas de acceso rápido. La Figura 9.1 muestra la interfaz gráfica de xfig. Para ejecutar PICS con xfig como su entrada se deben aplicar los siguientes pasos a cada módulo del sistema: 1. Inhibir las directivas al preprocesador de C. 2. Detectar tipos no declarados. 3. Extraer información estática. 4. Instrumentar el código fuente. 5. Insertar el administrador de las funciones de inspección. El resultado de los pasos mencionados anteriormente es el sistema instrumentado. En ese momento, la aplicación se debe ejecutar para proceder a la extracción de la información dinámica requerida por las estrategias de interconexión de domimios implementadas en PICS.

213 CAPÍTULO 9. CASOS DE ESTUDIO 207 Figura 9.1: Interfaz Gráfica de xfig

214 CAPÍTULO 9. CASOS DE ESTUDIO Inhibir las Directivas al Preprocesador de C Esta fase se puede realizar de dos maneras: i) Preprocesando el código fuente o ii) Comentando las directivas al preprocesador correspondientes a las librerías estándares. La primera se lleva a cabo modificando el archivo makefile de xfig en las partes donde se invoca a compilador (en este caso gcc). Esta tarea se debe realizar con el propósito de incorporar el parámetro -E que posibilita la expansión de todos los encabezados incluídos en el sistema. Esta aproximación tiene el inconveniente de generar mucho código complejo e innecesario que dificulta el proceso de comprensión. El lector puede observar la complejidad de esta estrategia en las Figuras 9.2 y 9.3 donde se muestra parte del makefile de xfig y la salida producida por la utilidad make respectivamente. La segunda consiste en utilizar las funcionalidades de PICS para inhibir las directivas que incluyen los archivos de cabecera. Para proceder a la aplicación de esta funcionalidad, cada módulo se carga dentro del ambiente de PICS y se ejecuta el comando que comenta las directivas al preprocesador (Comment C Preprocessor Directives). El resultado será el módulo de estudio con todas las directivas correspondientes comentadas. La Figura 9.4 muestra la interfaz de PICS con el módulo w util.c (2.222 loc) dentro de ella y la Figura 9.5 visualiza el mismo módulo con las directivas al preprocesador comentadas. Es importante notar que esta actividad se realiza automaticamente. No obstante, cuando las directivas al preprocesador se utilizan para generar programas, como es el caso para compilar xfig para diferentes arquitecturas, se necesita alguna intervención del programador Detectar Tipos no Declarados Generalmente, los sistemas usan librerías para alcanzar sus objetivos, xfig no es la excepción. En esos casos, el analizador sintáctico encuentra errores y por consiguiente no finaliza su tarea. El siguiente trozo de código de w util.c muestra este problema. char **grid_choices; int n_grid_choices, grid_minor, grid_major; Pixmap check_pm, null_check_pm; El lector puede observar que Pixmap no es un tipo de C y además no está declarado en w util.c (quizás esta declaración se pueda encontrar en algún archivo cabecera. No obstante, muchas veces estos tipos son parte de librerías cuyo código fuente no está disponible). En esta situación, PICS le pregunta al programador por el significado del identificador; si es un tipo lo incorpora a un archivo que mantiene los tipos no estándares. En otro caso, se comenta la línea o el programador debe resolver el problema.

215 CAPÍTULO 9. CASOS DE ESTUDIO 209 Figura 9.2: Trozo de Código del archivo makefile de xfig La Figura 9.6 ilustra la tarea descripta previamente. El lector puede observar que PICS marca la línea que presenta el inconveniente y exhibe una ventana que permite la incorporación de un nuevo tipo a la base de tipos o comentar la línea Extracción de la Información Estática El próximo paso se relaciona con la extracción de la información estática. Para llevar a cabo esta tarea, PICS aplica el analizador sintáctico de C y construye la tabla de símbolos del módulo de estudio. En este proceso pueden aparecer algunos errores porque: El analizador sintáctico de PICS no contempla algunas implementaciones del lenguaje C. Es posible encontrar macros no expandidas. En esos casos, PICS comenta las líneas donde se encontraron los errores; la Figura 9.7 ilustra el problema. Cuando todos los errores sintácticos fueron resueltos, el programador puede usar la hoja de Datos para acceder a las componentes del módulo analizado. La Figura 9.8 ilustra esta situación para el

216 CAPÍTULO 9. CASOS DE ESTUDIO 210 Figura 9.3: Salida de la Utilidad make caso del módulo w util.c. El programador selecciona el identificador g y PICS ilumina la línea donde está definido ese identificador. De la misma manera, PICS puede acceder a los nombres de funciones, tipos anónimos, tipos primitivos, estructuras, etc. El método de acceso a las componentes es simple, el programador sólo necesita hacer click con el ratón sobre el elemento deseado y PICS muestra la parte del código donde se encuentra la definición de la componente y todos los atributos asociados con ella Instrumentación del Código fuente La próxima tarea consiste en la aplicación del esquema de instrumentación definido en el capítulo 7. Esta operación inserta dentro del código C de w util.c las funciones de inspección en el comienzo y fin de cada función. Además de eso, también incorporará el código necesario para controlar las iteraciones. La forma de llevar a cabo esta tarea es sencilla, el programador hace click sobre el ícono Intrumentar Programa C y PICS produce la salida ilustrada en la Figura 9.9. Es importante notar que si el esquema de instrumentación no se aplica correctamente o está mal implementado pueden aparecer dos grandes problemas:

217 CAPÍTULO 9. CASOS DE ESTUDIO 211 Figura 9.4: Módulo w util.c de xfig cargado en PICS

218 CAPÍTULO 9. CASOS DE ESTUDIO 212 Figura 9.5: Módulo w util.c con las directivas al preprocesador de C comentadas

219 CAPÍTULO 9. CASOS DE ESTUDIO 213 Figura 9.6: Tipos no declarados en w-util.c

220 CAPÍTULO 9. CASOS DE ESTUDIO 214 Figura 9.7: Error sintáctico porque las macros no fueron expandidas en el módulo w-util.c

221 CAPÍTULO 9. CASOS DE ESTUDIO 215 Figura 9.8: Datos estáticos recuperados desde el módulo w-util.c

222 CAPÍTULO 9. CASOS DE ESTUDIO 216 Figura 9.9: Instrumentación de Código de w-util.c

223 CAPÍTULO 9. CASOS DE ESTUDIO 217 No se puede compilar el sistema. Se cambia la semántica del programa. La primera es simple de detectar porque gcc reportará los errores correspondientes. La segunda se detectará cuando el programador trabaje con el sistema Inserción del Administrador de Funciones de Inspección Como se explicó en el capítulo 7 las funciones de inspección están implementadas en otro subsistema con el propósito de facilitar su reuso. Para obtener una versión ejecutable de xfig, los prototipos de esas funciones se deben incluir en cada módulo xfig. Esta tarea se lleva a cabo insertando el archivo cabecera, donde se encuentran los prototipos de las funciones de inspección, como primera línea del módulo que se está analizando. En este caso, el programador debe: i) Posicionar el cursor sobre la primer línea del módulo y ii) Presionar el botón Insertar Declaraciones de Funciones de Inspección. La Figura 9.10 muestra el módulo w util.c con el archivo de cabecera como su primer directiva Compilación del Sistema Los pasos descriptos en las secciones hasta se realizan para cada módulo de xfig. Luego, se efectua un simple análisis del archivo makefile de xfig con el objetivo de incorporar los parámetros necesarios para compilar las funciones de la librería de GTK y lpthread en las invocaciones de gcc. Esas funciones son usadas por las estrategias de interconexión de dominios para mostrar la información dinámica de una manera agradable y permitir la ejecución paralela de xfig y el Monitor. Es importante remarcar que la actividad mencionada en el párrafo precedente es mandatoria para la utilización de SVS porque es una estrategia En Vida. No obstante, no sucede lo mismo con BORS ya que solamente necesita la librería lpthread (recuerde que esta estrategia muestra la relación comportamental-operacional después de la ejecución) para que los Inspectores registren las funciones usadas por el sistema Ejecución de xfig La nueva versión de xfig obtenida después de la aplicación de los pasos explicados en las secciones previas está en condiciones de ser ejecutada y de esta manera proceder a la observación de los resultados. El programador sólo necesita invocar, desde el intérprete de comandos del Sistema Operativo, el archivo ejecutable de xfig y la estrategia de interconexión de dominios recuperará la relación

224 CAPÍTULO 9. CASOS DE ESTUDIO 218 Figura 9.10: Declaraciones de las Funciones de Inspección dentro de w-util.c

225 CAPÍTULO 9. CASOS DE ESTUDIO 219 Figura 9.11: Funciones ejecutadas por xfig cada vez que se invoca Comportamental-Operacional. La Figura 9.11 muestra (en la ventana de la izquierda) las funciones que xfig ejecuta cada vez que se invoca, las cuales son detectadas automaticamente por SVS debido a la Instrumentación de Código realizada en las etapas previas. La Figura 9.12 ilustra las funciones usadas en la construcción de un círculo. La Figura 9.13 exhibe la misma perspectiva que la Figura 9.12 pero con las funciones empleadas para visualizar un cuadro. Es importante remarcar que: SVS ALCANZA UNA RELACIÓN DIRECTA ENTRE LOS DOMINIOS DEL PROBLEMA Y PROGRAMA DE xfig. Finalmente, es relevante mencionar que las funciones de inspección de código descriptas en el capítu-

226 CAPÍTULO 9. CASOS DE ESTUDIO 220 Figura 9.12: Funciones ejecutadas para hacer un círculo

227 CAPÍTULO 9. CASOS DE ESTUDIO 221 Figura 9.13: Funciones ejecutadas para construir un cuadro

228 CAPÍTULO 9. CASOS DE ESTUDIO 222 lo 8 se pueden usar para estudiar algunas funcionalidades específicas de xfig. Por ejemplo, sería factible usar el Grafo de Funciones en el análisis de las funciones estrechamente relacionadas con las operaciones utilizadas para realizar la tarea bajo análisis. También es importante la utilización del Grafo de Módulos en la detección de los módulos que se deben modificar en caso de realizar cambios en el sistema. La Figura 9.14 muestra el Grafo de Funciones del módulo w-util.c en su totalidad. La Figura 9.15 visualiza los posibles puntos de entrada del módulo w-util.c calculados con los comandos de grafos provistos por PICS. La Figura 9.16 ilustra una operación de Zoom que posibilita observar el nombre de alguna función de interés del programador. La Figura 9.17 presenta las funciones llamadas directa o indirectamente por una función específica. Finalmente es importante notar, que se puede utilizar el Visualizador de Tabla de Símbolos para inspeccionar los objetos definidos en las funciones bajo análisis (ver Figura 9.18) El Comando Agrep de Linux Esta sección describe como se aplica PICS al comando agrep del Sistema Operativo Linux. El comando agrep es similar al comando grep; en su versión más simple, tiene dos argumentos: una cadena de caracteres y un archivo. La función de agrep consiste en buscar la cadena de caracteres recibida como primer argumento en el archivo de entrada (segundo argumento). La salida de este comando son las líneas del archivo de entrada que contienen la cadena que se desea buscar. Es importante notar que se pueden especificar las cadenas de caracteres usando expresiones regulares que permiten expresar modelos de cadenas de caracteres complicados. En las siguientes subsecciones, se describen los pasos necesarios para usar PICS para entender agrep Inhibir las Directivas al Preprocesador de C Esta fase se llevó a cabo sin problemas porque todas las directivas al preprocesador usadas por la implementación de agrep tienen la forma #include < name.h >. Esta clase de directivas se pueden comentar sin realizar modificaciones sustanciales en el programa Detección de Tipos no Declarados De la misma manera que el paso descripto en la subsección esta tarea se pudo realizar sin inconvenientes. Esto se debe a que los tipos definidos por el programador en agrep se especifican a través de definiciones typedef en el módulo correspondiente. Esas declaraciones se detectan usando ténicas de análisis estático.

229 CAPÍTULO 9. CASOS DE ESTUDIO 223 Figura 9.14: Vista del Grafo de Funciones del Módulo w-util.c de xfig

230 CAPÍTULO 9. CASOS DE ESTUDIO 224 Figura 9.15: Vista de los posibles puntos de entrada del Módulo w-util.c de xfig

231 CAPÍTULO 9. CASOS DE ESTUDIO 225 Figura 9.16: Vista de una porción del Grafo de Funciones de w-util.c

232 CAPÍTULO 9. CASOS DE ESTUDIO 226 Figura 9.17: Funciones llamadas directa o indirectamente por la función reset-grid-menus

233 CAPÍTULO 9. CASOS DE ESTUDIO 227 Figura 9.18: Datos estáticos de w-util.c

234 CAPÍTULO 9. CASOS DE ESTUDIO Extracción de Información Estática Como fue declarado en el capítulo 8, el problema principal en este paso consiste en evitar las directivas al preprocesador de C y detectar los tipos no declarados. Sin embargo, en las subsecciones y se explicó que esos problemas se resolvieron sin mayores inconvenientes. Por estos motivos este paso se llevó a cabo exitosamente Instrumentación del Código Fuente Las funciones de inspección y las sentencias que controlan los ciclos se insertaron sin inconvenientes. No obstante, en la implementación de agrep muchas funciones finalizan con la sentencia exit(n). Esta peculiaridad permite registrar el comienzo y fin de algunas funciones pero no de todas. En esta situación, la estrategia BORS no se puede aplicar porque no es posible recuperar la información necesaria para construir el fe-tree. La resolución de este problema implica la definición e implementación de un procedimiento de verificación de trazas de ejecución cuyos fundamentos y pasos se explican en los párrafos siguientes. La información que retornan las funciones de inspección (para una función específica) consiste de las siguientes cadenas de caracteres: INPUT_INSPECTOR F OUTPUT_INSPECTOR F ambas cadenas indican el comienzo y fin de la función F. Cuando F finaliza con una sentencia exit(n) la cadena OUTPUT INSPECTOR F no se registra. En este momento, la rutina de verificación de trazas de ejecución se debe ejecutar. Esta rutina usa una pila para el proceso de verificación. Cada vez que se recupera una cadena OUTPUT INSPECTOR nombre (nombre se corresponde con el identificador de alguna función) el tope de la pila se elimina. Si todas las cadenas de entrada se procesan y la pila está vacía la ejecución finaliza existosamente. En otro caso, la pila contiene elementos porque algunas funciones finalizaron con la sentencia exit(n) (o porque el programa contiene algunos errores). En ese momento, la rutina de verificación debe generar las correspondientes cadenas OUTPUT INSPECTOR nombre donde nombre concuerda con el identificador de función encontrado en el tope la pila. Esas cadenas forman parte de la traza de ejecución que fue interrumpida por un exit(n) o por un error de programación.

235 CAPÍTULO 9. CASOS DE ESTUDIO Inserción del Administrador de Funciones de Inspección Esta tarea es dependiente del sistema. Muchas veces, los prototipos del administrador de funciones se insertan en cada módulo del sistema y las definiciones de funciones se incorporan en el módulo que contiene la función main. Sin embargo, en otros contextos, las definiciones se agregan en un módulo específico del sistema (uno incluído por todos los restantes). En el caso de agrep fue necesario la inserción de las definiciones de funciones dentro del módulo donde se definió la función main y los prototipos en los módulos restantes Compilación del Sistema La compilación del monitor y el sistema de estudio, se realiza invocando al compilador con los parámetros apropiados para vincular las librerías gráficas y aquellas que permiten la ejecución paralela de los inspectores con el sistema de estudio. Afortunadamente, el arhivo makefile de agrep es simple y la incorporación de esos parámetros se realizó modificando la variable que mantiene los parámetros del compilador. La siguiente línea de código muestra el resultado obtenido: CFLAGS= pkg-config gtk cflags --libs -lpthread -O (1) En (1) se incorporaron los siguientes parámetros: i) pkg-config gtk+-2.0 cflags libs que vincula las librerías gráficas de gtk+-2.0 y ii) lpthread que permite la ejecución paralela del sistema y el monitor. Con esas modificaciones el comando agrep se compiló sin problemas Ejecución de Agrep Después de realizar todos los pasos previamentes mencionados se obtiene una nueva versión del comando agrep. Esta versión permite visualizar las funciones usadas para la búsqueda de cadenas de caracteres específicas. En la siguiente subsección se muestran algunos ejemplos de SVS y BORS. SVS aplicado a agrep En esta sección SVS será aplicado al comando agrep. Para llevar a cabo esta tarea, este comando se ejecutará con entradas específicas y después de eso se podrá observar las funciones usadas. El comando agrep se puede invocar como se muestra a continuación: $> agrep -c int *.c (1)

236 CAPÍTULO 9. CASOS DE ESTUDIO 230 Figura 9.19: SVS aplicado a agrep esta invocación retorna como resultado el número de veces que la cadena int aparece dentro de cada módulo con extensión.c. La Figura 9.19 exhibe el resultado de aplicar SVS a agrep. La ventana de la izquierda visualiza las funciones usadas por la invocación del comando agrep mostrada en (1). En otras palabras, esta ventana muestra el Dominio del Programa. La ventana de la derecha expone la salida del comando agrep es decir el Dominio del Problema. El lector puede observar que SVS indica cuales son las funciones usadas para una invocación particular. De esta manera, el programador ahorra mucho tiempo cuando desea modificar el sistema porque sólo inspecciona algunas funciones (las indicadas por SVS y los operadores de grafos) en lugar de todo el sistema. Es importante notar que se debe ejecutar la rutina de verificación de trazas porque algunas funciones finalizan con la sentencia exit(n) y no con un return.

237 CAPÍTULO 9. CASOS DE ESTUDIO 231 Figura 9.20: Funciones del Módulo parse.c BORS aplicado a agrep BORS usa la misma información que SVS pero después de la ejecución. En este caso, la implementación de BORS retorna los contextos donde se invocó la función. Esta estrategia recibe como entrada las funciones que el programador quiere explicar. Luego, se construye el fe-tree y se emplea el procedimiento descripto en el capítulo 6. Suponga que el programador desea analizar cuales funciones del módulo parser.c se usaron para el ejemplo utilizado en la prueba de SVS 1. La Figura 9.20 muestra las funciones que componen el módulo de estudio. Observando esa figura es posible determinar que la entrada a BORS está compuesta por 1 El ejemplo es: $ agrep -c int *.c

238 CAPÍTULO 9. CASOS DE ESTUDIO 232 las siguientes funciones: parse wilcard; parse chlit; parse cset; get token; parse re; mk leaf ; mk alt; parse; wrap y cat2 (todas las funciones pertenecen a parse.c y están coloreadas en la Figura 9.20). La Figura 9.21 ilustra el resultado obtenido por BORS después de construir el fe-tree y aplicar dos veces un barrido por niveles. El primero para la función parse-re (la ventana de la izquierda superior) y el segundo para la función parse-wilcard (la ventana de la izquierda inferior). Las ventanas de la izquierda muestran los contextos de las funciones analizadas. Es posible percibir como estos contextos le dan más significado a la información dinámica recuperada por la técnica de instrumentación. Por ejemplo, la información expuesta en las ventanas de la izquierda hacen posible inferir que el comando agrep realiza un análisis sintáctico usando la función parse. Además, cuando la cadena de entrada tiene expresiones regulares o caracteres comodines, agrep emplea la función parse re y usa las funciones get token y parse wilcard. Finalmente, es importante notar que fue necesario la aplicación de la rutina de verificación de trazas para usar exitosamente a BORS Notas y Comentarios La complejidad de usar PICS para simplificar la comprensión depende de las peculiaridades del sistema de estudio. Algunas veces, los sistemas sólo usan directivas al preprocesador básicas y no emplean librerías externas como el caso de agrep. En estas situaciones, el proceso se simplifica porque las estrategias de recuperación de la información estática y dinámica se pueden aplicar con pocos cambios. No obstante, los sistemas usualmente se construyen con librerías gráficas y su código contempla la instalación del sistema en diferentes arquitecturas (xfig es un ejemplo). En esos casos, se requiere la intervención del programador para resolver los problemas sintácticos introducidos por las directivas al preprocesador y las características no ANSI-C. Esta afirmación se sustenta en la experiencia adquirida a través de la aplicación de PICS a diferentes sistemas (en este capítulo solamente se explicaron dos casos) con características dispares. Uno de esos sistemas fue EAR [BHPUa, BHPUb, BHPUc] (Un Evaluador de Algoritmos de Ruteo), este programa tiene como objetivo la evaluación de algoritmos de ruteo en línea; consta de 5000 líneas de código y presenta las mismas características que agrep. La principal dificultad con EAR fue que los tamaños de las trazas de ejecución contenían billones de invocaciones de funciones porque los algoritmos usados construyen grafos aleatorios conectados. Este problema fue la motivación principal para: i) Definir la estrategia de control de los ciclos y ii) Elaborar una técnica preventiva de reducción del tamaño de las trazas. Después de resolver este problema, todas las estrategias de PICS se aplicaron sin inconvenientes. Otro sistema estudiado fue un programa para implementar diferentes juegos. Esta aplicación fue desa-

239 CAPÍTULO 9. CASOS DE ESTUDIO 233 Figura 9.21: BORS aplicado a agrep

240 CAPÍTULO 9. CASOS DE ESTUDIO 234 rrollada por estudiantes de los primeros años de Ingeniería de Software de la Universidad de Minho (el tamaño de su código fuente es de 1.2 Kloc). Este programa fue usado porque los estudiantes de los primeros años de informática tienen pocas técnicas de codificación de programas, y por este motivo sus algoritmos no siguen convenciones estándares. Esta característica fue la principal razón para aplicar PICS a este sistema porque dentro del código fuente sería posible encontrar construcciones intrincadas que permitirían analizar la robustez del esquema de instrumentación. Afortunadamente, todas las aproximaciones implementadas en PICS fueron exitosamente aplicadas a este caso de prueba.

241 Parte V CONCLUSIÓN Y TRABAJOS FUTUROS 235

242 Capítulo 10 Conclusión Nunca dejes de sonreir, ni siquiera cuando estes triste, porque nunca sabes quien se puede enamorar de tu sonrisa. Gracia Marquez En este trabajo de doctorado se estudió el tema Comprensión de Programas (CP). El primer paso en la investigación consistió en el desarrollo de una conceptualización de CP. Esta tarea fue importante porque a través del estudio del estado del arte se identificó la ausencia de una definición concreta de esta disciplina. Este interesante resultado permitió orientar la investigación, detectar y resolver varios problemas encontrados en la literatura. A partir de los estudios realizados en la primer fase de esta tesis doctoral fue posible elaborar una definición de CP que afirma lo siguiente: Es necesario estudiar los conceptos relacionados con: Modelos Cognitivos; Visualización de Software; Métodos de Extracción y Administración de la Información y Estrategias de Interconexión de Dominios para la creación de nuevos e innovadores métodos, técnicas y herramientas de Comprensión de Programas. En los siguientes párrafos se presentan las conclusiones obtenidas en cada tópico mencionado en el cuadro precedente. 236

243 CAPÍTULO 10. CONCLUSIÓN Modelos Cognitivos El estudio de los Modelos Cognitivos fue importante porque permitió extraer las siguientes conclusiones: Fue necesario la elaboración de un modelo para construir productos de CP. Este modelo declara que un programador entiende un programa cuando puede relacionar los Dominios del Problema y Programa. En otras palabras, cuando encuentra las componentes del programa usadas para producir la salida. Para recuperar esta relación se debe: i) Construir algunas representaciones de los Dominios del Problema y Programa y ii) Definir procedimientos que vinculen esas representaciones. La interconexión entre diferentes dominios es la mejor forma de simplificar la comprensión porque el programador observa y trabaja con el sistema en diferentes niveles de abstracción con la representación más apropiada para su estructura mental. Las teorías del aprendizaje indican que el proceso de aprendizaje se simplifica si se proveen varios puentes cognitivos. En el contexto de CP, los puentes cognitivos representan visualmente diferentes aspectos del sistema y son útiles en la definición de formas de interconectar los aspectos visualizados. Esta característica, permite que el programador seleccione el puente cognitivo más adecuado para su trasfondo de conocimientos y por consiguiente, tenga más posibilidades de crear relaciones sustanciales y no arbitrarias entre los conceptos utilizados en el software (Aprendizaje Significativo). Los conceptos de MC presentan muchas ambiguedades porque son descriptos por profesionales de otras áreas. Con el propósito de salvar este inconveniente, se elaboraron nuevas definiciones de conceptos más cercanos al dominio de los profesionales de Ciencias de la Computación. Esas definiciones se formalizaron utilizando una terminología más adecuada para el desarrollo de aplicaciones de CP con soporte cognitivo Visualización de Software Las conclusiones y resultados en este contexto se presentan a continuación: La Visualización de Software (VS) es un área directamente relacionada con la CP porque provee estrategias para representar visualmente los aspectos del software que el programador quiere explorar. Actualmente, las herramientas de VS se confunden con las Herramientas de

244 CAPÍTULO 10. CONCLUSIÓN 238 Comprensión de Programas (HCP) porque tienen por objetivo simplificar el aprendizaje a través de la presentación de diferentes vistas. No obstante, esta concepción no es totalmente correcta porque además de visualizar el software las HCP reunen más requerimientos, como por ejemplo: Mostrar diferentes vistas de los Dominios del Problema y Programa y la relación existente entre ellos. Con esas observaciones en mente, fue posible describir los Sistemas de Visualización de Software Orientados a la Comprensión de Programas (Program Comprehension Oriented Software Visualization Systems (PC-SVS)) como aquellas aplicaciones que proveen algunas representaciones del problema y programa, y mecanismos para visualizar su relación. Se estudiaron todas las taxonomías actuales para verificar si contemplaban las características principales de los PC-SVS. El resultado obtenido fue negativo porque esas clasificaciones sólo visualizan el Dominio del Programa. Para salvar este inconveniente, se extendió la taxonomía más completa con criterios que describen claramente los PC-SVS Estrategias para Interconectar Dominios Constuir una estrategia para interconectar dominios del Problema y Programa no es una tarea simple porque implica crear una representación para cada dominio y definir un procedimiento de vinculación. Las estrategias elaboradas en esta tesis doctoral usan las siguientes representaciones del programa: fe-tree; Grafo de Funciones; Grafo de Comunicaciones de Módulos; etc. y como representación del Dominio del Problema: El ambiente en sí mismo; Mapas Conceptuales; Modelo de Domino; etc. Además de las representaciones mencionadas en el párrafo precedente, se propusieron dos estrategias de interconexión de dominios que llenan la brecha presentada por las herramientas de comprensión actuales, ellas son: SVS (Simultaneous Visualization Strategy) y BORS (Behavioral-Operational Relation Strategy). La primera es una técnica En Vida, esto es, la relación comportamental-operacional se muestra mientras el sistema se está ejecutando. La segunda es Post Mortem, en este caso se debe: i) Recuperar los objetos del Dominio del Problema y ii) Aplicar de algunos procedimientos que construyen las explicaciones correspondientes. Con el objetivo de proveer otro esquema para relacionar los conceptos utilizados en el sistema con las componentes de software, se elaboró el Análisis Comportamental. Este procedimiento es semiautomático y permite la vinculación de los conceptos del Dominio del Problema con diferentes trazas de ejecución. En este caso, la representación del Dominio del Problema consiste de Mapas Conceptuales o Modelo de Dominio y el procedimiento de vinculación se realiza por medio de instrumentaciones de código y ejecuciones del sistema para escenarios particulares.

245 CAPÍTULO 10. CONCLUSIÓN 239 Para finalizar esta sección es importante destacar que las estrategias de interconexión de dominios previamente mencionadas son aportes relevantes de esta tesis doctoral en el contexto de la Comprensión de Programas Extracción de la Información Para implementar los Conceptos de MC, las Vistas del Sistema y las Estrategias para Interconectar Dominios se definieron Estrategias de Extracción de la Información Estática y Dinámica del Sistema. Para la extracción de la información estática, se utilizaron técnicas de compilación tradicionales. En este contexto, el punto central fue recuperar información útil para interconectar los dominios evitando análisis complejos. Para la recuperación de la información dinámica, se definió una técnica de instrumentación de código. La idea principal consistió en la inserción de funciones de inspección que registran los nombres de las funciones usadas en tiempo de ejecución. Esta información provee una traza de alto nivel que se usa para interconectar los Dominios del Problema y Programa. Con la instrumentación de esas componentes del programa es suficiente para demostrar que: Con instrumentaciones de código se puede relacionar los Dominos del Problema y Programa. No obstante, es posible alcanzar algún grado más alto de precisión instrumentando otras construcciones del lenguaje tales como: if-then-else; switch; for; while; etc. El problema principal con esta aproximación es que la información recuperada por las funciones de inspección es enorme. Esta dificultad se resolvió por medio de la creación de una estrategia que controla la cantidad de información proporcionada por las funciones invocadas dentro de las iteraciones. Esta aproximación funciona adecuadamente, sin embargo se pueden realizar otras mejoras (ver capítulo 11) que minimizan los recursos y exploran sistemas con un alto número de invocaciones de funciones Resultados Generales El desafío inicial de esta tesis doctoral fue demostrar que: Es posible relacionar los Dominios del Problema y Programa usando instrumentaciones de código y esta relación simplifica CP. Las estrategias para interconectar dominios explicadas en el capítulo 6 y todos los conceptos usados

246 CAPÍTULO 10. CONCLUSIÓN 240 en su elaboración muestran como se pueden relacionar los Dominios del Problema y Programa usando el esquema de instrumentación definido en el capítulo 7. Para sustentar la afirmación mencionada en el párrafo anterior se realizaron las siguientes tareas: Se implementaron varias estrategias de interconexión de dominios en PICS, una herramienta que facilita la inspección y comprensión de sistemas escritos en Lenguaje C. Se utilizó PICS para analizar diferentes casos de estudio; en este tesis sólo se describieron dos: el graficador xfig y el comando de Linux agrep(ver capítulo 9). Con estos tests se concluyó que, a pesar de los distintos niveles de complejidad presentados por las aplicaciones analizadas, es posible relacionar los Dominios del Problema y Programa a medida que la aplicación se ejecuta (SVS) o después de la ejecución (BORS). También se observó la utilidad de las funciones de inspección y de las visualizaciones basadas en grafos provistas por PICS. Los resultados indican que la relación entre los Dominios del Problema y Programa ayuda a identificar rapidamente las componentes del programa usadas para producir una salida particular del sistema. Por esta razón, es claro que una herramienta de comprensión con este tipo de estrategias de interconexión reduce los costos y tiempo implicados en el mantenimiento y evolución de software; porque el programador se concentra solamente en el análisis de las funciones relacionadas con la parte del sistema que se desea modificar. Por otra parte, las funciones de inspección de código proveen otra forma de complementar la información de alto nivel proporcionada por la relación entre los Dominios del Problema y Programa alcanzada por SVS y BORS, porque posibilitan la recuperación de todos los atributos de los objetos computacionales empleados en la construcción de la salida del sistema. Por ejemplo, cuando se identifican las funciones usadas por el sistema, las funciones de inspección de código pueden recuperar sus códigos fuente y objeto, los parámetros, las variables locales, las variables globales utilizadas por la función, etc. Finalmente, si se necesita información de más bajo nivel se puede usar un depurador para realizar la inspección detallada de las componentes del programa.

247 Capítulo 11 Trabajo Futuro Queda prohibido no sonreir a los problemas, no luchar por lo que quieres, abadonarlo todo por miedo, no convertir en realidad tus sueños. Pablo Neruda En este capítulo se presentan las extensiones de este trabajo de doctorado, las cuales se relacionan con: 1. Mejoras en los Prototipos Implementados en PICS. 2. Mejoras en las Estrategias de Inspección de Programas. 3. Optimizaciones de las Técnicas de Interconexión de Dominios. 4. La Evaluación de Herramientas de Comprensión de Programas. En los párrafos siguientes se describen sinteticamente cada uno de los trabajos futuros correspondientes a las cuatro actividades principales mencionadas previamente. Algunos de ellos se pueden realizar como tesis de licenciatura o de maestría; otros son desafíos típicos de Comprensión de Programas y de este modo son considerados futuras propuestas de tesis doctorales Mejoras en los Prototipos Implementados en PICS A continuación se describen los trabajos relacionados con los prototipos de PICS. 241

248 CAPÍTULO 11. TRABAJO FUTURO 242 int f (int x, int y) *Especificiación de alto nivel { chunk_rutina(f;<sentencias dentro de la función>; <f realiza x*y>) int i,r; *Especificación más detallada i=0; chunk_rutina(f; chunk_sec({r=0};2; <inicialización>), r=0; chunk_iter(chunk_sec({i=0};2; <inicialización>), while (i<y) chunk_sec({i<y};2;<repetir hasta que "i" sea igual a "y">), { chunk_sec({r=r+x; i=+1;};2; <acumula el valor de x>)), r=r+x; chunk_sec({return r;};2; i=i+1; <retorna el valor acumulado>); <realiza xỳ* y>) } return r; } (a) (b) Figura 11.1: Desde los Programas a Modelos de Programas Transformar programas en patrones de programas: en el capítulo 3 los conceptos de Modelos Cognitivos se estudiaron y especificaron con la finalidad de proporcionar descripciones más cercanas al dominio del programador. Esas especificaciones tienen por objetivo traducir el código fuente de un programa en un programa de patrones que provee descripciones de alto nivel. Por ejemplo, una función definida como en la Figura 11.1.a se puede traducir en la función de patrones (ver capítulo 3) presentada en la Figura 11.1.b. El punto importante es que los conceptos de Modelos Cognitivos están claramente descriptos y de este modo pueden ser interpretados e implementados por los profesionales de Ingeniería de Software o Ciencias de la Computación. Por esta razón, la implementación de estas ideas y su posterior incorporación a una Herramienta de Comprensión de Programas (HCP) es una característica interesante para asistir al programador en el proceso de comprensión. Mejorar la Visualización de Grafos: PICS provee un ambiente para visualizar grafos basado en TCL/TK y Graphvis (un paquete de software cuya principal funcionalidad es construir trazados de grafos). El problema con esta aplicación es la eficiencia y algunos inconvenientes en la visualización de grafos grandes. Una forma de resolver esos problemas se basa en la utilización de librerías más robustas como por ejemplo: Jung; Prefuse; Cario; etc. para implementar las funcionalidades de PICS relacionadas con grafos. Esta tarea se puede llevar a cabo sin inconvenientes con las dos primeras librerías porque existen documentaciones y ejemplos que proporcionan las bases para el desarrollo de interfaces gráficas. En este caso, el trabajo consistirá en la reimplementación del sistema de visualización de PICS y la incorporación de otras características que son muy complicadas de llevar a cabo con TCL/TK, como por ejemplo:

249 CAPÍTULO 11. TRABAJO FUTURO 243 distintas clases de zoom (geométrico, ojos de pez, etc.); treemaps, etc. La tercera, Cairo, provee un objeto canvas muy útil para dibujar formas. Cairo se puede integrar con Graphvis, sin embargo los pasos necesarios para la integración de ambas herramientas se deben documentar con la finalidad de simplificar, a los futuros usuarios de este paquete de software, la implementación de aplicaciones tales como el Visualizador de Grafos de PICS. Esta tarea es interesante porque, además de contribuir con la documentación necesaria para la utilización de Cairo con Graphvis, permite la comparación de esta librería con otras tradicionalmente usadas para visualizar grafos. Completar la estrategia de detección de tipos de datos abstractos: la estrategia para la detección de tipos de datos abstractos definida en el capítulo 7 analiza la información de tipos de manera muy general 1. Es posible reforzar está estrategia analizando los accesos (lecutras y escrituras) a las variables que usa la función y definiendo funciones de similaridad con el propósito de lograr una vinculación funciones-datos más estrecha. Un punto de partida importante para realizar esta tarea es el trabajo desarrollado por Canfora et. al. en [CCMT93]. La concreción de este trabajo permitiría que la información que recibe la estrategia BORS como su entrada sea más precisa. Definir un repositorio de datos: las estrategias de extracción de la información recuperan muchos datos desde los sistemas. PICS almacena esa información en estructuras de datos y archivos con una complejidad temporal y espacial aceptables. No obstante, esta característica se degrada cuando se comienza a trabajar con diferentes sistemas o con programas compuestos por muchos módulos. Para salvar este inconveniente es necesario la elaboración de un modelo de base de datos cuyas entidades representen a los objetos de software más importantes y las relaciones existentes entre ellos. Esta tarea es enriquecedora porque es la base para la definición de un metamodelo de datos que se pueda usar para la construcción de diferentes herramientas de comprensión Mejoras en las Estrategias de Inspección de Programas Las tareas futuras se relacionan con procedimientos que faciliten la inspección de la información dinámica recuperada desde el sistema. Los siguientes ítems describen cada uno de ellos. 1 De hecho la estrategia fue descripta con el objetivo de mostrar que la estrategia BORS se puede automatizar.

250 CAPÍTULO 11. TRABAJO FUTURO 244 Proponer procedimientos para inspeccionar programas recursivos: la técnica de instrumentación explicada en el capítulo 6 no considera las rutinas recursivas. Esta clase de programas puede producir una explosión de información. Para solucionar este problema se necesitan la elaboración de algunas estrategias de control de la recursión. Resumen de Trazas: generalmente, las trazas de ejecución son enormes. Proponer estrategias para reducir esta información sin perder demasiada semántica es muy importante para facilitar el análisis dinámico y la comprensión de los sistemas de software Optimizaciones de las Técnicas de Interconexión de Dominios Las extensiones en este ámbito se describen a continuación. Construir representaciones del programas más completas: el modelo de CP declara que para construir HCP se necesita: i) Representar el Dominio del Problema; ii) Representar el Dominio del Programa y ii) Definir un procedimiento de vinculación de esas representaciones. A través de los experimentos llevados a cabo con diferentes programas fue posible detectar que: Mientras más completa sean las representaciones de los Dominios del Problema y Programa más fuerte será la relación que se pordá alcanzar entre ambos. Por esta razón, implementar representaciones de programas tales como Árboles de Sisntaxis Abstracta Decorados, Grafos de Dependencia, etc. son útiles para mejorar la CP porque permiten alcanzar mayor precisión cuando se requiere analizar los objetos del Dominio del Programa utilizados en el Dominio del Problema. Desarrollar representaciones del dominio del problema: se pueden encontrar muchas representaciones de programas pero no sucede lo mismo con el Dominio del Problema. En esta tesis doctoral se propusieron para representar el problema la Salida del Sistema, los Mapas Conceptuales y el Modelo de Domino. Si bien estas estrategias de representación del Dominio del Problema funcionaron bien es interesante elaborar otras representaciones innovadoras que permitan alcanzar relaciones más estrechas con el Dominio del Programa. Elaborar estrategias que relacionen datos con objetos del Dominio del Problema: las aproximaciones para interconectar dominios están fuertemente orientadas a relacionar funciones con los objetos del Dominio del Problema. Los datos son tan importantes como las funciones, pero las estrategias para recuperarlos y vincularlos con los objetos del Dominio del Problema son

251 CAPÍTULO 11. TRABAJO FUTURO 245 muy complejas. Por esta razón, la creación de técnicas que realicen este trabajo es una tarea de valor. Implementar estrategias de instrumentación de sentencias primitivas: en el capítulo 7 se describieron diferentes estrategias para instrumentar funciones, sentencias de iteración, selección y otras que modifican el flujo de control como por ejemplo: break; continue; etc. Las dos primeras fueron implementadas en PICS mientras que las restantes sólo se especificaron porque previamente se pudo demostrar que con instrumentaciones de funciones y sentencias de iteración es posible relacionar los Dominios del Problema y Programa. No obstante, es posible fortalecer esta relación si se instrumentan las sentencias de selección y las que modifican el flujo de control. La instrumentación de las primeras, permite que las estrategias tales como SVS y BORS se puedan especializar para que indiquen el nombre de las funciones y las partes de sus cuerpos que se ejecutaron para producir la salida. Mientras que la instrumentación de las segundas, posibilitan que el mecanismo de control de las iteraciones sea más robusto. Elaborar e implementar estrategias de minería de textos: en el capítulo 6 se declaró que la información informal es útil para la recuperación de la semántica de las funcionalidades del sistema. Por este motivo, el uso de procedimientos de minería de textos para inspeccionar diferente fuentes de información informal es otra característica que puede aumentar la calidad de las funcionalidades de todas las HCP. Extender las técnicas presentadas en esta tesis doctoral a otros paradigmas: las aproximaciones para interconectar los Dominios del Problema y Programa fueron elaboradas para programas secuenciales con memoria compartida. No obstante, las mismas ideas se pueden extender a otra clase de programas 2 y otros paradigmas tales como POO, concurrente, etc Evaluación de Herramientas de Comprensión de Programas Como trabajo futuro en esta área se planifican las siguientes actividades: Elaborar cirterios que posibiliten la selección de programas de prueba con características generales y objetivas (benchmarks) para evaluar el desempeño de HCP. 2 Web Application Viewer, descripto en el capítulo 4 presenta una extensión de la estrategia BORS para aplicaciones web.

252 CAPÍTULO 11. TRABAJO FUTURO 246 Analizar la posibilidad de agrupar las características de HCP en criterios estandarizados de evaluación siguiendo la línea de investigación mencionada en la subsección A.6.1 del apéndice A. Aplicar QEM con los criterios definidos en el apéndice A a HCP comerciales y aquellas destinadas al ambiente académico. Este trabajo tiene como propósito hacer público una escala de preferencias de HCP para que la comunidad de Ingeniería del Software pueda utilizarla para la selección de HCP. Analizar la efectividad de los criterios descriptos en el apéndice A como así también completar la lista de características con los resultados que se obtienen a partir de la experiencia en la aplicación de QEM a HCP. Contemplar los factores cognitivos en la evaluación de HCP es una tarea importante. El nivel de cognición alcanzado por el programador en el proceso de CP dependerá en gran medida de la efectividad de las estrategias de aprendizaje implementadas. En [BHU07] se han descripto los principales Modelos Cognitivos de Comprensión de Programas; dicho trabajo será analizado detalladamente con la finalidad de proporcionar otras características que posibiliten una evaluación más fina que la presentada en el apéndice A.

253 Parte VI APENDICES 247

254 Apéndice A Evaluación de Herramientas de Comprensión de Programas El derecho es el conjunto de condiciones que permiten a la libertad de cada uno acomodarse a la libertad de todos. Immanuel Kant A.1. Introducción Demostrar la utilidad de las Herramientas de Comprensión de Programas (HCP) es una tarea compleja debido a la necesidad de considerar muchos criterios y un mecanismo apropiado para la evaluación de este tipo de aplicaciones. Es claro que la mejor HCP debería poseer un conjunto completo de características que faciliten la Comprensión de Programas (CP). Pero, Cuáles son esas características? y Cómo la evaluación se puede llevar a cabo? son dos preguntas importantes que se deben responder como paso previo a la elaboración de un procedimiento de verificación de HCP. Además, si las HCPs reunen los principales requerimientos tradicionales entonces cabe la pregunta: Como las nuevas propuestas de HCP, que incluyen técnicas para relacionar los Dominios del Problema y Programa, influencian el Proceso de Comprensión? Este apéndice tiene los siguientes objetivos principales: Seleccionar un método para evaluar y establecer una escala de preferencia de HCP. Definir criterios de evaluación que permitan analizar la calidad de propuestas innovadoras tales como: Las estrategias que permiten interconectar los Dominios del Problema y Programa. 248

255 APÉNDICE A. EVALUACIÓN DE HERRAMIENTAS DE COMPRENSIÓN DE PROGRAMAS249 El apéndice está organizado como sigue. La sección A.2 describe el método de evaluación QEM que se utilizará para ponderar las HCP. La sección A.3 explica los criterios para evaluar el subsistema de Visualización de Software. La sección A.4 caracteriza las Estrategias de Inteconexión de Dominios. La sección A.5 presenta las principales propiedades de las Estrategias de Extracción de la Información. La sección A.6 expone los resultados obtenidos a través de la caracterización de cada uno de los sistemas que componen una HPC. Finalmente, la sección A.7 presenta las notas y comentarios del apéndice. A.2. Un Método de Evaluación de Calidad En esta sección se describe un Método de Evaluación de Calidad (QEM-Quality Evaluation Method 1 ) [OR02] [OGLR99] el cual será adaptado para evaluar HCP. El objetivo de esta tarea es introducir al lector en el método y el proceso de ranking utilizado por el mismo logrando de esta manera que el apéndice quede autocontenido. A.2.1. Pasos Requeridos para la Aplicación de QEM Basicamente QEM consta de los siguientes pasos: Seleccionar un conjunto de herramientas competitivas para evaluar o comparar: esta tarea, en el contexto de HPC, consiste en la selección de las herramientas que proveen mayores facilidades para simplificar la comprensión de grandes sistemas porque este es el principal objetivo de este tipo de software. Especificar los objetivos y el punto de vista del usuario: en este paso los evaluadores definen los objetivos y alcance de la evaluación. El propósito principal es evaluar un conjunto de características, las cuales serán definidas en las siguientes secciones, que las herramientas de comprensión deben poseer para cumplir con su objetivo eficientemente. Los usuarios que utilizarán el software de estudio serán expertos en Ciencias de la Computación. Por simplicidad en la aplicación del método no se considerarán diferentes niveles académicos de usuarios, lo que si se requiere es que los mismos posean un conocimiento razonable en programación. Definir las características y atributos de calidad y el árbol de requerimientos de atributos: en esta etapa los evaluadores definen las características de calidad y atributos (de HCP) que deberán ser categorizados en un árbol de requerimientos para su posterior uso en el 1 QEM fue concebido y utilizado para evaluar sitios web.

256 APÉNDICE A. EVALUACIÓN DE HERRAMIENTAS DE COMPRENSIÓN DE PROGRAMAS250 proceso de evaluación. Para cada una de las características se especifican, si es necesario, subcaracterísticas y atributos que se pueden medir por medio de variables cuyos valores permiten establecer un grado de preferencia. Basicamente, el trabajo realizado en este apéndice se basa en la definición de características de calidad de HCP. Este tipo de tareas no ha sido realizado en la literatura de CP y por consiguiente es una contribución importante. Definir una función de criterio para cada atributo y aplicar una estrategia para medir los atributos: para cada variable de medición es necesario la definición de un rango aceptable de valores y una función de criterio elemental. Dicha función mapea un valor en un dominio específico en un valor numérico que indica un grado de preferencia, el cual varía desde 0 % (totalmente insatisfactorio) hasta 100 % (totalmente satisfactorio). Calcular las preferencias elementales para producir la preferencia de calidad de las herramientas: este trabajo se lleva a cabo por medio de funciones que permiten obtener un indicador de preferencia de los sistemas en evaluación. Para cada característica, subcaracterística o atributo se producirá, a través de un proceso de agregación, un valor de preferencia que se utilizará para producir una preferencia de calidad global. Este último valor representa el grado de satisfacción de todos los requerimientos utilizados en la evaluación. Analizar, verificar y comparar los resultados parciales y globales: en este paso los evaluadores analizan y comparan los resultados (elementales, parciales y totales) obtenidos durante el proceso de evaluación. A.2.2. Definición de los Criterios Elementales Cada característica, subcaracterística o atributo se asocia con una variable de preferencia que tomará valores de acuerdo a la función de criterio elemental que debe ser definida por los evaluadores. El resultado de la aplicación de esta función representará una preferencia de calidad elemental. Dicha preferencia se puede clasificar en rangos de satisfacción, por ejemplo: [0 %,40 %] no satisfactorio; (40 %,60 %) satisfactorio y [60 %,100 %] totalmente satisfactorio. A.2.3. Cálculo de las Preferencias de Calidad Elementales En esta fase del proceso de evaluación se recolectan los datos necesarios para la aplicación de las funciones de preferencia elemental. Esos valores forman la base para el cálculo de los valores de las variables de más alto nivel. Es importante notar que la recolección de datos se puede realizar

257 APÉNDICE A. EVALUACIÓN DE HERRAMIENTAS DE COMPRENSIÓN DE PROGRAMAS251 en forma: Automática; Semi-automática o Manual. Para el caso de HPC la recolección de datos se realizaría en forma manual debido a la carencia de herramientas que puedan automatizar este paso. A.2.4. Cálculo de las Preferencias Globales En este paso, se define y prepara el proceso de evaluación que permitirá obtener un indicador de la competitividad del sistema. Esta tarea se realiza a través del cálculo de una preferencia global que indica el grado de satisfacción del programador producido por la HCP. Generalmente, para alcanzar este objetivo se utiliza el método LSP, el lector interesado en conocer el funcionamiento de LSP puede ver [Duj96]. La temática abordada por las secciones siguientes está relacionada con la elaboración de los criterios que se utilizarán para la construcción de un Árbol de Requerimientos utilizado por QEM en el proceso de evaluación. A.3. Criterios para Evaluar un Sistema de Visuazlización de Software En esta sección se describe brevemente el estado del arte relacionado con las Taxonomías de las Visualizaciones de Software y se mencionan las nuevas características que se basan en las falencias encontradas en las clasificaciones actuales. El propósito de este trabajo es que el apéndice quede autocontenido. El lector puede ver el capítulo 5 para obtener un conocimiento más acabado de esta temática. A.3.1. Clasificaciones de los Sistemas de Visualización de Software Brown en [Bro88] introduce una clasificación de la visualización centrada en las animaciones. Él describe su propuesta usando tres abcisas principales: Contenido; Transformación y Persistencia. El principal objetivo de este autor es fomentar CP a partir de la visualización explícita del funcionamiento del programa. Myers, un pionero en VS, presenta en [Mye90] una taxonomía con dos abcisas principales: La clase de objeto que el sistema de visualización intenta ilustrar y El tipo de información mostrada. En este trabajo, el estudio se centra en las principales características de visualización de: Código; Algoritmos o Programas en sus versiones: Estática y Dinámica.

258 APÉNDICE A. EVALUACIÓN DE HERRAMIENTAS DE COMPRENSIÓN DE PROGRAMAS252 Roman and Cox [RC93] proponen clasificar a los SVS usando los siguientes criterios: Alcance (o sea los aspectos del sistema que se pretenden visualizar); Nivel de Abstracción; Método de Especificación; Interface y Presentación. Es importante notar que en este trabajo los autores proponen una taxonomía más abarcativa de las VS. Price et. al. en [PBS93] presentan una taxonomía muy completa y multidimensional. Este trabajo describe los sistemas de VS usando seis caraterísticas: Alcance; Contenido; Forma; Método; Interacción; Efectividad. Esta taxonomía es la más referenciada por los investigadores de CP debido a la amplia gama de características que describen con más detalle las VS. Storey et. al. en [SvG05] proponen una clasificación, basada en la taxonomía de Price, pero orientada a la conciencia de las actividades humanas. En este trabajo, los autores presentan cinco características principales: Intento; Información; Presentación; Interacción y Efectividad. Es importante notar que, en todas las taxonomías presentadas en esta sección, las características están compuestas por subcaracterísticas que describen con mayor precisión el aspecto de estudio. El lector interesado en conocer en profundidad las taxonomás puede, además de analizar las referencias indicadas en esta sección, estudiar [BCVP + 08]. A.3.2. Nuevos Criterios para Mejorar la Caracterización de los SVS-PC Desde el estado del arte presentado en la sección previa (descripto con más profundidad en el capítulo 5) se pudo comprobar que: El Dominio del Problema y su relación con el Dominio del Programa es una característica ausente en todas, o casi todas, las clasificaciones de los SVS (ver [BHU07] para obtener una discusión más detallada del estado del arte). Este aspecto es relevante porque distingue los SVS con funciones explícitas de CP (PC-SVS, Program Comprehension Oriented Software Visualization Systems) de los comunes. A continuación, se describen algunos criterios centrados en la visualización del Dominio del Problema y su relación con el Dominio del Programa. Visualización del Dominio del Problema El Dominio del Problema se puede caracterizar por medio de los aspectos que se mencionan a continuación: Alcance: se usa para especificar las características del Dominio del Problema que se visualizarán. En este caso, es posible distinguir las siguientes categorías: Estímulo/Respuesta; Conceptos/Relaciones;

259 APÉNDICE A. EVALUACIÓN DE HERRAMIENTAS DE COMPRENSIÓN DE PROGRAMAS253 Subsistema/Relaciones; Comportamiento. Método de Especificación: especificar el Dominio del Problema es una tarea dificil. Aún más problemático es encontrar una especificación fácil de unir con las componentes del Dominio del Programa. Este criterio focaliza en el análisis de varias estrategias para resolver este inconveniente. La principal idea es verificar: i) El nivel de legibilidad de la especificación; ii) El tipo de visualización y iii) El nivel de estandarización de las especificaciones. Teniendo presente los ejes mencionados previamente, se han encontrado las siguientes clases de especificaciones: i) Ad-hoc; ii) Riguroso y iii) Formal. Clase de Creación: hace referencia a la estrategia usada para crear la visualización del Dominio del Problema, la cual puede ser: manual; semi-automática y automática. Nivel de Abstracción: expone el nivel de detalle empleado para mostrar las características del Dominio del Problema. Este criterio tiene las siguientes subcategorías: Directa; Estructural y Sintetizada. Interfaz: se puede caracterizar a través de los siguientes aspectos: Clase de Interfaz; Tipo de interacción; Vocabulario. Modelos Cognitivos: en este ámbito, se pudo detectar que existen criterios útiles para evaluar HCP [Wal02b, Sto98, Sto06, Sto05, Tie89]. Sin embargo, algunos aspectos tales como Componentes de los CM y Estrategias de Aprendizaje no son considerados. Visualización de la Interconexión entre los Dominios del Problema y Programa En este contexto, la visualización debe mostrar cuales son los elementos del programa usados para construir cada parte de la salida del sistema. El lector puede observar que se pueden usar algunos criterios del Dominio del Problema, tales como: Método de Especificación; Clase de Creación; Nivel de Abstracción; etc. para describir esta relación. No obstante, es posible encontrar algunas propiedades específicas que merecen alguna discusión. En primer lugar, se necesita redefinir la categoría Alcance porque la interconexión entre los Dominios del Problema y Programa se explica mejor usando los siguientes criterios: Ejemplo; Parcial; Total. Otra característica interesante de observar es como la estrategia interconecta los dominios antes que la relación. Dichas estrategias, se pueden clasificar en: En Vida (la relación se muestra a medida que se ejecuta el programa) o Post Mortem (la relación se visualiza después de la ejecución). Finalmente, es relevante indicar si la visualización muestra: Código; Dato o Ambos.

260 APÉNDICE A. EVALUACIÓN DE HERRAMIENTAS DE COMPRENSIÓN DE PROGRAMAS254 A.4. Criterios para Evaluar las Estrategias de Interconexión de Dominios Las estrategias de interconexión de dominios son una componente mandatoria en toda HCP porque facilitan la comprensión permitiendo que el programador seleccione el dominio más apropiado para su trasfondo de conocimientos. En la actualidad, no se han encontrado clasificaciones de estrategias de interconexión y por tal motivo se procedió definir una taxonomía que se basa en los tipos de especificaciones del Dominio del Problema y en la información contenida en las representaciones usadas para el Dominio del programa. En los párrafos siguientes se describe una propuesta de taxonomía que intenta llenar la brecha encontrada en el estado del arte. Las Estrategias de Interconexión de Dominios se pueden clasificar en Tradicionales e Innovadoras. El término Estrategia Tradicional se refiere a todas aquellas técnicas comunmente utilizadas para la traducción de un dominio del sistema estático o dinámico en otro de características similares. Por ejemplo, el Grafo de Dependencias de Módulos (GDM) es una vista estática del sistema que se puede traducir, a través de técnicas de análisis estático, al dominio del código fuente. En otras palabras, para cada nodo (módulo) de GDM es posible recuperar el código fuente asociado. Este es un ejemplo de interconexión de una vista estática a otra estática. Otro ejemplo de Estrategias de Interconexión Tradicionales lo presenta el Árbol de Ejecución de Funciones. Esta estructura de datos refleja la forma en que se invocan las funciones del sistema en tiempo de ejecución. De la misma forma que para el caso de GDM, los nodos del árbol (o sea las funciones del sistema) se pueden mapear directamente en el código fuente; en este caso cada nodo referenciará una función específica del sistema. Este es un ejemplo de una interconexión de una vista dinámica a otra estática. Se pueden elaborar ejemplos similares para las combinaciones restantes (dinámico-dinámico; estático-dinámico) de interconexiones de vistas. Es importante notar, que este tipo de estrategias son comunmente implementadas en HCP. Con el término Estrategia Innovadora se desea referenciar a toda aquellas técnicas que en forma muy esporádica son implementadas en HCP y por consiguiente el desarrollo de las mismas son verdaderas contribuciones en el campo de CP. Esta situación normalmente acontece cuando se desean elaborar vistas del sistema que permitan vincular el Dominio del Problema, es decir la salida del sistema, con el Dominio del Programa, o sea las componentes del programa (variables, funciones, módulos, etc). Generalmente, la elaboración de este tipo de vistas requiere de la combinación de información estática y dinámica y de la definición de una: i) Representación del programa; ii) Especificación/Representación del problema y iii) Estrategia de vinculación. Usualmente, las especificaciones del Dominio del Problema se pueden clasificar en: Formal: usa especificaciones formales para describir el Dominio del Problema. Por ejemplo,

261 APÉNDICE A. EVALUACIÓN DE HERRAMIENTAS DE COMPRENSIÓN DE PROGRAMAS255 especificaciones hechas en RAISE, VDM, etc. Rigurosa: emplean métodos rigurosos para describir el Dominio del Problema. Por ejemplo, especificaciones realizadas con UML. Informal: no sigue ningún patrón específico de reglas. Por ejemplo texto libre, etc. Por otra parte, las representaciones de programa se pueden clasificar en: Parcial: se refiere a aquellas representaciones que contienen sólo un conjunto reducido de características del programa. Por ejemplo: Grafo de Funciones; Grafo de Tipos; Grafo de Comunicaciones de Módulos; Grafo de Dependencias de Módulos; etc. Total: hace referencia a aquellas representaciones que contienen un conjunto significativo de componentes del programa y sus atributos. Por ejemplo: Árbol de Sintáxis Abstracta; Grafo de Dependencias del Sistema [GS07]; etc. Si se combinan las abcisas mencionadas previamente se obtienen los siguientes tipos de relaciones: i) Formal-Total; ii) Formal-Parcial; iii) Rigurosa-Total; iv) Rigurosa-Parcial; v) Informal-Total; vi) Informal-Parcial. Las relaciones mencionadas previamente se clasifican de acuerdo a su nivel de fortaleza. En primer lugar se encuentran aquellas que implican el uso de especificaciones formales. Esta clase de especificaciones son muy útiles porque están basadas en reglas que permiten derivar propiedades del sistema. El principal problema que presentan es que son muy dificiles de lograr. Esto se debe a la dificultad que surge cuando se quiere vincular una parte de la especificación formal, generalmente aquella referida a la funcionalidad que se está estudiando, con los trozos de código que la implementan. En segundo plano se encuentran las relaciones construídas con especificaciones que siguen un conjunto de reglas específicas pero que carecen de estrategias para derivar y demostrar propiedades del sistema. Finalmente, en el nivel inferior de la jerarquía se encuentran las relaciones que utilizan métodos ad-hoc para especificar el Dominio del Programa. La Figura A.1 muestra los criterios descriptos en forma gráfica. Es importante notar que todas las categorizaciones presentadas en esta sección proporcionan mucha más información, y por consiguiente permiten analizar el sistema desde diferentes puntos de vista, que sólo inspeccionar el Dominio del Problema o el Dominio del Programa. Esta afirmación se puede explicar desde el punto de vista de los Modelos Cognitivos de la siguiente manera: En primer lugar las relaciones existentes entre los Dominios de Problema y Programa actúan como Puentes Cognitivos que estimulan al programador a usar su trasfondo de conocimientos.

262 APÉNDICE A. EVALUACIÓN DE HERRAMIENTAS DE COMPRENSIÓN DE PROGRAMAS256 Figura A.1: Taxonomía para categorizar la Relación entre los Dominios del Problema y Programa La interpretación de esta clase de relación fuerza al programador a elaborar relaciones entre conceptos. Particularmente, este tipo de relaciones ayuda a entender las tareas realizadas y las componentes utilizadas por el sistema para construir cada parte de la salida. A.5. Criterios para Evaluar las Técnicas de Extracción de la Información En esta sección se establecen los criterios de evaluación para las técnicas de Extracción de la Información. Para llevar a cabo esta tarea, se realizó un estudio del estado del arte con el objetivo de encontrar debilidades que se pueden subsanar con nuevos criterios de evaluación o bien seleccionar una aproximación que sea completa y se pueda adaptar facilmente al método descripto en la sección A.2.