引用：Proceedings of the 2011 26th IEEE/ACM International Conference on Automated Software Engineering, Pages 384-387.

摘要:

在开发软件系统时，开发人员花费大量的时间理解现有的源代码。为了成功地实现新的或改变现有的行为，开发人员需要回答这样的问题：“我可以使用哪些类型和方法来解决这个任务？”或“我的实施应该遵循特定的命名或结构约定？”。本文介绍了一个源代码推荐工具Mendel，它可以帮助开发人员回答这些问题。基于开发人员当前浏览的实体，该工具使用了一个遗传学启发的隐喻来分析与当前工作上下文相关的源代码实体，并为用户提供当前正在处理的源代码实体的一些推荐属性(命名约定、使用的类型、调用的消息等)。Mendel的初步验证似乎证实了我们方法的潜力。

一、引言

源代码规则，如命名约定和编程习惯[1]、代码模板和模式[2]，在提高程序的可理解性方面起着重要作用。开发人员在源代码中引入这些规则，以明确特定的实现和设计概念。例如，在实现表示各种用户界面操作的类层次结构时，在该层次结构中的所有类的名称后面加上“Action”并不少见。同样，与同一任务相关的方法通常不仅在名称上相关，而且还可能共享其他特性。例如，它们可能具有相同的结构模式、使用相同的类型或调用相同的方法。

需要扩展或维护一段源代码的开发人员通常会花费大量时间来理解这个源代码。要成功地进行更改，他们需要了解管理正在更改的源代码段的各种规则。由于这些规则通常没有明确记录，所以这可能是一项非常重要的任务。

本文提出了一种新的面向对象系统的代码辅助算法Mendel，并给出了该算法在Smalltalk[1]中的概念证明。由于输入的源代码实体目前正由开发人员处理，该算法提供了开发人员关于该实体可能缺少哪些特征的建议。该算法基于遗传启发的隐喻。它假定以某种方式重新关联的源代码实体(例如通过类层次结构)通常由相同的规则管理。如果某个特定的源代码实体缺少一个由其大多数亲属共享的特定特性，那么我们将该特性视为适合推荐的候选特性。通过这种方式，我们的算法不同于大多数现有的编码助理：它不是为了预测要发送的合适消息，也不是开发人员需要采取的下一步行动。相反，它只关注源代码实体可能缺少的特性，例如哪些方法可能会被某些类重写，哪些源代码模板可能适合当前浏览的方法，或者哪些方法或引用类型的调用可能会从方法中丢失。

二、相关工作

在前面的工作中[3]，我们挖掘了软件系统的源代码，将嵌入的架构知识作为其源代码实体共享的结构规则。与前面的工作不同，Mendel提取了依赖上下文的规则，这使得开发人员能够及时利用这些规则。

表1总结了一些挖掘源代码以给出建议的方法，因此这些方法与我们的工具Mendel有关。所有这些工具都具有促进第三方代码(如API和框架)使用的共同目标。在表中，我们为每种方法显示了用作输入的数据类型、所提供建议的粒度、用于识别建议的技术的简要描述，以及是否需要语料库来训练该技术。

三、技术介绍

Mendel的目标是通过分析源代码实体与附近源代码实体之间的差异来检测缺失的特征。在下面的内容中，我们概述了Mendel用于为当前正在开发的源代码实体提供开发人员建议的算法。这种方法依赖于这样一种假设，即通过分析与之相关的实体，可以对所选实体中缺少的内容提供建议[4]。这些相关的实体可以被看作是被浏览实体的“家族”，这启发我们使用一个基因隐喻。我们的方法包括5个步骤。下面，我们使用一个正在运行的示例详细解释每个步骤，该示例是第二节中给出的示例的简化版本。特别是，考虑图1中显示的类层次结构。这个层次结构由一些实现命令设计模式的类组成。

假设现在开发人员向这个层次结构中添加了一个名为RemoveAction的新类(用虚线表示)，并希望实现方法performAction。在下面的内容中，我们描述了算法的每个步骤，以计算实现performAction方法的一组建议。

a)检索分析实体的家族：作为算法的第一步，我们首先检索与当前正在处理的实体e相关的源代码实体集。识别这个家族成员的family(e)依赖于这样一个假设，即我们可以基于密切相关的源代码实体提供有用的重新推荐。Mendel允许对任何一个类和方法进行分析。

因为我们分析了面向对象的系统，所以我们认为类的家族是同一层次结构中的所有类。这组家族成员是通过获取所选类的直接超类并返回该超类的所有直接子类以及这些直接子类的子类(已分析的类除外)来计算的。从系谱上讲，一个类的家族是其兄弟姐妹和侄女。

此外，在确定一个类的家族时，我们区分了被分析的类是具体的还是抽象的。如果开发人员正在处理一个抽象类，那么通过分析相关抽象类得到的建议将比具体类的建议更相关。因此，我们将抽象类的家族限制为也是抽象类的类，而具体类的家族将只包含具体类。当分析的类不属于任何类层次结构(即它直接从对象继承)时，其家族为空。

方法的家族被定义为具有相同签名的所有方法的集合，在方法的实现类家族的类中。例如，计算类移除的方法性能家族的结果如图2所示。在此图中，所选实体的家族成员显示为黑色；所有其他实体都已灰显。在我们的计算中，除了抽象类AbstractClipboardAction及其子类之外，我们将ApplicationAction的所有直接子类(removeAction的直接超类)都视为removeAction家族。在这些类中的任何一个类中，方法performAction的所有实现都被认为是实体的家族成员。

b)找出被分析的源代码实体及其族成员的特征：算法的第二步是确定被分析的源代码实体及其家族成员的特征traits(e)。

对于一个类，我们考虑以下属性：

• 构成该类名称的关键字；
• 该类的所有祖先；
• 该类实现的所有方法的签名；
• 该类中提及的所有类型。

对于方法，我们计算以下属性：

• 方法的通用解析树，给出方法结构的抽象表示；
• 该方法使用的所有类型；
• 从方法内调用的所有方法的签名；
• 该方法被分类的协议;
• 该方法中发生的所有super调用。

c)找出家族中的优势性状：我们算法的第三步是识别具有e家族成员特征的优势性状dominantTraits(e)。优势性状是家族中大多数实体所表现出来的性状。乍一看，只有当所有的家庭成员都拥有这些特质时，才认为这些特质占主导地位是合乎逻辑的。然而，根据以往的经验我们发现，源代码中的规则往往没有得到统一的尊重：虽然一个家族中的大多数方法可能会尊重例如命名约定，但并不一定适用于所有方法。这种偏差通常是由这样一个事实引起的，即规则通常只被隐式地知道，并且不会在源代码中自动强制执行。如果大多数家庭表现出这种特征，我们就认为这种偏差是显性的。

由于家庭规模的变化，大多数阈值的选择方式允许偏差，即使是小家庭，但偏差的数量仍然与家庭规模成比例。经过反复试验验证后，我们发现，对于大多数被测家庭来说，一个家庭大小的对数4表现良好。换言之，对于一个给定的实体家族F，如果至少

个家族成员表现出这一特征，我们认为这是一个显性特征。

d)找出隐性性状：隐性性状用于检测被分析个体可能需要的性状，但只与家庭中较小的一个子集共享。也就是说，隐性亲属与被分析实体共享的特征超出了明显的家庭特征(即显性特征)。

我们将实体e的隐性特征recessiveTraits(e) 定义为不属于该实体的主要特征的家庭特征，但是至少存在于该家族的

个成员中。对于一个类，如果至少有三分之二的家庭成员共享一个特征，我们认为它是隐性的。由于一个方法的家庭成员的数量往往比一个类的家庭成员要小得多，我们认为一个方法特征一旦被该方法的两个家庭成员共享就隐性了。

e)为分析的源代码实体提出建议的特性：建议的特性是对分析的源代码实体的建议更改或添加。如前所述，我们区分了两种被提出的特征：被分析的实体应该展示的特征，以及实体可能想要展示的特征。这种区别是为了强调一个事实，即不同程度的确定性与这些建议有关。

我们将不存在于被分析实体e中但在家族中占主导地位的特征视为应由e实现的属性，并将这组特征定义为:

应用到我们的运行示例中，Mendel建议方法Performation可能应该执行一个super调用，调用方法triggerEvent，并在协议“operations”中进行分类。

相反，实体e的隐性亲属所共有的特征被认为是实体可能展示的特征。这组特征定义为：

在我们的运行示例中，我们的工具建议该方法可能需要引用ActionStack并调用updateDarant或add。

所有建议的集合定义为：

参考文献：

[1] K. Beck, Smalltalk Best Practice Patterns. Prentice Hall, 1997.

[2] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns, Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.

[3] A. Lozano, A. Kellens, K. Mens, and G. Arevalo, “Mining source code for structural regularities,” in Proceedings of WCRE 2010. Washington, DC, USA: IEEE Computer Society, 2010, pp. 22–31.

[4] J. Sillito, G. C. Murphy, and K. De Volder, “Questions programmers ask during software evolution tasks,” in Proceedings of SIGSOFT/FSE 2006. New York, NY, USA: ACM, 2006, pp. 23–34.

致谢

此文由南京大学软件学院2018级硕士巫浩然翻译转述。