软件工程读书笔记专业：软件工程硕士A班学生姓名：丁浩宸学号：13214020二〇一④年八月The impact of imperfect change rules on framework API evolution identification:an empirical study实证研究：框架API更新辨别的不完善变化规则的影响Wei Wu·Adrien Serveaux·Yann-Ga¨el Gu´eh´eneuc·Giuliano Antoniol摘要:软件框架在持续更新。
程序员保持他们的客户端代码更新很费时。
而且不是所有的框架都有着更新的文档说明。
因此许多处理方法被提出以减少没有更新文档的影响，这些方法依靠通过辨别软件两个发行版本的改变规则。
但是这些改变规则是不完善的，即不是100%正确的。
在我们的知识范围内，并没有展示这些非完善改变规则的可用性的实证研究。
因此我们设计并实施了一个实验来评价非完善规则的影响。
在实验中，实验人员必须在三个不同的发行版本中找到21处丢失了的方法的替换。
三个版本分别依靠1）全部正确的改变规则，2）不完善的改变规则，3）无改变规则。
统计分析结果表明实验人员在三个不同的发行版本中找到的替换的精度有着显著差异。
其中依赖全部正确的改变规则的结果精度是最高的，没有改变规则的精度是最低的，不完善的改变规则在两者中间。
不完善改变规则和没有改变规则的精度差的效应值是巨大的，不完善改变规则和完全正确改变规则的精度差的效应值是适度的。
研究结果表明框架API更新方法总结出的改变规则确实可以帮助开发者，即使这些规则并不是一直正确的。
非完善改变规则可以帮助开发者在文档不可用时更新他们的代码，或者作为部分文档的补充。
完全正确和不完善改变规律间适度的差异表明提高改变规则的精度依然可以帮助开发者。
关键词软件维护·可用性·框架API更新·变化规则1背景介绍软件框架和函数库库广泛应用于软件开发以降低成本。
实际上,开发人员发展框架不断修正错误,补丁安全漏洞,满足新的需求。
从理论上说,应用程序接口(API)的新版本的框架应该是与以前的版本向后兼容的,从而可以使使用之前框架的程序在新的框架下可以继续运作。
然而,由于API的变化，升级到新版本的框架需要大量的努力。
开发人员必须深入研究文档和以前版本框架的源代码来理解他们的差异，来使他们的程序与新版本兼容。
他们推迟升级的时间越长,就需要越多的时间,因为会有更多的变化。
为适应新版本的框架的API变化,开发人员通常执行四个任务:(1)找到丢失的API的可能替代,(2)如果他们无法找到替代品，就要找到丢失的API的变通,(3)实现替代或变通,(4)测试实现。
一个有效的方法来帮助找到合适的替代品是文档。
然而,许多框架并没有足够的文档,特别是当涉及到更改版本和规则之间适应程序从一个老版本发布到一个新的。
一般情况下,很少有公司明确文档API的变化或提供这些信息给公众。
因此,许多方法已经被开发来找到丢失API的替代。
有些方法要求框架开发人员做额外的工作。
然而,开发人员可能无法或不愿意手动建立改变规则或使用特定的工具。
因此,为了避免框架开发人员的额外工作,其他方法自动识别描述目标之间的匹配方法的变化规则。
这些方法所产生的变化规律并不都是正确的。
他们的精度在不同的框架分析中有差异。
然而,使用这些方法变化规则所产生的升级文档,开发人员不知道变化规律是否是正确的,直到他们修改使用客户端程序。
我们设计并进行实验评估框架的有效性API演化改变规则。
在这项实验中,实验人员找到替代的目标方法借助完全正确的改变规则,不完善的改变规则,没有改变规则。
然后,我们测量实验人员的精度和发现替代方法的时间。
实验结果统计分析表明,完全正确的，不完善的,没有改变规则发现的替代品的精度有着明显不同，平均值分别为82%,71%和57%。
没有改变方法和不完善的变化规则之间的效应差很大,完全正确的改变方法和不完善的变化规则之间的效应差是适中的。
找到替代方法用不同的平均时间为24，23，25分钟(1413、1338和1413秒)。
这些结果表明改变规则框架API生成的进化方法是有用的,即使一些变化的规则是不正确的。
然而,正如所料,更高精度的变化规律会为他们提供更多的帮助。
因此,不完善变化规律可以作为替代不可用文档或作为部分文档的补充。
框架的开发人员也可以使用它们作为起点建立升级文档。
结果中不完善和完全正确改变规则是适中的。
因此,提高精度变化规律仍将帮助开发人员提高工作效率。
2相关工作2.1框架API进展方法2.1.1输入现有捕捉数字变化的方法需要框架开发人员手动输入的变化规则或使用一个特定IDE自动记录变化。
Chow和Notkin(1996)提出了一个方法,要求框架开发者提供新版本的变化规律。
CatchUP!(Henkel and Diwan2005)和JBuilder((Kemper and Overbeck2005)记录在一个版本的重构操作然后在另一个版本上重复它们。
MolhadoRef(Dig et al.2007年)也雇佣了一个record-and-replay技术处理API 级合并程序版本的变化。
这些方法因为框架的开发人员的参与可以提供准确的变化规律。
2.1.2特性框架API演化是使用从输入中提取具体的信息特征,如call-dependency关系或文本相似度。
捕捉API级别变换的特征(Chow and Notkin1996;HenkelandDiwan2005;Kemper and Overbeck2005;Dig et al.2007)是不同的手动添加或自动捕获改变规则。
这些方法对每个目标方法和它的替代品有一个特定的模型。
Godfrey and Zou’s(2005)和S.Kimetal(2005)使用文本相似密度,软件度量,并调用依赖关系描述方法和他们的目标更换。
Xing和Stroulia(2007)使用词汇和结构相似的逻辑设计模型提取的两个版本之间的差异,包括文本相似度,继承关系,使用依赖关系和关联关系。
Kim et al.’s(2007)计算目标方法和它的替代测量之间的LCS来区别他们。
SemDiff(Dagenais and Robillard2011),Sch¨afer et al.(2008),和AURA(Wu et al.2010)使用call-dependency关系来衡量信心值和各种预处理文本相似。
HiMa(Meng et al.2012)使用call-dependency关系和连续犯错的自然语言分析过虑评论。
2.1.3匹配技术捕捉API级别的数字变化方法只需要简单匹配与目标方法收集到的变化规律的匹配技术,但需要的开发者的参与可能不可用。
Godfrey、Zou(2005)和Kimetal(2005)的匹配技术是基于起源分析技术。
前者是半自动的而后者是自动的。
Diff-CatchUp(Xing和Stroulia2007)定义三组启发类、方法和字段，分别排列可能的替代方法。
SemDiff(Dagenais和Robillard 2011)和Sch¨afer(2008)第一次使用信心值来预选可能的替代方法,然后使用文本相似度给他们排序。
他们之间的区别是,前者着重于框架如何适应他们自己的改变而后者发现使用客户机代码的更改。
Kim等(2007)的分类器利用系统的重命名旧模式使用文本相似度来匹配老api和新api。
AURA(Wu et al.2010)使用多迭代器算法相结合call-dependency和文本相似性分析。
HiMa’s(Meng et al.2012)使用修改评论生成最初改变规则,然后使用call-dependency分析改进它们。
2.2对程序理解的实证研究另一个与这个工作相关的领域是对程序理解的实证研究。
Lawrie等进行了实证研究来调查的标识符对程序理解(Lawrie et al.2007)的影响。
Sharif et al.(2010)和Sharafi et al.(2012)使用追踪系统比较“骆峰式”和下划线标识符风格。
前者使开发人员识别标识符，注重准确性和速度而后者从性别的角度理解研究标识符。
一些研究集中在对图的理解,例如UML。
Cepeda和Gu´eh´eneuc 评估的三个基于设计模式理解追踪系统的视觉展示的影响。
Yusuf等人做了一个实验来研究影响项目理解的UML类图的特性(Yusuf et al.2007)。
Soh等人进行了一项实验来评专业状态和专业知识对UML类图理解的角色。
还有其他对程序理解的实证研究。
Abbes等人进行了一项实验来评估的影响两个反模式(Blob和Spaghett代码)对程序理解(Abbes et al。
2011)。
Ali等人使用追踪系统开发人员的首选实体排名,如类名、方法名(Ali et al.2012)。
3文章动机据我们所知,,尽管实证研究在软件工程的研究中很普及，但是没有实证研究显示进化框架API方法生成的变化规律的可用性,即如果不完善变化规则可以帮助开发人员识别更准确或更快的识别替代方法。
因此,我们设计并进行了这项研究。
4实验定义4.1实验问题我们期望实验结果能回答这两个研究问题:-RQ1:分别通过完全正确,不完善,没有改变规则发现的目标方法的替代方法的精度是否存在差异?-RQ2:分别通过完全正确,不完善,没有改变规则发现的目标方法的替代方法的时间是否存在差异?在这个实验中,虽然我们没有给出执行任务的任何时间约束,我们不能指望所有实验人员都能够或可以结束。
因此,我们采取计算答案的时间和精度两种方案。
4.2实验对象我们实验的对象是用JAVA编写的两个版本的三个框架的源代码.我们选择三种大小适中的方案作为我们的实验对象。
这三个方案是：JEDIT v4.1-v4.2，JFreeChart v0.9.11-v0.9.12和JHotDraw v5.2-v5.3。
JEDIT是一个文本编辑器。
在2000年和2013年间它有37个发行版本。
它的V4.1和V4.2之间的API和实现有着巨大的变化。
JFreeChart是一个图表库。
有2000年和2013年间有着54个发行版本，其v0.9.11和v0.9.12之间的API也改变了很多，并且有很多在v0.9.12用着非常相似的名称API。
在这两个方案的巨大变化对于开发人员和方法来识别API的变化是巨大的挑战。
JHotDraw是一个GUI framework，由Gamma等人开发的。
与前两个节目相比不活跃，2001年和2011年之间只有12个版本发型，V5.2和V5.3之间，他们有几个API变化。
