Visualización de la colaboración en la evolución de ítems

Informe Técnico -Technical ReportDPTOIA-IT-2007-002

Julio, 2007

Visualización de la colaboración en la evolución de ítems de software con base en los repositorios de

las herramientas SCM

Antonio González Torres Roberto Therón Sánchez Francisco García Peñalvo

Departamento de Informática y Automática Universidad de Salamanca

Revisado por: Dr. D. Luis Antonio Miguel Quintales Departamento de Informática y Automática Universidad de Salamanca D. Pablo Santos Luaces Códice Software S.L.

Aprobado en el Consejo de Departamento del 25 de julio de 2007

Información de los Autores:

Antonio González Torres Estudiante de doctorado Departamento de Informática y Automática Facultad de Ciencias -Universidad de Salamanca Plaza de la Merced S/N – 37008 – Salamanca [email protected]

Dr. Roberto Therón Sánchez Departamento de Informática y Automática Facultad de Ciencias -Universidad de Salamanca Plaza de la Merced S/N – 37008 – Salamanca [email protected]

Dr. Francisco García Peñalvo Departamento de Informática y Automática Facultad de Ciencias -Universidad de Salamanca Plaza de la Merced S/N – 37008 – Salamanca [email protected]

Este documento puede ser libremente distribuido. (c) 2007 Departamento de Informática y Automática -Universidad de Salamanca.

Resumen

En este trabajo proponemos una visualización para la evolución de los ítems desoftware durante el desarrollo de proyectos, utilizando como fuente de informaciónlos repositorios de datos de las herramientas de Administración de la Configuraciónde Software (SCM). Nuestra propuesta contempla la utilización de una estructuramatricial para visualizar la colaboración de los programadores en el desarrollo de unítem de software, un grafo para la representación de la estructura de las baselines,así como técnicas de interacción para proporcionar múltiples vistas, ampliar unaregión, o ver y comparar baselines.

En este documento realizamos una revisión bibliográfica de las principales técni-cas de Visualización de información utilizadas en la actualidad y recogemos variaspropuestas que buscan resolver el problema de la visualización de la evolución de lasversiones de software. Finalmente presentamos la propuesta de visualización, anali-zamos un caso de estudio, hacemos un resumen del trabajo, y discutimos nuestrasprincipales conclusiones y futuras líneas de trabajo.

Abstract

In this work we propose a visualization for the evolution of software items duringthe development of projects, using as the information source the data repositories ofthe Software Configuration Management (SCM) tools. Our proposal took into con-sideration a grid structure for the visualization of the collaboration of programmersin the development of software items, a graph structure for the representation ofbaselines and several interaction techniques for the creation of multiple views, zoominto areas, or view and compare baselines.

In this document we review the main information visualization techniques usedat the present time, as well as several proposals that look for solving the visualizationproblem of the evolution of software items. Then, we present our proposal for thevisualization and analyze a case study. Finally, we make a summary of the work anddiscuss the main conclusions and future research lines.

DPTOIA-IT-BORRADOR i

Índice

Índice de figuras iii

Indice de tablas v

1. Introducción 1

2. Antecedentes y conceptos relacionados 1

3. Revisión de técnicas de visualización 7

4. Visualización de la evolución de versiones de software 28

5. Diseño de la visualización y resultados 36

6. Conclusiones y líneas de trabajo futuro 47

Referencias 49

ii DPTOIA-IT-BORRADOR

Índice de figuras

1. Instantáneas en repositorio. . . . . . . . . . . . . . . . . . . . . . . . 52. Diagrama de flujo del proceso de administración de la configuración

de software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63. Taxonomía de las técnicas de visualización para grandes cantidades

de información. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74. Funciones de transformación y ampliación . . . . . . . . . . . . . . . 95. Ampliación simple de una área de interés. . . . . . . . . . . . . . . . 96. Técnica bifocal para la visualización de información. . . . . . . . . . . 107. Visualización aumentada mediante la utilización de la técnica del ojo

de pez. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118. Ejemplo de la técnica polifocal. . . . . . . . . . . . . . . . . . . . . . 119. Utilización de la técnica Ojo de pez sobre opciones de texto de un

menú. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1210. Técnica Ojo de pez aplicada al mapa de una ciudad. . . . . . . . . . . 1311. Ejemplo de utilización de la técnica TableLens. Tomado del sitio web

http://www.inxight.com/products/sdks/tl de Inxight Software, Inc. . 1312. Visualización de las variables del registro médico de un paciente. . . . 1413. Muestra la estructura de una tarea. . . . . . . . . . . . . . . . . . . . 1414. Ejemplo de una programación de tareas sencillas utilizando la técnica

PlanningLine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1515. Ejemplo del uso de la técnica Perspective Wall, según la versión orig-

inal presentada Mackinlay. . . . . . . . . . . . . . . . . . . . . . . . . 1616. Construcción de un Treemap tomando como referencia un árbol. . . . 1617. Ejemplo de un Treemap de Voronoi. . . . . . . . . . . . . . . . . . . . 1718. Visualización de ficheros en un disco duro mediante representaciones

circulares. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1819. Visualización hiperbólica circular. . . . . . . . . . . . . . . . . . . . . 1920. Visualización hiperbólica combinada con una estructura jerárquica. . 2021. Representación Cone Tree. . . . . . . . . . . . . . . . . . . . . . . . . 2122. Estructura semicircular propuesta por Andrews y Heidegger. . . . . . 2223. Ejemplo del método del “detalle angular”. . . . . . . . . . . . . . . . . 2324. Método del “detalle exterior”. . . . . . . . . . . . . . . . . . . . . . . 2325. Ejemplo del método del “detalle interior”. . . . . . . . . . . . . . . . . 2326. Ampliación del detalle correspondiente a un nodo en una visualización

circular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2327. Ampliación de anillos en una visualización circular. . . . . . . . . . . 2428. Árbol Spanning Tree con las aristas eliminadas codificadas con colores. 2429. Utilización de una representación Tree Ring para representar la evolu-

ción de una jerarquía en el tiempo. . . . . . . . . . . . . . . . . . . . 25

DPTOIA-IT-BORRADOR iii

30. Treevolution: representación de estructuras jerárquicas con evolucióntemporal, aplicado a la evolución de los lenguajes de programación. . 26

31. Utilización del color para mostrar la cantidad de citas en otros artículos. 2732. Contribuciones de diferentes autores a nuevas versiones de un docu-

mento y uso de colores. . . . . . . . . . . . . . . . . . . . . . . . . . . 2733. Aplicación de la aplicación de control de versiones a un documento

de la enciclopedia Wikipedia. . . . . . . . . . . . . . . . . . . . . . . 2834. Ejemplo de visualización con codificación de colores de acuerdo con

Voinea. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2935. Ejemplo de visualización con codificación de colores de acuerdo con

Voinea. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3036. Presentación del historial de versiones de un sistema propuesto por

Voinea. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3137. Historial de versiones de software haciendo uso de colores y texturas

para visualizar atributos. . . . . . . . . . . . . . . . . . . . . . . . . . 3138. Visualización de historial de versiones de software y representación

de un atributo mediante codificación de colores. . . . . . . . . . . . . 3239. Método de visualización de versiones de software mediante una matriz

de versiones desarrollado por Lanza. . . . . . . . . . . . . . . . . . . . 3340. Resumen de herramientas para la visualización de datos de la admi-

nistración de versiones de código tomado de [35]. . . . . . . . . . . . 3441. Representación de líneas de código producida por CVSViewer3D. . . 3442. Visualización de historial de versiones de software y representación

de un atributo mediante codificación de colores. . . . . . . . . . . . . 3543. Diseño propuesto para la matriz de versiones (figura girada 90◦). . . . 3744. Detalle del diseño propuesto para la matriz de versiones (figura girada

90◦). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4045. Vista normal del Revision Tree y el Baseline Navigator (figura girada

90◦). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4146. Visualización de un árbol de versiones en 3D. . . . . . . . . . . . . . 4247. Manipulación del segmento de árbol presentado en la figura 47. . . . . 4248. Segmento del árbol en 3D correspondiente al mostrado en la figura

44 de la versión matriz de versiones en 2D. . . . . . . . . . . . . . . . 4349. Visualización realizada por Perforce. . . . . . . . . . . . . . . . . . . 4550. Visualización de la colaboración en las baselines mediante anillos cod-

ificados con por colores. . . . . . . . . . . . . . . . . . . . . . . . . . 4651. Visualización de la colaboración en las baselines mediante anillos cod-

ificados con por colores. . . . . . . . . . . . . . . . . . . . . . . . . . 4652. Antigüedad de los cambios realidos en los nodos de una baseline. . . . 47

iv DPTOIA-IT-BORRADOR

Indice de tablas

1. Términos y conceptos utilizados en la administración de la configu-ración de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Elementos visuales y variables representadas por la visualización delRevision Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3. Comparación de las herramientas de visualización para la representa-ción de árboles de revisión . . . . . . . . . . . . . . . . . . . . . . . . 43

DPTOIA-IT-BORRADOR v

.

Antonio González et al.

1. Introducción

El desarrollo de un producto de software es un complejo proceso que requierede una estrecha colaboración, comunicación y coordinación entre los diseñadores,desarrolladores y administradores del proyecto. Los participantes en el desarrollopueden formar parte de equipos de trabajo distribuidos en diferentes localidadesgeográficas con idiomas nativos distintos y participar en una o varias etapas delciclo de vida del sistema. Así, resulta de gran importancia contar con informaciónprecisa sobre las tareas que ejecuta cada participante y la colaboración que tienelugar durante el ciclo de vida de un sistema.

En este punto es relevante hacer referencia al estándar IEEE 828-1990 [4] el cualdefine el proceso de administración de la configuración del software y la documenta-ción como “un sistema que proporciona los métodos y herramientas para identificary controlar el software durante su desarrollo y uso. Las actividades de este proce-so incluyen la identificación y establecimiento de puntos de referencia; la revisión,aprobación y control de cambios; el seguimiento y reporte de esos cambios; las au-ditorías y revisiones de la evolución de un producto software”. En este contexto,las herramientas de administración de la configuración de software, conocidas comoherramientas SCM1, apoyan dicho proceso y los repositorios de éstas se conviertenen un elemento fundamental para el almacenamiento y posterior recuperación deinformación sobre baselines, revisiones, fechas, horas y autores de los cambios quesufre un sistema o ítem de software.

Este trabajo se enfoca en la visualización de la evolución de los ítems de softwarey la colaboración que tiene lugar durante su desarrollo. Para ello hacemos uso dealgunos elementos de información que proporcionan los repositorios de datos de lasherramientas SCM.

En la sección 2 de este documento estudiamos en detalle el proceso de admi-nistración de la configuración de software y algunos conceptos relacionados, en lasección 3 realizamos una revisión de las principales técnicas de visualización exis-tentes y en la sección 4 efectuamos una revisión bibliográfica sobre la visualizaciónde la evolución de versiones de software. Finalmente, en la sección 5 presentamosnuestra propuesta y un prototipo que desarrollamos para validar el diseño; en lasección 6 hacemos un resumen del trabajo y discutimos las principales conclusiones.

2. Antecedentes y conceptos relacionados

La administración de la configuración de software consiste en controlar la evolu-ción de sistemas complejos [9] o, de forma más detallada: es el proceso que administrala evolución de un proyecto de desarrollo hasta obtener un producto de software osistema, contemplando todos los niveles de comunicación de la organización e in-cluyendo todas las modificaciones que los programadores realizan al código. Para

1En su acepción del inglés, Software Configuration Management tools

DPTOIA-IT-BORRADOR 1

Visualización de la colaboración en la evolución de ítems de softwarecon base en los repositorios de las herramientas SCM

cumplir con ese cometido, los sistemas de administración de la configuración desoftware deben proporcionar servicios de administración del repositorio de compo-nentes y asistencia en el proceso de control manteniendo un historial sobre quécambios han sido realizados, quien los realizó y en qué fecha u hora. Además debenbrindar soporte al espacio de trabajo del desarrollador, así como al trabajo colabora-tivo mediante la administración de múltiples usuarios que intentan realizar cambiosa un mismo objeto.

Las funciones básicas que debe proporcionar un sistema de administración dela configuración son el control de versiones mediante procedimientos de check-out ycheck-in, soporte al desarrollo paralelo mediante el uso de ramas, así como facilidadespara la comparación y fusión2 de las ramas de un ítem.

La operación check-out consiste en indicar al sistema que se va a iniciar la mo-dificación de un fichero, cuyo contenido puede ser un documento o código, para querealice una copia y la entregue al espacio de trabajo del usuario. Mientras que laoperación check-in es ejecutada para notificar al sistema que la modificación ha fi-nalizado y que los archivos del área de trabajo del desarrollador deben ser copiadosal repositorio para dar origen a una nueva versión o revisión.

Una rama permite desarrollar de forma simultánea múltiples versiones o modifi-caciones independientes a un ítem de software. La creación de una rama puede darorigen a una versión distinta del producto o permitir la modificación simultánea deítems de software. En caso de que una o varias ramas se hayan originado debidoa modificaciones del código, es posible fusionar esas modificaciones en otra rama oen la rama principal del ítem; siendo necesaria la intervención humana cuando doso más integrantes del grupo de desarrollo hayan efectuado cambios en una mismalínea o en un grupo común de líneas del código de un ítem de software o de cualquierdocumento.

La comparación de versiones permite ver las diferencias entre dos versiones a nivelde línea, resaltando las líneas que han sido agregadas, modificadas o eliminadas enla versión más reciente.

Los mecanismos para la administración de la colaboración entre los miembros deun equipo de desarrollo contemplan el bloqueo de un objeto y su posterior desbloqueouna vez que se ha modificado o bien permitir a varios de los desarrolladores accedera un mismo objeto de forma simultánea para posteriormente combinar o fusionar loscambios. Este último mecanismo consiste en la copia del objeto, la modificación deéste y su posterior combinación. Para estos mecanismos utilizaremos la terminologíausada por Collins-Sussman, Fitzpatrick y Pilato [7], por lo que al primer mecanismolo denominaremos como lock-modify-unlock (bloquear, modificar y desbloquear) y alsegundo como copy-modify-merge (copiar, modificar y combinar), siendo este últimoel más utilizado en la actualidad; por lo que asumiremos de ahora en adelante quees el mecanismo utilizado cuando se omita indicarlo de forma explícita.

Las herramientas de administración de la configuración se pueden clasificar segúnsu arquitectura en centralizadas, distruibuidas o peer to peer.

2Merge por su significado en inglés.

2 DPTOIA-IT-BORRADOR


Las herramientas con repositorios centralizados proporcionan facilidades paraque los desarrolladores puedan realizar sus labores mediante conexiones directas conel repositorio o copiando los ítems de software en que se encuentra trabajando a surepositorio local cuando hace check-out.

Las herramientas con arquitectura distribuida deben implementar mecanismos decomunicación y administración adicionales para proporcionar los servicios requeridospor los programadores, mediante:

1. Apoyo a la colaboración a través de una vista consistente del repositorio.

2. Tolerancia a fallos.

3. Soporte para ambientes de trabajo heterogéneos.

Tabla 1: Términos y conceptos utilizados en la adminis-tración de la configuración de software

Términos ConceptoVersión Es una secuencia de copias de un ítem, cada una incorporando

nuevas modificaciones. Cada versión es identificada por unnúmero en la forma X.Y donde Y es el número de revisión yX es el número de versión. El número de versión aplica a todoel sistema y no a un componente en particular.

Revisión Son cambios menores realizados a la versión de un sistema oítem.

Baseline Las baselines son utilizadas en este documento de forma análo-ga a las versiones, con la diferencia que se enfatiza en los cam-bios de la estructura del proyecto entre una y otra versión.

Repositorio Estructura de información que almacena la información rela-tiva a la evolución de los proyectos de desarrollo y los ítemsde software.

Proyecto Conjunto de programas y documentos relacionados con el de-sarrollo de un sistema.

Workspace Es el espacio o área de trabajo local que almacena los ítemsde software o documentos durante el proceso de modificaciónefectuado por cada desarrollador.

Ítem Hace referencia a un componente básico de software, comouna clase, o a un documento de texto.

Check-out Es la operación que cambia el atributo read-only3 a modify4

para crear una nueva revisión de un ítem de software.Check-in Esta operación envía las actualizaciones de una revisión al

repositorio para convertirla en una revisión regular.Continúa en la siguiente página

3Atributo de solo lectura4Atributo de modificación



Términos y conceptos utilizados en la administración de la configuración de softwareTérminos Concepto

Rama5 Las ramas son utilizadas para soportar la concurrencia y mo-dificaciones paralelas a los ítems de software.

Main Esta es la rama principal de la evolución de un ítem. En ellase integran todas las ramas o revisiones realizadas a éste.

Actualización Consiste en actualizar las áreas de trabajo con los cambiosque haya sufrido el ítem desde que el desarrollador hizo check-in hasta el momento. La actualización ocurre a petición delprogramador con el de contar con las últimas modificacionesrealizadas por otros usuarios.

Fusión6 Fusiona dos revisiones del mismo ítem que han sido modifi-cadas en paralelo.

Integración Se le llama así a la fusión de dos ramas en las cuales se hancreado varias revisiones del ítem.

Rebalse Consiste en actualizar las ramas con los cambios que hayasufrido el ítem por las fusiones realizadas con la rama princi-pal.

Dichas herramientas hacen uso de servidores con copias del repositorio en cadauna de las localizaciones geográficas y pueden utilizar replicación en tiempo real oalmacenamiento caché combinado con sincronización periódica. Algunas aplicacionescomerciales utilizan esta arquitectura pero mantienen un servidor central con unacopia maestra del repositorio.

Por lo general estas herramientas permiten a cada programador contar con supropio ambiente de trabajo, al cual se copian los archivos que requiere modificarcuando hace check-out. Dichos archivos se vuelven a copiar en el repositorio del sitiocuando ha finalizado la modificación y ejecutado la operación check-in. En caso deque más de un miembro del equipo haya trabajado sobre el mismo componente, serealiza la fusión de los archivos. La tabla 1 presenta un resumen de algunos términosrelevantes relacionados con la administración de la configuración del software.

Por otro lado, existen herramientas con arquitecturas distribuidas del tipo peer-to-peer que le proporcionan [9] al desarrollador un ambiente de trabajo con elrepositorio de componentes completo y cuando se realiza un cambio éstos son repli-cados a los otros repositorios. En esta arquitectura los repositorios pueden funcionarcomo clientes y servidores de otros repositorios. SVK (http://www.svk.elixus.org)y Git (http://git.or.cz) son ejemplos de herramientas de arquitecturas distribuidasmientras BitKeeper (http://www.bitkeeper.com) es distribuida del tipo peer-to-peer.

Las estructuras de almacenamiento que utilizan estas herramientas van desdearchivos de texto plano hasta bases de datos. Lo más común es el uso de estructurasde archivos, bases de datos y la combinación de ambas. En el caso de SVK y Subver-

5Branch por su connotación en inglés6Merge en inglés



Figura 1: Instantáneas en repositorio.

sion (http://subversion.tigris.org), el repositorio es un sistema de archivos en formade árbol que recuerda todos los cambios realizados a cada archivo y directorio dentrodel árbol. Herramientas como ClearCase (http://www.ibm.com/)hacen uso de basesde datos, mientras que otras como PlasticSCM (http://www.codicesoftware.com)hacen uso de una combinación de bases de datos y el sistema de archivos.

Cada vez que estas herramientas leen información del repositorio lo hacen de laúltima versión almacenada, pero también proporcionan acceso a los estados previosdel sistema de archivos. El repositorio puede almacenar información de múltiplesproyectos o de solo un proyecto. En el caso de las herramientas que hacen uso deuna estructura de archivos se almacena cada proyecto en un subdirectorio en elsistema de archivos, por lo que cuando un desarrollador hace check-out se copiael subdirectorio del proyecto en el cual está trabajando a su ambiente de trabajo.Cada vez que el usuario actualiza la estructura y envía los cambios al repositoriose crea una nueva revisión de éste, es decir una nueva instantánea7 del estado delrepositorio. La figura 1, tomada de [7], muestra un ejemplo de visualización delrepositorio utilizado por Subversion. Las instántaneas del sistema de archivos paracada versión son denominadas baselines a efectos de este documento.

En el caso de las herramientas que hacen uso de bases de datos para la repre-sentación del repositorio, se representa mediante el uso de registros y campos lasucesión de cambios. Así, de igual forma es posible tomar una versión o revisiónparticular para trabajar sobre ella, o bien trabajar sobre la última revisión. Con

7Las instántaneas o vistas se denominan snapshots en su acepción del inglés



Figura 2: Diagrama de flujo del proceso de administración de la configuración desoftware.

estas herramientas también es válido ver cada versión como una instánea o baseline.

Otro detalle importante a mencionar es que el manejo de versiones es un procesoatómico en el cual se cambia el número de versión para todo el conjunto aunque sólohaya modificado un archivo, tomando como referencia el número de versión mayorpresente en todo el conjunto de archivos.

La figura 2 muestra el proceso completo de administración de la configuraciónde software, en donde las cajas con líneas discontinuas muestran pasos opcionales.El proceso presentado en dicha figura es de carácter general y por lo tanto puedediferir con el uso de cada herramienta.



3. Revisión de técnicas de visualización

Figura 3: Taxonomía de las técnicas de visualización para grandes cantidades deinformación.

El problema de la visualización consiste en desplegar una gran cantidad de in-formación navegable en un espacio muy reducido [17]. Así, es necesario combinardiferentes técnicas de visualización e implementar mecanismos de interacción quepermitan navegar a través de los datos sin perder de vista el contexto, pero queademás proporcionen medios que faciliten la interpretación de elementos particu-lares.

La meta de toda nueva propuesta de visualización debería ser proporcionar unarepresentación visual intuitiva que requiera poco esfuerzo de aprendizaje y puedaser integrada dentro de las técnicas existentes.

El diseño de una representación visual se puede efectuar considerando la estrate-gia de diseño espacial, temporal o ambas. El diseño espacial utiliza la distribucióny diseño gráfico para presentar la información en una sola vista, mientras que laestrategia del diseño temporal hace uso de transiciones de vista para distribuir lainformación entre múltiples vistas [18]. La utilización conjunta de ambas estrate-gias permite crear diseños con múltiples vistas y se apoya en el uso de técnicas deinteracción para lograr proporcionar facilidades de navegación y filtrado.

Las técnicas de visualización se pueden categorizar de forma general como orien-tadas a la distorsión o no orientadas a la distorsión. La figura 3 muestra una taxono-mía preparada por Leung [17] para técnicas orientadas a la visualización de grandescantidades de información basadas en esas dos categorías.



Una vista distorsionada es creada mediante la aplicación de una función matemáti-ca de transformación a una imagen sin distorsiones. Lo que define esta función escómo la imagen original será asociada a una vista distorsionada. Las funciones deampliación son funciones derivadas de la función de transformación y proporcionaun perfil de los factores de acercamiento o alejamiento asociados al área de interésen la imagen sin distorsiones.

Las técnicas no orientadas a la distorsión son adecuadas para aplicaciones de pe-queño tamaño que se encuentran basadas en texto pero no proporcionan un contextoadecuado para soportar la navegación en un conjunto de información a gran escala.Por otro lado, las técnicas orientadas a la distorsión permiten al usuario examinar deforma dinámica e interactiva datos en detalle en una sección de la pantalla mientrasse presenta una vista global del espacio en que se encuentra inmersa. Dentro de losmecanismos de interacción que se pueden proporcionar al usuario se encuentran:

Selección

Navegación

Filtrado

Enlace

Zoom

Las técnicas orientadas a la distorsion se utilizan en conjunto con funciones detransformación que definen la forma en que la información será presentada al usuarioy la interacción que tendrá lugar. Dentro de las técnicas orientadas a la distorsionse pueden mencionar las siguientes:

Técnicas de ampliación (Bifocal – Polifocal – Ojo de Pez)

Table Lens

Perspective Wall

Espacios hiperbólicos

Circular

Jerárquica (Tree Map – Cone Trees – estructuras circulares)

Líneas de vida

Líneas de planificación

Las técnicas de ampliación hacen uso de de funciones de transformación y am-pliación para amplificar una área, como ilustra la figura 4 tomada de [17], en dondela función de transformación representa la tasa de cambio con distancia desde el



Figura 4: Funciones de transformación y ampliación

Figura 5: Ampliación simple de una área de interés.



Figura 6: Técnica bifocal para la visualización de información.

punto del foco y la función de ampliación controla la ampliación en el punto delfoco.

Estas técnicas de visualización se combinan en la etapa de diseño de una soluciónde visualización de información con el objetivo de brindar mayores posibilidades devisualización y navegación. En este contexto las técnicas de ampliación revisten granimportancia debido a que permiten revisar fácilmente ítems específicos de informa-ción que se encuentran inmersos u ocultos en grandes cantidades de información.Éstas técnicas se utilizan para ampliar un punto concreto, una zona vertical u hori-zontal o bien ampliar al mismo tiempo una zona horizontal y una zona vertical queintersectan en un punto determinado. La figura 5, tomada de [17], sirve para ilustrarel concepto de ampliación de un punto concreto en una visualización, mientras lasfiguras 6c y 6d ([17]), muestran la ampliación en una y dos dimensiones. La figura6a se corresponde con la función de transformación, mientras que la figura 6a conla función de ampliación. Es importante notar que la función de transformación re-presenta una distorsión no suavizada o abrupta, como queda patente al examinar lafunción de ampliación y las figuras que resultan de su aplicación. Aunque este tipode ampliación fue propuesta originalmente por [13] suele atribuirse a Robert Spencey Mark Apperley en 1982 [24].

Posteriormente, Furnas propone la técnica Ojo de Pez en 1986 [10]. Las figuras7c y 7d ([17]) muestran dos variantes de la técnica Ojo de Pez. En esta propuestala función de transformación tiene como resultado una curva suavizada, ver figura7a, y como consecuencia el pico de la función de transformación crece gradualmente,como lo muestra la figura 7b, lo que produce el efecto de una suave caída desde elpunto de foco hacia el resto de la visualización.



Figura 7: Visualización aumentada mediante la utilización de la técnica del ojo depez.

Figura 8: Ejemplo de la técnica polifocal.



Figura 9: Utilización de la técnica Ojo de pez sobre opciones de texto de un menú.

La aplicación de las técnicas de visualización para ampliar una área concreta re-sulta de gran utilidad, pero cuando se navega en un conjunto con gran cantidad deelementos es frecuente que resulte necesario comparar dos o más elementos. Para ellose utilizan de forma conjunta las técnicas de ampliación e interacción que permitanmostrar de forma ampliada y simultánea varias áreas a la vez. La figuras 8c y 8dmuestran la ampliación de varias áreas de interés o focos de forma simultánea y secorresponde con la técnica propuesta por Naftali Kadmon y Eli Shlomi en 1978 [13]para la presentación de datos estadísticos sobre mapas de cartografía. La ilustraciónen la figura 8a es la función de transformación de una proyección polifocal y repre-senta la tasa de cambio con distancia desde el punto del foco, mientras que la funciónde la figura 8b es la función ampliación y representa el foco de la presentación.

El “Ojo de Pez” permite mantener el contexto a la vez que se visualiza una áreaespecífica y se puede aplicar en conjunto con cualquier otra técnica de visualización;textual, tabular, jerárquica, circular, hiperbólica y líneas de vida y de planificación,entre otros.

Las figuras 9 y 10 muestran dos ejemplos del uso de la técnica del ojo de pez, endonde la primera muestra un ejemplo de visualización de texto y la segunda amplíaun sector del mapa de una ciudad.

Es importante hacer la distinción entre visualizar información con el ojo de pezy hacerlo con el zoom geométrico. El zoom geométrico permite al usuario especificarla escala del aumento cada vez que se amplié o reduzca el tamaño del área de interésy por lo general se encuentra fijada a un punto concreto y no conserva el contexto,mientras que el ojo de pez conserva el contexto (es decir, al centrarse en un área, sedeja de ver el resto).



Figura 10: Técnica Ojo de pez aplicada al mapa de una ciudad.

Figura 11: Ejemplo de utilización de la técnica TableLens. Tomado del sitio webhttp://www.inxight.com/products/sdks/tl de Inxight Software, Inc.

El zoom semántico cambia la forma o contexto en el cual la información estásiendo presentada. Un ejemplo de gran utilidad para entender esta técnica es el queproporciona Stephens [26] y en base al cual se desarrolla el siguiente: Se cuenta conuna agenda electrónica en la cual se visualiza el calendario anual de forma global,cuando el puntero se detiene sobre un mes este se amplía y visualizan los días de esemes y al concentrarse en un día particular se muestran las diferentes horas de esedía y al posicionarse sobre éstas se proporciona información sobre las citas o tareasprogramadas.

La técnica de visualización denominada como Table Lens es del tipo foco + con-texto y funciona de forma muy efectiva sobre grandes cantidades de informacióndispuesta en forma tabular [21], en donde mediante una lente bifocal se puede am-pliar una o varias filas y columnas a la vez, el ancho de la columna se puede ampliarcon el ratón, se pueden crear subgrupos de columnas y se pueden realizar filtradossobre el conjunto de datos. La figura 11 muestra un ejemplo de la técnica Table Lensque ha sido desarrollado por Inxight.



Figura 12: Visualización de las variables del registro médico de un paciente.

Figura 13: Muestra la estructura de una tarea.



Figura 14: Ejemplo de una programación de tareas sencillas utilizando la técnicaPlanningLine.

La presentación de información de eventos claves suscritos a un espacio temporaly relacionada con dos o más variables se puede exponer haciendo uso de representa-ciones tabulares apoyadas por elementos con combinaciones de colores, líneas dediferentes grosores y el uso de etiquetas. Dos referencias de gran utilidad son laspropuestas por Catherine Plaisant [20] y Wolfgang Aigner [1]. Plaisant aborda elproblema de visualización del historial médico de un paciente mediante una visua-lización denominada como LifeLines, la cual se ilustra en la figura 12, y relacionaun grupo de variables como notas, hospitalizaciones, exámenes, medicamentos, otrostratamientos y vacunas con el espacio temporal, pero además utiliza etiquetas paraidentificar cada una de las instancias de estas variables. Por otro lado Aigner pro-pone visualizar la planificación de tareas de una forma similar a los diagramas deGantt, pero agrega valor semántico a la exposición mediante el uso de colores paraindicar la duración mínima y máxima de las tareas, y el uso de líneas para indicarel inicio prematuro o finalización posterior a las planificadas. La figura 13 muestrala estructura de una tarea mientras que la figura 14 exhibe un ejemplo sencillo deeste tipo de visualización denominado como PlanningLine, que es considera del tipovista general + detalle.

La técnica Perspective Wall integra la visualización de foco + contexto parabrindar soporte haciendo uso de animación interactiva en 3D a información estruc-turada de forma lineal [18]. Dicha técnica utiliza un panel frontal para visualizaruna área de forma detallada y dos paneles laterales en perspectiva para presentarel contexto y fue propuesta originalmente para la administración de documentos yficheros, pero su uso se puede extender a cualquier problema que contenga un altocontenido temporal. La figura 15 muestra un ejemplo de ésta visualización.

La técnica de visualización conocida como Treemaps fue propuesta en 1991 porBrian Johnson y Ben Shneiderman [12] como una alternativa para visualizar informa-ción jerárquica en un espacio rectangular en 2-D utilizando el 100% de la superficiedisponible, proporcionando controles interactivos, facilitando la rápida extracción deinformación con una baja carga perceptiva y cognitiva, a la vez que se proporciona



Figura 15: Ejemplo del uso de la técnica Perspective Wall, según la versión originalpresentada Mackinlay.

Figura 16: Construcción de un Treemap tomando como referencia un árbol.



Figura 17: Ejemplo de un Treemap de Voronoi.

una presentación estéticamente placentera. De acuerdo con los autores este tipo devisualización resulta adecuado para jerarquías en las cuales la estructura es de granimportancia y la información asociada con los nodos internos se deriva de sus hijos.El método consiste en hacer corresponder la información jerárquica con la estructurarectangular, como se muestra en la figura 16 en la cual el árbol tienes dos ramas yse asigna el 50 % de la superficie del treemap a ésta y el otro 50 % se divide entre losnodos de la rama derecha. La asignación del espacio de la rama derecha se asigna deforma similar, a la rama izquierda se le asigna el 50 % del espacio, es decir el 25 %del total, y el otro 50 % a la rama derecha. El espacio correspondiente a la ramaderecha – izquierda del árbol se reparte entre los nodos hijos de ésta.

En [3] se presenta una variante de la propuesta original de los Treemaps basa-da en rectángulos y denominada Treemaps de Voronoi. Esta variante se aplicó ala visualización de métricas de software y en lugar de utilizar rectángulos empleapolígonos. Las razones que brindan los autores para utilizar esta variante son lassiguientes:

Al realizar la distribución la subdivisión del espacio se realiza sólo en unadimensión, teniendo como resultado rectángulos cuyo alto es desproporcionadomientras que el ancho es apenas perceptible



Figura 18: Visualización de ficheros en un disco duro mediante representacionescirculares.

En las modificaciones en las cuales la subdivisión se realiza en dos dimensionesla figura resultante se acerca a un cuadrado, por lo que el ancho y el altoconverge en uno.

El otro inconveniente es que con la modificación de subdivisiones en dos di-mensiones no se distingue la relación entre los nodos.

El uso de los Treemaps con subdivisiones en una y dos dimensiones no permitereflejar de forma fiel el área que correspondería a cada valor que se quiererepresentar.

Mediante el uso de polígonos es posible abarcar el área que corresponde a cadavalor que se requiere representar debido que éstos se pueden adaptar mejor al entornoal contar con un número variable de bordes. La figura 17 muestra un ejemplo de losTreemaps de Voronoi [3].

Otra implementación que resulta interesante considerar es la que propone KarlWetzel [34] para la visualización de ficheros en un disco duro y que en lugar deutilizar rectángulos, cuadrados o polígonos propone el uso de componentes circularescodificados por colores 18. Sin embargo, aunque esta visualización resulta vistosa no



Figura 19: Visualización hiperbólica circular.

aprovecha todo el espacio de presentación y no es posible determinar a primeravista la relación jerárquica entre los componentes. Una referencia complementariade utilidad para entender esta técnica es el artículo de Teoh y Ma [27].

Shneiderman hace una revisión histórica de las diferentes versiones que existensobre los Treemaps en [23].

La visualización hiperbólica fue propuesta como una técnica de visualización deltipo foco + contexto con capacidad para manipular grandes jerarquías de informa-ción. De acuerdo con Lamping [15] es posible presentar hasta 1000 nodos de loscuáles 50 se encuentran cerca del foco y puede desplegar etiquetas de texto concontenido significativo. Sin embargo, se debe evitar la tentación de desarrollarlas en3D debido a que la navegación en éstas estructuras resulta compleja y hace difícillograr obtener información útil de forma sencilla. La figura 19 es un ejemplo de estetipo de visualización, en la cual inicialmente se despliega un árbol con su raíz como



Figura 20: Visualización hiperbólica combinada con una estructura jerárquica.

elemento central conectado a unos cuantos nodos que mediante el uso de técnicas deinteracción hacen posible traer a escena elementos adicionales pero también sacara otros de ésta. Los nodos de más bajo nivel en la representación mostrada en lafigura 19 son los que se encuentran en el borde de la circunferencia.

La representación hiperbólica de la figura 20 representa una estructura semi-jerárquica en donde puede existir una relación no jerárquica entre pares. Esta visua-lización puede resultar de utilidad para representar la organización de carpetas y losmovimientos de elementos entre éstas. En nuestro caso podría ser considerada en elfuturo para la representación del repositorio de las herramientas de administraciónde versiones de código o las estructuras de las baselines.

Sin lugar a dudas, la visualización hiperbólica es una técnica de visualizaciónque reviste gran importancia en el mundo de la visualización de información, por lariqueza que proporciona su estructura correctamente combinada con las técnicas deinteracción apropiadas.



Figura 21: Representación Cone Tree.

La técnica de visualización denominada como Cone Trees [22] consiste en unavisualización animada en 3D de datos jerárquicos cuya raíz se encuentra en la partesuperior de la presentación y los descendientes se dibujan en las capas inferiores,permitiendo la interación para expander o contraer la estructura cuando se navegaa través de ella, así como para seleccionar diferentes elementos. Conforme se bajaen la estructura el diámetro de cada nivel se reduce para asegurar que la estructurase ajuste al ancho del área de despliegue. Además, cuando un nodo se selecciona, laestructura rota para mostrar el nodo seleccionado y el camino hacia la parte superiorde la jerarquía. De acuerdo con las autores de esta visualización se realiza en 3Dporque se maximiza el uso efectivo del área de presentación y visualiza la estructuracompleta. La figura 21 es un ejemplo de este tipo de representación.

Sin embargo, los resultados que se muestran en [6] evidencian que la localizaciónde elementos en estructuras cónicas tridimensionales es más lenta que al realizarlovisualizaciones de árbol en 2D. Por otro lado el desempeño de la estación de trabajose ve reducido significativamente cuando la densidad del árbol aumenta. Lo anteriorestuvo en detrimento del entusiasmo que suscitaron las visualizaciones en 3D entrelos usuarios que también probaron la solución en 2D. Una apreciación adicional sobrela visualización en 3D es que no proporciona una forma de enfocarse en una partede la estructura sin perder el contexto.

Las técnicas de representación circular y semicircular se usan mayoritariamentepara visualizar información jerárquica, existiendo diversas propuestas como [2, 25].Además, de las que también proponen [19, 27, 36]. En las representaciones circulary semicircular la raíz del árbol de la jerarquía se dibuja en el centro de la estructuray los nodos hijo se reparten el área de los anillos concéntricos, de la misma forma enque se parte una torta pero con la variante de que cada porción se divide de forma



Figura 22: Estructura semicircular propuesta por Andrews y Heidegger.

sucesiva en cada anillo, conforme se desciende en la jerarquía, entre los hijos de unnodo. El área que ocupa cada nodo es proporcional a la cantidad de información quealmacenan y la cantidad de anillos representa la profundidad del árbol. La jerarquíase comienza dibujando de adentro hacia afuera, por lo que los ficheros y carpetasque se encuentran en los niveles más bajos de la jerarquía se dibujan en los discosque se encuentran más alejados del centro.

La técnica aplicada por Andrews y Heidegger a una estructura de directorioses expuesta en [2]. Dicha técnica utiliza uno o más semicírculos para visualizarjerarquías de gran tamaño en un espacio bidimensional. Cada semicírculo se componede varios discos que pueden ser configurados por el usuario y representan entre 5 y10 niveles de la jerarquía. Cuando un usuario selecciona un nodo de la jerarquía, sedespliega otro semicírculo con la información o estructura jerarquica que almacena.La figura 22 muestra un ejemplo en el cual ha sido seleccionado un nodo y se muestrala estructura que depende de éste.

Por otro lado Stasko y Zhang desarrollaron una herramienta de visualizaciónradial denominada Sunburst, que fue utilizada como base para realizar un estudio deusabilidad de la técnica de visualización radial y encontraron que la principal críticade usabilidad de los usuarios tenía relación con la díficil distinción de las líneascirculares cuando se visualizan jerarquías de gran tamaño que además contienengrandes voluménes de información. Por lo que en [25] proponen tres métodos; detalleangular, detalle externo y detalle interno.



Figura 23: Ejemplo del método del “detalle angular”.

Figura 24: Método del “detalle exterior”.

Figura 25: Ejemplo del método del “detalle interior”.

Figura 26: Ampliación del detalle correspondiente a un nodo en una visualizacióncircular.



Figura 27: Ampliación de anillos en una visualización circular.

[htb]

Figura 28: Árbol Spanning Tree con las aristas eliminadas codificadas con colores.

El método del “detalle angular”8 permite seleccionar y ampliar de forma paulatinauna área de interés mientras la vista general se continúa presentando de formareducida. En tanto el método denominado “detalle exterior”9 la estructura permaneceen el centro de la visualización, el área seleccionada emerge y se mantiene de formacercana al punto seleccionado y puede continuar expandiendóse hasta formar unanillo alrededor de la estructura principal. Mientras que el método detalle interior10

expande la estructura creando un anillo interno vacío en el cual dibuja el área deinterés que ha sido seleccionada como una estructura anidada. Las figuras 23, 24y 25 fueron tomadas de [25] para mostrar una secuencia de imágenes e ilustrarlos métodos mencionados anteriormente y dejar la inquietud sobre la convenienciade utilizar una u otra. En nuestro caso particular consideramos que la visualizacióncon los métodos “detalle angular” y “detalle interior” no proporcionan el mismo nivelde detalle que permite obtener el método “detalle exterior”, por lo que esta última

8Angular Detail en su acepción en inglés9Detail Outside por su nombre original en inglés

10El nombre original que los autores dan a ésta técnica es Detail Inside



representación podría resultar en una visualización más adecuada.

Figura 29: Utilización de una representación Tree Ring para representar la evoluciónde una jerarquía en el tiempo.

En [36] se presenta una variante de la visualización circular, denominada comoInterRing, y se sugiere el uso de diversas técnicas con las que se pretende supe-rar algunas de las limitaciones de este tipo de presentación. Dentro de las técnicassugeridas por el autor se encuentran la de visualización multifocal, uso del zoom ypanning, rotación y operaciones del tipo “arrastrar y soltar”11, selección manual ysemiautomática, así como coloreado de nodos. Mediante el uso de éstas técnicas esposible ampliar el área que corresponde a un nodo, es decir, hacer más grande laporción de torta que le corresponde para visualizar mejor el detalle del contenido.También es posible ampliar un determinado anillo de la estructura mediante el usodel ratón. La figura 26 muestra un ejemplo en el cual se expande el área correspon-diente a un nodo, mientras que la figura 27 presenta un caso en el cual se amplíanlos anillos de una visualización (figuras tomadas de [36]).

Otras variantes de visualización circular, que además también se pueden clasificarcomo hiperbólicas, son las que presentan [19, 27] para la visualización de árboles deltipo Spanning Tree. Los árboles del tipo Spanning Tree son grafos dirigidos sin ciclos,por lo que son ideales para la representación de las estructuras de los repositorios. Lavisualización de la figura 28 propuesta en por Pavlo en [19] resulta de especial interésal mostrar mediante codificación de colores la eliminación de aristas al convertir elgrafo en un grafo dirigido, pues esta permitiría mostrar los cambios de la estructuradel un repositorio mediante líneas codificadas por colores.

Como se ha visto en ésta sección, las técnicas de visualización jerárquica pre-dominan en el área de visualización de información y combinan diferentes técnicaspara representar información multidimensional, en la mayoría de caso el color es unelemento predominante.

11Conocidas como drag and drop en inglés.



[h]

Figura 30: Treevolution: representación de estructuras jerárquicas con evolución tem-poral, aplicado a la evolución de los lenguajes de programación.

Therón propone un metáfora del tipo tree-ring denominada Treevolution [28]para representar estructuras basadas en jerarquías temporales con el fin de facilitarla navegación y descubrir relaciones en la historia de los lenguajes de programación.Esta visualización se encuentra estrechamente relacionada con las anteriores y podríaser utilizada para representar la evolución temporal de la estructura de una baselineo repositorio. La figura 29a es la representación de una estructura jerárquica cuyaevolución es representada por un tiempo t en cada nivel, en donde cada tiempo t secorresponde con un anillo de la figura 29b. Treevolution se fundamenta en el conceptoilustrado por las figuras 29a y b para representar la evolución de los lenguajes deprogramación, una ilustración de Treevolution es puede apreciar en la figura 30.

Además de las técnicas mencionadas anteriormente y los mecanismos de intera-cción que se pueden utilizar para realizar transformaciones y filtrados de informa-ción, es de gran importancia mencionar y resaltar el uso que se le puede dar al color



Figura 31: Utilización del color para mostrar la cantidad de citas en otros artículos.

Figura 32: Contribuciones de diferentes autores a nuevas versiones de un documentoy uso de colores.

para agregar significado y dimensiones a la visualización de información. En nuestrocontexto y basándonos en el articulo de Chen [5], el uso de color resulta de granutilidad para mostrar la colaboración que ha tenido lugar sobre un mismo fichero odirectorio. La figura 31 muestra el uso del color aplicado a la cantidad de citas queha recibido un artículo.

Las figuras 32 y 33 fueron tomadas de un trabajo realizado por Viegas y Watten-berg [29] en el cual visualizan los cambios realizados a un documento de la enciclo-pedia online Wikipedia. La figura 32 muestra la forma en que se utiliza el esquemade colores y la colaboración entre una versión y otra, mientras que la figura 33 esun ejemplo de uno de los análisis efectuados.



Figura 33: Aplicación de la aplicación de control de versiones a un documento de laenciclopedia Wikipedia.

4. Visualización de la evolución de versiones de soft-ware

Para los administradores de proyectos de desarrollo y sus equipos de trabajoresulta de gran valor tener conocimiento del proceso de evolución que sufren lossistemas y los ítems de software durante el proceso de desarrollo. Es pertinente contarcon información sobre la colaboración que ha tenido lugar durante el desarrollo decada ítem de software y el sistema en su totalidad, así como sobre información dela evolución de las mediciones realizadas mediante métricas de software.

La evolución de los ítems de software se basa en los cambios que son realiza-dos por los colaboradores del proyecto de desarrollo. De acuerdo con el trabajoexpuesto en [8] un cambio es cualquier alteración al software y se debe almacenaren el historial de la base de datos. Asimismo, los cambios se pueden categorizar entres tipos; adaptación, correctivos y perfeccionamiento. En donde los de adaptaciónagregan nueva funcionalidad al sistema, los correctivos reparan errores y los de per-feccionamiento buscan el mejoramiento de la calidad del código.

Pero además, a cada cambio se le pueden asociar ciertos atributos como la fechay hora, información sobre qué ficheros fueron modificados y cuáles líneas fueronagregadas o eliminadas, el desarrollador o autor del cambio, el tipo de cambio, laamplitud del cambio (cuántos ficheros y líneas fueron afectadas), el esfuerzo requeri-



Figura 34: Ejemplo de visualización con codificación de colores de acuerdo conVoinea.

do por la persona que realizó el cambio (medido en horas) y cuántos días calendarioduró en efectuarse la modificación. Los dos últimos puntos son controvertidos y soloqueremos resaltarlos sin entrar en su análisis.

En la misma investigación se realiza un revisión de algunas metáforas de vi-sualización que los autores consideran que podrían utilizarse de forma separada ocombinada en la visualización del repositorio de la administración de la configuracióny versiones:

Vistas de matrices.

Gráficas de barras en 3D.

Gráficas de barras o tipo pastel.

Hojas de cálculo.

Vistas de redes.

Utilización de perspectivas.

Manipulación directa mediante interacción.

Es también importante resaltar la exploración realizada, en el artículo menciona-do, al repositorio y el filtrado efectuado para obtener diferentes vistas del mismo:estadísticas básicas sobre los cambios efectuados, cambios indexados por tiempo,cambios indexados por desarrollador, tamaño de los cambios indexados por versiónliberada, actividad indexada por desarrollador y amplitud del cambio, y el periodode tiempo que abarcaron los cambios.

De forma adicional, aunque pueda parecer obvio, la gran cantidad de informa-ción de los proyectos almacenada en los repositorios puede ser utilizada para con-tabilizar un proyecto, realizar auditorías del desarrollo y entender la evolución de



Figura 35: Ejemplo de visualización con codificación de colores de acuerdo conVoinea.

éstos. Tomando esto como fundamento Voinea y Telea [32] sostienen que los esfuer-zos actuales de investigación por aprovechar el potencial de dichos repositorios seconcentran en los campos de la minería de datos y la visualización de información,y en menor medida en la extracción de datos. En este contexto la minería de datosse concentra en la extracción de información relevante de los datos primarios delrepositorio, la visualización de información se enfoca en la utilización de técnicasde visualización e interacción para permitir al usuario explorar grandes cantidadesde datos, mientras que la extracción de datos se centra en la recuperación de infor-mación y análisis sintáctico de los resultados de las consultas al repositorio de laherramienta de administración de la configuración.

La visualización propuesta despliega la evolución de un sistema completo comouna pila de componentes codificados por colores y en donde cada color representauna métrica. La figura 34 presenta la forma en que es visualizada la información,mientras la figura 35 muestra un ejemplo real que hace uso de una herramientadenominada CVSgrab [30].

El enfoque utilizado por CVSgrab [31] evoluciona con el uso de combinacionesde colores y texturas para la representación de atributos, como se ilustra en la figura36.

En esta herramienta los colores y texturas pueden representar atributos como elautor de una revisión, el tamaño de un componente o cualquier otro atributo querequiera ser visualizado. La figura 37 muestra un ejemplo de una visualización deeste tipo.



Figura 36: Presentación del historial de versiones de un sistema propuesto porVoinea.

Figura 37: Historial de versiones de software haciendo uso de colores y texturas paravisualizar atributos.



Figura 38: Visualización de historial de versiones de software y representación de unatributo mediante codificación de colores.

En otra investigación [11], Jazayeri y Riva proponen visualizar el historial deversiones del software haciendo uso de presentaciones en 3D y códigos de colores.Para ello capturan la evolución del software a través del tiempo en base a los cambiosque sufre la estructura y los atributos del software. En donde los atributos son elnúmero de versión, el tamaño y la complejidad. La propuesta consiste en visualizarpara cada componente las versiones y valores de un atributo a la vez, en donde cadavalor es representado por un color diferente. La figura 38 muestra un ejemplo deeste sistema de visualización.

Un método interesante para entender la evolución del software fue desarrolladopor Lanza en [16], que consiste en una matriz de evolución que utiliza las métricas desoftware para representar el desarrollo de un sistema en el tiempo. Los autores uti-lizan cajas rectangulares para representar las clases del sistema, en donde el ancho delas cajas representa el número de métodos y el alto la cantidad de atributos de dichasclases (ver figura 39). Sin embargo, se podrían realizar cambios a esta visualizaciónpara representar más de dos métricas tomando prestadas algunas ideas de [31] sobrecolores y texturas. Una de las grandes ventajas que ofrece la matriz de evoluciónpara visualizar un repositorio de versiones es que permite determinar fácilmente elcomportamiento de un sistema a través del tiempo; cuántos cambios se le han rea-lizado, si ha crecido, disminuido o se ha mantenido constante el número de líneaso métodos, cuántos autores han participado en el desarrollo, cuáles componenteshan sido creados o eliminados recientemente, cuáles componentes han crecido expo-nencialmente o visto reducido su tamaño de forma significativa, entre otras muchasposibilidades.

Según Xie, Poshyvanyk y Marcus en [35] las herramientas de visualización de



Figura 39: Método de visualización de versiones de software mediante una matrizde versiones desarrollado por Lanza.

repositorios de los sistemas de administración de la configuración pueden ser capacesde proporcionar al usuario un amplio espectro de información útil desde diferentesniveles de granularidad, sistema, fichero, método o línea, y su diseño puede ser guiadopor las siguientes preguntas:

¿Quién ha estado trabajo en los artefactos?

¿Cuáles autores trabajan en los mismos ficheros?

¿Cuáles tipos de modificaciones hizo el autor?

¿Cuándo fue hecha una modificación?

¿Por qué fue hecha una modificación?

¿Qué ficheros cambian juntos de forma frecuente?

¿Cuáles partes de código son estables?

¿Cuáles partes de código cambian frecuentemente?

¿Cuántos autores han trabajado en una versión de software?

¿Cuántos ficheros o líneas han sido agregadas o eliminadas?



Figura 40: Resumen de herramientas para la visualización de datos de la adminis-tración de versiones de código tomado de [35].

Figura 41: Representación de líneas de código producida por CVSViewer3D.



Figura 42: Visualización de historial de versiones de software y representación de unatributo mediante codificación de colores.

Tomando como base lo anterior, los autores efectuaron una revisión de herramien-tas de visualización de repositorios [35], cuyo resumen se puede observar en la figura40.

En el mismo trabajo se propone una herramienta denominada CVSViewer3Dpara extraer, procesar y visualizar la información de los repositorios de los sistemasde administración de versiones de código en los diferentes niveles de granularidadhaciendo uso de gráficos de barras en 2 y 3D. La figura 41 muestra un ejemplo devisualización del número de líneas de las clases de un proyecto.

Por otro lado Koike [14] propone una estructura de visualización para mostrarel historial de evolución de los elementos, presentando cada elemento en 2D perola representación completa en 3D como se ilustra en la figura 42. De acuerdo conel autor mencionado, algunas de las principales características de la presentaciónpropuesta son:

La estructura visualiza la evolución de los objetos a través de múltiples revi-siones y versiones.

Se puede apreciar la estructura de los módulos al permitir observar la relaciónentre los objetos.

Los usuarios pueden interactuar con el sistema seleccionando componentes.

Sin embargo, la aplicación no ofrece una vista del tipo foco + contexto que lepermita al usuario ubicarse en el espacio de la visualización. Lo anterior con laconsecuente desventaja de no poder relacionar la información que es examinada conel contexto general y de inducir al usuario a que se extravíe fácilmente. Más adelantese examinará esta visualización con más detalle al efectuar una comparación con elproblema de visualización que nos ocupa en el presente trabajo.



5. Diseño de la visualización y resultados

En esta sección presentamos nuestra propuesta en 2D para la visualización dela historia de la colaboración en el desarrollo de un ítem de software. Dicha visuali-zación consiste en una representación matricial para mostrar la colaboración entrelos desarrolladores del ítem de software y de un grafo que reproduce la estructurade las baselines. El objetivo de esta propuesta es mostrar las contribuciones de losmiembros del equipo a través de muchas revisiones, baselines y largos periodos detiempo sobre el mismo ítem o documento. Es importante considerar que la evoluciónde cada ítem de software o documento tiene intrínsicamente asociado un atributo detemporalidad, el cual es el elemento más importante que se requiere para entenderel proceso de evolución de cualquier sistema.

El diseño de la representación que describimos a continuación presentó variosretos de visualización: la presentación de grandes árboles de revisión donde las base-lines tienen muchas ramas y cada una tiene a su vez varias revisiones de ítems desoftware; la navegación a través del árbol de versiones mientras se ofrece una vistade foco + contexto; soportar la interacción necesaria para permitir la inspección demás de una baseline a la vez, exhibir la colaboración de los desarrolladores en eldesarrollo de cada baseline y relacionar toda la información con la línea de tiempo.

La figura 43 presenta la propuesta del diseño de nuestra propuesta denominadaRevision Tree. Por conveniencia de presentación hemos girado 90◦dicha figura parapresentar la mayor cantidad de detalle posible ya que la herramienta aprovecha elancho de la pantalla del ordenador para visualizar la representación temporal. Endicha figura mostramos tres vistas diferentes de una misma evolución de un ítem.

Por otro lado la tabla 2 muestra los elementos gráficos utilizados en el diseñoy la figura 44 es un segmento en el cual se pueden observar con mayor detalle lascaracterísticas de éste.

Decidimos utilizar una estructura matricial para mostrar la colaboración entrelos desarrolladores porque proporciona un mecanismo intuitivo para visualizar larelación de trabajo entre autores y baselines; las filas se utilizan para representara los autores mientras las columnas sirven para representar a las baselines. Sobrela estructura matricial descansa una línea de tiempo que se compone de una líneaazul que separa cada día, así como etiquetas mostrando la fecha y hora en que labaseline fue creada. El color de los días se alterna entre blanco y gris y se muestranalineadas por hora cada una de las revisiones creadas. Se utilizan diferentes colorespara distinguir entre la rama principal y las ramas creadas por cada programador:los nodos amarillos y las flechas anaranjadas se usan para la rama principal mientrasque las flechas azules y los nodos azules representan las otras ramas.



Figura 43: Diseño propuesto para la matriz de versiones (figura girada 90◦).



Tabla 2: Elementos visuales y variables representadas porla visualización del Revision Tree

ElementoVisual

Descripción Representación

Autores Nombre del desarrollador. Etiqueta con el nombre deldesarrollador.

Baseline Número de la baseline. Se despliega en el parte su-perior de la visualización.

Fecha Indica la fecha de creación de lasramas, baselines o revisiones.

La etiqueta con la fecha semuestra en la línea tempo-ral.

Columna por día Es el espacio gráfico para repre-sentar un día y la actividad queha tenido lugar;la creación de ra-mas, baselines y revisiones.

Una línea azul oscuro conflechas en los extremos.

Hora Muestra la hora cuando una nue-va rama o revisión ha sido crea-da en la rama principal o encualquier otra rama.

Una etiqueta con la hora semuestra en la línea tempo-ral.

Nueva ramaprincipal

Indica la creación de la rama prin-cipal.

Óvalo alargado de color púr-pura.

Nueva rama Muestra la creación de una nuevarama.

Óvalo alargado de coloramarillo.

Línea de la ramaprincipal

Resalta la rama principal delítem.

Línea de color naranja.

Arcos Conectan las ramas y revisionescreadas por el desarrollador quese encuentra trabajando en la ra-ma principal.

Arcos de color verde.

Revisiones de larama principal

Revisiones creadas en la ramaprincipal.

Nodos de color azul.

Línea de las ra-mas

La línea de las ramas conectan larama principal con otras ramas,dos ramas entre sí y las revisionesdentro de una misma rama.

Líneas verdes.

Revisión Representa la creación de unanueva revisión de un ítem de soft-ware.

Nodos de color amarillo.

Fusión Una fusión ocurre cuando uno omás ramas son combinadas con larama principal.

En la rama principal lasflechas entrantes prove-nientes de otras ramasrepresentan una fusión.

Continúa en la siguiente página



Elementos visuales y variables representadas por la visualización del Revision TreeElemento

VisualDescripción Representación

Día sin actividad Representa un día sin actividaden la creación de baselines, ramaso revisiones.

Una pequeña línea verticalde color azul en la línea tem-poral, para cada día sin ac-tividad.

Mes sin activi-dad

Indica un mes completo sinninguna actividad en la creaciónde baselines, ramas o revisiones.

Un círculo pequeño es uti-lizado en la línea temporalpara representar un mes es-table.

La estructura matricial permite enfocarse sobre uno o varios puntos a la vez,permitiendo ampliar ampliar una o varias columnas a la vez (ver figura 43b) o bienvarias filas (figura 43c), como lo indican las flechas de color negro.

Otros detalles de gran importancia que incluye el diseño, pero que no fueronimplementados en el prototipo, es que al seleccionar un nodo se resalten todas lasaristas que entran y salen de éste, así como el camino que sigue una arista cuandoésta es elegida. Otro detalle relevante es que los periodos en los cuáles no hay cambiosya sea por falta de actividad o por ser fin de semana se representan mediante el usode dos barras azules pequeñas dispuestas de forma vertical (ver figura 44). La figura45 es una vista normal del prototipo desarrollado que combina el Revision Tree y elBaseline Navigator.

A continuación analizaremos la funcionalidad y características del Revision Treey posteriormente lo haremos con el Baseline Navitator.

La figura 46 muestra la visualización de un árbol de versiones de la herramientaPlasticSCM12 que es equivalente al árbol de versiones mostrado en la figura 43.A primera vista, cuando se observa el árbol de versiones en 3D parece una buenasolución y resulta de un gran atractivo considerando la gran cantidad de adeptosa éste tipo de visualización. Sin embargo, al efectuar un acercamiento como el quese despliega en la figura 47 y comparar este segmento con el de la figura 44 es fácilnotar como en la solución en 3D se produce ocultamiento de información; los nodosque se encuentran al frente de la estructura esconden a los que se encuentran detrásde ésta. Adicionalmente, la navegación a través del árbol en la versión 3D resultaun tanto difícil debido que la estructura se mueve completa (no es ambiente virtualpor el que se puede navegar), no cuenta con una vista del tipo foco + contexto ypara ver toda la figura es necesario tener una vista global en la cual el árbol no tieneningún significado práctico.

Mientras, la solución en 2D proporciona una fácil exploración y se pueden notartodos los detalles de la colaboración mediante un rápido vistazo. Además, es posibleenfocarse en áreas específicas sin perder el contexto, ni tiempo al tratar de navegarpor la estructura. Aunque el Revision Tree se aprecia mejor en pantallas de gran

12http://www.codicesoftware.com/



Figura 44: Detalle del diseño propuesto para la matriz de versiones (figura girada90◦).



Figura 45: Vista normal del Revision Tree y el Baseline Navigator (figura girada90◦).



Figura 46: Visualización de un árbol de versiones en 3D.

Figura 47: Manipulación del segmento de árbol presentado en la figura 47.



Figura 48: Segmento del árbol en 3D correspondiente al mostrado en la figura 44 dela versión matriz de versiones en 2D.

tamaño, aún es espacios reducidos ayuda a obtener una idea general sobre la evolu-ción de un ítem. Lo anterior se ilustra en la figura 48, que expande en un 80% delárea de visualización la fila correspondiente a Borja.

Hasta este punto, el trabajo realizado por Ware [33] ha sido de gran ayuda:en él se analiza el uso de 3D en la visualización de información y propone el usode una actitud de 2 1/2D al diseñar representaciones; sugiere el uso consciente devisualizaciones en 3D en combinación con 2D para producir mejores soluciones.

La tabla 3 presenta una serie de preguntas sobre algunos elementos de informa-ción básicos que debe proporcionar una representación de la evolución de ítems desoftware o sistemas e indica mediante una X la herramienta que responde a cadapregunta. Las lista de preguntas pretende servir como orientación y se recomien-da agregar a ésta todas áquellas que puedan ser consideradas como pertinentes alrealizar un estudio comparativo más exahustivo al que presentamos en éste trabajo.

Tabla 3: Comparación de las herramientas de visualiza-ción para la representación de árboles de revisión

Preguntas PlasticSCM Koike Perforce RevisionTree

¿Cuántos programadoresestán participando en eldesarrollo de un ítem desoftware?

X X

¿Quiénes son los desarro-lladores que están con-tribuyendo a la evolucióndel ítem de software?

X

¿Quién es el programadorcon más contribuciones a laevolución de un ítem?

X



¿Cuántas baselines consti-tuyen el proceso de evolu-ción?

X

¿Existe alguna revisiónque no ha sido fusionada(merged) después de unlargo periodo de tiempo?

X X X

¿Cuánto ha durado el desa-rrollo de un ítem?

X X

¿Cuál baseline tiene más ra-mas y revisiones?

X X

¿Cuál rama tiene más revi-siones?

X X X X

¿Cuál es el periodo de tiem-po en que no hay actividad?

X X

¿Existe algún periodo detiempo en el cual el desa-rrollo del ítem se encontrabaestable y de pronto comenzóa tener una gran actividad?

X

¿Se puede comparar la ac-tividad de las baselines?

X

Al tratar de responder estas preguntas a partir de la figura ?? tomada de Plas-ticSCM es necesario efectuar rotaciones, ampliar determinadas áreas perdiendo elcontexto y hacer scrolling. Después de hacer estas operaciones se obtiene la figura 47,la cuál todavía no logra responder algunas preguntas en tanto que la correspondien-te visualización presentada en la figura 44 proporciona las respuestas a todas éstaspreguntas, incluso para un usuario con poca capacitación en el área, sin realizar ungran esfuerzo de interacción.

Al revisar las capturas de pantalla del prototipo se puede concluir que la visuali-zación resulta clara y responde las preguntas anteriores, así por ejemplo nos damoscuenta de que Borja ha hecho la mayoría de las contribuciones en las versiones 10 y11, el desarrollo del ítem inició el 23 de febrero y la revisión 11 se obtuvo despuésde 15 días, la baseline con más ramas y revisiones (en el segmento en estudio) es la11, las ramas 0162 y 0172 tienen el mismo número de revisiones, hay dos periodosde tiempo en los cuáles no hay actividad en el ítem; entre el 24 de febrero y el 27de febrero, así como entre el 1 de marzo y el 8 de marzo.

Con respecto a la visualización propuesta en [14] visualizando el repositorio deuna herramienta de administración de versiones de código, nuestras principales preo-cupaciones es que no proporciona una vista de foco + contexto, la navegación a travésde la estructura puede resultar complicada y el comportamiento de ésta presentaciónal visualizar en 3D sistemas complejos puede presentar inconvenientes principal-mente por las altas demandas de procesador y memoria, así como los problemas de



Figura 49: Visualización realizada por Perforce.

oclusión que pueden ocurrir.

Finalmente, la representación producida por Perforce que se ilustra en la figura49 ofrece una vista general + detalle, mostrando información acerca de las ramas,fusiones, permite obtener las fechas y hora de revisiones haciendo clic sobre los nodosy revisando la información en Tab Details que se encuentra localizado en el panelizquierdo. Sin embargo, esta visualization no proporciona información acerca de losprogramadores que están contribuyendo al desarrollo de un ítem, cuánto tiempo hanestado los programadores trabajando en ítem, sobre los periodos sin actividad, nipermite comparar dos baselines o ver la línea de tiempo en un rápido vistazo. Porotro lado, la representación es estática y no ofrece opciones de interacción.

Por otro lado, nuestra propuesta incorpora el Baseline Navigator para visualizar,comparar y obtener información la antigüedad de las modificaciones de las baselines.El Baseline Navigator es un grafo radial cuyos nodos representan las carpetas yficheros que forman una baseline. Mediante la interacción entre Revision Tree y elBaseline Navigator es posible visualizar la estructura y colaboración que ha tenidolugar en el desarrollo de cada baseline mediante un clic sobre esta y el botón ShowColaboration. La figura 50 muestra un acercamiento del Baseline Navigator y permiteobservar con mayor detalle la codificación de colores de los anillos concéntricos decada nodo, en donde cada anillo representa a un desarrollador que haya hecho unamodificación en ese nodo y cuando el ratón pasa por encima de él muestra su nombreen la esquina superior izquierda.



Figura 50: Visualización de la colaboración en las baselines mediante anillos codifi-cados con por colores.

Figura 51: Visualización de la colaboración en las baselines mediante anillos codifi-cados con por colores.



Figura 52: Antigüedad de los cambios realidos en los nodos de una baseline.

También es posible comparar dos baselines haciendo clic primero sobre la baselinecon menor numeración y luego sobre la baseline con la numeración más alta, yhaciendo clic sobre el botón Compare Baseline para ejecutar la comparación. Lafigura 51 muestra la comparación de dos baselines. En la figura se puede notar queen un sector del Baseline Navigator las líneas son más gruesas y combinan el colorrojo con el amarillo. El color rojo representa la revisión antigua mientras que laslíneas amarillas la revisión reciente.

Con el Baseline Navigator es posible determinar cuales nodos han sufrido cambiosde forma más reciente haciendo uso de colores en los nodos. En la figura 52 se puedennotar tres tonos de color verde, en donde el tono más claro representa la modificaciónmás reciente.

6. Conclusiones y líneas de trabajo futuro

El desarrollo de los ítems de software de un proyecto involucra el trabajo co-laborativo de muchos programadores a través de varios equipos de trabajo. Suscontribuciones en la creación de baselines, ramas y revisiones resultan de especial



interés para los administradores de proyectos.

La historia o evolución de los ítems de software proporcionan información acercade cuántos programadores están participando en el desarrollo, quiénes son los desa-rrolladores que están contribuyendo a la evolución, quién es el programador con máscontribuciones a la evolución de un ítem particular, cuántas baselines constituyen elproceso de evolución, cuánto tiempo ha tomado el desarrollo de un ítem, cuál base-line tiene más ramas y revisiones, cuál rama tiene más actividad en las revisiones, asícomo información relacionada que haga posible la extracción de conclusiones útilespara auditar y administrar el proceso de desarrollo.

En este trabajo revisamos una gran cantidad de autores y notamos que la ma-yoría coincide en que la información almacenada por los sistemas de administraciónde la configuración representan una fuente de datos de gran valor por contar con in-formación detallada sobre los diferentes componentes que conforman un sistema; endonde esa información contempla las horas en que se ha modificado un componente,quien ha realizado la modificación, cuáles autores han contribuido al desarrollo deun componente, el comportamiento de éste desde su creación (ha crecido, se hareducido o permanece estable), pero además permite determinar la relación entrecomponentes a partir de información como cuáles componentes cambian a la veze incluso cuáles son los autores que trabajan sobre esos componentes relacionados.Adicionalmente se revisaron una serie de técnicas de visualización con el objetivode explorar las diferentes posibilidades de visualización para el problema que nosocupa.

Finalmente, proponemos un diseño de visualización y comparamos su utilidaden relación con varias soluciones al problema de visualización de la evolución delsoftware, la colaboración entre los desarrolladores y los cambios en las baselines.La solución propuesta proporciona información de forma rápida mediante el usode técnicas básicas de interacción e incorpora la visualización y comparación debaselines.

Dicha solución ofrece una vista del tipo foco + contexto, una estructura matricialen combinación con un grafo para la visualización de las baselines (ambas resultanfamiliares para cualquier desarrollador), una línea de tiempo que guía al usuarioy le permite posicionarse en el espació temporal, así como varias posibilidades deinteracción para obtener información útil para el usuario. Con nuestra representa-ción el usuario puede obtener muchas respuestas acerca de la evolución del ítem,permitiendo que el equipo de trabajo esté informado sobre quien está trabajando enlas diferentes baselines y revisiones.

Considerando que la visualización siempre tiene visibles todas las revisiones, nosólo por demanda como la visualización en 3D, los usuarios pueden revisar todaslas baselines y revisiones en poco tiempo sin que ocurra ocultación de informaciónu oclusión. La línea de tiempo presenta el intervalo de tiempo completo desde queel ítem fue creado, soporta las comparaciones temporales y hace evidente la concu-rrencia de los programadores.

Adicionalmente, la interactividad agrega funcionalidad para filtrar datos o enfo-



carse en áreas específicas. En síntesis: la visualización en dos dimensiones ofrece unapresentación más clara y funcional en relación con la producida por PlasticSCM.Lo anterior se debe principalmente a que la visualización propuesta por PlasticSCMno soporta una vista de foco + contexto y solamente proporciona información útilen un nivel detallado pero el usuario requiere interactuar con el sistema por largotiempo para lograr obtener la información requerida. Esta presentación solo per-mite inspeccionar una revisión a la vez, mientras los nodos y etiquetas puede causaroclusión en el nivel general.

En futuros desarrollos se puede considerar la visualización del repositorio com-pleto mediante el uso de una representación matricial en la cual las filas representenlas clases y las columnas las diferentes baselines, mientras que en las celdas se re-presentan los programadores participando en la baseline mediante diferentes colores.Así por ejemplo, se puede acceder a la evolución de cada ítem en particular (medi-ante el Revision Tree presentado en este documento) haciendo clic sobre cada una delas clases en la columna. También se puede desarrollar otra estructura paralela paraasociar de forma directa los programadores a los componentes en que se encuentrantrabajando.

Referencias

[1] Wolfgang Aigner, Silvia Miksch, Bettina Thurnher, and Stefan Biffl. Planning-lines: novel glyphs for representing temporal uncertainties and their evaluation.In Information Visualisation, 2005. Proceedings. Ninth International Conferen-ce, pages 457–463. IEEE Xplore, 2005. [Citado en pág. 15.]

[2] Keith Andrews and Helmut Heidegger. Information slices: Visualising and ex-ploring large hierarchies using cascading, semi-circular discs. Late BreakingHot Topic Paper, IEEE Symposium on Information Visualization (InfoVis’98),1998. [Citado en págs. 21 y 22.]

[3] Michael Balzer, Oliver Deussen, and Claus Lewerentz. Voronoi treemaps forthe visualization of software metrics. In SoftVis ’05: Proceedings of the 2005ACM symposium on Software visualization, pages 165–172, New York, NY,USA, 2005. ACM Press. [Citado en págs. 17 y 18.]

[4] H.R. Berlack and M. Updike-Rumley. Ieee standard for software configurationmanager plans, 1990. [Citado en pág. 1.]

[5] Chaomei Chen. Citespace ii: Detecting and visualizing emerging trends andtransient patterns in scientific literature. Journal of the American Society forInformation Science and Technology, 1(57):359–377, 2006. [Citado en pág. 27.]

[6] Andy Cockburn and Bruce McKenzie. An evaluation of cone trees. In Pro-ceedings of the 2000 British Computer Society Conference on HumanComputerInteraction, 2000. [Citado en pág. 21.]



[7] B. Collins-Sussman, B. Fitzpatrick, and M. Pilato. Version Control with Sub-version. Sebastopol, CA USA: O’Reilly Media, Inc., 2004. ISBN: 0-596-00448-6.

[Citado en págs. 2 y 5.]

[8] Stephen G. Eick, Todd L. Graves, Alan F. Karr, Audris Mockus, and PaulSchuster. Visualizing software changes. IEEE Trans. Softw. Eng., 28(4):396–412, 2002. [Citado en pág. 28.]

[9] Jacky Estublier. Software configuration management: A roadmap. The Futureof Software Engineering, 2000. ISBN 1-58113-253-0. [Citado en págs. 1 y 4.]

[10] G. W. Furnas. Generalized fisheye views. In CHI ’86: Proceedings of the SIGCHIconference on Human factors in computing systems, pages 16–23, New York,NY, USA, 1986. ACM Press. [Citado en pág. 10.]

[11] Harald Gall, Mehdi Jazayeri, and Claudio Riva. Visualizing software releasehistories: The use of color and third dimension. In ICSM ’99: Proceedings of theIEEE International Conference on Software Maintenance, page 99, Washington,DC, USA, 1999. IEEE Computer Society. [Citado en pág. 32.]

[12] Brian Johnson and Ben Shneiderman. Tree-maps: a space-filling approach tothe visualization of hierarchical information structures. In VIS ’91: Proceedingsof the 2nd conference on Visualization ’91, pages 284–291, Los Alamitos, CA,USA, 1991. IEEE Computer Society Press. [Citado en pág. 15.]

[13] Naftali Kadmon and Eli Shlomi. A polyfocal projection for statistical surfaces.The Cartographic Journal, 15(1):36–41, Junio 1978. [Citado en págs. 10 y 12.]

[14] Hideki Koike and Hui-Chu Chu. Vrcs: Integrating version control and modulemanagement using interactive 3d graphics. In VL ’97: Proceedings of the 1997IEEE Symposium on Visual Languages (VL ’97), page 168, Washington, DC,USA, 1997. IEEE Computer Society. [Citado en págs. 35 y 44.]

[15] John Lamping, Ramana Rao, and Peter Pirolli. A focus+context techniquebased on hyperbolic geometry for visualizing large hierarchies. In CHI ’95:Proceedings of the SIGCHI conference on Human factors in computing sys-tems, pages 401–408, New York, NY, USA, 1995. ACM Press/Addison-WesleyPublishing Co. [Citado en pág. 19.]

[16] Michele Lanza. The evolution matrix: recovering software evolution using soft-ware visualization techniques. In IWPSE ’01: Proceedings of the 4th Interna-tional Workshop on Principles of Software Evolution, pages 37–42, New York,NY, USA, 2001. ACM Press. [Citado en pág. 32.]

[17] Y.K. Leung and M.D. Apperlley. A review and taxonomy of distortion-orientedpresentation techniques. ACM Transactions on Computer-Human Interaction,Volumen 1(Número 2):126 – 160, Junio 1994. [Citado en págs. 7, 8 y 10.]

[18] Jock D. Mackinlay, George G. Robertson, and Stuart K. Card. The perspectivewall: detail and context smoothly integrated. In CHI ’91: Proceedings of the



SIGCHI conference on Human factors in computing systems, pages 173–176,New York, NY, USA, 1991. ACM Press. [Citado en págs. 7 y 15.]

[19] Andrew Pavlo, Christopher Homan, and Jonathan Schull. A parent-centeredradial layout algorithm for interactive graph visualization and animation. ArXivComputer Science e-prints, 1, jun 2006. [Citado en págs. 21 y 25.]

[20] Catherine Plaisant, Brett Milash, Anne Rose, Seth Widoff, and Ben Shneider-man. Lifelines: visualizing personal histories. In CHI ’96: Proceedings of theSIGCHI conference on Human factors in computing systems, pages 221–ff., NewYork, NY, USA, 1996. ACM Press. [Citado en pág. 15.]

[21] Ramana Rao and Stuart K. Card. The table lens: merging graphical and sym-bolic representations in an interactive focus + context visualization for tabularinformation. In CHI ’94: Proceedings of the SIGCHI conference on Human fac-tors in computing systems, pages 318–322, New York, NY, USA, 1994. ACMPress. [Citado en pág. 13.]

[22] George G. Robertson, Jock D. Mackinlay, and Stuart K. Card. Cone trees:animated 3d visualizations of hierarchical information. In CHI ’91: Proceedingsof the SIGCHI conference on Human factors in computing systems, pages 189–194, New York, NY, USA, 1991. ACM Press. [Citado en pág. 21.]

[23] Ben Shneiderman. Treemaps for space-constrained visualization of hi-erarchies. Human-Computer Interaction Lab / University of Maryland,http://www.cs.umd.edu/hcil/treemap-history/, 28 de abril 2006. Consultadoel 15 de octubre del 2006. [Citado en pág. 19.]

[24] Robert Spence and Mark Apperley. Data base navigation: an office environmentfor the professional. Behaviour and Information Technology, 1(1):43–54, 1982.

[Citado en pág. 10.]

[25] John Stasko and Eugene Zhang. Focus+context display and navigation tech-niques for enhancing radial, space-filling hierarchy visualizations. In INFOVIS’00: Proceedings of the IEEE Symposium on Information Vizualization 2000,page 57, Washington, DC, USA, 2000. IEEE Computer Society.

[Citado en págs. 21, 22 y 24.]

[26] Tood Stephens. A passion for metadata – an interview with todd stephens ofbellsouth. Wilshire Conferences, Inc., Created at: 2003, Retrieved at: November2004, 2003. [Citado en pág. 13.]

[27] Soon Tee Teoh and Kwan-Liu Ma. Rings: A technique for visualization of largehierarchies. April 2002. [Citado en págs. 19, 21 y 25.]

[28] Roberto Therón. Hierarchical-temporal data visualization using a tree-ringmetaphor. Lecture Notes in Computer Science. Smart Graphics, 4073:70–81,2006. [Citado en pág. 26.]



[29] Fernada Viegas, M Wattenberg, and Kushal Dave. Studying cooperation andconflict between authors with history flow visualizations. ChiLetters, 6:575–582,2004. [Citado en pág. 27.]

[30] Lucian Voinea and Alexandru Telea. Mining software repositories with cvsgrab.In MSR ’06: Proceedings of the 2006 international workshop on Mining softwarerepositories, pages 167–168, New York, NY, USA, 2006. ACM Press.

[Citado en pág. 30.]

[31] Lucian Voinea and Alexandru Telea. Multiscale and multivariate visualizationsof software evolution. In SOFTVIS 2006, pages 115 – 124. Association forComputing Machinery Inc., 2006. [Citado en págs. 30 y 32.]

[32] Lucian Voinea and Alexandru Telea. An open framework for cvs repositoryquerying, analysis and visualization. In MSR ’06: Proceedings of the 2006 in-ternational workshop on Mining software repositories, pages 33–39, New York,NY, USA, 2006. ACM Press. [Citado en pág. 30.]

[33] Colin Ware. Designing with a 2 1/2d attitude. Information Design Journal,10(3):Páginas: 255 – 262, 2001. [Citado en pág. 43.]

[34] Kai Wetzel. Pebbles: Using circular treemaps to visualize disk usage.http://lip.sourceforge.net/ctreemap.html, Setiembre 2004. [Citado en pág. 18.]

[35] Xinrong Xie, Denys Poshyvanyk, and Andrian Marcus. Visualization of cvsrepository information. In WCRE ’06: Proceedings of the 13th Working Confe-rence on Reverse Engineering (WCRE 2006), pages 231–242, Washington, DC,USA, 2006. IEEE Computer Society. [Citado en págs. iv, 32, 34 y 35.]

[36] Jing Yang, Matthew O. Ward, Elke A. Rundensteiner, and Anilkumar Patro.Interring: a visual interface for navigating and manipulating hierarchies. Infor-mation Visualization, 2(1):16–30, 2003. [Citado en págs. 21 y 25.]


Documents

Visualización de la colaboración en la evolución de ítems