生成特定于查询的类API摘要 （Generating Query-Specific Class API Summaries）

链接:Generating query-specific class API summaries | Proceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineeringhttps://dl.acm.org/doi/10.1145/3338906.3338971 Generating Query-Specific Class API Summaries

摘要

源代码摘要是以文本和/或代码的形式对复杂代码元素的简明表示，旨在帮助开发人员快速理解，进而帮助他们执行特定任务。生成特定于任务的摘要在自动代码摘要领域仍然是一个挑战。我们提出了一种为API类生成按需、外部混合摘要的方法，该摘要与编程任务相关，并以自然语言查询的形式表示。摘要包括从API参考文档中提取的最相关的句子和最相关的方法。

外部评估人员评估了从JDK和Android库检索到的几个编程任务类生成的摘要。大多数人认为总结是完整、简洁和可读的。与三种基线方法产生的总结进行比较后发现，仅在我们的总结中呈现的信息比仅在基线总结中呈现的信息更相关。最后，一项外部评估研究表明，这些总结有助于用户更快、更准确地评估API检索结果的正确性。

1 介绍

自动软件摘要是生成一个或多个软件工件的简明表示的过程，它传达了软件涉众执行特定软件工程任务所需的信息[31]。研究人员已经提出了许多软件工件的总结技术，包括：源代码、问答论坛上的帖子、错误报告和问题请求、用户手册、代码和产品评审、代码更改等[36]这些总结的目标之一是促进对软件工件的快速理解。例如，在代码检索任务期间，检索到的代码的摘要可以帮助开发人员快速确定它们是否无关，或者它们是否需要深入分析以建立相关性。

软件工件通常由自然语言文本和/或源代码组成。生成的摘要可以是文本的，只包含源代码，也可以是混合的（即两者都包含）。为文本软件工件生成文本摘要的方法依赖于自动化（自然语言）文本摘要领域的标准技术[24、25、31、36、40、41]。更具挑战性的是总结代码库和混合工件的方法，其中标准技术不适用。其中，混合文档和摘要比较困难，因为它们通常需要在文本和源代码组件之间建立关系。

自动代码摘要技术的一个共同特点是，生成的摘要独立于用户任务（即，摘要的用途）。Binkley等人[13]研究了人类对同一代码、但不同任务的书面总结，得出结论，一个人对同一代码、不同任务产生不同的总结。它还强调了总结非平凡的不熟悉代码是非常具有挑战性的，并且不清楚任务特定的总结需要什么级别的详细信息。此外，McBurney和McMillan[28]表明，由代码作者或相同代码的读者（即用户）编写的源代码摘要之间存在显著差异。此外，人工编写的摘要与自动生成的摘要具有不同的属性。研究人员尚未解决的一个主要挑战是确定哪种类型的摘要最适合给定的用户任务。虽然本文并没有完全解决这个问题，但通过引入和评估一种技术（称为KG APISumm），它可以根据用户编程任务自动生成源代码摘要（表示为自然语言查询），从而向前迈出了重要的一步。

许多开发人员任务都与使用某些API（应用程序编程接口）有关。为了找到相关的API，开发人员通常求助于API文档[15、26、42、44、48]。在本文中，我们关注自动生成类的混合提取摘要，支持开发人员查找与其编程任务相关的API。摘要是根据用户文本查询的需要生成的，用户文本查询描述了手头的编程任务。摘要是混合的，因为它们包括附在被总结课程的相关方法上的摘要句子。KG APISumm是一种提取摘要的方法，因为摘要语句是从参考文档中选择的。摘要是特定于任务的，因为提取的句子和方法与用户查询最相关。换句话说，对于两个不同的查询，一个类可能有两个不同的摘要。

大多数现有的自动代码摘要技术仅依赖于摘要代码工件来生成摘要。代码元素和其他信息源之间的关系很少使用，因此它们不能用于创建特定于编程任务的摘要。只有少数摘要技术依赖于从摘要代码元素外部的源中提取代码相关信息[28、34、35、37、39、48]（参见第5节）。一个问题是，与解决编程任务相关的API信息分散在多个信息源中，并且它们以多种方式相互关联。我们对这个问题的解决方案是构造一个API知识图（API KG），它在方法和句子级别表示关于库的细粒度信息。对文档中的各个句子进行推理的能力对于生成特定于查询且简洁的摘要至关重要。

我们为JDK和Android构建了一个API KG，并针对类API摘要的内在和外在评估进行了几项实证研究，涉及外部评估人员。评估人员发现总结是完整、简洁和可读的。此外，它们还包含相关信息，这些信息在使用三种基线汇总方法获得的汇总中缺失。最后，总结帮助用户更快、更准确地识别与编程任务相关的API。

2 基于KG的类API摘要

KG APISumm将自然语言用户查询Q（描述开发人员任务）、现有库L中的类C以及库L的API知识图（APIKG（L））作为输入。

APIKG（L）用于提取最多S个描述C功能的句子，以及最多M个与Q最相关的C方法。对于每个HMI KG，APISumm还包括从参考文档中提取的最多S个最相关的句子。M和S可由用户自定义，这决定了摘要的最大大小。图1显示了一个示例，其中M=3（即最多包含三个方法）和S=2（即每个方法和类用两句话描述）。

为了生成摘要，KG APISumm需要将API元素相互关联，并与参考文档中的各个句子关联。API KG捕捉了这种关系。

 

2.1 API KG结构

为了构造 apikg (l) ，我们从 l 的参考文档中提取所有的 api 定义和描述。

构建 api kg 的第一步是提取 api 的结构信息。ApiKG 后来丰富了 api 元素和 api 描述之间的关系。Api kg 的高级模式如图2所示，其中包含实体(circles)及其关系(箭头)。Api kg 包括结构知识(白色圆圈)和陈述性知识(矩形)两部分。

 

结构化知识描述 api 实体的结构(例如 api 包、类、方法/字段)和 api 的签名(例如 api 方法的参数和返回值)。它包括各种 api 实体，以及它们之间的包含关系和泛化/实现关系。此外，每个 api 实体都有属性，例如，完全限定的名称，添加的版本，api 文档 url 等。

结构化知识还描述了方法的参数，返回值，抛出的异常及其类型。它还包括 api 元素之间的“ see also”关系，这表明与 api 元素密切相关(例如，提供类似功能的 api 方法)。陈述性知识描述了 api 的功能和指令。这些描述表示为自然语言语句，并将在知识融合部分进一步处理，以识别概念，并将它们彼此联系起来，与一般的软件概念联系起来。

2.1.1 结构知识抽取。

结构化知识中的API实体及其关系是从API参考文档中的类/接口声明、类/接口成员声明和方法声明中提取的。我们开发了一个web爬虫，它从web上获取API参考文档。我们还根据特定API参考文档（例如JDK和Android API文档）的结构开发了一个解析器，用于提取API实体及其属性和关系。

请注意，参数和返回值是可由多个方法共享的独立API元素。例如，两个方法可能具有相同的返回值。可以间接连接接受具有相同含义的参数或返回值的方法。我们通过匹配名称（仅针对参数）、类型和描述来确定两个方法的参数或返回值的相似性。

2.1.2 描述性知识抽取。

我们使用从API参考文档中提取的各种API元素的自然语言文本描述作为描述性知识提取的输入。这些描述包括：包、类/接口、字段、方法、方法返回值和方法参数描述。提取的文本描述处理如下：

1. 删除所有HTML标记和单独的代码段。
2. 保留句子中提到的代码元素每个文本描述被分成几个句子
3. 这些句子分为不同的类型。

根据 maalej 和 robillard [26]的报告，在 jdk 和。Net 包含的信息很少或没有价值。句子分类的目的是排除无意义的句子，并识别与不同类型的陈述性知识相关的句子。基于先前的研究结果[26]以及我们对 jdk 和 android api 参考文档的分析，我们定义了以下与陈述性知识提取相关的句子类型。[功能]ー api 实体功能的描述。示例: “用于报告键和按钮事件的对象”。[ directive ]ー描述 api 的使用情况，例如，正确或不正确的使用情况，方法参数的约束，异常引发的情况。例如: “ illegalargumentexception: if 修饰符参数包含无效修饰符”。所有其他情况，通常是执行细节。例如: “有两种方法可以通过程序确定版本号”。

我们使用反向传播（BP）神经网络[21]训练分类器，将句子分为三种类型之一。为此，我们通过以下方式将句子转换为BP神经网络的输入：（1）使用标准预处理程序（即标记化、停止字删除和柠檬化）将每个句子转换为一袋单词；（2） 通过平均每个句子中的单词向量，为每个句子生成一个向量；（3）使用Word2vec[30]根据API参考文档中所有句子的语料库来训练单词向量。

为了准备训练数据，我们随机选择句子的子集，并手动将每个句子标记为三种类型中的一种。第3.1节介绍了我们实现中分类器的训练和校准细节。

最后，对于分类为[Functionality]或[Directive]的API元素的每个句子，我们在API元素和句子之间创建一个“hasFunctionality”或“hasDirective”关系。

2.1.3 知识融合。

我们将不同API元素的描述中引用的概念相互关联，也将这些概念与更一般的知识图中的概念联系起来。这些概念关系有助于确定API元素之间的关系及其与用户查询的相关性。

不同API实体的描述可能涉及各种API相关概念，例如“系统服务”、“下载”、“系统通知”。为了简单起见，我们将这些在API描述中提到的概念称为API概念。识别这些概念引用可以揭示共享它们的API元素之间的语义关系。例如，提供类似或相关功能的不同API类或方法在语义上是相关的，即使它们在结构上不是相关的（例如，通过直接引用）。一些APIConcept可以进一步与现有的通用知识图（如Wikidata）中的通用软件相关概念（我们简称为软件概念）联系起来。这些常识图揭示了概念之间的进一步关系。例如，APIconcept“download”链接到软件概念“download”，然后通过Wikidata中定义的关系进一步连接到“service”和“upload”。通用知识图的使用使我们能够确定在库的结构或参考文档中不明确的关系。

知识融合过程包括三个步骤：（1）API概念参考提取；（2） 跨句概念融合；软件概念融合。它需要一个通用概念过滤的初步步骤，该步骤独立于库。

通用概念过滤。

我们从一般知识图（如Wikidata）中提取软件概念。

Wikidata是一个免费、开放的知识图表，提供一般知识，包括许多与软件相关的概念（例如，“服务”、“上传”、“下载”、“计算机网络”）和关系（例如“下载”、“部分”、“服务”>、“下载”、“与之相反的”、“上传”）。然而，Wikidata中的大部分概念和关系与软件无关。因此，我们需要使用过滤器从API KG的一般知识图中仅选择软件概念。

我们从一般知识图中选择软件概念，并将这些概念及其关系添加到API KG中。

与描述性知识提取中的句子分类类似（参见第2.1.2节），我们使用BP神经网络来训练文本分类器，以区分软件相关概念和无关概念。分类基于一般知识图中每个概念的文本描述。例如，Wikidata中的每个概念都有相应的Wikipedia[12]文章对其进行描述。我们通过以下方式将概念描述转换为BP神经网络的输入：（1）使用标准的预处理程序（即标记化、停止字删除和柠檬化）将每个概念的描述转换为一袋单词；（2） 通过平均每个概念描述中的词向量，为每个概念生成向量；（3）使用Word2vec[30]基于所有泛型概念描述的语料库来训练词向量。作为培训数据，我们随机选择了一部分通用概念，并手动将其标记为与软件相关或不相关。第3.2节详细介绍了我们实现中使用的分类器的培训和校准。

API概念参考提取。

我们确定了API元素的描述语句中与API Concept相对应的部分。

通过识别名词短语，从API元素的描述句中提取概念引用。可能会采用更复杂的提取技术，但研究其适用性是未来工作的主题。我们使用解析器解析每个描述性句子，遵循标记化、词性标记、柠檬化、选区解析和依赖性解析的标准过程。我们从解析树中提取所有原子名词短语，其中不包括其他较小的名词短语。然后，我们从提取的名词短语中删除停止词，并删除仅包含特殊字符的名词短语（如“#”、“！”）。描述句中所有剩余的原子名词短语都被视为候选概念引用。

跨句概念融合。

我们将API元素的不同描述语句链接到同一API concept。已识别的API Concept通过引用这些概念的描述性语句中的链接添加到API KG中。

为了识别引用同一API concept的候选概念引用（即名词短语），我们根据词汇相似性和上下文相似性对候选概念引用进行聚类。对于两个候选概念引用n1和n2（本例中为名词短语），它们的相似性sim（n1，n2）是两个相似性（w1+w2=1）的线性组合。

 

n1和n2的上下文相似性（simcon）是n1和n2所在的两个API文档段落的文本向量之间的标准化余弦相似性。这些段落是根据HTML标记从参考文档网页中提取的，例如”<p>“、“<br>”。我们选择段落而不是更大的上下文，例如文档，因为我们注意到概念引用的相关语句通常彼此非常接近。在下式中，Vp（n）是n所在段落的k维文本向量，Simcos是两个向量之间的余弦相似性。给定一个段落，其向量表示的生成方式类似于用于描述性知识提取的句子分类中使用的句子向量生成（见第2.1.2节），即预处理后对段落中的一袋单词的向量求平均值。

 

基于每对候选概念引用之间的相似性，我们计算它们之间的距离为1− sim（n1，n2）并使用分层聚类算法[43]对所有候选概念参考进行聚类。最初，每个候选概念引用都被视为一个集群。在以下每次迭代中，具有最小距离的两个簇合并在一起。通过平均两个簇中候选概念引用之间的距离来计算两个簇之间的距离。当最高簇间相似性低于给定阈值时，迭代过程结束（稍后在第3.2节中解释）。

对于每个簇，选择与同一簇中其他簇具有最高平均相似性的候选概念引用，并将其用作簇的名称。集群的名称作为一个新的API概念添加到API知识图中。最后，我们从集群中API概念引用所在的每个描述性语句向新的API concept添加一个“refere to”关系。

软件概念融合。

我们将API Concept或API实体链接到通用KG（又称软件概念）中的通用软件相关概念。注意，软件概念融合对于API概念和API实体有不同的含义：前者意味着API concept与软件概念相关；后者意味着API实体的功能与软件概念相关。

对于每个API concept，我们收集所有包含引用的描述性语句。对于每个软件概念，我们使用通用知识图（即相应的维基百科文章）中的文本描述。然后，对于每个API concept或软件概念，我们使用标准的预处理过程（即标记化、停止字删除和柠檬化）将其描述转换为一包单词，并通过平均描述中的单词向量来生成概念向量。我们使用Word2vec[30]基于API概念和软件概念的组合语料库来训练单词向量。语料库包括两部分：（1）API参考文档的所有文本描述；（2）软件概念的所有文本描述。

给定一个API概念ac，我们将其与所有软件概念进行比较，并生成一组候选软件概念，这些概念的名称（包括别名）中至少有一个公共标记。然后，对于每个候选软件概念sc，我们估计ac和sc之间的文本相似性，作为它们向量之间的余弦相似性。如果相似性高于给定阈值，我们将ac视为sc的参考，并添加ac到sc的“relatedTo”关系。API实体的软件概念融合以类似的方式进行。

为了便于识别候选软件概念，我们通过将每个API实体的短名称（即完全限定名称最后一个点后的部分）拆分为大小写和下划线，自动为每个API实体生成一个特殊别名。API实体的向量是基于其所有描述性语句生成的。

2.2 摘要生成

为了生成摘要，我们需要API KG中的类、方法、句子及其关系。我们计算用户查询和这些实体之间的相关性得分。因为知识图中的每个实体都有一个对应的文档，所以我们可以使用一些文档相似性模型方法（例如，从文本检索）直接计算查询和实体文档之间的相似性。然而，对于小文档，例如只有几句话作为描述的方法实体，这种方法的性能往往很差。它们没有利用实体之间的关系（例如API之间的结构关系）和来自一般知识的知识。

因此，我们根据实体和查询与用户查询的文本和概念相似性，在它们之间设计了基于KG的相似性。文本相似性度量文本内容的语义表示之间的相似性，这可以从文本语料库中学习。概念相似性度量其对应概念的语义表示之间的相似性，这可以从API知识图中学习。

具体地说，给定一个查询q，它和候选实体e的相似度是通过它们的文本相似度和概念相似度的线性组合（w1+w2=1）来计算的。

 

q和e（即Simtext（q，e））之间的文本语义相似度是基于它们的文本向量计算的。它们的文本向量的生成方式与用于句子分类的句子向量相同（见第2.1.2节），方法是对从所有知识图实体文档中收集的语料库（API概念和软件概念的组合语料库）训练的词向量进行平均。e的单词向量是其文档中单词的向量。q和e（即Simconcept（q，e））之间的概念相似性是使用它们的概念向量来计算的，这些概念向量是基于API知识图生成的。对于API KG中的每个实体，我们使用node2vec[18]，一种可伸缩的图形特征学习方法来训练图形向量。图形向量反映KG中实体的结构特征。e的概念向量可用其图向量表示。

我们在相同的向量空间中表示查询q，如下所示：

1）候选实体选择。我们从q中提取关键词，包括概念引用和动词。概念参考提取的方式与API概念参考提取的方式相同（见第2.1.3节）。动词通常映射到方法名。通过这种方式，我们将查询简化为一组关键字。对于每个关键字，我们确定一组候选实体。与查询相关的候选实体集是为关键字找到的候选实体集的并集。标识基于其名称（包括别名）是否包含关键字。具体来说，句子实体的名称就是句子本身。为了增加匹配实体的可能性，我们通过将每个API实体的短名称（即完全限定名称最后一个点后的部分）拆分为大小写和下划线（例如，对于类java.math.BigDecimal，我们生成一个别名“big decimal”），自动为每个API实体生成一个特殊的别名。

2） 文本相似度计算和过滤。通过计算每个候选实体和q的文本向量之间的余弦相似度来估计它们之间的文本相似度。如果实体与查询的文本相似性小于某个阈值t，则从候选实体集中删除该实体。

3） 计算查询的概念向量。我们使用候选实体集合的概念向量来估计查询q的向量表示。最简单的方法是平均所有候选实体的图向量。然后，查询q可以映射到API KG中映射的相关候选实体集的中心点。考虑到每个候选实体e与查询的相关性和关键字重要性，为其分配权重（见等式5和6）：

在等式5中，TFIDF（t）是查询q中一个关键字t的TFIDF值|Ct |是通过关键字t提取的候选实体数。一个实体A可以由两个关键字提取，一个关键字可以提取多个实体。例如，如果这两个关键字提取的实体数分别为10和20，且其TFIDF分数分别为0.2和0.3。该实体A的重要性得分为0.2/10+0.3/20=0.035。

 

基于q和e的文本向量（Vtext）和概念向量（Vconcept），它们的文本相似度和概念相似度通过以下等式计算，其中Simcos表示两个向量之间的余弦相似度。

 

最后，使用等式4中的KGSim（q，e），KG APISumm为类和与用户查询相关的每个方法对API方法和描述性语句进行排序。然后，它为每个方法选择前M个方法（可能少于M个），并选择前S个句子（可能少于S个）的类。

3 实施

我们为JDK1.8[6]和Android API 27[2]构建了一个API知识图。

3.1 知识抽取的实现

我们使用Beautiful Soup[3],，一个用于解析HTML和XML文档的Python库，来解析API参考文档的HTML页面以进行知识提取。我们还使用NLTK[7]，一个用于文本处理的Python库，在描述性知识提取中实现文本预处理（即标记化、停止字删除和 词形还原）。

为了训练句子分类器，我们开发了一个基于网络的句子标注工具，并邀请24名硕士和博士生对从API文档中随机选择的句子进行标注。这些学生有2到5年（平均3年）的Java和Android开发经验，其中10人有至少6个月的工业实习经验。每个句子由两名学生分别标记为三种类型之一（即，[功能]、[指令]或[其他]）。学生可以访问句子的完整上下文（即参考文档）。对于标记不同的句子，第三个学生被分配给另一个标签，以解决冲突。三票中有两票的标签被选为最终标签。最后，我们获得了8345个标记句子：4167个标记为功能性，3557个标记为指令，621个标记为其他。

基于句子语料库，我们使用gensim[30]提供的word2vec算法为每个单词训练了一个128维的单词向量。我们根据默认设置为培训设置以下超参数：最小计数=3，窗口大小=10，样本=0.001，算法=skip gram。

用于句子分类的BP网络是使用Tensorflow 1.10.0[11]实现的，这是一个用于深度学习框架的Python框架。基于默认设置，我们为训练设置了以下超参数：一个包含256个神经元的隐藏层，学习率=0.01，输出层的softmax函数，批量大小=512。在10%标记数据的测试集上，这些参数的准确度为0.9。

3.2 知识融合

实现泛型概念过滤中使用的泛型概念的描述从下载的英文维基百科转储中提取[1]。我们邀请了四名学生为数据添加标签，以进行一般概念筛选。Wikidata有大量的概念（约5000万），其中大部分与软件无关。因此，我们选择了一组可能与软件相关的概念，如下所示。我们选择了所有与“编程语言”、“软件”或“计算机科学”有“子类”、“实例”或“部分”关系（直接或间接）的概念。然后，我们选择了一组概念，这些概念的名称或维基百科描述中包含诸如“软件”、“图书馆”、“计算机”等关键词。通过这种方式，我们选择了22306个概念，每个概念都被两个学生独立地标记为软件相关或非软件相关。两人的共识率达到99.8%。对于标记不同的概念，第三个学生被分配给另一个标签，以解决冲突。三票中有两票的标签被选为最终标签。得到21809个软件相关概念和497个无关概念。由于Wikidata的大部分概念与软件无关，我们随机选择了另外32216个概念（不符合我们之前的标准），并自动将它们标记为无关概念，使得相关概念的数量是软件相关概念的1.5倍。最后，我们获得了54522个标记的通用概念（21809个与软件相关，32713个与软件无关）。通用概念过滤的BP网络也用Tensorflow 1.10.0实现。我们使用了与句子分类相同的超参数。

我们使用NLTK解析描述性语句，以提取API概念引用。交叉概念参考提取中的层次聚类是用SciPy 1.0.0实现的[10]。相似性计算（方程式1）中的两个权重相等地设置为0.5，层次聚类的距离阈值设置为1.6。这些参数是在使用一个小测试数据集进行调优的基础上选择的，从API概念参考提取结果中随机选择，并由两位作者标记。

用于软件概念融合的词向量以与句子分类相同的方式进行训练。唯一的区别是，这里使用的语料库包含了来自维基百科的所有软件概念的描述。相似性阈值设置为0.8，用于融合API概念的最大软件概念数设置为5。这些参数是在使用一个小测试数据集进行调优的基础上选择的，该数据集由随机选择的API概念或API实体组成，并标记了应该从中融合的软件概念（由两位作者标记）。

3.3 结果API知识图

结果API KG包括562578个实体和4243842个关系。其中，API实体有137113个，API实体之间的关系有305826个。KG包括292684个描述性语句：130641表示功能性语句，162043表示指令性语句。在这些句子中，确定了54596个API概念，这些概念与278994个句子（平均5.11个）相关联。知识图还包括78182个软件概念，其中20640个软件概念与49256个API概念和90209个API实体相关联。

3.4 摘要生成

我们使用node2vec[8]来训练图向量。因为我们认为关系是相似的，所以我们把所有关系的权重设置为1。用于培训的超参数遵循node2vec实现提供的默认设置。

计算组合相似性（见等式4）时使用的两个权重w1和w2分别设置为0.6和0.4，基于测试数据集的调整，使用随机选择的SO问题的查询，以及作者根据其经验提出的高质量答案和查询。

我们使用M=3和S=2摘要生成，即一个类摘要最多包含三个方法，对于类本身和每个方法，最多包含两个句子。

4 评估

我们进行了几项实证研究，以评估API摘要的内在质量和有用性。我们有兴趣回答以下关于KG APISumm生成的摘要的研究问题。

RQ1 KG APISumm生成的摘要的内在质量是什么？

RQ2 KG APISumm生成的摘要与其他方法生成的摘要有何不同？

RQ3 KGAPISumm生成的摘要在帮助开发人员进行APIsRetrieval时有多大用处？

RQ4 KG APISumm是否为同一类的不同查询生成不同的摘要？

RQ1的答案将告知我们生成的摘要是否包含相关和可理解的信息。RQ2将显示KG APISumm生成的摘要是否包含其他类别摘要中未包含的相关信息，反之亦然。RQ3提供了外部评估，并将指出总结是否有助于解决特定的开发人员任务。最后，RQ4将告诉我们KG APISumm是否实际生成特定于任务的摘要，也就是说，同一个类对于不同的查询将有不同的摘要。

为了回答研究问题，我们收集了一组与编程任务相对应的查询。我们要求外部评估人员评估KGAPISumm为这些任务生成的摘要（RQ1）的质量，并将其与三种基线方法生成的摘要（RQ2）进行比较。另一组用户分析了为另一组查询检索到的类和方法，有无生成摘要的帮助（RQ3）。最后，我们通过为不同的查询提供具有不同摘要的类的示例来回答RQ4。在我们的复制包[9]中可以找到实证研究的详细信息。

 

4.1 总结的内在质量

我们根据先前研究中提出的评估[32,45]，对KG APISumm生成的API总结进行了经验内在评估。

4.1.1任务和查询。

我们根据以下标准选择了出现在StackOverflow（SO）问题中的编程任务：

（1）问题有一个标签“Java”或“Android”；

（2） 编程任务涉及使用JDK1.8或Android API 27中包含的API；

（3） 这个问题有一个公认的答案。我们根据分数对符合上述标准的SO问题进行了排名，并选择了排名靠前的20个问题。从这些问题中，我们随机选择了六个Java问题和六个Android问题。SO问题包括在表1中。C列显示此任务的相关类的数量，M列显示相关方法的数量。

通过查阅SO答案，我们确定了每个查询的正确答案（类和方法）。涉及两名合著者和两名外部人员，其中一名合著者担任专家。每个问题由两人（至少一名外部人员）分析。每个人都独立地注释了他认为相关的类和方法。如果一个类/方法被两个人标记为相关，则认为该类/方法是正确的。否则，专家将做出最终判断，选择一个或两个选项。

4.1.2 参与者。

我们邀请了12名在Android和Java开发方面有经验的硕士生来评估API摘要的质量。通过对50名研究生的调查，对他们的编程技能进行了评估。选出了12名经验最丰富的人。总结评估人员了解并理解如何解决每项任务非常重要。12名学生中的6名评估了RQ1的总结，而另外6名（随机决定）评估了RQ2的总结。

4.1.3协议。

学生们在实验室的一节课中完成了评估，并在其中一位作者的监督下进行了后期访谈。对于每个任务，他们阅读任务的SO post解决方案，以确保他们知道如何解决任务。然后，他们评估每个摘要的完整性、简洁性和可理解性，就像之前的软件摘要研究一样[32,45]。对于每堂课的总结，学生们以4分的利克特量表回答了三个问题（1-不同意；2-有点不同意；3-有点同意；4-同意）：

 

（1） 完整性–摘要是否包含所有必要信息？

（2） 简洁性–摘要是否不包含（或很少）不必要或冗余的信息？

（3） 可理解性–摘要是否可理解？

我们对第二个问题采用否定的措辞，以保持对答案的解释与所有三个问题类似。在参与者完成评估后，如果评分很低（1或2），我们会要求解释。

4.1.4结果和分析。

每个问题由三名学生针对每个摘要回答。我们在所有总结中累积每个问题的答案，并关注“肯定”（3或4）和“否定”答案（1或2）的百分比。

图3显示了每个问题答案的分布。完整性方面，45.2%的答案为4（同意），45.2%的答案为3（稍微同意），9.6%的答案为2（稍微不同意），没有1个（不同意）答案。为了简洁起见，53.8%的答案是4，36.6%的答案是3，9.6%的答案是2，没有1个答案。为了便于理解，80.6%的答案是4，19.4%的答案是3，没有2和1个答案。

我们使用了单样本T检验[14]用于验证参与者评分和随机评分之间差异的统计显著性。无效假设是完整性、简洁性和可理解性评分是随机的，每个属性的评分平均值为2.5。结果表明，对于每个属性，统计差异为sig非常重要（p<0.01），因此我们拒绝了无效假设。七份总结至少得到一个2分（有些不同意）为了简洁。参与者在采访后解释说，他们认为总结中的一些方法是不相关的，并认为这是不必要的信息。

然而，对于所有七个总结，至少有一个3（多少同意）或4（同意）简洁性评级。例如，java.math.BigDecimal类摘要的简洁性评级为2,4,4。该类与“如何在java中将数字四舍五入到小数点后n位”问题相关，在摘要中包括以下方法：

java.math.BigDecimal.movePointRight(int),

java.math.BigDecimal.movePointLeft(int), and java.math.BigDecimal.scale().

一个评分员认为scale（）方法是该任务唯一正确的方法，另外两个是不必要的，hences给了2分。其他两个被认为是movePointRight（int）的评分员也适用于此任务。

六份摘要的完整性评分为2（有些不一致）。评分员报告说，这些评分是由那些认为其他方法（未包括在总结中）与任务相关的人给出的。同样，这些班级也得到了至少一个3（多少同意）或4（同意）的评分，因为其他评分者认为列出的三种方法是最相关的，即使他们发现了其他相关方法。例如，java.util.Map.Entry类的摘要完整性评分为2、4、4。该类与查询“如何有效地迭代Java映射中的每个条目？”相关。一位评分员认为，总结遗漏了任务的有用方法。其他两名评分员认为这两个类的句子足够有用，可以解释这个类可以用于在地图上迭代，因此他们的评分为4。迭代由java.util.Map中的方法完成，而java.util.Map.Entry中的方法仅用于包装数据。在这种情况下，较低的评级似乎更合适。

我们还将查看每个问题的同意率。为了简洁起见，29%的摘要得到了所有三个评分员的相同评分，97%的摘要得到了至少两个评分员的相同评分。为了完整性，29%的总结得到了所有三个评级者的相同评级，100%得到了至少两个评级者的相同评级。为了便于理解，55%的总结得到了所有三个评级机构的相同评级，100%的总结得到了至少两个评级机构的相同评级。

4.1.5对有效性的威胁。

对结构效度的主要威胁是在确定12个查询的正确答案时引入的主观性。为了减少偏差，我们选择了与SO帖子相关的任务，并使用了有效答案。

KG APISumm的校准影响我们结论的内部有效性。我们使用了与评估中使用的数据不同的数据，以找到我们方法的最佳参数。另一个威胁是基于人的评估的主观性和错误倾向。为了缓解这一威胁，我们对每个摘要和报告的协议数据依赖三名评估人员。

评估中使用的任务数量影响我们结论的外部有效性。需要进行更大的评估。

4.2与基线方法的比较

对于回答RQ2，我们使用与回答RQ1相同的任务和总结（见第4.1.1节）。我们要求按照第4.1.2节所述选择的12名参与者中的6名将KG APISumm产生的总结与三种基线方法产生的总结进行比较。

4.2.1基线方法。

我们使用了三种基线方法，一种由作者实现，两种使用现有工具。

第一个基线基于TextRank[29]，这是一个用于自动文本摘要的基于图形的排名模型。我们使用TextRank生成类的摘要，使用类中的所有句子。TextRank提取最多五个句子作为课堂总结。对于实现，我们使用gensim[4]。

 

第二种基线方法基于谷歌。为了生成一个类摘要，我们在Google中搜索SO标题，将结果限制在jdk参考文档网站或android sdk文档网站。我们将相关搜索结果（类和方法）的摘要作为API摘要。

第三种基线方法是Biker[22]，这是一种API推荐方法，通过结合SO和API文档中的信息，为推荐的API提供总结。我们在Biker中使用SO问题标题作为查询，将搜索限制在类级别，并从搜索结果中获取摘要。

4.2.2协议。

在比较以两种不同方式生成的发行说明时，我们采用了与先前研究中使用的协议类似的协议[34,35]。我们将每个查询/任务分配给两名参与者，每个参与者对四项任务的总结进行评分。对于每个查询/任务，向参与者展示相同的相关类，但有不同的摘要，每个摘要由不同的方法生成。评分员一次只比较两份摘要。给定摘要S1和S2，对于C类和查询Q，每个都由不同的方法产生，请求者被要求考虑摘要的每一个元素（即方法/类句子和方法签名，因此问题或代码片段）。对于每个摘要元素，他们被要求标记该元素是否：（1）仅存在于S1中；（2） 仅存在于S2中，仅存在于B中；或（3）同时存在于S1和S2中。然后，对于仅在S1或S2中的元素，在4-Likert量表上评估唯一元素是否有用。评级对应：1-强烈不同意；2-不同意；3-同意；4-强烈同意。我们要求评分员对这些独特的项目进行全面评估，而不是对每个项目进行单独评估，这会让参与者在时间和精力上付出太多的代价。

因为Biker只为JDK工作，所以我们只比较使用Android查询的Egg APISumm TextRank和Google，而这三种查询都用于JDK查询。如果一种方法不能为一个类生成摘要，那么在比较这个类的不同摘要时，我们将忽略这种方法。例如，Google没有使用指定的查询检索某些相关类）。

4.2.3结果和分析。

表2显示了每一对的平均评级。单元格(i,j)中的平均评级表示由第i行方法产生的摘要中呈现的信息的评级，而不是由由第j列方法产生的摘要中呈现的信息的评级。

例如，提供KG-APISumm摘要的信息(第2行)和不在TextRank摘要(第4列)的平均评分为3.29。相反，呈现TextRank摘要(第4行)而不是KG-APISumm摘要(第2列)的信息的平均评分为2.30。

在72%的案例中，两个总结的评分是相同的。在48%的案例中，两个总结的两个评分是

3和4。在51%的情况下，一对摘要的两个评级是1和2。在15%的情况下，两种评级相差很大，一种是1或2，另一种是3或4，表明不一致程度很低。

4.2.4对有效性的威胁。

由于我们使用相同的数据，我们与之前的研究有着相同的结构效度威胁。

我们结论的内部有效性受到以下事实的影响：基线方法生成不同类型的总结，我们必须使用这些工具生成的数据编写总结，以便与我们的进行比较。另一个威胁是基于人的评估的主观性和错误倾向。为了缓解这一威胁，我们依靠每个摘要对两名评估员和报告的协议数据。

结论的有效性受到以下事实的影响：我们对不同的摘要对使用了不同的数据集。

评估中使用的任务数量影响我们结论的外部有效性。需要进行更大的评估。

4.3总结的有用性

我们对RQ3进行外部评估。一组学生被要求找到一个查询的相关类，该查询由一个名为Biker的工具返回[22]。学生在有或没有KG APISUM生成摘要的情况下执行这些任务。目标是评估KG APISumm总结的使用是否有助于执行给定任务。

4.3.1任务和查询。

我们从用于评估Biker[22]的数据集中选择了20个查询（用于API检索），并使用其基本事实信息。我们将查询分为10种类型，并为每种类型的查询随机选择两种查询。查询分类结合了与查询（一个或多个）相对应的基本真相类的数量以及在Biker搜索结果中排名的基本真相类。对于具有一个基本真相类的查询，有五种类型的排名：前10名中的前1名、前2-3名、前4-5名、前6-10名的基本真相类。对于具有多个地面真相类的查询，有五种类型的排名：所有地面真相类都在前3名、前5名、前10名、前10名中至少有一个、前10名中至少有一个、前10名中的所有。我们创建这些类别的原因是，我们希望最大化检索任务和结果的多样性（即，一个或多个具有不同等级的相关类）。我们将查询分为两组，QA和QB。每个组包含10个查询，每个查询类别一个表单。

4.3.2参与者。

我们邀请了12名具有Java编程经验的硕士生，但他们的经验水平不同（初学者、中级、高级）。通过对50名研究生的调查，对他们的编程专业知识进行了评估。这些学生都没有参加以前的研究。我们将参与者分为两组，每组六人（PA和PB），每组有两名初学者、两名中级和两名高级。

4.3.3协议。

研究因素是使用总结（即自变量）。我们对各组采取了平衡的治疗分配。PAW组的参与者被要求使用KG APISumm总结和QB组的任务完成QA组的任务，而不使用总结。相反，PB组的参与者被要求完成QB组的任务，使用KG APISumm总结和QA组的任务，而不使用总结。总的来说，要求每位参与者完成全部20项任务，其中10项使用KG APISumm总结，10项不使用。对每个参与者来说，任务是交错的，一个进行KG APISumm总结，一个不进行总结。

对于给定的任务，参与者将获得相应的查询和Biker检索到的前10个类（使用完整的javadoc）。在第一次治疗中，结果列表还包括每个类别的KG APISumm总结。请注意，在某些情况下，相关类别不在前10名。参与者被要求选择他们认为可以解决查询中描述的问题的类。如果参与者认为提供的信息不充分，他们可以使用互联网，但我们要求他们忽略任务查询来源的SO帖子。

我们开发了一个网站，每个人用来完成任务，一个接一个，并提交他们的答案。系统自动记录完成时间。我们记录了每个任务完成的时间和每个答案的正确性。如果参与者提交的班级包含至少一个地面实况课，我们认为答案是正确的，正确的分数是1。否则，此查询的正确性得分为0。

4.3.4结果和分析。

表4报告了每种治疗的平均完成时间和正确性，这表明使用KG APISumm总结时，参与者（两组）完成任务的速度快17.9%（37秒），他们的答案更正确（平均）。

我们使用Kolmogorov-Smirnov检验[27]（p<0.05）验证了数据的分布（即正常），并使用Welch的Ttest[49]验证了处理间差异的统计显著性。时间和正确率的差异均有统计学意义（p<0.05）。

对于大多数查询，使用摘要会导致更快的响应，但并非所有情况下都如此。在某些情况下，参与者坚持额外的网络搜索，导致更长的响应时间。在某些情况下，参与者在短时间后提交了一个空答案，这基本上表明他们无法解决任务。使用总结的参与者倾向于花更多的时间阅读总结，而不是搜索其他结果。

我们分析了总结对来自主题组的初学者、中级和高级程序员的影响（见表5）。初学者在每项任务中平均花费的时间（在两种治疗中）比中级和高级参与者花费的时间要多，中级和高级参与者花费的时间相似。此外，初学者所看到的平均时间改进要比中级和高级参与者所经历的时间改进大，这表明总结对没有经验的程序员更有用。我们还观察到，当任务更复杂时（即oracle中有多个类），摘要比任务更简单时节省更多时间。对于单类任务，总结对于前10个案例最有帮助（221s->172s）。对于多类任务，总结对多个前10个案例最有帮助（232s->160s）。

4.3.5对有效性的威胁。

我们与以前的研究一样，面临着simlar结构有效性威胁，但我们通过选择具有外部oracle的任务缓解了这一问题，在其他研究中进行了定义。

另一个威胁是人类执行任务的主观性和错误倾向。为了缓解这种威胁，我们设计了一种平衡的治疗方法，以考虑受试者和任务之间的可变性。

结论的有效性受到平均值比较的影响，我们通过报告统计显著性来减轻这种影响。评估中使用的任务和用户数量影响我们结论的外部有效性。需要进行更大的评估。

 

4.4 API摘要中的可变性

我们想验证KG APISumm是否为不同的查询生成不同的摘要。我们看了一些例子。

我们从Biker数据集中选择了七个查询，这些查询包含GroundTruth中相同的类，即java.nio.file.Files[5]。该类提供对文件和目录进行操作的方法。

这七个查询如表3所示。第3列显示了总结中包括的方法。列中的相同方法名称表示重写。第4列显示了来自Biker数据集的地面真实值方法。

每个查询的类语句都是相同的（此处未显示），但不同查询的方法不同，隐含的描述语句也不同（此处未包括）。然而，总结中的七个问题中有六个包括了摩托车手的地面真相方法，一个（Q6）没有。尽管如此，总结中包含的方法在某种程度上是相关的。总之，KG APISumm为同一类生成不同的查询相关摘要。

5 相关工作

我们调查了相关的研究，主要集中在类级别的源代码摘要。最近关于自动软件摘要的调查[31,36]涵盖了总结其他类型的软件工件或比类更小的代码元素（例如，代码块或方法）的方法。最相关的是Petrosyan等人[39]的工作，他们用从开发教程中提取的用法解释来扩充API类型文档，而Treude和Robillard[48]则是根据SO的见解来完成的。在这两种情况下，注入的信息都是通过有监督的文本分类器来检测的。

其他相关工作集中于发现相关教程片段[23]，并将源代码示例链接到API文档[33,46]。与我们的方法一样，这些方法将API与各种源中的相关文本或代码片段链接起来。但是，与我们的工作不同，它们不构建API相关知识的图表，也不生成依赖于查询的摘要。

在其他工作中，Moreno等人[32]研究了Java类的自然语言注释的生成，方法是利用静态分析识别的代码原型（即表示代码元素的角色或职责的抽象）。Panichella等人[38]使用了类似的方法来记录测试用例。Haiduc等人[19,20]提出使用文本检索技术（特别是向量空间模型和潜在语义索引）为方法和类选择描述性术语。De Lucia等人[16,17]也采用了类似的方法来生成类关键字。这些类型的摘要严格依赖于从要摘要的代码中提取的信息，并且与任务无关。

在其他粒度上总结代码的一些工作也是相关的，因为它根据与代码的关系（结构或文本）从要总结的代码以外的其他来源提取信息。例如，McBurney和McMillan[28]为Java方法生成摘要，包括有关代码上下文的信息（例如，调用的方法）。Moreno等人[34,35]从问题追踪器中提取信息，作为发行说明总结代码更改。Panichella等人[37]从相关的开发人员通信中提取方法描述。最近，Huang等人[22]提出了Biker，这是一个向查询推荐相关API的工具。同时，它生成基于模板的摘要，包括来自API描述和SO帖子中相关代码示例的信息。本文中使用了摩托车手摘要，以进行比较。与我们在此介绍的工作不同，所有这些方法生成的摘要并不特定于编程任务或用户查询。

6结论

我们提出了一种使用API知识图生成基于查询的类API摘要的方法（KG APISumm）。查询是编程任务的自然语言形式。在许多情况下，不同的查询会导致相同类的不同摘要。一组外部主体认为总结是完整、简洁、易懂的，并且包含比其他三种总结工具生成的总结更有用的独特信息。更重要的是，在KG APISumm摘要的帮助下，解决20个不同API检索任务的受试者平均比没有摘要的受试者获得更好更快的检索任务答案。更重要的是，新手程序员在检索任务中使用这些摘要的好处最大。