Mining Version Histories to Guide Software Cha（挖掘版本记录以指导软件更改论文注解）

1. 解决问题： 指导程序员：修改这些函数时，别人也修改了这些函数。

应用从大量数据集中进行自动隐藏预测信息抽取——即数据挖掘实现，

2. 给定一系列现存的修改，挖掘关联规则能够：

①能够建议和预测可能的更进一步的修改

②通过程序分析检测无法检测的耦合。

③能够避免因为不完整的修改造成的错误。

3. ROSE原型：能够在一个初始修改后，正确的预测更进一步将要修改的位置。是现存软件实现修改的可获得的最佳预测方案。

4. ROSE需要的是：版本历史库和一个简单的能够将文件分解为细粒度类，函数或节之类的实体 的解析器。

5. 以前的工作：利用历史数据去理解项目和它们的演化，去检测在几个文件或类之间的进化的耦合关系。或者支持源文件的指向。

6. 当前的工作：

①检测在细粒度的项目实体（比如函数或变量而不是类）中的耦合度，因而能够增加局部性和集成程序分析。

②在不同种类的修改中调查多维度的关联规则。

③全面地评估预测相关或预测相关或者未注意到的修改（thoroughly evaluates the ability to predict related or missing changes）。

④ 研究预测能力在项目生命周期中如何变化，以及如何受到活动、发布和版本历史长度的影响。

7. cvs：concurrent versions system 协作版本系统。

开发源代码的配置管理工具，其源代码和安装文件都可以免费下载。CVS是源于unix的版本控制工具，对于CVS的安装和使用最好对unix的系统有所了解能更容易学习。

版本控制的作用是追踪文件的变化,简单说,就是当你出错了,可以很容易地回到没出错时的状态。大型的、频繁修改的、多人编写的软件项目,需要一个版本控制系统(简称VCS,行话叫做"文件数据库"),追踪文件的变化,避免出现混乱。 

特性	CVS	SVN	GIT
并发修改	支持	支持	支持
并发提交	不支持	支持	支持
历史轨迹	不支持更名	支持更名	支持更名
分布式	不支持	不支持	支持

8. evolutionary coupling（演化的耦合）

无论数据库schema何时改变，sqlquery方法都会更改。——这种依赖就叫做演化式耦合，以表明它是由演化而来的，与由项目分析所决定的逻辑式耦合对立。

为了增加研究粒度，可以从两个文件之间修改的关系，增进到变量和函数之间的修改关系，以此来获得演化的耦合度。

9. ROSE工具在两个场景中为程序员推荐相应地修改是有用的：

　①改进的导航：用户修改了一些代码，ROSE可以自动的推荐给用户接下来可能可以进行的修改。

　②预防错误场景：ROSE在用户提交相应的修改时会检查是否存在相应的高频度的修改，但用户还没有实现，如果没有实现则会弹出相应的提示。

10. ROSE概览：　

　ROSE包括的两部分：

① 预处理采用完整的版本存档作为输入。

归档被镜像到数据库中(数据收集)，更改被映射到实体和事务中(数据准备)，最后，大型事务引起的噪音被消除(数据清理)。预处理确保快速访问所有必要的信息。

②挖掘从预处理数据创建规则。

规则描述了软件实体之间的含义，例如，如果fKeys[]被更改，那么initDefaults()也会被更改。可以对所有规则进行挖掘，但通常，ROSE只对具有特定左侧的规则进行挖掘。因此，挖掘被加速，规则总是最新的。

11. 用三元组表示被改变的实体：

（c，i，p）

c指句法范畴，i指标识符，p指父实体（⊥指根实体）

（method; initDefaults（）;（class; Comp; （file; Comp:java; . . .）））

例如这个：表示 Comp类中的initDefaults（）方法，该类在Comp.java文件中。

可以使用不同的粒度来表示句法范畴。

12. 可以使用下列的谓词来研究不同种类的更改，每种都代表了数据挖掘中的不同的维度。

①实体被修改：alert(e)//表示修改实体

②一个实体被加入到另一个实体中：add_to(e)

③一个实体被从另一个实体中删除：del_from(e)

13. 一个事务是一组被开发者提交到版本数据库中的更改。

一个事务中的元素被称为items（元件），每个都代表着一次修改，是之后数据挖掘的基础。

14. CSV作为常用的代码配置工具，尽管受人欢迎，但是也有一些弱点，解决这些弱点需要特殊的数据清洗：

①推断事务。

大多数现代版本控制系统都有产品版本控制的概念，也就是说，人们可以在事务改变整个产品时访问它们。但是，CVS只提供文件版本控制。要从CVS归档中恢复每个产品的事务，我们必须将每个文件的单个更改分组到单个事务中。ROSE遵循经典的滑动窗口方法[9]:同一作者的两个后续更改以及相同的日志消息，如果它们最多相隔200秒（窗口选择200秒），那么它们就是一个事务的一部分。滑动时间窗口方法对于捕获长事务非常重要，否则这些事务可能被分割为[36]。

②分支和合并。

产品的进化有时会分支成不同的进化链，这些链随后可能会再次合并。在CVS归档中，分支的合并不会显式地反映出来;相反，合并成为一个大型事务，其中包括在分支中所做的所有更改。为了检测事务中的耦合，必须避免大型合并事务。ROSE忽略所有影响30多个实体的更改。

③得到实体。

 

 

CVS对它存储的文件没有语法知识;它只管理每个更改的文件和行号。因此ROSE解析文件以获得语法实体，如类、函数、源代码中的字段或文档中的节。接下来，ROSE将这些语法实体与行范围关联起来。如图5所示，ROSE可以将任何更改(通过文件和行给出)与受影响的组件关联起来。

15. 数据挖掘的规则表示方法：

意味着无论何时用户修改域fkeys[]时，都应该修改initDefault方法和plug.properties文件

对于关联规则r，是两个不相交的集合x1和x2组成的对(x1,x2)，x1称为antecedent（前项），x2成为consequent（后项）

规则有一个基于一系列事务中的证据数的概率解释，证据数由两种方法来评估：

①support count 支持计数。

支持计数确定规则派生的事务数。假设字段fKeys[]在11个事务中被更改。在这11个事务中，10个还包括initDefaults()方法和文件 plugin .properties的类型alter的变化。因此，上述规则的支持计数为10

②confidence置信度：

置信度决定了结果的强度，或给定前件的所有备选结果的相对数量。在上面的例子中，更改initDefaults()和plug的结果。在涉及fKeys[]的11个事务中，有10个应用了属性。因此，上面规则的置信度是10=11 0:909。

16. 基于以上规则的评价，我们可以定义：

① 一个集合x在一组事务D中的频度为freqD=|{t|t∈D，x⊆t}|

②一个规则x1⇨x2在一组事务中的支持度为：countD(x1⇨x2)=freqD(x1∪x2)

③在一组事务中x1⇨x2的置信度为：confD(x1⇨x2)=countD(x1⇨x2) / freq(x1)

④ 规则r，有s=countD（r）和c=confD（r），则记为： r[s;c]D ；如果内容已知或无关紧要，则省略事务D

17. 应用规则：一旦用户提交了所有的changes，则最终的版本就作为一次事务。

代表未提交的所有现今的items的集合，称为Σ

18. ROSE通过申请匹配的规则来给出用户进一步的修改建议。如果修改的集合匹配一个规则的前项，则称为规则匹配一组元件items（a rule matches a set of items）

对一个（situation）Σ的建议和一组规则，被定义为所有匹配规则的集合（the union of the consequents of all matching rules:）

而对于给定的situationΣ和一个规则r，ROSE会基于r规则的给出建议的结果：

19. 应用规则：

应用上述规则可以得到所有规则结果的并集，因为它们有相同的前项。ROSE将根据它们的置信度对项目进行排序。

考虑到新situation，ROSE动态地计算新的规则，如第5.3节所述。

规则的数量以及推荐的数量取决于用户选择的支持数和置信阈值。

20. 多维规则：

唯一不同的是用于挖掘的数据类型:

对于一维挖掘，我们使用alter items;

对于多维挖掘，我们使用alter、add_to和del_from项。

多维规则的好处是在新加一个变量（比如foo），它会触发add_to类型的修改，而一维规则不会匹配任何规则，因为foo是新增的，没有历史版本。

21. 计算规则：

Apriori Algorithm是单行的计算关联规则的算法。它以最小的支持度和最小的置信度，计算所有高于阈值的关联规则的集合。

Apriori Algorithm →计算所有的规则，然后为给定的situation搜集对应的规则。

ROSE为计算规则提出的两条优化：

①先例的约束。

在我们的具体案例中，前项等于situation;因此，我们只会根据情况动态地挖掘规则。

使用这样的约束前提挖掘[31]只需要几秒钟。此方法的另一个优点是它是增量式的，因为它允许添加新事务，而无需重新计算所有规则。

②单一的结果。

为了进一步加快挖掘过程，我们修改了该方法，使其只计算规则及其结果中的单个项。所以，对于一个situationΣ，规则的形式为：Σ→{e}；而对于ROSE来说，这样的规则是足够的，因为ROSE无论如何都会计算结果的并集。

 

ROSE需要一个数据库查询来查找包含当前situation(受约束的前项)的所有事务，另一个数据库查询来计算其他项的置信值(单个结果)。

对于像GCC这样的大型版本历史记录，ROSE查询的平均运行时间大约是0.5秒，（在使用Intel 2.0 GHz Pentium 4和1gb RAM的PC上进行测量），且解析时间不包括在内(解析只需几分之一秒，因为已更改的文件已经驻留在内存中)。

22. 粒度：

ROSE在两个层次上实行挖矿：

①细粒度挖掘。

对于C、c++、JAVA和PYTHON源代码以及TEX文档，我们对alter项使用细粒度实体，比如字段、函数和子部分。对于add_to和del_from项，我们在任何情况下都使用文件实体。所有其他文件(如图像或文本文件)都用文件实体的alter项表示。

②粗粒度挖矿：

不管文件类型如何，我们只对文件实体使用alter项。此外，当文件被添加或删除时，我们使用add_to和del_from项来捕获目录实体。

粗粒度规则有较高的支持度，且通常返回更多的结果，但它们都较不准确，因此只有有限的用处。

 

23. ROSE可以用于python、c、c++语言中。并且可以检测用不同语言编写的程序部件之间的耦合

24. 评估：

分场景进行评估，场景为：

①浏览源代码时的导航。

②错误的预防。

③关闭。在用户提交代码事，ROSE错误的建议出现的频率。。

不直接影响使用场景的其他问题的评估：

①粒度。granularity

默认情况下，ROSE建议对函数和其他细粒度实体进行更改。如果ROSE只建议更改文件，结果会怎样?

②维护。maintenance

添加和删除是很难预测的。如果将ROSE应用于没有向程序添加新功能的维护任务，它的性能如何?作为一种启发，我们将仅更改现有实体的事务归类为维护。

③多个维度。

ROSE尝试使用特殊的add to和del from项来预测添加和删除。这些额外项目的实际效益是什么?

④历史。

ROSE至少需要多少版本历史才能生成有用的建议?有用性会随着时间的推移而降低吗?

此外，建议的质量是否随着开发阶段和版本而变化?

⑤最近的变化。

随着系统的发展，较早的更改在确定相关更改时可能变得越来越不相关。关注最近的变化会提高建议的质量吗

25. 评估方法：

使用8个常见的开源代码，一个月作为评估周期，检查每个事务，是否它的items可以被从最近的历史中得到预测。步骤如下：

①为一个事务创造一组queries，一个query=(Q,E),包括一个situation Q∈ T，和一个期望的输出E=T-Q

在导航场景中，每个事务T都有|T|查询，每个事务T的情况都由单个条目e∈T组成。

在预防场景中，每个事务T都有|T|查询，每个事务T的情况都由一个删除条目组成。

在闭包场景中，每个事务有一个查询，其情况由整个事务T组成。

②对于每个query q=(Q,E)，使用在time(T)时间内完成的所有Ti作为训练集，从这些事务中遵循Q进行挖矿得到一个规则集。这意味着规则R仅包含约束规则Q→{x}

③假设用户不会使用所有的建议，因此，我们只需要考虑基于置信度排序的前十个单一的规则（single consequent rules）R10⊂R。在评估中，使用R10来得到query的结果，即Aq=applyR10(Q)。所以，Aq的大小总是小于等于10

④q=(Q,E)的结果Aq包括两个部分：

Aq∩E是匹配的期望的输出，被认为是正确的；

Aq-E是不期望的建议，即被用户认为是错误的。

26. 两种信息检测的评估方法：

①precision Pq（精确度），描述返回的结果中被认为是正确的那部分的概率；（你认为的正样本，有多少猜对了）

②recall Rq（召回率），表示在对原来的样本进行测试时，被返回的结果中是正确的那部分规则所占比重。（正样本有多少被找出来了）

精确率是针对我们预测结果而言的，它表示的是预测为正的样本中有多少是真正的正样本。那么预测为正就有两种可能了，一种就是把正类预测为正类(TP)，另一种就是把负类预测为正类(FP)，也就是

 

而召回率是针对我们原来的样本而言的，它表示的是样本中的正例有多少被预测正确了。那也有两种可能，一种是把原来的正类预测成正类(TP)，另一种就是把原来的正类预测为负类(FN)。

其实就是分母不同，一个分母是预测为正的样本数，另一个是原来样本中所有的正样本数。

例子：

假设我们手上有60个正样本，40个负样本，我们要找出所有的正样本，系统查找出50个，其中只有40个是真正的正样本，计算上述各指标。

 

• TP: 将正类预测为正类数 40
• FN: 将正类预测为负类数 20
• FP: 将负类预测为正类数 10
• TN: 将负类预测为负类数 30

 

准确率(accuracy) = 预测对的/所有 = (TP+TN)/(TP+FN+FP+TN) = 70%

精确率(precision) = TP/(TP+FP) = 80%

召回率(recall) = TP/(TP+FN) = 2/3

链接：https://www.zhihu.com/question/19645541/answer/91694636

初始：为了避免没有元组被返回（Aq为空），将Pq=1；为了避免没有元组被期望，则将召回率设为1

目标：得到高精准率和高召回率，使其都接近于1。

高精准率=1：意味着推荐的规则均被接受。（认为的正样本都是正确的）

高召回率=1：意味着推荐所有的规则。（正样本都被找出来了）

但是如果期望的输出超过10个，那么召回率永远不可能为1，因为尽管所有的规则是正确的，但我们只考虑置信率的前十个。

27. feedback ：反馈：

对每次query，我们都会得到一个准确率和召回率对（Pq，Rq），为了全面地评价所有评估的queries Z，可以使用macroevaluation（宏计算）平均技术将所有得到的对总结到一个对中，宏观评估只简单的使用所有的（Pq，Rq）对，计算它们的平均值，作为所有queries Z的准确率和召回率。

由于宏计算决定了查询的预测强度，因此有时将其称为面向用户的方法。

28. 如果ROSE没有返回任何的推荐，即Ａｑ＝Ø称其准确率为１.　这样会对平均的准确率造成影响，因此在计算时，如果没有特殊的说明，则只考虑返回结果不为空的情况。

所以，我们只评估有至少一个返回结果的queries，因此将这个反馈称为Fb=|Z*| / |Z|

29. likelihood 可能性：

目的：检查对程序员的实际的可用性。

likelihood：意味着一个期望的修改位置是否出现在ROSE的前三个推荐中（假设一个程序员可以直接看出前三个中是否有应该修改的地方），

Lk表示在ROSE的前k个推荐中，至少有一个是正确的。

30. 评估预防错误：

推荐的修改与已修改合起来才能够作为一个完整的事务。

31. 判断闭包的能力：

输入一个完整的事务，观察ROSE是否会返回E=空。（E=空时，召回率为1）

32. 判断粒度：

如果使用粗粒度评估，则每条定位的建议会变得较无用，且推荐数量会更多。

33. 判断维护性：

我们研究了ROSE在仅包含alter项的事务中是否表现得更好。我们将这种事务称为维护事务。相反，非维护事务至少包含一个add to或del from项。

35. 结果：最近的更改：

因为最近的更改比以前的更改更可能与当前的系统相关，因此可以使用重命名的方法，如果一个方法m被重命名为m‘，则m的旧版本将不会与新的或者未来的更改相关。设计实验证明了这种方法是否有助于提高准确率和召回率。

两种方法：

① 最后的180天。我们仅根据过去180天计算实体的支持数，并以此作为排名标准。

因此，一个项目在清单中的位置取决于它在过去半年内根据情况变化的频率。

②线性加权。作为一种替代方法，我们使用一个线性递增加权函数，将0赋给最老的事务，将1赋给最近的事务。作为排名标准，我们取所有支持建议的交易的权重之和。

如果新的更改与原来的版本的差别不大，那么这种方法不会有很大影响。而对于经常重构的项目，为最近的更改设置高的权重是可行的。

37. 效度威胁：

①无序性：由于因为事务中的所有更改同时提交到版本存档，事务不会记录所涉及的单个更改的顺序，因此，我们的评估不能将订单考虑到所做的更改，并对所有更改一视同仁。但在实践中，我们期望特定的变更顺序比其他的更频繁，这可能会影响导航和预防的结果。

②我们没有试图评估ROSE从过去的事务中学到的事务质量。因此，学习和评估的规则可能反映出好的实践和坏的实践。

③我们已经检查了ROSE的预测能力，并假设建议一个更改，缩小到单个文件甚至单个item，将是有用的。然而，很有可能在编译或测试期间发现缺失的相关更改(在这种情况下，ROSE的建议不会造成损害)，或者被训练有素的程序员知道(他们可能发现ROSE的建议是正确的，但是会分散注意力)。最终，对程序员的有用性只能通过对真实用户的研究来确定，我们打算在将来完成这些研究。

38. 相关的工作：

①A.T. Ying, G.C. Murphy, R. Ng, and M.C. Chu-Carroll, “Predicting Source Code Changes by Mining Change History,” IEEE

Trans. Software Eng., vol. 30, no. 9, pp. 574-586, Sept. 2004

在CVS版本系统中使用关联规则挖掘来挖掘CVS版本数据库。只能在粗粒度下推荐修改的文件。

②Z. Xing and E. Stroulia, “Data-Mining in Support of Detecting

Class Co-Evolution,” Proc. 16th Int’l Conf. Software Eng. and

Knowledge Eng. (SEKE ’04), June 2004

在UML图的版本上使用关联规则挖掘来检测类的共同演化。他们的方法产生了有希望的初步结果，但还没有大规模的评估。

③A.E. Hassan and R.C. Holt, “Predicting Change Propagation in

Software Systems,” Proc. Int’l Conf. Software Maintenance (ICSM

2004), Sept. 2004

Hassan和Holt研究了几种用于预测细粒度实体[16]的变化传播的启发式方法。启发式方法基于历史的cochange和静态依赖。哈桑和霍尔特没有考虑关联规则。

④日志消息的词频分析和关键字分类可以识别变化的目的，并将其与变化的大小和变化之间的时间联系起来

39. 未来的工作：

① 分类法。

方法中的每一次更改都意味着封闭类中的一次更改，这也意味着封闭文件或包中的更改。我们希望利用这些分类法来识别这样的模式，比如这个更改意味着在这个包中(而不是在这个方法中)进行的更改可能在位置上不够精确，但是提供了更高的可信度。

②序列规则。

现在，我们只关联同一事务中发生的更改。在将来，我们还希望检测跨多个事务的规则:系统总是在发布之前进行测试(通过适当的更改表示)。

③进一步的数据源。

归档的更改不仅包含作者、日期和位置。可以扫描日志消息(包括要提交的更改之一)，以确定更可能与更改相关的关注点(例如，修复还是新特性)。此外，还可以将更改链接到bug数据库，以识别导致修复的更改[29]。由于这些更改稍后会在修复中撤消，所以ROSE不应该将它们用于学习。

④ 重构。

目前，ROSE不能识别函数或文件的重命名。我们计划将这种重构的检测[13]集成到ROSE中，从而为已重命名的实体生成额外的规则。

⑤ 程序分析。

另一个未使用的数据源是程序分析;尽管我们的方法可以检测出那些甚至不是ZIMMERMANN等人的项目之间的耦合:使用挖掘版本历史来指导软件变更443个程序，但是了解程序的语义可以帮助将相关的变更分为可能的和不可能的。此外，可以通过程序分析发现的耦合[33]不需要在ROSE的建议中重复。

⑥ 规则表示。

ROSE检测到的规则描述了实际的软件过程，它可能是也可能不是预期的过程。因此，这些规则可以而且应该是明确的。在之前的工作[35]中，我们使用可视化挖掘来检测逻辑耦合项的规则性和不规则性。这种可视化可以进一步向程序员和经理解释这些建议。