英语原文共 22 页，剩余内容已隐藏，支付完成后下载完整资料

基于LSTM的非API方法参数推荐

摘要

自动代码补全是高级IDE提供的最有用的功能之一。参数推荐，作为一种特殊的代码补全，也被广泛使用。虽然现有方法专注于流行API的参数推荐，但大量非API调用也要求准确的参数推荐。为此，我们提出了一种基于LSTM的方法，在输入方法调用时立即推荐非API参数。利用从大量开源应用程序收集的数据，我们训练LSTM神经网络以推荐基于被调用方法的标识符、相应的形式参数和语法正确的候选参数列表。为了将这些标识符输入LSTM神经网络，我们通过段落向量（一种基于无监督神经网络的学习算法）将它们转换为固定长度的向量。通过在示例应用程序上训练得到的LSTM神经网络，对于给定的调用站点，我们可以预测哪个候选参数更有可能是正确的。我们通过对85个开源C应用程序的十倍验证来评估所提出的方法。结果表明，所提出的方法在推荐非API参数方面优于最先进的方法。它将精度从71.46%显着提高到83.37%。

关键词 参数推荐；LSTM；深度学习；非API

第1章 绪论

代码补全功能是IDE预测开发人员正在输入的语句的剩余部分（或部分剩余部分）的功能。如果它经常正确地预测用户在只输入几个字符后打算输入的语句，它可能会加快编码速度[1]。代码补全被发现是开发人员使用的EclipseIDE中的十大命令之一，这表明代码补全被广泛使用。

方法调用参数的推荐是一种特殊的代码补全。当开发人员正在输入一个方法调用时，例如updateTitle()，IDE将检查可能的参数并推荐最可能的参数或提供排名候选的列表。大多数主流IDE都是根据候选参数的类型和对应的形式参数的类型来推荐实参的，即候选参数应该与对应的形式参数类型兼容。但是，通常存在着大量类型兼容的候选对象。在这种情况下，基于类型的参数推荐会导致候选列表很长，并且需要很长时间来选择。

为了提高参数推荐的性能，已经提出了一些方法。张等人建议精确推荐。它采用k近邻算法根据调用的API方法的最近k次使用来推荐API使用的参数。阿萨杜扎曼等人试图通过利用API参数推荐的本地性来改进Precise，即调用站点之前的源代码行。雷切夫等人提出了一种基于统计语言模型的方法，称为SLANG，根据API方法调用的序列及其相关参数推荐API方法和API参数。刘等人提出了一种基于相似性的方法来从候选参数中选择正确的参数。海伦道恩等人基于缓存的n-gram提出了SLP-Core来建模和完成源代码，它也可用于推荐参数。尽管这些方法在为流行的API推荐参数方面效果很好，但它们可能不容易扩展到为非API方法（在调用它们的项目中定义的方法）推荐参数。例如，Precise取决于调用方法的k次用法。因此，它可能不适用于非API方法，因为在推荐时可能没有可用的调用方法。

通过分析85个开源C应用程序（详见第5节），我们观察到47%（=972660/2097709）的方法调用是非API调用。如此大量的非API调用表明非常需要可以为非API方法调用推荐参数的方法。为此，在本研究中，我们提出了一种新方法来为非API方法推荐参数，这些方法没有丰富的调用历史，甚至在推荐点没有可用的调用。我们观察到（如第2节所述），在大多数情况下，开发人员可以根据被调用方法的正式签名和候选者列表，从语法正确的候选者列表中选择正确的参数，而无需查看被调用者的调用历史。因此，利用来自开源应用程序的大量真实数据，深度学习技术也可以学习通用定量规则，从候选参数列表中选择正确的参数，而无需查看调用方法的调用历史。为此，我们提出了一种基于LSTM的方法来为非API方法推荐参数。对于应用程序中的每个参数，所提出的方法生成一个元组，其中包含实际参数、调用的方法、相应的形式参数和语法正确的替代参数列表。这些替代方案与实际参数一起构成了调用站点的解决方案空间。通过静态源代码分析生成的解空间将生成正确参数的问题转化为从多个候选中选择正确参数的问题。因此，即使正确的参数从未出现在训练数据中（这对于非API调用很常见），我们的方法也可能成功。

为了评估所提出的方法，我们对从85个开源C应用程序中提取的972660个非API参数（及其上下文）进行了十倍验证。评估结果表明，所提出的方法在推荐非API参数方面优于最先进的方法。精度从71.46%提高到83.37%。

综上所述，本研究有以下贡献：

• 一种基于LSTM的方法，用于为非API方法调用推荐参数。据我们所知，我们是第一个将LSTM技术应用于参数推荐的人。我们也是第一个训练神经网络从一小部分语法正确的候选中选择正确参数的人。
• 在开源应用程序上对所提出的方法进行了十倍验证，其结果表明所提出的方法优于最先进的方法。

本文的其余部分的结构如下。第2节介绍了关于开发人员如何从候选列表中选择参数的案例研究。第3节介绍了问题陈述。第4节提出了推荐论点的方法。第5节介绍了对开源应用程序所提议方法的评估。第6节讨论相关问题。第7节简要回顾了相关研究。第8节提供了结论和未来的工作。

第2章 论据选择的案例研究

2.1 问题

为了调查开发人员是否可以在不查看调用历史的情况下从候选列表中选择正确的参数，我们进行了一个案例研究，该研究着重关注以下问题。

Q1：在没有调用历史的情况下，开发者是否可以在只给出当前调用上下文的情况下选择正确的参数？如果是，可以选择多少百分比的正确参数？

Q2：如果开发者经常可以根据当前的调用上下文选择正确的参数，那么选择的数量规则是什么？

问题Q1涉及当只有当前调用上下文可用时，开发人员多久可以选择正确的参数。回答这个问题可能会揭示我们是否可以根据上下文信息推荐参数。如果开发者在大多数情况下能够选择正确的论点，则可能揭示上下文中嵌入了潜在的语义信息，我们可以从中学习，这是本研究的假设。

问题Q2涉及开发人员如何选择正确的参数。如果开发者能够抽象出参数选择的定量规则，我们就可以基于这些规则进行进一步的研究。如果开发人员无法弄清楚任何定量规则，我们可能有理由求助于深度学习技术来学习给定上下文和正确参数之间的潜在关系，因为深度学习技术专门用于从大数据中映射关系。

2.2 学科申请

我们从GitHub中搜索至少有5个版本并且可以导入Eclipse的知名且流行的开源C应用程序。从这些应用程序中，我们选择获得最多收藏的前85个应用程序。此类应用程序也将用于第5节中的评估。对于来自生成的85个应用程序的非API方法调用中的每个实际参数，我们提取参数名称、方法名称、形式参数名称和前五个词法相似且语法正确的候选参数。我们总共得到972660个非API参数。从这些非API参数中，我们随机选择30个满足以下条件的参数作为我们案例研究的主题参数。

• C1：对于每个参数，至少有四个语法正确的替代候选者可用。
• C2：被调用方法的名称由不少于两个词组成。
• C3：对应的参数名称由不少于四个字符组成。
• C4：论证的语义与其对应上下文的语义之间的潜在关系得到了作者的证实。

第一个条件确保我们不会选择只有极少数替代方案（甚至根本没有替代方案）的极其简单的情况。第二个和第三个条件确保正确命名软件实体的标识符。最后一个条件确保下划线语义对于有经验的开发人员来说是清晰的。在972660个参数中，符合条件的参数有747437个。每个非api参数的语法正确备选项的平均值为5.6。

2.3 受访者

我们邀请25名受访者参加此案例研究。所有受访者都是具有至少一年实际项目软件开发经验的软件开发人员。应该注意的是，参与案例研究的所有开发人员都无法访问当前项目应用的程序的源代码。

我们选择此类开发者作为受访者，原因如下。首先，很难从行业中邀请这么多有经验的开发人员参加这样的案例研究。其次，我们约束所有受访者都至少有一年的软件开发经验，因为我们假设只有有经验的开发人员才能挖掘实际参数和方法调用上下文之间的语义。

图1 手动参数选择的结果

2.4 设置

我们按照以下流程设置实验。首先，我们设计了一份问卷，其中包括30个参数选择问题。每个问题包括两部分：第一部分是问题部分，给出方法名称、形式参数名称，并要求开发人员从以下选项中选择正确的参数。第二部分是答案选项，其中包括按字母顺序排列的4-5个语法正确的候选者（包括当前参数）标记为选项A-E。其次，我们通过在线问卷平台问卷星发布问卷，将问卷的网址发送给开发者，让每个开发者从候选人的字母顺序列表中选择正确的参数。第三，一旦开发人员完成了参数选择，我们要求他们写出他们选择参数的定量规则或他们如何进行选择。如果他们没有这样的规则，我们建议他们说“不知道”。之后，他们提交答复。最后，我们调用问卷星后端的响应，对数据进行统计分析。

我们总共向25个开发者发送了这样的问卷，并收到了20个完整的回复（他们完成了所有的30个选择问题），2个开发者没有返回问卷，3个开发者返回未完成的回复。

2.5 结果

2.5.1 Q1：正确的参数选择

结果如图1所示。横轴代表不同的受访者，纵轴代表回忆，即受访者正确选择了多少百分比的正确论点。假设原始源代码中的当前参数是正确的，则只有当它们与当前参数相同时，所选参数才是正确的。

从图1中，我们观察到开发人员在大多数情况下都可以选择正确的参数(92%=552/600)。召回率在83.3%到100%之间变化，平均为92%。最低召回率高达83.3%，表明所有受访者无需查看相关调用历史即可频繁做出正确选择。

2.5.2 Q2：数量规则

我们还注意到，没有一个受访者指定参数选择的定量规则。他们中的大多数（20个中的16个）声明他们根据标识符的语义选择参数。他们根据方法名称、参数的语义和候选参数来猜测被调用方法的功能。然而，语义和功能难以量化，因此无法指定量化的选择规则。

我们从案例研究中得出的结论是：在大多数情况下，开发人员可以仅根据标识符以及调用方法的形式签名，从语法正确的候选列表中选择正确的参数，尽管他们中的大多数无法为其指定数量规则选择。

2.6 有效性问题

案例研究外部有效性的第一个问题是案例研究中涉及的数据仅从一小部分应用程序中提取。因此，从这些数据得出的结论可能不适用于其他应用。为了减少这种威胁，我们从GitHub中选择了85个最流行的开源应用程序，其中源代码更有可能具有代表性。

案例研究外部有效性的第二个问题是我们只随机抽取30个参数及其相应的上下文。结果可能因不同样品而异。因此，案例研究的结果可能不适用于其他样本。为了减少这种威胁，我们根据3个条件限制了30个案例，以确保所有案例中涉及的标识符都被正确命名。

案例研究外部有效性的第三个问题是所有分析的应用程序都是用C语言实现的。但是，对C应用得出的结论可能不适用于编程语言（例如Java），因为C和Java语言之间存在本质区别：C是一种面向过程的编程语言，而Java是一种面向对象的编程语言.在未来的研究中验证更多编程语言的结果会很有趣。案例研究外部有效性的第四个威胁是，参与案例研究的所有受访者都不是来自行业的开发人员，而是来自大学学校的经验不足的开发人员。由于受访者不是源代码的原始开发人员，他们可能会错过他们选择中嵌入的量化选择规则的抽象。同时，这些受访者的个人能力可能会影响案例研究的结果。为了减少这种威胁，所有选择的受访者都是具有至少一年项目经验的软件开发人员。他们熟悉软件的开发过程。

案例研究的结构有效性面临的问题是从应用程序中提取的论点可能是不正确的。例如，开源代码可能包含错误，即开发人员为方法调用提供了错误的参数。为了减少这种威胁，我们选择了最流行的开源应用程序，其中的错误一旦发生就更有可能得到修复。

案例研究内部有效性的威胁在于，没有将参数的语义映射到相应上下文的直接规则。为了减少这种威胁，我们手动检查每个选定的参数并确认存在潜在的语义关系。

第3章 问题陈述

定义1（非API方法调用）。非API方法调用是在调用出现时在同一项目中定义的方法调用。

建议的方法是为非API方法调用推荐参数。建议方法的输入是在推荐点可用的不完整程序，包括调用方法的签名和调用上下文。建议方法的输出是给定调用的推荐参数。

IDE可以立即决定何时采用建议的方法。一旦开发人员输入方法调用，IDE将决定调用的方法是API方法还是非API方法。如果该方法是在工作项目中定义的，它是一种非API方法，因此IDE应采用建议的方法来推荐参数。否则，应采用传统的API特定方法来推荐参数。

第4章 方法

4.1 概述

该方法的关键思想是，可以根据调用的方法及其上下文（尤其是语法正确的候选参数列表）推荐正确的参数，尽管我们并不完全知道参数与其上下文之间的量化关系。因此，我们使用训练数据训练LSTM（长短期记忆）神经网络模型，即来自样本应用程序

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[590362]，资料为PDF文档或Word文档，PDF文档可免费转换为Word