Anlisis de repositorios de software

Entender la evolucin del software

Marco D'Ambros1, Harald C. Gall2, Michele Lanza1 y Martin Pinzger2

1. Facultad de Informtica, Universidad de Lugano, Suiza

2. Departamento de Informtica, Universidad de Zurich, Suiza

Resumen. Repositorios de software tales como sistemas de control de

versiones, sistemas de la comunicacin archivada entre el personal del
proyecto se utiliza para ayudar a gestionar el proyectos de software. Los
profesionales del software y los investigadores reconocen cada vez beneficio
de la minera de esta informacin para apoyar el mantenimiento de sistemas
de software, diseo de software o reutilizacin, y validar empricamente nuevas
ideas y tcnicas. La investigacin es ahora procediendo a descubrir formas en
que la minera de estos repositorios puede ayudar a entender desarrollo de
software, apoyar las predicciones sobre el desarrollo de software y planificar
aspectos evolutivos de los proyectos de software.
Este captulo presenta varias tcnicas de anlisis y visualizacin para entender
el software desarrollando las ricas fuentes de artefactos que estn disponibles.
Basado en los modelos de datos que necesitan ser desarrollados para cubrir
fuentes tales como modificaciones e informes de errores que describimos
cmo usar una base de datos de historial de versiones para el anlisis de la
evolucin. Para ello presentamos enfoques para analizar el esfuerzo del
desarrollador para determinadas entidades de software. Adems presentamos
el acoplamiento de cambio anlisis que pueden revelar las dependencias de
cambio ocultas entre las entidades de software. Finalmente nosotros mostrar
cmo investigar deficiencias arquitectnicas en muchos lanzamientos e
identificar tendencias en la evolucin. Los grficos de Kiviat se pueden utilizar
eficazmente para visualizar tales resultados del anlisis.

3.1 Introduccin
El anlisis de la evolucin del software se ocupa de los cambios de software, sus
causas y sus efectos. Utiliza todas las fuentes de un sistema de software para
realizar un anlisis retrospectivo. Tales datos comprenden el historial de
liberacin con todo el cdigo fuente y la informacin de cambio, datos de
informe de fallo y datos que se pueden extraer del sistema en ejecucin. En
particular, el anlisis de la liberacin y los datos de informes de errores ha
ganado importancia porque almacenan informacin valiosa para analizar la
evolucin del software. Mientras que la recuperacin de los datos que residen
en sistemas de control de versiones como CVS o Subversion se ha convertido
en un tema bien explorado, el reto final radica en los datos recuperados y su
interpretacin.

Algunos temas recientes abordados en el campo del anlisis de repositorios de

software incluyen los siguientes:

Esfuerzo del desarrollador y anlisis de redes sociales. Una de las metas

en este tema es averiguar el esfuerzo que los miembros del equipo estn
gastando en mantener y desarrollar mdulos de software y cmo se
comunican entre s. Esto permite a un director de proyecto planificar los
recursos y razonar sobre las deficiencias en los procesos de desarrollo y
la estructura del equipo.
Cambiar el impacto y la propagacin. El objetivo principal de este tema
es evaluar el impacto de un cambio, como la adicin de un nuevo o
cambio de una caracterstica existente, en la arquitectura, diseo e
implementacin de un sistema de software. Ser capaz de evaluar el
impacto de los cambios permite estimar el esfuerzo por tareas de
mantenimiento y evolucin, determinar el impacto de un cambio en la
arquitectura y el diseo existentes de un sistema. Los resultados tambin
se utilizan para proporcionar directrices para los programadores, como
si el mtodo de cambio de un programador tambin debe cambiar el
mtodo b y c.
Anlisis de tendencia y hotspot. En este tema se observa la tendencia de
las entidades de software a descubrir las deficiencias en la arquitectura
actual, el diseo y la implementacin de sistemas de software. Hotspots
son las entidades que con frecuencia cambian y por lo tanto son crticas
para la evolucin de un sistema. Uno de los objetivos es encontrar
heursticas y mecanismos de alerta que alarmen a los gerentes de
proyectos y arquitectos de las tendencias negativas de las entidades de
software (y en particular de los hotspots del sistema) y brinden
sugerencias para devolver el sistema a un estado estable.
 Prediccin de defectos y defectos. Una gran cantidad de informacin es
proporcionada por repositorios de software que pueden ser introducidos
en la minera de datos y algoritmos de aprendizaje automtico para
caracterizar las propiedades actuales y predecir futuras de las entidades
de software. Una propiedad de las entidades de software que es
abordada por muchos enfoques es la prediccin de la ubicacin y el
nmero de defectos en las entidades de software, tales como archivos
de origen. El resultado es una lista de entidades que probablemente se
vern afectadas por defectos, lo que permitir al equipo de desarrollo
planear acciones preventivas como la refactorizacin.

En este captulo abordaremos los tres primeros temas y tcnicas actuales tales
como nuestras Figuras fractal para analizar el esfuerzo de desarrollo, el
Evolution Radar para analizar el impacto del cambio en los archivos fuente y los
diagramas de Kiviat para analizar las tendencias mtricas y detectar hotspots
del sistema. En la siguiente seccin presentamos un enfoque general para
analizar los repositorios de software para entender la evolucin del software.
Los ejemplos de cmo modelar y recuperar los datos se presentan en la Seccin
3.3. Los datos modelados son la entrada para las diferentes tcnicas de anlisis
de evolucin de software que presentamos en la Seccin 3.4.

3.2 Una visin general del anlisis del repositorio de software

Cuando los repositorios de minera de software se pueden considerar muchos
artefactos de software: cdigo fuente de los sistemas de control de versiones,
errores de los sistemas de seguimiento de errores, la comunicacin de listas de
correo electrnico o cualquier otro artefacto de software como la
documentacin. Esta diversidad de informacin es la base de muchos tipos de
anlisis de la evolucin.

3.2.1 Un enfoque general

La figura 3.1a muestra un esquema de cmo analizar los repositorios de
software para estudiar la evolucin del software. En el esquema identificamos
tres pasos fundamentales necesarios para el anlisis final de los datos:

1. Modelado de datos. El primer paso de la minera consiste en crear un

modelo de datos de un sistema de software en evolucin. Se pueden
 modelar varios aspectos del sistema y su evolucin: La ltima versin del
cdigo fuente, la historia de los archivos registrados por el sistema de
control de versiones, varias versiones del cdigo fuente (por ejemplo,
una por liberacin), documentacin, informes de errores,
Desarrolladores de archivos de listas de correo, etc. Aunque aspectos
como el cdigo fuente o los historiales de archivos tienen una correlacin
directa con el sistema, para otros como informes de errores o archivos
de listas de correo, la informacin til debe ser filtrada y enlazada a
artefactos de software. Cuando se disea el modelo, es importante
considerar el equilibrio entre la cantidad de datos a tratar (en la fase de
anlisis) y el beneficio potencial que estos datos pueden tener, es decir,
no todos los aspectos de la evolucin del sistema deben ser
considerados, Los que pueden abordar un problema especfico de
evolucin del software o conjunto de problemas.
2. Recuperacin y procesamiento de datos. Una vez definido el modelo, se
tiene que crear una instancia concreta del mismo. Para ello, necesitamos
recuperar y procesar la informacin de las distintas fuentes de datos. El
procesamiento puede incluir el anlisis de los datos (por ejemplo, cdigo
fuente, archivos de registro, informe de fallos, etc.), la aplicacin de
tcnicas de concordancia para vincular diferentes fuentes de datos (por
ejemplo, artefactos del sistema de versiones con reportes de fallos [179,
136] La reconstruccin de la informacin no registrada (p. Ej., Reconstruir
la informacin de compromiso de los archivos de registro CVS [566]) y la
aplicacin de otras tcnicas como la minera de datos.
 3. Anlisis de datos. El anlisis consiste en utilizar los datos modelados y
recuperados para abordar un problema de evolucin del software o
conjunto de problemas mediante diferentes tcnicas y enfoques.

3.2.2 Nuestro enfoque

La Figura 3.1b ilustra cmo abordamos el anlisis de la evolucin del software
a travs de repositorios de software de minera. Como fuentes de datos
consideramos los archivos de registro del sistema de versiones junto con los
datos del informe de errores. Definimos un modelo de datos que describe un
sistema de software evolutivo basado en estas dos fuentes de datos (modelado
de datos). Dado un sistema para analizar, se analizan los archivos de registro
del sistema de versiones y los datos de los informes de fallos y se crea una
instancia concreta del modelo (recuperacin de datos). Todos los modelos se
almacenan en una base de datos de historial de versiones (RHDB), que es el
punto de partida para todos los anlisis posteriores. Para la parte de anlisis
utilizamos diferentes tcnicas y herramientas, dirigidas a resolver problemas
especficos de evolucin de software. En el resto de este captulo introducimos
primero el RHDB, el modelo de datos que hay detrs y la forma en que se rellena
la base de datos. A continuacin, presentamos diferentes tipos de anlisis de
evolucin de software construido en la parte superior de la RHDB: Distribucin
de esfuerzos de los desarrolladores, acoplamiento de cambios, anlisis de
tendencias y deteccin de puntos calientes. Para el RHDB y cada tcnica de
anlisis evolutivo tambin presentamos trabajos relacionados en el campo.

3.2.2 Nuestro enfoque

La Figura 3.1b ilustra cmo abordamos el anlisis de la evolucin del software
a travs de repositorios de software de minera. Como fuentes de datos
consideramos los archivos de registro del sistema de versiones junto con los
datos del informe de errores. Definimos un modelo de datos que describe un
sistema de software evolutivo basado en estas dos fuentes de datos (modelado
de datos). Dado un sistema para analizar, se analizan los archivos de registro
del sistema de versiones y los datos de los informes de fallos y se crea una
instancia concreta del modelo (recuperacin de datos). Todos los modelos se
almacenan en una base de datos de historial de versiones (RHDB), que es el
punto de partida para todos los anlisis posteriores. Para la parte de anlisis
utilizamos diferentes tcnicas y herramientas, dirigidas a resolver problemas
especficos de evolucin de software. En el resto de este captulo introducimos
primero el RHDB, el modelo de datos que hay detrs y la forma en que se rellena
la base de datos. A continuacin, presentamos diferentes tipos de anlisis de
evolucin de software construido en la parte superior de la RHDB: Distribucin
de esfuerzos de los desarrolladores, acoplamiento de cambios, anlisis de
tendencias y deteccin de puntos calientes. Para el RHDB y cada tcnica de
anlisis evolutivo tambin presentamos trabajos relacionados en el campo.

3.3 Historial de lanzamiento

Cuando nos referimos a la historia de un artefacto de software, queremos decir
la forma en que fue desarrollado, cmo creci o se redujo con el tiempo,
cuntos desarrolladores trabajaron en l y en qu medida. Estos tipos de
informacin se registran mediante sistemas de control de versiones y se
pueden reconstruir analizando sus archivos de registro. Sin embargo, cuando
analizamos la evolucin, nuestro objetivo es entender la arquitectura de un
sistema, las dependencias entre sus componentes y detectar puntos evolutivos.
Para soportar este tipo de anlisis, se puede utilizar informacin adicional como
informes de fallos de problemas. El problema es vincular estos datos a los
artefactos de software para responder a preguntas especficas, por ejemplo,
qu archivos fueron afectados por un error determinado?
En esta seccin presentamos nuestro enfoque para integrar la informacin del
sistema de versionado y los datos de reportes de errores y poblar un RHDB [179,
136]. En primer lugar introducimos el sistema de control de versiones y el
sistema de seguimiento de errores desde el cual recuperamos los datos. A
continuacin, describimos el modelo detrs del RHDB, es decir, el modelo de
un sistema de software en evolucin y finalmente explicamos cmo rellenar la
base de datos. CVS y Bugzilla. CVS [135] ha sido el sistema de control de
versiones ms utilizado por la comunidad de cdigo abierto en los ltimos aos.
Actualmente est siendo reemplazado por Subversion [480] (SVN).
Nuestro enfoque para poblar el RHDB se basa en los archivos de registro del
sistema de versiones, por lo tanto, se puede aplicar tanto a CVS y SVN. Para
cada archivo versionado, el archivo de registro contiene la informacin
registrada por el sistema de control de versiones en el momento de la
validacin: El nmero de versin (o revisin), la marca de tiempo del commit,
el autor que realiz el commit, el estado Desarrollo o eliminacin), el nmero
de lneas aadidas y eliminadas con respecto al commit anterior, las ramas que
tienen la versin actual como root y los comentarios escritos por el autor
durante el commit. El Listado 3.1 muestra un fragmento de un archivo de
registro CVS.
Bugzilla [95] es un sistema de seguimiento de fallos que se utiliza en gran
medida en la comunidad de cdigo abierto. Su ncleo es una base de datos
personalizable con una interfaz web que permite a los desarrolladores,
probadores y usuarios normales reportar y realizar un seguimiento de los
problemas detectados en el sistema de software. Un informe de error tpico
contiene las siguientes piezas de informacin: Un identificador que
inequvocamente identifica el error, el estado del error compuesto por el
estado (nuevo, asignado, reabierto, resuelto, verificado, cerrado) y la
resolucin (fijo, invlido, wontfix, notyet, , Duplicado, worksforme), la ubicacin
en el sistema identificado por el producto y el componente, el sistema
operativo y la plataforma en la que se detect el error, una breve descripcin
del problema y una lista de comentarios sobre ella (descripcin larga). Por otra
parte, cada error se refiere a varias personas: El reportero que inform el error,
una persona que est a cargo de arreglarlo (asignado a), las personas de
garanta de calidad que son responsables de asegurar que el software cumple
con ciertos estndares de calidad (qa), y Una lista de personas interesadas en
ser notificado del progreso de correccin de errores (CC).

3.3.1 El modelo RHDB

La Figura 3.2 muestra el ncleo del modelo RHDB.
En el modelo, un commit de CVS corresponde a una versin de archivo, que
tiene toda la informacin relacionada con el compromiso: Versin asociada al
commit, fecha, autor, estado (exp o muerta), lneas aadidas y eliminadas con
respecto al commit anterior, Versin y el comentario escrito por el autor. Un
historial de archivos, que corresponde al archivo real en el sistema de archivos,
est compuesto por una secuencia de versiones de archivo, una por commit.
Tiene un nombre de archivo con (rcsfile) y sin (workingfile) el nombre de ruta
completo. Se puede asociar un historial de archivos a muchos alias, utilizados
para etiquetar las versiones del sistema. Un proyecto se compone de mdulos
que contienen directorios e historiales de archivos. Un directorio puede
contener subdirectorios e historiales de archivos. Finalmente, se puede asociar
una versin de archivo a uno o ms informes de errores. La relacin entre los
informes de errores y las versiones de archivos es "muchos a muchos", lo que
significa que una versin de archivo (y por lo tanto un historial de archivos)
puede verse afectada por muchos errores y un error puede afectar a diferentes
versiones de archivos e historiales de archivos.

3.3.2 Cmo rellenar el RHDB

La Figura 3.3 bosqueja el proceso de poblado RHDB. El usuario debe ingresar la
url del repositorio CVS y de la base de datos Bugzilla, y luego la tarea de poblado
(que en funcin del tamao del sistema puede tardar varias horas) se ejecuta
en modo por lotes. Los pasos principales del proceso son:
1. La ltima versin del sistema se recupera mediante un comando CVS
checkout. A continuacin, para cada directorio, el archivo de registro que
describe el historial de los archivos contenidos se recupera y analiza.
2. Para cada archivo, los datos sobre todos sus commits (su historial) se
almacenan en la base de datos, as como un enlace al archivo real.
3. Cada vez que se encuentra una referencia a un error en el mensaje de
confirmacin (el comentario escrito por el autor en el momento del
commit), el informe de fallo correspondiente se recupera de la base de
datos Bugzilla, se analiza y se almacena en la base de datos junto con el
enlace El archivo afectado. Dado que el vnculo entre los artefactos CVS
y el informe de problemas de Bugzilla no est formalmente definido,
utilizamos expresiones regulares para detectar referencias de errores.
 3.3.3 Trabajo relacionado

Se propusieron varios enfoques para crear y poblar un modelo subyacente de

un sistema de software en evolucin. Estos enfoques varan segn la
informacin que consideren (por ejemplo, slo el repositorio de cdigo fuente
o tambin el sistema de seguimiento de errores y los archivos de correo), las
fuentes de datos que admiten (por ejemplo, slo CVS o SVN, ClearCase, etc.) y
cmo se vinculan estas fuentes Uno al otro.
El RHDB presentado anteriormente se basa en el sistema de control de
versiones de CVS y en el sistema de seguimiento de errores de Bugzilla, en el
que se construyen los enlaces entre las dos fuentes, tal como se presenta en la
Seccin 3.3.2. La principal contribucin del RHDB es que fue el primero en
vincular los artefactos CVS y los informes de problemas de Bugzilla.
Otros dos enfoques similares al RHDB, tambin basado en CVS y Bugzilla,
Pero que tambin utilizan otras fuentes de informacin son Hipikat [133, 511,
510] de D.
Cubranic et al. Y softChange [196, 195] de D. German. Ambas tcnicas utilizan
informacin de los archivos de correo y, adems, Hipikat tambin considera los
datos de la documentacin en el sitio web del proyecto analizado (si est
disponible).
En ambos enfoques, los vnculos entre diferentes fuentes de informacin se
deducen basados en convenciones (por ejemplo, en algunos proyectos hay una
convencin para incluir en el comentario de compromiso una referencia a la
entrada del sistema de seguimiento de fallos) o heurstica (por ejemplo, es
probable que el Autor de una correccin de errores ha cometido una revisin
de cdigo fuente cerca de la hora en que se cerr el informe de problema en el
sistema de seguimiento de errores).
Un problema comn que se encuentra al enlazar archivos de correo con el
repositorio CVS es que las personas tienden a tener varias direcciones de correo
electrnico, que podran no ser las mismas que las registradas en los archivos
de registro CVS. [197]

En el modelo Hipikat (ver Figura 3.4), un mensaje es un correo en el archivo de

correo,
Una versin de archivo corresponde a un commit de CVS en el repositorio (una
revisin), una tarea de cambio es un informe de problema de Bugzilla y un
documento es un documento de diseo recuperado, por ejemplo, del sitio web
del proyecto.
En la arquitectura softChange (ver Figura 3.5), vemos dos componentes
principales:
El extractor de rastro y el realzador de hechos. El Extractor de Rutas recupera
los siguientes rastreos de software: registros de CVS, informe de problemas de
Bugzilla, cambios y versiones del sistema (archivos tar distribuidos por el equipo
de software). El Fact Enhancer utiliza los senderos de software recuperados
para generar / inferir hechos nuevos. Por ejemplo, reconstruye el commit-set,
ya que la operacin commit en CVS no es atmica, vincula los artefactos CVS
con el informe de problemas Bugzilla o los mensajes de los archivos de correo,
etc.
La informacin almacenada por Hipikat forma una "memoria de grupo
implcita" (donde
Grupo representa el grupo de desarrolladores), que se utiliza para facilitar la
insercin de los recin llegados en el grupo, recomendando artefactos
relevantes para tareas especficas. Los datos recuperados y procesados por
softChange se utilizan para dos tipos de anlisis y visualizacin de la evolucin
del software: (i) estadsticas de la evolucin global del proyecto, utilizando
histogramas en los que el eje x suele representar la dimensin temporal y (ii)
anlisis de las relaciones Entre archivos y autores, utilizando grficos donde los
autores y / o archivos estn representados como nodos y sus relaciones como
aristas.
Otro enfoque similar al RHDB es el marco de Kenyon [58] por J. Bevan et al.
Kenyon proporciona una infraestructura extensible para recuperar el historial
de un proyecto de software desde un repositorio SCM o un conjunto de
releases y para procesar la informacin recuperada. Tambin proporciona una
interfaz comn basada en ORM (Object-Relational Mapping) para acceder a los
datos procesados almacenados en una base de datos.
La Figura 3.6 muestra la arquitectura de flujo de datos de alto nivel de Kenyon.
La clase DataManager es el punto de entrada de ejecucin: lee un archivo de
configuracin e invoca a los otros componentes, es decir, la recuperacin de
configuracin, el extractor de hechos y el almacenamiento de datos de objetos.
La clase SCMInterface asla a Kenyon de la implementacin concreta de
diferentes sistemas SCM. Las clases abstractas de FactExtractor y MetricLoader
son los puntos de API para extensiones de invocacin de herramientas
especficas. Esto significa que los usuarios de Kenyon son libres de adjuntar sus
propias herramientas externas de extraccin de hechos y de cargador mtrico
(tpicamente anlisis especfico). Adems de esta extensin, Kenyon ofrece
herramientas de extraccin de hechos y herramientas de carga mtricas
predefinidas. Kenyon guarda los resultados de cada
Procesada a una base de datos. Se proporciona un mecanismo ORM para
ayudar a automatizar el almacenamiento y la recuperacin de objetos Java
desde la base de datos.
Como se muestra en la Figura 3.6, Kenyon recupera informacin de SCM
solamente (o
Sistema de archivos, es decir, conjunto de liberaciones), sin considerar otras
fuentes, tales como sistema de seguimiento de fallos o archivos de correo. Por
otro lado Kenyon soporta varios SCMs, a saber: CVS, SVN, ClearCase y conjuntos
de releases en el sistema de ficheros.
Un aspecto comn de Kenyon y el RDHB es que ambos almacenan los datos
para los anlisis de evolucin posterior, mientras que para softChange y Hipikat
la tarea de uso de los datos ya est definida.

3.4 Anlisis de Evolucin del Software

El RHDB contiene una instancia concreta de nuestro modelo de un sistema de
software en evolucin. Este es el punto de partida del cual, con el apoyo de
herramientas y tcnicas, Podemos hacer varios tipos de anlisis. Cada tcnica
que diseamos y cada herramienta que Implementada considera una
perspectiva particular sobre la evolucin del software, y Un objetivo
particular. A continuacin, presentamos algunos problemas de anlisis de la
evolucin del software Y describir nuestras tcnicas para hacerles frente.
3.4.1 Anlisis del esfuerzo del desarrollador
El primer problema de evolucin de software que abordamos es el esfuerzo
de desarrollo. Nosotros Desea responder a preguntas tales como: Cuntos
desarrolladores trabajaron en una entidad? Cmo Fue el esfuerzo repartido
entre ellos? Existe un propietario de la entidad, basado en el Principio de
propiedad de cdigo? Adems, tambin queremos ser capaces de categorizar
entidades En trminos de "distribucin del esfuerzo". Para un analista o un
gerente de proyecto, las respuestas A estas preguntas proporcionan
informacin valiosa para una posible reestructuracin Equipos de desarrollo.
Los sistemas de control de versiones registran la informacin necesaria para
responder a estas preguntas, Ya que cada artefacto tiene una lista de
versiones correspondientes a los compromisos, y la Lista de autores que
realizaron los commits3. El problema es cmo representar y Agregue esta
gran cantidad de informacin de bajo nivel4 para obtener una visin del
equipo Estructura y entender quines son los responsables de una entidad de
software, escalando Desde un mdulo hacia abajo hasta el archivo individual.
Nuestro enfoque se basa en la "Figura Fractal" [139, 136] visualizacin, que
Encapsula toda la informacin relacionada con el autor de un artefacto de
software dado. Da Una visin inmediata de cmo, en trminos de esfuerzo de
desarrollo y distribucin entre Autores, un artefacto ha sido desarrollado.
Podemos averiguar fcilmente si el desarrollo Fue hecho principalmente por
un autor o muchas personas contribuyeron a l y para
3 Slo sabemos quin realiz el commit, es decir, si un commit incluye
cambios hechos por Varias personas, todas ellas estn asignadas a un solo
desarrollador.
4 Como ejemplo: El sistema Mozilla, el primero de septiembre de 2005, tena
4656 cdigo fuente Archivos con un nmero total de 326.000 versiones de
archivos, que corresponden a cientos de miles De los datos relacionados con
el compromiso de analizar.
En qu medida. Una figura fractal se compone de un conjunto de rectngulos
con diferentes tamaos Y colores. Cada rectngulo, y por lo tanto cada color,
representa un autor que trabaj en el archivo. El rea del rectngulo es
proporcional al porcentaje de compromisos realizados Por el autor sobre todo
el conjunto de compromisos. Para ms detalles sobre el diseo El algoritmo y
el poder expresivo de Fractal Figures ver [139].
Las Figuras Fractal permiten que las entidades de software sean categorizadas
en trminos de distribucin del esfuerzo Entre desarrolladores siguiendo el
principio de gestalt. Se definieron cuatro Patrones que representan cuatro
modelos de desarrollo, representados en la Figura 3.7: (a) Un desarrollador,
(B) pocos desarrolladores equilibrados, (c) un desarrollador importante y (d)
muchos equilibrados Desarrolladores.
Los patrones de desarrollo nos permiten clasificar las entidades de acuerdo a
la Se desarrollaron desde la perspectiva de los autores. Sin embargo, la
naturaleza visual de Patrones y las propias figuras de fractal, es til para
obtener una impresin cualitativa Slo del modelo de desarrollo. Para
proporcionar tambin una medida cuantitativa, El Valor Fractal, que para un
determinado artefacto de software se define como:

Donde A = {a1, a2,. . . , an} es el conjunto de autores y nc (ai) es el nmero de

compromisos Realizada por el autor ai con respecto al artefacto de software
dado. El fractal El valor mide la fragmentacin de una figura fractal, es decir,
cunto se gasta el trabajo En la entidad correspondiente se distribuye entre
diferentes desarrolladores. (3.1) se define De tal manera que cuanto menor
sea la cantidad nc (ai) NC es (siempre menor que 1), ms se reduce Por la
potencia cuadrada, ya que la ecuacin cuadrada es sub-lineal entre 0 y 1. Por
lo tanto, Cuanto menor sea el rectngulo, menor ser su contribucin
negativa al Valor Fractal es. El valor de Fractal oscila entre 0 y 1 (no
alcanzable). Es 0 para entidades desarrolladas Por un solo autor, mientras
tiende a 1 para entidades desarrolladas por un gran nmero de Autores.
Para explotar el poder expresivo de las Figuras Fractal las aplicamos en el
contexto de Vistas polimtricas [309]. Las cifras representan entidades RHDB,
a saber, archivos, directorios, Y mdulos. Para aplicarlos en un directorio o un
mdulo, resumimos la informacin de confirmacin De todos los archivos
pertenecientes al directorio o mdulo dado. Mapeamos na mtrica Medida
del tamao de la figura. La mtrica puede ser estructural como LOC

Higo. 3.7. Patrones de desarrollo basados en la gestalt de las Figuras Fractal

[139] [2005] IEEE
O evolutivo como el nmero de commits, el nmero de bugs, el nmero de
lneas aadidas Etc. A continuacin presentamos diferentes escenarios de
ejemplo que muestran cmo usar Fractal Figures para abordar el problema de
la comprensin de la distribucin del esfuerzo de desarrollo.
Deteccin de un desarrollador importante
La Figura 3.8 muestra la jerarqua de directorios de webshell de Mozilla. Las
figuras del fractal representan Directorios que contienen al menos un archivo,
mientras que las cifras grises representan el contenedor Directorios, es decir,
directorios que contienen slo subdirectorios. La mtrica de tamao Tamao
de directorio en trminos de nmero de archivos contenidos. Vemos que la
jerarqua de webshell OfMozilla incluye todos los cuatro patrones de
desarrollo. La sub-jerarqua marcada Como 1 tiene un patrn de desarrollador
importante (el autor azul hizo la mayora de los compromisos). Los Ingeniero
inverso sabe a quin hacer preguntas sobre el diseo y el cdigo contenido En
esta sub-jerarqua. Por el contrario, el directorio marcado como 2 muestra
que Muchos desarrolladores trabajaron en l, y no hay desarrollador principal.
Modificar cdigo en Estos directorios ser ms esfuerzo ya que no hay una
sola persona para hacer preguntas Sobre el cdigo. El ingeniero inverso
necesitar el soporte de otras herramientas como Code-Crawler [310] o
BugCrawler [138]. Esta informacin no es compleja o difcil de obtener, Pero el
valor de la visualizacin de la figura fractal es que transmite esta informacin
en Un contexto (la jerarqua en este caso), fcil y rpido de leer, y con el
mismo visual Principio para todas las entidades de software a las que se
aplica.
Higo. 3.8. Fractal Figuras aplicadas A la jerarqua de webshell de Mozilla [139]
[2005] IEEE. Los La mtrica de tamao asigna el tamao del directorio En
trminos de nmero de contenidas Archivos
3 Anlisis de repositorios de software para comprender la evolucin del software

Higo. 3.9. Fractal Figures aplicado a la jerarqua de red / protocolo de Mozilla.

El tamao
Mapas mtricos del nmero de informes de errores
Reevaluacin de la formacin del equipo de desarrollo La Figura 3.9 muestra un
ejemplo con la implementacin del protocolo de red de Mozilla.
La mayora de los directorios que introdujeron bugs tienen muchos patrones de
desarrolladores balanceados, Pero uno que tiene un patrn principal del
revelador: red / protocolo / http /Src Este directorio es responsable de la
mayora de los errores generados en la red /Jerarqua del protocolo. Esta visin
puede ser valiosa para un gerente de proyecto o un analista.
Muestra que una nueva evaluacin de la formacin del equipo de Dado el
elevado nmero de errores y un importante patrn de Red / protocolo / http /
directorio src.
Trabajo relacionado
Muchas tcnicas de anlisis de evolucin de software se centran ms en los
desarrolladores y sus Interaccin con los artefactos de software que con los
propios artefactos de software. Liu et al [330] aplicaron la herramienta
CVSChecker para analizar archivos de registro CVS con el objetivo de entender
Contribuciones de autores e identificacin de patrones. Queran estudiar la
Desarrollo de cdigo abierto y para comprender qu actividades se llevan a
cabo en Proyecto de cdigo abierto y por quin. La herramienta CVSChecker
soporta el anlisis de la Rendimiento de un desarrollador individual y los
patrones de distribucin de esfuerzo de los equipos.
CVSChecker tiene un conjunto de analizadores que extraen informacin de la
fuente CVS Cdigo y almacenarlos en una base de datos relacional. La
herramienta utiliza entonces esta informacin Para producir cuatro tipos de
visualizaciones:
1. Distribucin temporal de la actividad CVS, para cada desarrollador (ver Figura
3.10a);
2. Distribucin de los tipos de operaciones CVS, para cada desarrollador;
3. Distribucin de los tipos de operaciones CVS, para cada archivo;
4. Agregado y eliminado lneas de cdigo (LOC) por cada desarrollador, en cada
archivo (vea un
Ejemplo en la figura 3.10b).
(B) Se agreg y elimin LOC para cada desarrollador, para cada archivo
Higo. 3.10. Visualizaciones de ejemplo CVSChecker [330]
Las visualizaciones se utilizan en [330] para extraer patrones de desarrollo para
caracterizar El proceso de desarrollo de cdigo abierto.
Grba et al. [203] defini una medida para la nocin de propiedad de cdigo en
Repositorios CVS. Definieron que un desarrollador es el dueo de un archivo si
l / ella posee La mayor parte de ella en trminos de lneas. l / ella posee una
lnea de cdigo si l / ella era el ltimo que comprometi un cambio a esa lnea
en el repositorio. Sobre la base de ese principio, Presentaron la visualizacin del
Mapa de Propiedad, que muestra la evolucin de Un proyecto de software, de
acuerdo con las siguientes reglas (resumidas en la figura 3.11):
Cada archivo se representa como una lnea coloreada;
El eje x representa la dimensin temporal, de izquierda a derecha;
 Cada confirmacin de un archivo en el repositorio se representa como un
crculo Lnea correspondiente;
Cada desarrollador est representado por un color;
Los compromisos (crculos) se colorean segn el desarrollador que los Trozos
de historias de archivos (correspondientes a trozos de lneas) se colorean deAl
propietario del archivo, durante el intervalo de tiempo considerado.
En [203] los autores utilizaron la visualizacin del Mapa de Propiedad para
definir el desarrollo Patrones como el monlogo (un perodo en el que todos
los cambios y la mayora de los El mismo autor), la adquisicin (un desarrollador
se hace cargo de una gran cantidad de cdigo en un corto Cantidad de tiempo),
trabajo en equipo (dos o ms desarrolladores cometen una rpida sucesin de

Higo. 3.11. Los principios De la propiedad Visualizacin del mapa [203] [2005]
IEEE
Cambios en varios archivos), etc. Los patrones fueron definidos con el objetivo
de caracterizar Diferentes comportamientos de desarrollador.
En [528], Voinea y Telea presentaron una visualizacin similar, en la que los
archivos CVS Se representan como lneas coloreadas y el color representa el
desarrollador. La visualizacin Se implementa en CVSgrab, una herramienta que
tambin soporta la visualizacin y Anlisis de las actividades en el repositorio.
En [528] los autores aplicaron un algoritmo de cluster En las visualizaciones para
poner ficheros (lneas) con desarrollo similar (con respeto A los autores oa la
actividad) cerca uno del otro. El objetivo de su trabajo era Permiten a los
desarrolladores y directores de proyectos explorar visualmente la evolucin de
un software De manera que facilite el entendimiento del sistema y del proceso.
Voinea et al. Tambin present la herramienta CVSscan [529], basada en
CVSgrab para la extraccin Los datos del repositorio CVS. La herramienta puede
visualizar la evolucin de CVS visualizando la evolucin de lneas individuales.
CVSscan ofrece tres Tipos de codificacin de color para asociar el color de cada
lnea de cdigo a su autor. Esta visualizacin Se utiliza en [529] para entender
quin realiz modificaciones en el cdigo Y donde, facilitando as la
comprensin del proceso de desarrollo. La informacin de autor almacenada
en los repositorios CVS tambin se utiliz en el contexto de redes sociales. En
[68] Bird et al. Cre redes sociales o envi correos electrnicos De archivos de
correo electrnico OSS. Vincularon correos electrnicos con cuentas CVS para
analizar Relacin de actividad de correo electrnico y actividad de compromiso
y la relacin de estado social Con actividad de compromiso. El estudio de caso
que realizaron en el servidor HTTP de Apache Proyecto indic una fuerte
relacin entre el nivel de actividad en el cdigo fuente, Y una relacin menos
fuerte con la actividad de cambio de documentos. Tambin se enteraron Que
los desarrolladores (personas con cuentas de correo electrnico y CVS) juegan
un papel mucho ms significativo Social que otros participantes en los archivos
de correo.

3.4.2 Anlisis de acoplamiento de cambio

Cambio de acoplamiento es la dependencia implcita entre dos o ms artefactos
de software Que se han observado a menudo cambian juntos durante la
evolucin de un sistema. Esta informacin de cambio simultneo puede estar
presente en el sistema de control de versiones, o Debe inferirse mediante
anlisis. Por ejemplo, SVN marca los archivos co-changing en commit Tiempo
como pertenecientes al mismo conjunto de cambios mientras que en CVS los
archivos que se cambian (Es decir, lgicamente) acoplado debe deducirse del
tiempo de modificacin de cada individuo archivo.
El Evolution Radar [137, 140] es una tcnica de visualizacin interactiva para
Analizar los acoplamientos de cambio para detectar la decadencia de la
arquitectura y los componentes acoplados En un sistema de software dado.
Aborda las siguientes preguntas: Cules son los componentes (Por ejemplo,
mdulos) con el acoplamiento ms fuerte? Qu entidades de bajo nivel (por
ejemplo, Archivos) son responsables de estos acoplamientos?
La figura 3.12 muestra los principios estructurales del Radar de la Evolucin. Se
visualiza Dependencias entre grupos de entidades, en este caso especfico las
dependencias entre Mdulos (grupos) como grupo de archivos (entidades). El
mdulo en foco se visualiza como Un crculo y colocado en el centro de un
grfico circular. Todos los otros mdulos del sistema estn representados Como
sectores. El tamao de los sectores es proporcional al nmero de archivos
contenidos En el mdulo correspondiente. Los sectores se clasifican segn este
tamao mtrico, Es decir, el ms pequeo se coloca a 0 radian y todos los
dems en el sentido de las agujas del reloj (vase la figura 3.12). Dentro de cada
sector, los archivos se representan como crculos de color y se Coordenadas
donde el ngulo y el radio se calculan de acuerdo con lo siguiente reglas:
Radio d (o distancia desde el centro). Es inversamente proporcional al cambio
Acoplamiento del archivo con el mdulo en foco, es decir, cuanto ms se
acoplan, Ms cerca est el crculo (representando el archivo) al crculo central
(que representa el Mdulo en foco). ngulo . Los archivos de cada mdulo
se ordenan alfabticamente considerando la totalidad Directorio, y los crculos
que los representan se distribuyen uniformemente En los sectores con respecto
a las coordenadas angulares. Las mtricas arbitrarias se pueden asignar en el
color y el tamao de las figuras del crculo. En el Los archivos Evolution Radar
se colocan de acuerdo con el cambio de acoplamiento que tienen con el
Mdulo en foco. Para calcular este valor mtrico usamos la siguiente frmula:
CC (M, f) es el acoplamiento de cambio entre el mdulo M en foco y un archivo
dado F yCC (fi, f) es el acoplamiento de cambio entre los ficheros fi yf. Tambin
es posible Utilice otros operadores de grupo en lugar del mximo tal como el
promedio o la mediana.
Utilizamos el mximo porque nos seala los archivos con el acoplamiento ms
fuerte, es decir, El principal responsable de las dependencias de cambio.
El valor del acoplamiento entre dos ficheros es igual al nmero de transacciones
Que incluyen ambos archivos. Dado que las transacciones de cambio no son
registradas por CVS, Reconstruirlos utilizando el enfoque de la ventana de
tiempo deslizante propuesto por Zimmermann YWeigerber en [566], que es
una mejora de la ventana de tiempo fijo ms simple enfoque. Para ms detalles
sobre el deslizamiento y el enfoque de la ventana de tiempo fijoNos referimos
a los lectores a [137, 566]. El Evolution Radar se implementa como una
visualizacin interactiva. Es posible Para inspeccionar todas las entidades
visualizadas, es decir, archivos y mdulos, para ver las Informacin como autor,
lneas de timestamp aadidas y eliminadas, etc. Adems, tambin es Posible ver
el cdigo fuente de los archivos seleccionados. Tres caractersticas importantes
para realizar Anlisis con el radar de la evolucin son (1) que se mueven a travs
del tiempo, (2) que siguen Y (3) desove.
(1) Movindose por el Tiempo. La medida de acoplamiento de cambio
depende del tiempo. Si lo calculamos para toda la historia del sistema,
obtendremos engaosos Resultados. La figura 3.13 muestra un ejemplo
de tal situacin. La figura 3.13 muestra la historia, en trminos de
commit, de dos archivos, donde el tiempo Est en el eje horizontal de
izquierda a derecha y los compromisos se representan como crculos. Si
Calculamos la medida de acoplamiento de cambio de acuerdo con toda
la historia que obtenemos 9 Compartido se compromete en un total de
17, que es un valor alto porque significa que los archivos Cambiaron
juntos ms del cincuenta por ciento del tiempo. Aunque este resultado
es correcto, Es engaosa porque nos lleva a la conclusin de que file1 y
file2 estn fuertemente Pero eran tan slo en el pasado y no estn
acoplados en absoluto durante el ltimo ao del sistema. Dado que
analizamos la informacin de acoplamiento de cambio para detectar
Arquitectura y los problemas de diseo en la versin actual del sistema,
la reciente Cambio son ms importantes que los viejos [202]. En otras
palabras, si dos Archivos estaban fuertemente acoplados en las primeras
fases de un sistema, pero no En los ltimos tiempos (tal vez porque el
acoplamiento fue eliminado durante una reingeniera Fase), no los
consideramos como un problema potencial.

Higo. 3.13. Un ejemplo de resultados engaosos obtenidos al considerar

toda la historia de Artefactos para calcular el valor de acoplamiento de
cambio: obtenemos un acoplamiento de cambio fuerte, mientras que
File1 y file2 no estn acoplados en absoluto durante el ltimo ao Por
estas razones, el Radar de Evolucin depende del tiempo, es decir, se
puede calcular Ya sea considerando toda la historia de los archivos o con
respecto a un tiempo dado ventana. Al crear el radar, el usuario puede
dividir la vida til del sistema en intervalos de tiempo. Para cada intervalo
se crea un radar diferente, y el acoplamiento de cambio Se calcula con
respecto al intervalo de tiempo dado. La coordenada del radio tiene la
Misma escala en todos los radares, es decir, la misma distancia en
radares diferentes representa la Mismo valor del acoplamiento. Esto
hace posible comparar radares y analizar La evolucin del acoplamiento
en el tiempo. En nuestra implementacin de herramientas el usuario A
travs del tiempo "mediante el uso de una corredera, lo que hace que el
radar correspondiente se muestre.
Esta caracterstica introdujo tambin un problema: Cmo hacemos un
seguimiento de los mismos En el tiempo, es decir, en diferentes radares?
Para responder a esta pregunta introdujimos Una segunda caracterstica
llamada seguimiento.

(2) Seguimiento. Permite al usuario realizar un seguimiento de los

archivos a lo largo del tiempo. Cuando un archivo Se selecciona para el
seguimiento en una visualizacin relacionada con un intervalo de tiempo
particular, es En todos los radares (con respecto a todos los dems
intervalos de tiempo) en los que El archivo existe. El resaltado consiste
en el uso de un borde amarillo para el Archivos y en mostrar una etiqueta
de texto con el nombre del archivo. De esta manera es posible Detectar
archivos con un acoplamiento de cambio fuerte con respecto al ltimo
perodo de tiempo Y luego retroceder en el tiempo y analizar el
acoplamiento en el pasado. Esto permite La distincin entre
acoplamiento de cambio persistente, es decir, siempre presente, y
reciente Cambiar acoplamiento, es decir, presente slo durante los
ltimos intervalos de tiempo.
(3) Desove. La caracterstica de desove tiene como objetivo inspeccionar
los detalles del acoplamiento de cambio. Los valores atpicos indican que
los archivos correspondientes tienen un fuerte Archivos del mdulo en
foco, pero ignoramos cules. Para descubrir esta dependencia Entre los
archivos que generan un segundo Evolution Radar como sigue: Los
outliers son Agrupados para formar un mdulo temporal Mt
representado por una figura circular. El mdulo En foco (M) se ampla
entonces, es decir, se crea una figura circular para cada archivo que
compone eso. Finalmente, se crea un nuevo Evolution Radar. El mdulo
temporal Mt se coloca en
El centro del nuevo radar. Los archivos pertenecientes al mdulo
previamente en foco
(M) se colocan alrededor del centro. La coordenada del radio, es decir, la
distancia desde la Es inversamente proporcional al acoplamiento de
cambio que tienen con el mdulo En el centro Mt. Para la ordenacin
angular se utiliza la ordenacin alfabtica. Dado que todos los Los
archivos pertenecen al mismo mdulo hay slo un sector.

Utilizamos el Evolution Radar para responder a las preguntas

mencionadas al principio
De esta seccin: Cules son los mdulos con el acoplamiento ms fuerte
en un software dado sistema? Qu archivos son responsables de estas
dependencias evolutivas? En Lo siguiente aplicamos el radar en
ArgoUML, una fuente abierta grande y de larga duracin Software
system.We primero presentar escenarios de ejemplo de cmo estudiar
el cambio de acoplamiento A diferentes niveles de abstraccin, deteccin
de decaimiento de arquitectura y problemas de diseo Y realizar anlisis
de impacto. Finalmente utilizamos el radar para analizar la evolucin de
Acoplamientos e identificar fases en la historia del sistema.

Deteccin de problemas de diseo y deterioro de la arquitectura

De la documentacin de ArgoUML conocemos la descomposicin del

sistema en mdulos Enfocamos nuestro anlisis en los tres mdulos ms
grandes Model, Explorer y Diagrama. De la documentacin sabemos que
el modelo es el mdulo central que todos Los otros dependen y
dependen. El Explorador y el Diagrama no dependen uno del otro.

Hemos creado un radar para cada seis meses de la historia del sistema.
Empezamos el
Estudio de la ms reciente, ya que nos interesan los problemas de la
actual Versin del sistema. El uso de un intervalo de tiempo
relativamente corto (seis meses) asegura que El acoplamiento se debe a
cambios recientes y no est "contaminado" por compromete mucho en
el pasado. Como mtricas utilizamos el acoplamiento de cambio para la
posicin y el color de las figuras. El tamao (el rea) es proporcional al
nmero total de lneas modificadas En todos los compromisos realizados
durante el intervalo de tiempo considerado.

La Figura 3.14b muestra el Radar de Evolucin de los ltimos seis meses

de historia del
Explorer. A partir de la visualizacin vemos que el acoplamiento con
Diagrama es
Mucho ms fuerte que la de Modelo, aunque la documentacin indica
que la
La dependencia es con Modelo y no con Diagrama. Los archivos ms
acoplados en Diagrama Son FigActionState.java, FigAssociationEnd.java,
FigAssociation.java.
Usando la funcin de seguimiento, descubrimos que estos archivos slo
han sido recientemente acoplados Con el mdulo Explorer. En la figura
3.14a que muestra los seis meses previos, No estn cerca del centro. Esto
implica que la dependencia se debe a Slo cambios.

Para inspeccionar los detalles del acoplamiento de cambio, utilizamos la

caracterstica de desove: Agrup los tres archivos y gener otro radar,
que se muestra en la figura 3.15. Este grupo como el centro. Ahora vemos
que la dependencia se debe principalmente a ExplorerTree. Java. La alta
dependencia entre dos mdulos se reduce
Una dependencia entre cuatro archivos. Estos cuatro archivos
representan un problema en el sistema, Porque modificar uno de ellos
puede romper los otros. El hecho de que pertenezcan a Diferentes
mdulos enterra esta dependencia oculta.
La visualizacin en la figura 3.14b muestra que el archivo
GeneratorJava.java
Es un valor atpico, ya que su acoplamiento es mucho ms fuerte con
respecto a todos los dems Archivos en el mismo mdulo
(CodeGeneration). Al desovar el grupo compuesto De
GeneratorJava.java obtuvimos una visualizacin muy similar a la de la
Figura 3.15, En el que el principal responsable de la dependencia es de
nuevo ExplorerTree.java.

La lectura del cdigo revel que la clase ExplorerTree es responsable de

administrar
Los oyentes del ratn y la generacin de nombres para las figuras. Esto
explica las dependencias Con FigActionState, FigAssociationEnd y
FigAssociation en el Diagrama
Mdulo, pero no la dependencia con GeneratorJava. El pasado (ver
Figura 3.14a y Figura 3.16a) revela que GeneratorJava.java Es un valor
atpico desde enero de 2003. Esta dependencia duradera indica
problemas de diseo.
Higo. 3.14. Evolution Radars para el mdulo Explorer de ArgoUML en
2005 [137] [2006] IEEE

Se requiere una inspeccin adicional para el archivo ExplorerTree.java en

el Explorador
, Ya que es el principal responsable del acoplamiento con los mdulos
Diagrama
Y CodeGeneration. Los radares en la figura 3.14b y la figura 3.14a
muestran que durante 2005 el archivo NSUMLModelFacade.java en el
mdulo Modelo tuvo el acoplamiento ms fuerte con

Higo. 3.15. Detalles del acoplamiento de cambio entre el mdulo

Explorer y el Archivos FigActionState.java, FigAssociationEnd.java y
FigAssociation.java [137] [2006] IEEE

Explorer (mdulo en el centro). Pasando seis meses atrs en el tiempo,

de junio a diciembre 2004 (vase la figura 3.16a), vemos que el
acoplamiento con NSUMLModelFacade .java era dbil, mientras que
haba una dependencia muy fuerte con ModelFacade.

Java. Este archivo tambin fue muy modificado durante ese intervalo de
tiempo, dada su dimensin Con respecto a las otras cifras (el rea es
proporcional al nmero total
De lneas modificadas). ModelFacade.java tambin fue fuertemente
acoplado con el Diagrama (Vase la figura 3.16b). Al mirar su cdigo
fuente descubrimos que esto
Era una clase de Dios [439] con miles de lneas de cdigo, 444 pblicas y
9 privadas
Mtodos, todo esttico. La clase ModelFacade no est presente en los
otros radares (Figura 3.14b y Figura 3.14a) porque fue retirado del
sistema en enero 2005. Leyendo el cdigo fuente de los archivos ms
acoplados en estos dos radares, Es decir, NSUMLModelFacade.java,
descubrimos que tambin es una clase muy grande con
317 mtodos pblicos. Por otra parte, hemos descubierto que 292 de
estos mtodos tienen la La misma firma de mtodos en la clase
ModelFacade6, con ms del 75% de los Cdigo duplicado. ModelFacade
represent un problema en el sistema y por lo tanto fue remoto. Dado
que muchos mtodos se copiaron a NSUMLModelFacade, el problema
ha Acaba de ser trasladado.

Este ejemplo muestra cmo la informacin histrica puede revelar

problemas, que son
Difcil de detectar con una sola versin del sistema. Conocer la evolucin
de
ModelFacade nos ayud a entender el papel de NSUMLModelFacade en
el actual
Versin del sistema. Mostramos ejemplos de cmo utilizar el Evolution
Radar para detectar problemas Partes del sistema ArgoUML, que
representan buenos candidatos para la reingeniera.
Los principales hallazgos del escenario de ejemplo discutido son:
Los mdulos Diagrama y Explorador son los ms acoplados. Dado que
esta dependencia
Higo. 3.16. Evolution Radars de los mdulos Explorador y Diagram de
ArgoUML desde Junio A diciembre de 2004 [137] [2006] IEEE

Los mdulos deben ser reestructurados para disminuir el acoplamiento

o menos
La documentacin debe ser actualizada. Identificamos los cuatro
archivos principales responsables Para esta dependencia oculta.
 Los archivos GeneratorJava.java en el mdulo CodeGeneration y
ExplorerTree.
Java en el mdulo Explorer debe analizarse ms a fondo y, si Posible,
refactorizado. GeneratorJava.java tiene un acoplamiento persistente con
el Explorer, mientras que ExplorerTree.java est acoplado con
CodeGeneration Y Diagrama.

Se detectaron dos clases problemticas: ModelFacade y

NSUMLModelFacade.
La mayora de los mtodos de la primera clase fueron copiados a la
segunda, y luego
ModelFacade se elimin del sistema.

Trabajo relacionado
El concepto de acoplamiento de cambio (es decir, lgico) fue introducido
por primera vez por Gall et al. [185] Para detectar relaciones implcitas
entre mdulos. Utilizaron el acoplamiento lgico para analizar
Dependencias entre los diferentes mdulos de una gran empresa de
Sistema de software y demostr que el enfoque puede utilizarse para
obtener Sobre la arquitectura del sistema. Posteriormente, los mismos
autores revisaron la tcnica para Trabajo a un nivel de abstraccin ms
bajo. Detectaron acoplamientos lgicos a nivel de clase [187] y lo valid
en 28 versiones de un sistema de software industrial. Los autores
Mostraron a travs de un estudio de caso que las debilidades
arquitectnicas como mal diseado Interfaces y jerarquas de herencia
podran ser detectados en base a acoplamiento lgico informacin.

Ratzinger et al. [433] utilizaron la misma tcnica para analizar el

acoplamiento lgico
A nivel de clase con el objetivo de conocer y mejorar la calidad de la
sistema. Para lograr esto, definieron los olores de cdigo basados en el
acoplamiento lgico Entre las clases del sistema.
Se han realizado otros trabajos con niveles de granularidad ms finos.
Zimmermann et al. [567] utilizaron la informacin sobre los cambios que
se estn produciendo juntos para predecir las entidades (Clases,
mtodos, campos, etc.) que puedan ser modificados cuando se est
modificado. Breu y Zimmermann [80] aplicaron las tcnicas de
datamining sobre Para identificar y clasificar las preocupaciones
transversales en los sistemas de software. Ying et al. Tcnicas de minera
de datos aplicadas al historial de cambios de la base de cdigo para
identificar Cambiar patrones para recomendar cdigo fuente
potencialmente relevante para una modificacin particular Tarea [561]
Bouktif et al. [77] mejora la precisin y el recuerdo del co-chancing
Deteccin de archivos con respecto a los enfoques anteriores.
Introdujeron el concepto De los patrones de cambio en general y el
patrn de cambio Synchrony particular para el intercambio Archivos.
Propusieron un enfoque para detectar tales patrones de cambio en CVS
Repositorios basados en la deformacin dinmica del tiempo.

Similar al Evolution Radar, la tcnica de visualizacin de EvoLens puede

ser usada
Para analizar las relaciones de acoplamiento de cambio entre los archivos
de origen y los mdulos de software. En lugar de las vistas de radar, utiliza
una visualizacin grfica que permite al usuario Para desplazar la
informacin de acoplamiento de cambio desde el nivel de mdulos hasta
el archivos fuente. Permite al usuario revelar acoplamientos de cambio
detallados al coste de Siempre teniendo una vista de radar de todo el
sistema. Las ideas bsicas y las Conceptos de la EvoLens Views han sido
desarrollados por Ratzinger et al. [432].

Beyer y Hassan en [59] presentaron el Evolution Storyboards, una

visualizacin Tcnica para la evolucin del software que ofrece vistas
dinmicas. Los storyboards enfatizan
La historia de un proyecto utilizando una secuencia de paneles, cada uno
de los cuales representa un Perodo de tiempo en la vida del proyecto.
Para crear cada panel se calcula un intercambio Grfico y utilizar un
diseo en el que ms fuerte el acoplamiento entre dos archivos Es,
cuanto ms cerca se ubican, revelando as grupos de archivos co-
cambiados con frecuencia.

Mostraban dos aplicaciones principales de la herramienta: Primero

analizaron cmo la estructura De un sistema de software decado o se
mantuvo estable en el tiempo, mediante la comparacin de los clusters
De los archivos co-cambiado con la descomposicin autorizada del
sistema. En el segundo Aplicacin, detectaron archivos que implementan
preocupaciones transversales, detectando Los archivos que siempre se
mueven de panel a panel, lo que significa que estos archivos Se acoplan
(cerca en la disposicin) con muchos otros durante la vida del proyecto.

En [178] Fischer y Gall presentaron EvoGraph, un enfoque ligero basado

en Los datos del RHDB para el anlisis evolutivo y estructural de los
sistemas de software. Ellos
Combin el historial de cambios y los espacios de informacin de cdigo
fuente en un solo enfoque, Para apoyar la comprensin sobre la
interaccin entre la evolucin de los requisitos Y el desarrollo del sistema.
La tcnica EvoGraph se compone de cinco
Fases:
(1) Seleccin de archivos: Archivos de origen que presentan un
acoplamiento lgico extraordinario Con respecto a las transacciones de
cambio cruzadas.
(2) Co-cambio visualizacin.
(3) Extraccin de hechos: Para los archivos seleccionados en el paso
anterior, Informacin de transaccin de cambio detallada se recopila del
RHDB y como resultado Se crean vectores de cambio para cada archivo
dentro de una transaccin. (4) Minera: El cambio Vectores son la entrada
a la minera de cambio de datos de transaccin paso; La salida es una
descripcin De la evolucin longitudinal de las dependencias
estructurales de los archivos seleccionados.
(5) Visualizacin: Las dependencias estructurales se visualizan en un
electrocardiograma Diagrama de estilo.

3.4.3 Anlisis de tendencias y deteccin de puntos calientes

En esta seccin presentamos el ArchViewapproach utilizado para crear
diferentes
Vistas del cdigo fuente. Las vistas visualizan los mdulos de software
que se Descomposicin de un sistema en unidades de implementacin
manejables. Tales unidades, por ejemplo, Son paquetes, directorios de
cdigo fuente, clases o archivos de origen. El objetivo de ArchView es
sealar los aspectos especficos de la implementacin de una y mltiples
fuentes Liberaciones de cdigo. Por ejemplo, destacar mdulos que son
excepcionalmente grandes, complejos, Y muestran fuertes relaciones de
dependencia con otros mdulos. Ellos son los Los llamados hot-spots en
el sistema. Adems, los mdulos con un fuerte Tamao y complejidad, o
los mdulos que se han vuelto inestables se destacan. Tal Pueden ser
utilizadas por ingenieros de software, por ejemplo
para (1) obtener una pista de la aplicacin Diseo y su evolucin; (2)
detectar los mdulos importantes que implementan La funcionalidad
clave de un sistema de software; (3) para detectar los mdulos
fuertemente acoplados; (4) identificar tendencias de evolucin crtica.
Las ideas bsicas y los conceptos subyacentes de
ArchView se han desarrollado en la obra de Pinzger et al. [417].
ArchView obtiene los valores de mtrica de cada mdulo y la relacin de
dependencia
Desde el RHDB y los asigna a un vector de caractersticas m. Se rastrean
los vectores de entidades
Higo. 3.17. Diagrama de Kiviat de moduleA que representa medidas de
seis mtricas de cdigo fuente M1, M2, ...., M6 de una versin

Sobre las n liberaciones seleccionadas y compuestas a la matriz de

evolucin E. Los valores en a matriz cuantifica la evolucin de un mdulo
de software:

La matriz contiene n vectores de caractersticas con medidas de mtricas

i. Matrices de la evolucin Se calculan para cada mdulo. Forman la
entrada bsica a nuestro ArchView Visualizacin que presentaremos a
continuacin.

El enfoque de ArchView utiliza la tcnica de visualizacin de vistas

polimtricas presentada Por Lanza et al. [309]. En lugar de usar
rectngulos para presentar mdulos y mtricas ArchView utiliza
diagramas de Kiviat que tambin se conocen como diagramas de radar.

Estos diagramas son adecuados para presentar mltiples valores

mtricos disponibles para un mdulo Como se describe a continuacin.

La figura 3.17 (a) muestra un ejemplo de un diagrama de Kiviat que

representa
Seis mtricas M1, M2, ...., M6 de una liberacin del mdulo moduleA. El
subyacente
Los datos proceden de la siguiente matriz de evolucin E:
En un diagrama de Kiviat, los valores mtricos estn dispuestos en un
crculo. Para cada mtrica Hay una lnea recta que se origina en el centro
del diagrama. La longitud de esta lnea Se fija para todas las mtricas y
cada valor de la mtrica se normaliza segn l. En el Ejemplos
presentados en esta seccin usamos la siguiente normalizacin:

Donde cl denota la longitud constante de la recta y max (m) el mximo

Valor de una mtrica m a travs de todos los mdulos a visualizar. Con
el valor normalizado Y el ngulo de la recta que indica la mtrica la
posicin de dibujo del punto En la lnea se calcula. Para que los valores
de mtrica sean visibles en el diagrama adyacente Los valores mtricos
estn conectados formando un polgono como el que se muestra en la
figura 3.17.

Al visualizar los valores de mtrica para una serie de versiones

posteriores, Se centra en resaltar el cambio entre los valores mtricos.
Tpicamente, los aumentos en Los valores mtricos indican la adicin y
disminuyen la eliminacin de la funcionalidad. los
La adicin de funcionalidad es un signo habitual de la evolucin de los
sistemas de software por lo que representa No hay problema en
particular. Por el contrario, la eliminacin de la funcionalidad a menudo
indica Cambios en el diseo. Por ejemplo, los mtodos se mueven a una
clase diferente para resolver Una relacin de dependencia (bidireccional)
y mejorar la separacin de las preocupaciones O los mtodos se eliminan
debido a la eliminacin del cdigo muerto (es decir, el cdigo que no se
utiliza nunca ms).

Para resaltar los cambios en los valores mtricos usamos los diagramas
de Kiviat como se describe antes de. Los n valores de cada mtrica
obtenidos de las liberaciones mltiples se dibujan en La misma lnea.
Nuevamente los valores mtricos adyacentes de la misma liberacin
estn conectados por Una lnea que forma un polgono para cada
liberacin. Entonces el rea emergente entre dos polgonos De dos
lanzamientos posteriores se llenan de diferentes colores. Cada color
indica Y destaca el cambio entre los valores de mtrica de dos
liberaciones. Cuanto mayor sea el Cambiar el polgono ms grande. La
figura 3.17 (b) representa el mismo conjunto de medidas para el mdulo
A, pero esta vez de Dos lanzamientos. Al llenar el rea entre los
lanzamientos, el cambio de los valores mtricos es Resaltado. Para
distinguir los cambios entre diferentes versiones de cdigo fuente,
Utilizar tonos grises. Esto permite al usuario detectar tendencias en los
valores mtricos, como se mostrar En los siguientes dos escenarios de
anlisis.

Anlisis del tamao y complejidad de los mdulos de software

El primer escenario se refiere a un anlisis del crecimiento del tamao y

la complejidad del programa De mdulos de software. Demostramos
esto mediante la visualizacin de tamao tpico y programa Mtricas de
complejidad tomadas de tres versiones 0.92, 1.3a y 1.7 del contenido de
Mozilla Y mdulos de diseo. Configuramos ArchView con el siguiente
conjunto de mtricas: Halstead contenido inteligente (HALCONT),
Halstead esfuerzo mental (HALEFF), Halstead Dificultad del programa
(HALDIFF), complejidad ciclomtica de McCabe (CYCL) y lneas de Cdigo
(LOC). La vista resultante se representa en la figura 3.18.

Los mdulos interesantes estn representados por diagramas de Kiviat

con grandes, llenos, Polgonos grises. Indican un fuerte aumento y
disminucin en el tamao y el programa Complejidad de los mdulos de
software mientras que los polgonos pequeos representan mdulos
ms estables. Siguiendo esta gua podemos ver fcilmente que
NewLayoutEngine y DOM (Document Object Model) son los dos mdulos
ms grandes y complejos de la Implementacin de contenido y diseo de
Mozilla. Por ejemplo, en la versin 1.7 DOM comprende197.498 y
NewLayoutEngine 156.438 lneas de cdigo C / C ++. En contraste, el El
mdulo XML comprende 23.471 lneas de cdigo.

Higo. 3.18. Grfico de Kiviat de seis mdulos de contenido y diseo de

Mozilla que muestra el crecimiento en Tamao y complejidad del
programa. Los polgonos gris claro indican cambios entre las liberaciones
0.92 Y 1.3a. Los polgonos gris oscuro muestran cambios entre 1.3a y 1.7

Los polgonos grises grandes estn contenidos por los diagramas de Kiviat
de los mdulos DOM, NewHTMLStyleSystem y XML que indican que la
implementacin de estos tres Los mdulos ms modificados.
Observando el tamao seleccionado y la complejidad del programa Los
valores de los tres mdulos aumentaron primero de
Liberar 0,92 a 1,3a y luego disminuir desde la liberacin 1,3a a 1,7. Por
ejemplo, el
La mtrica HALCONT del mdulo DOM de la versin 0.92 a la versin 1.3a
aument de
15.167 a 18.228 seguido por una disminucin a 14.714 en la versin 1.7.
Aparentemente, de Se aadi una funcionalidad de liberacin de 0,92 a
1,3a a estos tres mdulos que durante La implementacin de la ltima
versin fue refactorizada o eliminada. En comparacin A estos tres
mdulos, los valores mtricos de los otros mdulos indican slo Cambios
menores en tamao y complejidad del programa por lo tanto son
estables. Basado en el Supuesto de que los mdulos que cambiaron en
un lanzamiento pasado probablemente cambiarn en Futuro libera los
tres mdulos DOM, NewHTMLStyleSystem, y XML son los candidatos
Que son fundamentales para la evolucin de la implementacin de
contenido y diseo De Mozilla.

Deteccin de puntos calientes del sistema

Los hot spots del sistema son mdulos de alta actividad indicados por
diferentes Como el nmero de problemas que afectan a un mdulo o el
nmero de cambios en un mdulo. En este escenario de analizar puntos
calientes del sistema nos centramos en proporcionar respuestas A las
siguientes tres preguntas: Cules son los mdulos con errores
frecuentes? Cual Son los mdulos ms crticos? Qu mdulos se han
estabilizado? Las respuestas a estas Se pueden encontrar preguntas en
el RHDB en particular en los datos de Bugzilla. Nosotros cuantificamos La
criticidad y estabilidad de un mdulo de software por el nmero de
cdigo fuente Modificaciones (es decir, entradas de registro CVS)
realizadas para corregir errores que se informaron

Higo. 3.19. Grfico de Kiviat de seis mdulos de contenido y diseo de

Mozilla que muestran estabilidad. Los polgonos gris claro indican
cambios entre las liberaciones de 0,92 y 1,3a. Gris oscuro Los polgonos
muestran cambios entre 1.3a y 1.7

Durante un perodo de observacin dado tal como el tiempo entre dos

liberaciones. Para Detalle la criticidad y la estabilidad que tomamos los
diferentes niveles de gravedad de los errores que van Desde los
bloqueadores hasta los errores menores y triviales (los niveles de
gravedad se toman Del repositorio Bugzilla). Esto conduce al siguiente
conjunto de medidas: nmero de Modificaciones para errores con
gravedad no especificada (UNSPEC), nmero de modificaciones Para
errores de bloqueo (BLOCKER), nmero de modificaciones para errores
crticos (CRITICAL), Nmero de modificaciones de los principales errores
(MAJOR), nmero de modificaciones Bugs (MINOR), nmero de
modificaciones para errores normales (NORMAL), nmero de
modificaciones Para errores triviales (TRIVIAL) y nmero de
modificaciones para mejoras sugeridas (MEJORAR). Configuramos
ArchView con estas medidas y seleccionamos Seis mdulos de contenido
y diseo de Mozilla desde la versin 0.92, 1.3a y 1.7. La resultante La vista
del punto caliente del sistema se muestra en la figura 3.19.

Los grandes polgonos grises del DOM y NewLayoutEngine indican que

estos Dos mdulos obtuvieron el mayor nmero de entradas de registro
CVS para corregir errores. Por ejemplo, Hasta la versin 1.7 DOM obtuvo
254 modificaciones de 130 bugs clasificados como bloqueadores y 904
Modificaciones de 487 bugs calificados como crticos. NewLayoutEngine
tiene 309 registros CVS Entradas de 121 bloqueadores y 1.097 entradas
de registro de informes de errores crticos. Curiosamente, La mayora de
las modificaciones en la implementacin de estos dos mdulos se
debieron a Errores de alta severidad y slo unos pocos debido a errores
insignificantes. Este hecho es indicado por el corte De la medida de
TRIVIAL que ocurre en ambos diagramas de Kiviat. En comparacin con
estos dos Los otros mdulos de contenido y diseo requeran menos
modificaciones para corregir errores.
Por ejemplo, XSLT consigui 7 modificaciones debido a 3 errores de
bloqueo y 48 modificaciones Debido a 12 bugs crticos. Curiosamente, el
Kiviat de XSLT muestra un pico en el nmero De insectos triviales
(TRIVIAL). Se realizaron 123 modificaciones debidas a 3 insectos triviales
Que es ms del doble que los valores de los otros cinco mdulos (por
ejemplo, DOM Obtuvo 55 y NewLayoutEngine 43 modificaciones).
Aparentemente, un gran nmero de archivos Tuvo que ser tocado para
arreglar los tres errores triviales. Por ejemplo, se modificaron 56 archivos
Para corregir el error # 88623. Esto plantea la pregunta acerca de cmo
"trivial" este error fue cuando Las modificaciones tuvieron que hacerse
en 56 archivos fuente.

Con respecto a la criticidad y estabilidad de los mdulos de software,

Tendencia de estas medidas. Ms especficamente, los mdulos estables
estn indicados por Polgonos gris oscuro significando menos bugs y
modificaciones durante el desarrollo de Versin 1.7. De acuerdo con la
Figura 3.19, los mdulos NewHTMLStyleSystem y XML Se vieron
afectados por casi cero cambios. Representan el contenido ms estable
y Mdulos de diseo. Los otros cuatro mdulos parecen ser ms crticos
Polgonos de color gris claro y gris oscuro, mientras que los polgonos de
color gris claro Diagramas. Esto significa que una gran cantidad de
errores de fijacin tuvo lugar en el perodo de tiempo Desde la liberacin
0,92 hasta 1,3a, que luego disminuy en el tiempo de desarrollo de la
liberacin 1.7.

Por ejemplo, el nmero de modificaciones para la fijacin de bugs

bloqueadores disminuy de 65 Entre las liberaciones de 0,92 y 1,3a a 8
modificaciones entre 1,3a y 1,7. Ese Es un claro indicador de que los otros
cuatro mdulos eran crticos en las versiones anteriores, pero Se
estabiliz en la versin 1.7.

Trabajo relacionado

Se han desarrollado una serie de enfoques que abordan la visualizacin

de datos de
Varias versiones de software. Por ejemplo, Riva et al. Utilizar grficos 2D
y 3D para visualizar Y navegar el historial de liberacin de un sistema de
software [188]. El tiempo se visualiza en La coordenada z expresada en
nmeros de secuencia de liberacin (RSN). La estructura de Cada versin
de software se visualiza utilizando grficos 3D con un diseo de rbol.
Cada grfico es Espacialmente posicionado a lo largo de la coordenada z
mostrando la secuencia de liberaciones. Un cubo Denota un subsistema
o un mdulo de software. Los bordes indican la descomposicin de cada
uno En subsistemas y mdulos. Una medida puede ser asignada a los
grficos 3D Utilizando el atributo de color. Por ejemplo, mapearon el
nmero de versin de un mdulo De manera que un mdulo que no est
presente en una liberacin est representado por un cubo negro, Un
mdulo en la versin 1 est representado por un cubo rojo, en la versin
2 por un cubo azul, etc.

Un enfoque similar al enfoque de Riva et al. Es presentado por Collberg

et al. En [121]. Desarrollaron GEVOL, un sistema basado en grficos para
visualizar la evolucin De los sistemas de software. Cada estado de un
sistema se representa mediante un grfico. Colores Se aplican para
indicar el cambio en el tiempo tal como cuando partes particulares del
programa Fueron creados y modificados en primer lugar, el programador
modific qu partes, o qu Partes han crecido en complejidad. Todos los
nodos empiezan a ser rojos, luego se vuelven ms plidos Cada vez que
se han mantenido sin cambios. Cuando un nodo cambia de nuevo, vuelve
a rojo. Cuando un usuario nota un evento interesante, como un
segmento de cdigo cambia con frecuencia, Puede hacer clic en un nodo
para examinar el conjunto de autores que han afectado a estos Cambios.

Lanza desarroll un mtodo llamado EvolutionMatrix [308]. En lugar de

usar Un diseo de rbol Lanza utiliza un diseo de matriz.
EvolutionMatrix muestra la evolucin De las clases de un sistema de
software. Cada columna de una matriz representa una versin de El
software, mientras que cada fila representa las diferentes versiones de
una clase. Figura 3.20.
Higo. 3,20. Matriz de evolucin con cuatro caractersticas tpicas de un
sistema de software en evolucin[308], ACM, 2001

Muestra un ejemplo de Matriz de Evolucin con caractersticas tpicas

de un sistema Tales como las clases de la primera versin, las clases
eliminadas, un salto importante en la evolucin, Y la ltima versin del
sistema.

Siguiendo el principio de Polymetric View, se pueden asignar una serie

de medidas
A la anchura, altura y color de los rectngulos que representan las clases.
Patrones recurrentes En la matriz que llevaron a una categorizacin de la
evolucin de las clases. Por Por ejemplo, una clase que est creciendo
alternativamente y encogindose en tamao se llama Pulsar.

Las clases de pulsos pueden ser vistas como puntos calientes en el

sistema: para cada nueva versin de la Los cambios del sistema en una
clase pulsar deben ser realizados. Otras categoras de clases, Por
ejemplo, son Supernova (la clase de repente explota en tamao) o Dayfly
(clase con Una vida corta). En [548] Wu et al. Presente Espectroscopia de
Evolucin, una tcnica de visualizacin que Combina mtricas y colores
gradientes para representar la evolucin de los sistemas de software. Un
espectografo se muestra como una matriz similar a la EvolutionMatrix
en la que el tiempo es Presentado en el eje X y la dimensin de los
archivos se presenta en el eje Y. Una fila En la matriz representa el
historial de cambios de un archivo y una columna almacena el cambio
Mtricas para todos los archivos durante un perodo de tiempo
determinado. Cada celda representa un archivo En un perodo
determinado. Despus de cambiar un archivo, su color se vuelve ms
claro y ligero Siempre que no se efecte ningn cambio en dicho
expediente. En otras palabras, el archivo comienza a enfriarse
Si no le ocurre ningn cambio en el futuro. Usando esta funcin de color
Evolution Spectographs puede Se utilizar para resaltar el crecimiento
del sistema y el cambio de dependencia en un grfico.

3.5 Conclusin

Repositorios de software de minera es un tema de investigacin

bastante reciente que se ha adoptado Tanto por la evolucin del
software como por la comunidad emprica de ingeniera de software.
Como hemos visto en este captulo, hay dos desafos principales:

Desafo tcnico. El desafo reside en el modelado y manejo de Tipos de

informaciones. La gran cantidad de informacin disponible en la fuente
Repositorios plantea tambin problemas de escalabilidad que se han
abordado En gran medida. Como hemos visto, en la mayora de los casos
los investigadores han optado por utilizar Relacionales para manejar los
datos, ya que permiten una fcil consulta.

Desafo conceptual. Una vez que los datos son recuperados y

modelados, un gran reto Reside en hacer algo significativo con los datos
disponibles. Como hemos visto
En los diversos enfoques, al principio hay siempre una serie de Preguntas
que deben ser contestadas y, posteriormente, los investigadores
Mecanismos necesarios para responder a esas preguntas. Una tcnica
muy utilizada en Este caso es la visualizacin, ya que permite (si bien
elegido) para detectar patrones en el mar De los datos que uno tiene que
navegar.

Como un reto importante en el futuro, vemos la dicotoma actual entre

ingeniera avanzada Y la evolucin del software. Creemos que los
repositorios de software, actualmente Utilizados para los anlisis
retrospectivos, deben convertirse en parte integral de cualquier
Proyecto, y como tal no debe separarse de la versin ms reciente, que
Es generalmente el foco de todos los esfuerzos de mantenimiento.