RESUMEN Los proyectos de software utilizan distintos repositorios para almacenar el proyecto y evolucin de la informacin como el cdigo fuente,

bugs y parches. Un sistema integrado que combina estas mltiples repositorios, a lo largo de con tcnicas de bsqueda de eficiencia que se puede responder a una amplia gama de pregunta relacionada con la historia de la evolucin del proyecto sera beneficioso tanto a los desarrolladores de software (para el desarrollo y mantenimiento) y los investigadores (por anlisis empricos). Por ejemplo, la lista de cambios en el cdigo fuente o la lista de desarrolladores asociados con una correccin de errores son consultas frecuentes para los desarrolladores e investigadores. Integracin y la recopilacin de esta informacin es tedioso y engorroso, propenso a errores cuando se hace manualmente, especialmente para grandes proyectos. Enfoques anteriores a este marco problemtico de que limitar al usuario a un conjunto de plantillas de consulta predefinidas, o usar consulta lenguas con un poder limitado. En este trabajo, se argumenta la necesidad de un marco construido con lenguajes recursivamente enumerables, que pueden responder a las consultas temporales, y es compatible con la negacin y la recursividad. Como primer paso hacia ese marco, se presenta un sistema basado en Prolog que hemos construido, junto con una evaluacin del mundo real integrado datos del proyecto Firefox. Nuestro sistema permite unos investigadores para el desarrollo de las tareas frecuentes y empricos de anlisis. INTRODUCCIN Los proyectos de software son ms grandes que nunca y sus historias para ejecutar ms que nunca, por lo que los desarrolladores se sienten abrumados cuando lo se enfrentan a tareas tales como la comprensin del programa o la bsqueda a travs de los datos de la evolucin de un proyecto. Ejemplos de tales frecuente tareas de desarrollo incluyen la comprensin del flujo de control, la bsqueda de la lista de funciones que dependen de una funcin, la bsqueda de mdulos que se ver afectada cuando un mdulo se cambia durante una correccin de errores, etc Del mismo modo, durante la fase de mantenimiento de software, frecuentes tareas incluyen el seguimiento de los archivos que se estn cambiando debido a un correccin de errores, la bsqueda de desarrolladores que es adecuado para la fijacin de un error (por ejemplo, dado que se ha fijado errores similares en el pasado o que ha trabajado en los mdulos de que el error se produce en). Adems, un marco que permite realizar consultas sobre datos de la evolucin integrados para grandes proyectos sera beneficioso para la investigacin en ingeniera de software emprica, donde los datos de estos depsitos se utiliza con frecuencia para la hiptesis pruebas. Todas estas tareas requieren bsqueda expresiva y eficiente sobre grandes conjuntos de datos que cruza repositorios, por tanto, un marco que puede integrar estos datos de mltiples fuentes y responder a una amplia serie de consultas sera beneficioso para el desarrollo de software tanto y el anlisis emprico. Mientras que muchos marcos de bsqueda y visualizacin se han propuesto, que permiten eficientes de bsqueda y anlisis de la evolucin del software datos, tienen dos inconvenientes principales: (1) no son flexibles suficiente, por ejemplo, permiten un rango limitado de consultas, o fijados han plantillas de bsqueda, (2) no son lo suficientemente potente como, por ejemplo, lo hacen no permitir consultas recursivas, o no son compatibles con la negacin, sin embargo, estas caractersticas son esenciales para una amplia gama de bsqueda y anlisis tareas. En este artculo se muestra cmo se puede subsanar estas deficiencias mediante el uso de una integracin basada en Prolog y el marco de la consulta. Nosotros Prolog eligi por tres razones principales: (1) es declarativa, que permite la expresin elegante y concisa de la recopilacin de datos e hiptesis pruebas, (2) que soporta la negacin, y (3) que soporta recursiva consultas, por ejemplo, para calcular el cierre transitivo, lo cual es esencial en muchos estudios de anlisis de impacto. Nuestro

marco captura una riqueza de los datos histricos de la evolucin de software (informacin sobre fallos, desarrolladores, cdigo fuente), y permite sucintas pero amplia gama consultas sobre estos datos. Las tres novedades principales de nuestro marco de trabajo son: (1) es temporalmente al tanto, todas las tuplas de la base de datos tiene informacin de tiempo que permite la comparacin de los datos de evolucin (por ejemplo, cmo ha cambiado el complejidad ciclomtica de un archivo cambiado con el tiempo); (2) que soporta potentes funciones de lenguaje tales como la negacin, la recursividad y la cuantificacin; (3) que permite la integracin eficiente de los datos procedentes de mltiples repositorios en la presencia de datos incompletos o faltantes utilizando varias heursticas. En particular, con una sola consulta (Q12 en la seccin 4), podemos recopilar los datos tossing fallos que meticulosamente recogen manualmente en uno de nuestros esfuerzos anteriores [3]. El resto del trabajo se organiza de la siguiente manera: se discute relacionados trabajar en la Seccin 2. Se describen las ventajas de usar un Prolog marco basado, las novedades clave en nuestro diseo, y nuestra modelo de datos en la Seccin 3. Se demuestra cmo nuestro marco puede elegantemente expresarse y responder con eficacia, una amplia gama de consultas, sin necesidad de plantillas predefinidas, en la Seccin 4; estas consultas formar el ncleo de una biblioteca de consulta que puede ser utilizado por los desarrolladores y los investigadores en sus actividades. Hemos probado nuestro marco de un gran proyecto en el mundo real con distinto cdigo fuente y error repositorios: un subconjunto de Firefox1 evolucin datos. Desde repositorio de cdigo fuente de Firefox, se extrajeron registro de cambios historias para llenar la base de datos de cdigo fuente. Nosotros luego extrajeron los errores asociados con estos archivos de origen. Finalmente, hemos aadido la funcin de llamada (bordes de la grfica llamada esttica) a la base de datos, para demostrar cmo nuestro marco es beneficioso impacto anlisis. En la Seccin 5 se presentan los resultados preliminares de la evaluacin nuestro marco de Firefox de datos, en trminos de tamao y resultado velocidad de las consultas. En la seccin 6 se describen los retos de investigacin abiertos y la orientacin futura de nuestro trabajo. Hindle y alemn [12] propuesto SCQL, una de primer orden y temporal lgica basada en lenguaje de consulta para los repositorios de control de cdigo fuente. Su modelo de datos es un grfico dirigido que exhibe relacin entre la fuente de revisiones de cdigo, archivos y solicitudes de modificacin. SCQL admite consultas universales y existenciales, como lo hacemos, pero lo hace no admite negacin y la recursividad, lo que hacemos. A pesar de que no lo hacen proponer un nuevo lenguaje, la diferencia significativa es que consideramos mltiples repositorios de software para integrar los datos y contestar consultas. En lugar de cambios en el cdigo fuente nico, nuestro marco captura las relaciones entre los tres artefactos: desarrolladores, insectos y cdigo fuente. Fischer et al. [7] propuso un mtodo para rellenar una liberacin historia de base de datos que combina informacin de cdigo fuente con error seguimiento de los datos y es por lo tanto capaz de identificar los datos que faltan no cubiertas por los sistemas de control de versiones, tales como puntos de fusin. Similar a Fischer et al., construimos nuestra base de datos inicialmente mediante la extraccin informacin desde el cdigo fuente y los registros de errores. Alemn [8] propone recuperar la historia de la evolucin del software usando software senderos de informacin dejada por los contribuyentes a el proceso de desarrollo, tales como listas de correo, sitios web, la versin registros de control, actualizaciones de software, la documentacin y el cdigo fuente. El mtodo se utiliza para recuperar los rasgos de software para la evolucin Ximian proyecto. Nuestra coleccin de datos y la base de datos de poblacin es similar al alemn, sin embargo

nuestro marco es una herramienta de bsqueda basada en que puede responder a las consultas de agregacin de datos procedentes de mltiples repositorios.Begel et al. [1] desarrollado un marco llamado Libro de cdigos, que es capaz de combinar mltiples repositorios de software dentro de una plataforma. Nuestro trabajo es similar, pero el principal reto en la construccin un marco para proyectos de cdigo abierto se encuentra en la recopilacin y precisin la integracin de los datos relacionados en ausencia de repositorios organizados y falta de datos [7]. Su lenguaje de consulta se limita a regular expresiones, pero tiene soporte para un conjunto fijo de precalculada transitivo resultados del cierre, que utilizamos Prolog, un lenguaje Turing-completo, por lo tanto, nuestro marco puede expresar y responder a las consultas de libre disposicin, incluyendo las temporales. Nussbaum et al. [14] present la ltima base de datos de Debian que integra informacin sobre el proyecto Debian desde varios fuentes para responder a consultas de los usuarios relacionadas con los errores y el cdigo fuente que utilizan un marco basado en SQL. Sin embargo, su estructura no tiene soporte para consultas que requieren negacin o el cierre transitivo. Starke et al. [16] llev a cabo un estudio emprico sobre los programadores " actividades de bsqueda para identificar las deficiencias de bsqueda existente herramientas. Ellos encontraron que el estado de la tcnica de bsqueda de cdigo fuente Herramientas basado en el SQL-marco no son lo suficientemente eficaces para expresar la informacin que el desarrollador est buscando. Creemos que declarativa compatibilidad con consultas mejorar la experiencia de bsqueda de cdigo de los desarrolladores. Caractersticas principales Ahora exhibir algunas de las caractersticas clave de nuestro marco; existente enfoques no apoyan una o ms de estas caractersticas. 3.2.1 Consultas temporales Los enfoques previos que construyen bases de datos a partir de la integracin de mltiples repositorios de software no son capaces de responder temporal consultas. Por ejemplo, las siguientes preguntas no pueden ser respondidas por los sistemas existentes: (1) que modific el archivo A en un da determinado, (2)? quien fue el B bug asignado durante un perodo determinado?, (3) lo que se realizaron cambios en un archivo F durante un perodo especfico de tiempo?, (4) cmo tienen mtricas de cdigo fuente (por ejemplo, la complejidad, la densidad de defectos) de un archivo con el tiempo? 3.2.2 La recursividad Clausura transitiva es til para el anlisis de impacto, por ejemplo, "devolver el conjunto de archivos que se vern afectados por las modificaciones a presentar F. "El problema con los enfoques anteriores es que o bien no se puede calcular cierre transitivo, o no se puede calcular cuando el grfico (donde bordes indicar un "depende" relacin) no se conoce estticamente. Por ejemplo, podramos querer encontrar todos los descendientes de un archivo F despus de que ha sido reprogramado. Si no conoce la definicin de "depende", es decir, en este caso, es-descendiente-de, en el momento construimos la base de datos, primero tenemos que escribir una consulta que genera el grfico y, a continuacin transitivamente cerrarla, usando un lenguaje lo suficientemente potente como para expresar clausura transitiva. Del mismo modo, supongamos tenemos un error en F B1 archivo, y queremos encontrar la lista de posterior errores en F que podran haber sido introducidas en el proceso de de fijacin B1. El problema es que la lista de errores posteriores se construye dinmicamente, por ejemplo, todos los bichos en F menos la lista de errores en F que dependen de otros errores en otros archivos. Los enfoques anteriores como libro de cdigos [1] cierre utilizacin pre-computada transitivo para una eficiente responder a un conjunto predefinido de preguntas, por ejemplo: "el conjunto de todas

F funciones depende ", sin embargo, las consultas como" una lista de todas las funciones que F1 y F2 depende de "no se puede responder porque requieren soporte de idioma para recursin / cierre transitivo. Por otra parte, cuando los datos de los nuevos lanzamientos se aade a la base de datos, precomputados cierre transitivo no funciona, porque el "depende" relaciones podra haber cambiado debido a los nuevos datos, por lo tanto, un algoritmo dinmico cierre transitivo sera necesario. Nota que no estamos recibiendo la expresividad de forma gratuita, como el cierre transitivo es caro cuando se calcula ingenuamente (O (N3)), sin embargo, puede ser acelerado a travs de la multiplicacin de matrices (O (N! log (N))) [4], o incluso adems con algoritmos aleatorios [5]. 3.2.3 Integracin En los proyectos de cdigo abierto, a menudo es difcil de integrar relacionados informacin porque est espacialmente dispersa e incompleta. Para ejemplo, a menudo los informes de errores no se cuenta con informacin completa sobre archivos que se han modificado durante una correccin de errores. Considere la posibilidad de errores de Mozilla 334314, de acuerdo al informe de fallo Bugzilla, tres cambios fueron hechos de presentar ssltap.c para corregir este error una vez por el desarrollador de Identificacin alexei.volkov.bugs y dos veces por desarrolladores ID Nelson. La informacin en la referencia de parche para este cambio es incompleto; 2 es no est claro que-tiene-que-hacer-el cambio. Sin embargo, desde el cambio iniciar de archivo ssltap.c, podemos recuperar los desarrolladores, cambios y cambiar las marcas de tiempo, lo que nos ayuda a completar la base de datos de errores. Como otro ejemplo, considere la siguiente consulta: "devolver la lista de errores para que el desarrollador que inform del fallo que lo arreglaron. "Bug Mozilla 420212 es un ejemplo, el usuario Nelson Bolyard inform del fallo y el desarrollador con ID nelson lo arreglen. Entidad de resolucin, es decir, identificar usuario "Bolyard Nelson" y desarrollador de "Nelson", como la mismo persona es difcil de automatizar. Por lo tanto, el error de notificacin y correccin de errores-tuplas en nuestra base de datos contendr nombres diferentes y bug 420212 no ser devuelto en el resultado de la consulta. Para solucionar este problema, se utiliza una heurstica que comprobar si dos nombres tienen una subcadena comn, por ejemplo, en este caso "Nelson Bolyard" contiene "Nelson". Sin embargo, esto no siempre es as, por ejemplo, "mate" es un ID de desarrollador se encuentra en los archivos de registro y hay ms de un desarrollador cuyo nombre o ID contener "mate", por ejemplo, "matthewgertner" y "Mattyisageek". Actualmente usamos un script de Perl para conocer las identificaciones y Los nombres que figuran en cada uno y luego comprobar manualmente de falsos positivos. En el futuro tenemos la intencin de utilizar la integracin automatizada heurstica (similar a Fischer et al. [7]) para aumentar la escalabilidad y precisin. 3.3 Almacenamiento Como se muestra en la Figura 1, obtenemos informacin de tres fuentes: (1) repositorios de cdigo fuente, tamao, localizacin, dependencias de cdigo fuente a partir de la grfica de la funcin llamada esttica, etc, (2) errores repositorios- que inform del fallo, cul es la situacin actual del bicho, bicho datos de dependencia, etc, y (3) la interaccin entre los desarrolladores- que arroj errores a los cuales, dos desarrolladores que trabajaron en mismo archivos, etc Note como llamadas a funciones, los insectos y las interacciones desarrollador inducir grficos de dependencia. Integramos la informacin de estos tres fuentes y almacenarlos en una base de datos, a fin de que nuestro marco puede responder a las consultas en origen, como se demuestra en la Seccin 4. El esquema de la base de datos se presentan en la Tabla 1. Ahora procedemos para describir el esquema de base de datos, contenidos, y actualizaciones.

Cdigo fuente. Los datos de cdigo fuente se almacena en tres tablas: bsico informacin del cdigo fuente, los cambios de cdigo fuente y el cdigo fuente dependencias. El cdigo fuente bsica de informacin de la tabla (sourcebasic) Almacena, para cada mdulo (archivo): su ubicacin, la lista de funciones que define, mtricas de complejidad, informacin densidad de defectos, y los correspondientes a fecha. Tenga en cuenta que un archivo puede tener varias entradas en el base de datos debido a varias versiones, por lo tanto, cuando un archivo no se cambia en un comunicado, todos los valores de marca de tiempo, pero la liberacin no se modifican. Estas entradas son importantes para el seguimiento de los cambios entre versiones. En la tabla de cambio de origen (sourcechange), almacenamos los detalles de todos revisiones que se han hecho a un archivo, ya sea como mejoras de caractersticas o correcciones de errores: la fecha en que se hizo el cambio, el ID de revisin, el ID del error (si el cambio se debi a una correccin de errores) y el promotor que lo cometi, y aadi nmero de lneas. Para un cambio de la fuente entrada en la base de datos, tambin se almacenan el nmero de das desde la primero commit3 la actividad actual se place.4 En la dependencia fuente mesa (sourcedepend), almacenamos la informacin de la que otras entidades de un mdulo o funcin depende de forma directa, es decir,

RESULTADOS Se seleccionaron al azar 2128 archivos C y 58 C + + archivos de la Fuente de Firefox repositorio de cdigo y extrae su cambio completo registrar historias para llenar nuestra base de datos el cambio de fuente. Se extrajeron los errores asociados a estos archivos de origen, resultando en 932 error archivos de la base de datos de errores. Tambin hemos aadido a nuestra dependencia de fuentes tabla de los 50 bordes de llamadas de funcin inducidos por el grfico de llamadas esttico entre las funciones de estos archivos. En total, nuestra base de datos contena 63.142 tuplas. En la tabla 4 se presentan las preguntas que hemos utilizado para probar la definiciones de consulta mostr en la Tabla 3. La primera columna muestra el invocacin consulta, la segunda columna muestra el nmero de resultar tuplas, 5 y la tercera columna muestra el tiempo de ejecucin de la consulta, en milisegundos. Se encontr que el tiempo necesario para responder a una consulta mediante aumentos DES con el aumento en el nmero de tuplas resultantes, por lo que puede ser muy altos para las consultas con resultados de gran tamao, por ejemplo, Q10, tenemos la intencin de abordar este problema de escalabilidad en el trabajo futuro.