CN110688303A - 一种基于一体化开发平台的软件工件关系的挖掘方法 - Google Patents

Abstract

本发明公开了一种基于一体化开发平台的软件工件关系的挖掘方法，包括：首先从GitHub页面提取所有的显式引用，过滤掉噪声后，识别缺陷报告、提交请求和来自显式引用的提交记录之间的“解决”关系，并恢复工件之间“解决”关系的缺失链接，再使用文本挖掘和机器学习技术分析剩余引用中的其他关系，最后基于识别出的解决关系和非解决关系，构建连接图。本发明的方法可以提高挖掘的准确性和效率。

Description

一种基于一体化开发平台的软件工件关系的挖掘方法

技术领域

本发明涉及计算机技术领域，具体涉及一种基于一体化开发平台的软件工件关系的挖掘方法。

背景技术

随着开源软件发展的日益普及，软件工件的数量有了巨大的增长，使人们能够深入了解如何构建软件。研究人员总是在寻找大规模的、有代表性的软件工件，以生成新型现有技术的系统的、无偏差的验证。。

现有技术中，有部分研究方法，通过重建缺陷报告与修复代码变化之间的关系，来挖掘软件工件之间的关系，例如，ReLink，MLink，RCLinker，FRLink，PULink。

本申请发明人在实施本发明的过程中，发现现有技术的方法，至少存在如下技术问题：

现有技术中的研究方法是分别针对两个系统(缺陷存储库和源代码版本控制系统)进行研究，然后研究如何将两个系统之间的工件连接起来，不适用于一体化开发平台，并且，通过重建缺陷报告与修复代码变化之间的关系，来挖掘软件工件之间的关系，容易忽略软件工件之间的其他引用关系，因而导致准确性不高。

由此可知，现有技术中的方法存在准确性不高的技术问题。

发明内容

有鉴于此，本发明提供了一种基于一体化开发平台的软件工件关系的挖掘方法，用以解决或者至少部分解决现有技术中的方法存在准确性不高的技术问题。

本发明提供了一种基于一体化开发平台的软件工件关系的挖掘方法，包括：

步骤S1：从给定的软件工件中获取有效的显式引用，其中，软件工件包括软件缺陷报告、代码库提交记录和提交请求；

步骤S2：采用关键字匹配和基于事实的分析方法，从获取的有效的显式引用中识别出解决关系；

步骤S3：对于有效的显式引用中的其他引用，采用监督机器学习方法预测引用的非解决关系，其中，其他引用为有效的显式引用中除具有解决关系的引用之外的引用，非解决关系为引用的原因；

步骤S4：根据识别出的解决关系和预测的非解决关系，挖掘软件工件关系。

在一种实施方式中，步骤S1具体包括：

从给定的软件工件中获取所有显式引用，对显式引用中的噪声进行过滤，获取有效的显式引用。

在一种实施方式中，步骤S2具体包括：

步骤S2.1：当提交请求或代码库提交记录中是否包含预设关键字时，将提交请求与软件缺陷报告之间的引用关系、或代码库提交记录与软件缺陷报告之间的引用关系作为解决关系；

步骤S2.2：根据开发人员对软件缺陷报告的评论识别出解决关系。

在一种实施方式中，所述方法还包括步骤S2.3：

根据识别出的解决关系构建软件缺陷报告、代码库提交记录以及提交请求之间的三角关系。

在一种实施方式中，所述方法还包括：

构建提交请求与代码库提交记录之间的映射关系，并通过映射关系消除三角关系中的虚假解决关系。

在一种实施方式中，步骤S3具体包括：

步骤S3.1：选取预设数量的具有非解决关系的引用作为训练样本，利用训练样本对构建的预测模型进行训练；

步骤S3.2：对有效的显式引用中的其他引用，采用经典的VSM模型结合TF-IDF方法进行特征提取，利用训练后的预测模型预测出非解决关系。

在一种实施方式中，步骤S4具体包括：

根据识别出的解决关系和预测的非解决关系，构建软件工件之间的连接图，并通过构建的连接图挖掘软件工件之间的关系。

本申请实施例中的上述一个或多个技术方案，至少具有如下一种或多种技术效果：

本发明提供的一种基于一体化开发平台的软件工件关系的挖掘方法，首先，从给定的软件工件中获取有效的显式引用；接着采用关键字匹配和基于事实的分析方法，从获取的有效的显式引用中识别出解决关系；然后，对于有效的显式引用中的其他引用，采用监督机器学习方法预测引用的非解决关系，最后根据识别出的解决关系和预测的非解决关系，挖掘软件工件关系。

由于本发明提供的方法，从给定的软件工件中获取有效的显式引用后，可以采用关键字匹配和基于事实的分析方法，识别出解决关系，从而可以使得识别出的解决关系具有较高的准确性；并且对于有效的显式引用中的其他引用，可以采用监督机器学习方法预测引用的非解决关系，也可以使得识别出的非解决关系具有较高的准确性，进而根据识别出的解决关系和预测的非解决关系，挖掘软件工件关系，故而提高了挖掘方法的准确性，并且本发明的方法适用于集成了缺陷存储库和源代码版本控制系统的一体化开发平台。此外，采用关键字匹配和基于事实的分析方法不涉及复杂的计算，采用机器学习方法构建预测模型来预测引用的非解决关系，可以提高效率。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种基于一体化开发平台的软件工件关系的挖掘方法的流程图；

图2为本发明实施例的整体框架图；

图3为本发明实施例的识别解决关系的流程图；

图4为本发明实施例中完整的修复三角的示意图；

图5为本发明实施例中缺失代码提交记录的示意图

图6为本发明实施例的缺失提交请求的示意图；

图7为本发明实施例的分析非解决关系的流程图；

图8为本发明实施例的构建连接图的算法的代码示意图。

具体实施方式

本发明的目的在于针对现有技术中的方法存在的准确性不高的技术问题，提供的一种基于一体化开发平台的软件工件关系的挖掘方法，通过识别出显式引用中的解决关系，识别其他引用中的非解决关系，进而挖掘软件工件之间的关系，从而达到提高挖掘的准确性的技术效果。

为实现上述技术效果，本发明的主要构思如下：

提供一种自动提取和分析一体化开发平台的软件工件之间关系的方法，先从GitHub页面提取所有的显式引用，过滤掉噪声后，识别缺陷报告、提交请求和来自显式引用的提交记录之间的“解决”关系，并恢复工件之间“解决”关系的缺失链接，再使用文本挖掘和机器学习技术分析剩余引用中的其他关系，最后基于识别出的解决关系和非解决关系，构建连接图。

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本实施例提供了一种基于一体化开发平台的软件工件关系的挖掘方法，请参见图1，该方法包括：

步骤S1：从给定的软件工件中获取有效的显式引用，其中，软件工件包括软件缺陷报告、代码库提交记录和提交请求。

具体来说，在软件开发过程中，会不断创建缺陷报告和代码更改提交记录等相互关联的工件，这些工件通常为软件开发和维护提供丰富的信息。软件工件关系可以是软件缺陷报告与代码更改提交记录之间的关系、软件缺陷报告与提交请求之间的关系。

在具体的实施过程中，给定软件缺陷报告或提交请求，则可以通过GitHubAPI V3识别所有引用的缩短链接，同时过滤掉其他存储库的链接。识别的In和Out引用分别记录在R_in和R_out中，此过程返回C_out和C_in，C_out和C_in中分别记录R_out和R_in中相应引用的内容，然后过滤噪声引用，从而可以获得有效的显式引用。

其中，GitHub提供了一个名为GitHub Flavored Markdown(简称GFM)的扩展Markdown，它支持开发人员轻松引用缺陷报告(issue)，提交请求(PR)和代码提交记录(commit)。需要说明的是，如果其他人引用了一个工件，那么在所引用的工件的时间轴上也会出现与该引用相对应的事件。因此，本发明的第一步是提取嵌入在这些工件的网页上的所有这些显式引用。就方向而言，引用分为两种类型，In和Out引用。In引用仅存在于缺陷报告或提交请求页面的“事件”列表中，该列表指示当前工件的其他位置，而没有详细信息。Out引用可以分散在工件的主体和注释中，表示对其他工件的引用，Out引用的详细内容可以直接从当前工件的Web页面获得，其将用于关系推断。

对于R_out中的每个引用，本发明实施方式只是提取引用的周围句子作为其内容；而对于R_in中的引用，需要跳转到引用当前工件的源工件，并遍历其主体和注释以搜索引用链接周围的内容。(如果源工件是提交请求，则内容还包括关联的代码提交记录的内容。)因此，此过程返回C_out和C_in。

在一种实施方式中，步骤S1具体包括：

从给定的软件工件中获取所有显式引用，对显式引用中的噪声进行过滤，获取有效的显式引用。

具体来说，在通常情况下，上面提取的引用太粗糙并且包括应该被过滤掉的各种噪声。本发明中主要关注三种主要类型的噪声引用，即虚假，无效和幻像引用。

·虚假引用意味着贡献者实际上并不打算引用任何内容。然而，他恰巧或错误地在文本中使用了语法“#ID”或“commit sha”，因此被GitHub识别为引用。

·无效引用是指不提供有效信息的引用。虽然它可以被视为这两个工件之间的联系，但它实际上揭示了它们之间非常微弱的关系。在本发明的方法中，只是将其视为无效引用，因为本发明主要关注更重要的关系。

·虚拟引用是工件和孤立的代码提交记录之间的引用。在GitHub中，存在一种工件引用既不能在任何提交请求下也不能在代码库中找到的代码提交记录的情况。换句话说，这些提交记录无法访问。

本发明总结了以下启发式方法，它们可以处理一些典型类型的“虚假”，“无效”和“幻象”引用。

(1)在“虚假”引用中提取一些经常出现的关键字，包括linux版本，cpu类型，源代码，十六进制代码。如果引用的内容(即引用链接周围的句子)包含这些关键字之一，本发明会将其视为“虚假”引用并将其删除。

(2)删除彼此相邻的引用，以“#1”和连续的数字开头。一些开发人员可能会列举以“#1，#2...#n”开头的问题。根据GFM语法，这些数字也将被视为引用。

(3)删除自我引用。这属于无效引用的第一种情况。可以通过检查目标和源缺陷报告(或提交请求)ID是否相同来检测它们。

(4)删除其内容仅提及另一个工件，但没有任何详细的解释的引用。将这些视为无效引用的第二种情况。

(5)通过简单地遵循上述定义来删除幻像引用。也就是说，删除既不与任何提交请求关联也不在代码库中的引用。通过过滤过程，可以拥有精炼的引用集。

通过上述方法，本发明可以更为准确地获取有效的显式引用，从而为后续的挖掘提供基础。

步骤S2：采用关键字匹配和基于事实的分析方法，从获取的有效的显式引用中识别出解决关系。

具体来说，获取的有效的显式可以是缺陷记录与关闭(包括合并)的提交请求或缺陷记录和代码库提交记录之间的一组引用，通过提取相应的内容集C_in和C_out，然后对C_in和C_out的语义分析来推断出引用的原因，本发明采用关键字匹配和基于事实的分析来识别“解决”关系。

在一种实施方式中，步骤S2具体包括：

步骤S2.1：当提交请求或代码库提交记录中是否包含预设关键字时，将提交请求与软件缺陷报告之间的引用关系、或代码库提交记录与软件缺陷报告之间的引用关系作为解决关系；

步骤S2.2：根据开发人员对软件缺陷报告的评论识别出解决关系。

具体来说，步骤S2.1是通过关键字匹配识别自动关闭的缺陷报告，这种自动关闭的缺陷报告意味着被解决了，属于“解决”关系。步骤S2.2则是根据开发人员对软件缺陷报告的评论进行识别。图3为本发明实施例的识别解决关系的流程图，包括步骤S2.1～S2.3。

在具体的实施过程中，步骤S2.1中，在GitHub中，贡献者可以在提交请求描述和提交记录信息中包括以下关键字{close，closing，fix，fixes，resolve，resolve，closed，fixed，resolved}，后跟“#issue id”。当此提交请求或提交记录合并到代码库的默认分支时，引用的缺陷报告将自动关闭。

步骤2.2是从开发人员的断言中识别。一些开发人员会通过在缺陷报告的时间线上提交他们的评论来明确断言哪些代码提交记录或提交请求修复了当前问题。对于上述场景，自动关闭事件将被一般的Out引用替换，并具有固定关系的明确指示。在本实施方式中，需要满足以下两个条件：(i)引用内容集内容的结构为预设的结构，例如通过扫描R_out中所有已过滤Out引用的内容集C_out，查找结构为“动词+介词/介词短语+#id”的短语，其中“动词”包括{closed,fixed,resolved,dealt,solved,addressed,implemented}，“介词或介词短语”包括{by,via,through,over,with,in,with(the)help of,in(the)favor of,with(the)favor of}，“#id”指向相应的提交请求或代码提交记录，此外，本发明还允许一些特殊格式，如“fixed，see#id”，“address，see#id”。(ii)基于时间线，该评论出现在缺陷报告被关闭前的预设时间内，包含上述短语的评论应该在当前缺陷报告的结束事件之前和不远处，预设时间可以根据经验获得。

满足以上两个条件的引用，会被确认为是“解决”关系引用。

在一种实施方式中，所述方法还包括步骤S2.3：

根据识别出的解决关系构建软件缺陷报告、代码库提交记录以及提交请求之间的三角关系。

具体来说，本发明将缺陷报告，解决此缺陷的代码库提交记录以及提供候选提交记录以解决此缺陷的提交请求链接在一起，形成“解决三角”结构。

由于缺陷报告和代码库提交记录之间或者缺陷报告与相应的提交请求之间缺少引用，这个“解决三角”并不总是那么明显，因此，所述方法还包括：

构建提交请求与代码库提交记录之间的映射关系，并通过映射关系消除三角关系中的虚假解决关系。

具体来说，对于通过GitHubAPI获得的一组精炼提交请求(S_p)，以及通过“gitlog-p”获得的一组代码库提交记录(S_c)，本发明可以通过下述方式来构建它们之间的映射。

(1)使用显式引用构建提交请求和代码库提交记录之间的映射。S_p中的一些提交请求可以在S_c中明确引用代码库提交记录来指示它们的映射关系；并且一些代码库提交记录也可以引用提交请求(或其关联的提交记录)来明确指示它们来自何处。通过文本挖掘检测这样的显式引用较易实现。本发明为它们建立联系，分别从S_p和S_c中删除它们。

(2)在没有显式引用但具有相同SHA的情况下(提交记录(commit)的sha值，唯一标识)，在提交请求关联的提交记录和代码库提交记录之间构建映射。对于剩余的S_p和S_c，对于每个提交请求p∈S_p，在S_c中查找p的所有提交记录的SHA。如果找到匹配的SHA，那么可以将S_c中相应的提交记录链接到p，并分别从S_c和S_p中删除它们。但显然，如果在S_c中找到p的所有提交记录的SHA，从而知道这个p直接合并到代码库中了。

(3)在没有相同SHA但是有一些关于提交请求关闭方式的提示的情况下，构建提交请求关联的提交记录和代码库提交记录之间的映射。现在在剩下的S_p和S_c中，在S_c中找不到每个提交请求p的提交记录SHA，这意味着它们可能被squash，rebase或cherry-pick到代码库中。在这种情况下，本发明实施方式将通过查找类似的代码更改来构建映射。

有时候，如果可以提供有关如何关闭或合并此提交请求的提示，则可能会降低映射计算成本。因此，对于S_p中的每个提交请求p，本发明检查结束事件及其周围的注释，以查找此类提示。

如果存在类似“rebase”(及其变体)的术语，本发明将其视为“将此提交请求中的代码提交记录单独rebase到默认分支”。假设p是在时间戳t_p创建的。然后，对于p的每次提交，从S_c中的提交中查找p的时间晚于t_p的消息。如果找到匹配的消息，将S_c中相应的提交链接到p，并分别从S_c和S_p中删除它们。使用类似的方法来处理“cherry-pick”的情况，然而，并非所有p中的提交记录都可以在S_c中找到。

如果存在类似“squash”(及其变体)的术语，将其视为“使用squash合并此提交请求中的所有代码提交记录。”。对于这种情况，人为地squashp中的所有代码提交记录，遵循“git log-p”的输出格式输出到c_p中。假设在时间戳t_p创建p，然后在S_c的提交记录中查找时间晚于t_p的c_p的更改摘要。当找到它时，将S_c中的代码提交记录与p链接，并分别从S_c和S_p中将它们删除。

(4)在没有相同的SHA或提交请求关闭方式的任何提示下，在提交请求关联的提交记录和代码库提交记录之间构建映射。最后，在最一般的情况下考虑剩余的S_p和S_c，这很少给出它们的映射关系的提示。

然后，对于S_p中的每个p，重复上述过程(3)，依次假设它被rebase，cherry-pick和squash。每当构建映射链接时，该过程就会中断，否则，继续采用下一个假定的合并方式(依次为rebase，cherry-pick和squash)。

通过以上四个步骤(1)～(4)，本发明可以使用S_c中的一些代码库提交记录来映射S_p中的一些提交请求，由此可以构建缺少的缺陷报告-提交请求或缺陷报告-代码提交记录的边。图5和图6分别为缺失代码提交记录、缺失提交请求的示意图，图4为本发明实施例中完整的修复三角的示意图。其中，显式的“解决”关系和恢复的缺失“解决”关系都是后续构建连接图的依据。

通过已确定的三角修复关系，能够消除步骤2.2中引入的虚假的“解决”关系，因为有一些缺陷报告的引用虽然被识别为“解决”关系，但是在代码库中实际找不到对应的代码提交记录，通过建立解决三角，可以消除类似的问题。换句话说，如果无法建立三角形关系，则说明是虚假解决关系。

步骤S3：对于有效的显式引用中的其他引用，采用监督机器学习方法预测引用的非解决关系，其中，其他引用为有效的显式引用中除具有解决关系的引用之外的引用，非解决关系为引用的原因。

具体来说，分析非解决的关系类型，流程图如图7所示。一般来说，除了“解析”之外，一个工件可能涉及另一个工件的原因很多。本发明主要关注三种常见类型，即重复，改进和依赖。

·重复表示两个工件描述相同的内容。

·改进表示在功能，性能，设计等方面，一个工件可以改进另一个工件。

·依赖表示一个工件依赖于另一个工件。

在一种实施方式中，步骤S3具体包括：

步骤S3.1：选取预设数量的具有非解决关系的引用作为训练样本，利用训练样本对构建的预测模型进行训练；

步骤S3.2：对有效的显式引用中的其他引用，采用经典的VSM模型结合TF-IDF方法进行特征提取，利用训练后的预测模型预测出非解决关系。

具体来说，请参见图7，为本发明实施例的分析非解决关系的流程图。(1)和(2)对应训练过程。剩余引用集是指通过步骤S1中提取的显式引用中除“解决”关系以外的引用，预测关系是指非解决引用。

本发明采用采用监督机器学习方法来预测引用的原因，具体的实现过程如下：

(1)训练样本。可以手动选择一些非解决引用，并将它们分为四类，即重复，改进，依赖和其他类，它们用作训练样本。

(2)特征提取。采用经典的VSM模型结合TF-IDF方法从每个引用的内容中提取特征。为了避免过多的特征，可以对每个符号执行“文本规范化”和“词干化”作为预处理，并使用贪心算法作为后续处理执行基于相关的特征选择(CFS)。然后利用训练样本对模型进行训练，得到预测模型。

(3)部署阶段。给定一个新的引用r_test及其内容c_test，通过获取有效的显式引用和识别解决关系后，过滤掉“解决”关系引用，通过步骤(2)的方式进行特征提取。然后训练上述已经规范化和词干化的样本，通过SVM分类器(图7中的预测模型)，对未知样本进行分类，预测相关引用的原因(此处“引用的原因”即为分类的类别)。

步骤S4：根据识别出的解决关系和预测的非解决关系，挖掘软件工件关系。

请参见图2，为本发明实施例的整体框架图，从软件存储仓库数据库和待分析的缺陷报告中，提取出显式引用，然后过滤噪声引用，则获得了有效的显式引用，然后识别出有效的显式引用的解决关系和其他引用的非解决关系，构建解决三角，接下来构建连接图，从而挖掘出软件工件之间的关系。

在一种实施方式中，步骤S4具体包括：

根据识别出的解决关系和预测的非解决关系，构建软件工件之间的连接图，并通过构建的连接图挖掘软件工件之间的关系。

具体实施过程中，可以将给定的缺陷报告b_c作为初始的中心，并在b_c和其他相关工件之间建立连接图。首先通过步骤S1至步骤S3来探索b_c周围的关系，即识别出解决关系和非解决关系。根据这些信息，可以更新连接图。接下来，对于与b_c相关的每个软件工件，继续探索和构建子连接图并将子图包含到整个子图中。直到迭代次数达到指定的最大深度(MAXDEPTH)，停止此探索，可以将MAX DEPTH设置为2。需要说明的是，以与b_c相关的每个工件为中心分别建立子连接图，然后将这些子连接图包含到以b_c为中心的子图中，即为整个子图。第一次迭代是以b_c为中心建立子连接图并入到整个子图中，第二次是以与b_c关联的工件为中心建立子连接图并入到整个子图中，递归，深度为2。

具体的连接图生成算法的部分代码参见图8，算法的输入是一个给定的中心点(缺陷报告)b_c和最大探索深度MAX_DEPTH，执行Main方法，首先初始化一个空的连接图G_b，然后调用BuildingGraph方法，BuildingGraph方法的参数是一个点集(工件集)A_c，整数值level和图G，此时进行第一次调用，传入的参数是A_c＝{b_c}，level＝MAX_DEPTH，G＝G_b。BuildingGraph方法首先判断level是否等于0，如果等于0，那么算法结束，代表遍历的深度，否则的话对于A_c中的每个工件a_i，执行步骤1到步骤4，获得工件a_i与周围工件的关联关系，将这些关系填充到图G中，并且将所有与a_i关联的工件的集合设置为B_c，最后再次调用BuildingGraph方法，传入的参数是A_c＝B_c，level＝level-1，G＝G。递归调用BuildingGraph方法的目的是探索所有b_c周边与之直接或间接关联的工件。

为了更清楚地说明本发明的实流程，下面通过示例予以详细介绍：

图7示出了识别出预测关系(“非解决”关系)以及基于预测关系和解决关系构建连接图的过程。其中，通过预测模型预测出非解决关系包括两个主要的过程：训练过程和部署过程，训练过程是通过预处理、特征提取、后置处理以及人工标注获取训练引用集，然后对模型进行训练得到预测模型，部署阶段是利用预测模型对剩余的引用集进行特征提取后，预测出非解决关系。最后，根据预测关系和解决关系构建连接图。需要说明的是，步骤1中提取了所有的显式引用，这其中有一部分是“解决”关系的引用，其余的部分是所谓的剩余引用，具体可以是“这个问题在某某缺陷报告中也提到过”。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明实施例进行各种改动和变型而不脱离本发明实施例的精神和范围。这样，倘若本发明实施例的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (7)

1.一种基于一体化开发平台的软件工件关系的挖掘方法，其特征在于，包括：

步骤S1：从给定的软件工件中获取有效的显式引用，其中，软件工件包括软件缺陷报告、代码库提交记录和提交请求；

步骤S2：采用关键字匹配和基于事实的分析方法，从获取的有效的显式引用中识别出解决关系；

步骤S3：对于有效的显式引用中的其他引用，采用监督机器学习方法预测引用的非解决关系，其中，其他引用为有效的显式引用中除具有解决关系的引用之外的引用，非解决关系为引用的原因；

步骤S4：根据识别出的解决关系和预测的非解决关系，挖掘软件工件关系。

2.如权利要求1所述的方法，其特征在于，步骤S1具体包括：

从给定的软件工件中获取所有显式引用，对显式引用中的噪声进行过滤，获取有效的显式引用。

3.如权利要求1所述的方法，其特征在于，步骤S2具体包括：

步骤S2.1：当提交请求或代码库提交记录中是否包含预设关键字时，将提交请求与软件缺陷报告之间的引用关系、或代码库提交记录与软件缺陷报告之间的引用关系作为解决关系；

步骤S2.2：根据开发人员对软件缺陷报告的评论识别出解决关系。

4.如权利要求3所述的方法，其特征在于，所述方法还包括步骤S2.3：

根据识别出的解决关系构建软件缺陷报告、代码库提交记录以及提交请求之间的三角关系。

5.如权利要求4所述的方法，其特征在于，所述方法还包括：

构建提交请求与代码库提交记录之间的映射关系，并通过映射关系消除三角关系中的虚假解决关系。

6.如权利要求1所述的方法，其特征在于，步骤S3具体包括：

步骤S3.1：选取预设数量的具有非解决关系的引用作为训练样本，利用训练样本对构建的预测模型进行训练；

步骤S3.2：对有效的显式引用中的其他引用，采用经典的VSM模型结合TF-IDF方法进行特征提取，利用训练后的预测模型预测出非解决关系。

7.如权利要求1所述的方法，其特征在于，步骤S4具体包括：

根据识别出的解决关系和预测的非解决关系，构建软件工件之间的连接图，并通过构建的连接图挖掘软件工件之间的关系。

Images