开源软件库中文件修改的统计特性:案例分析

开源软件的开放合作模式有望改变传统的软件开发方式,挖掘SVN(Subversion)代码库中文件的版本变化规律,有助于发现潜在缺陷,从而改善软件质量。以两个面向对象开源软件为例,发现其中的类文件修改次数大致服从幂率分布,并且修改次数多的类,其相邻版本间内容的修改量也大致服从幂率分布;此外,类的修改次数与代码行数和导入类的个数呈明显的正相关性,表明类的功能和结构倾向于变得更复杂。案例分析的发现有望为研究开源软件的演化规律、重构时间点的选择以及维护任务的分配等提供新的思路。     

Exploring the relationship of a file’s history and its fault-proneness: An empirical method and its application to open source programs

ContextThe knowledge about particular characteristics of software that are indicators for defects is very valuable for testers because it helps them to focus the testing effort and to allocate their limited resources appropriately.ObjectiveIn this paper, we explore the relationship between several historical characteristics of files and their defect count.MethodFor this purpose, we propose an empirical approach that uses statistical procedures and visual representations of the data in order to determine indicators for a file’s defect count. We apply this approach to nine open source Java projects across different versions.ResultsOnly 4 of 9 programs show moderate correlations between a file’s defects in previous and in current releases in more than half of the analysed releases. In contrast to our expectations, the oldest files represent the most fault-prone files. Additionally, late changes correlate with a file’s defect count only partly. The number of changes, the number of distinct authors performing changes to a file as well as the file’s age are good indicators for a file’s defect count in all projects.ConclusionOur results show that a software’s history is a good indicator for ist quality. We did not find one indicator that persists across all projects in an equal manner. Nevertheless, there are several indicators that show significant strong correlations in nearly all projects: DA (number of distinct authors) and FC (frequency of change). In practice, for each software, statistical analyses have to be performed in order to evaluate the best indicator(s) for a file’s defect count.     

USB移动存储器备份工具的设计与实现

为了自动地完成USB移动存储器上备份文件的更新,介绍了一种USB移动存储器备份工具的设计与实现,给出了USB接口监测的源代码和备份文件的更新算法。该方法克服了人工方式更新移动存储器上过时的副本,费时费力,可能会遗漏某些文件的更新之缺点,简化了文件备份过程,提高了文件备份的效率。     

利用Wireshark软件进行信令分析

Wireshark软件是开源软件中应用最广的一种信令分析软件,支持众多的信令协议。PCAP文件格式是一种通用的封包存储格式,这个格式的文件可以被Wireshark软件直接读取。在分析PCAP文件格式的基础上,通过构建数据文件,可以利用Wireshark软件对已有的信令数据进行信令分析。分析结果可以用于科学研究和工程实践,避免了手工分解信令数据时的低效率,提高了工作的时效性。     

The limited impact of individual developer data on software defect prediction

Previous research has provided evidence that a combination of static code metrics and software history metrics can be used to predict with surprising success which files in the next release of a large system will have the largest numbers of defects. In contrast, very little research exists to indicate whether information about individual developers can profitably be used to improve predictions. We investigate whether files in a large system that are modified by an individual developer consistently contain either more or fewer faults than the average of all files in the system. The goal of the investigation is to determine whether information about which particular developer modified a file is able to improve defect predictions. We also extend earlier research evaluating use of counts of the number of developers who modified a file as predictors of the file’s future faultiness. We analyze change reports filed for three large systems, each containing 18 releases, with a combined total of nearly 4 million LOC and over 11,000 files. A buggy file ratio is defined for programmers, measuring the proportion of faulty files in Release R out of all files modified by the programmer in Release R-1. We assess the consistency of the buggy file ratio across releases for individual programmers both visually and within the context of a fault prediction model. Buggy file ratios for individual programmers often varied widely across all the releases that they participated in. A prediction model that takes account of the history of faulty files that were changed by individual developers shows improvement over the standard negative binomial model of less than 0.13% according to one measure, and no improvement at all according to another measure. In contrast, augmenting a standard model with counts of cumulative developers changing files in prior releases produced up to a 2% improvement in the percentage of faults detected in the top 20% of predicted faulty files. The cumulative number of developers interacting with a file can be a useful variable for defect prediction. However, the study indicates that adding information to a model about which particular developer modified a file is not likely to improve defect predictions.     

The impact of tangled code changes on defect prediction models

When interacting with source control management system, developers often commit unrelated or loosely related code changes in a single transaction. When analyzing version histories, such tangled changes will make all changes to all modules appear related, possibly compromising the resulting analyses through noise and bias. In an investigation of five open-source Java projects, we found between 7 % and 20 % of all bug fixes to consist of multiple tangled changes. Using a multi-predictor approach to untangle changes, we show that on average at least 16.6 % of all source files are incorrectly associated with bug reports. These incorrect bug file associations seem to not significantly impact models classifying source files to have at least one bug or no bugs. But our experiments show that untangling tangled code changes can result in more accurate regression bug prediction models when compared to models trained and tested on tangled bug datasets—in our experiments, the statistically significant accuracy improvements lies between 5 % and 200 %. We recommend better change organization to limit the impact of tangled changes.     

方法级别的细粒度软件缺陷定位方法

当软件缺陷报告在跟踪系统中被指派给开发人员进行缺陷修复之后,缺陷修复人员就需要根据提交的缺陷报告来进行软件缺陷定位,并做出相应的代码变更,以修复该软件缺陷.在缺陷修复的整个过程中,软件缺陷定位占用了开发人员大量的时间.提出了一种方法级别的细粒度软件缺陷定位方法MethodLocator,以提高软件修复人员的工作效率.MethodLocator首先对缺陷报告和源代码方法体利用词向量（word2vec）和TF-IDF结合的方法进行向量表示;然后,根据源代码文件中方法体之间的相似度对方法体进行扩充;最后,通过对扩充后的方法体和缺陷报告计算其余弦距离并排序,来定位为修复软件缺陷所需做出变更的方法.在4个开源软件项目ArgoUML、Ant、Maven和Kylin上的实验结果表明,MethodLocator方法优于现有的缺陷定位方法,它能够有效地将软件缺陷定位到源代码的方法级别上.     

基于有序哈希链的文件数据同步方法

针对现有文件数据同步传输方法效率低、局部更新困难的问题,提出一种哈希链构建及文件数据同步方法。将C/S架构中服务器端文件或目录的变化作为一系列哈希节点,根据时间先后顺序,通过哈希函数迭代文件或目录的哈希值,形成能够记录文件库所有操作状态的有序哈希链。客户端只需根据哈希链节点执行相同文件操作并进行同步更新,而不需要对每个文件数据进行同步认证,确保文件库的完整性、不可抵赖性、可溯源性和防篡改性。采用有序哈希链的同步方法对不同终端进行文件数据差异监视和一致性检测,以快速获取文件变化并进行逻辑同步。实验结果表明,该方法在文件库未变动模式下的平均同步加速比为94.85%,在文件库变动的模式下,相较于“quick check”策略和常规策略的Rsync算法,平均同步加速比分别为6.5%和69.99%。有效地减少了同步过程中时间和资源的消耗。     

Identifying and understanding header file hotspots in C/C++ build processes

Software developers rely on a fast build system to incrementally compile their source code changes and produce modified deliverables for testing and deployment. Header files, which tend to trigger slow rebuild processes, are most problematic if they also change frequently during the development process, and hence, need to be rebuilt often. In this paper, we propose an approach that analyzes the build dependency graph (i.e., the data structure used to determine the minimal list of commands that must be executed when a source code file is modified), and the change history of a software system to pinpoint header file hotspots—header files that change frequently and trigger long rebuild processes. Through a case study on the GLib, PostgreSQL, Qt, and Ruby systems, we show that our approach identifies header file hotspots that, if improved, will provide greater improvement to the total future build cost of a system than just focusing on the files that trigger the slowest rebuild processes, change the most frequently, or are used the most throughout the codebase. Furthermore, regression models built using architectural and code properties of source files can explain 32–57 % of these hotspots, identifying subsystems that are particularly hotspot-prone and would benefit the most from architectural refinement.