引用：L. Ponzanelli, S. Scalabrino, G. Bavota, A. Mocci, R. Oliveto, M.D. Penta, M. Lanza, “Supporting software developers with a holistic recommender system”, ICSE 2017, pp. 94-105, 2017.
摘要
推荐系统的职责是在编程任务期间为开发人员提供智能支持。这种支持包括从推荐程序实体到考虑相关的问答页面。然而，当前的推荐系统将对修改历史和开发者活动的环境分析限制在 IDE内部，没有考虑到开发者已经咨询和阅读过的内容，例如在 Web 浏览器执行的搜索。。鉴于许多编程任务的分面性质以及单个工件提供信息的不完整性，需要若干异构资源来获得开发人员完成任务所需的更广泛的描述。
我们介绍Libra，一个全面的推荐系统。通过将开发人员浏览过的资源构建成一个整体的元信息模型，分析它们的语义关系，同时使用专用的交互式导航图扩充Web浏览器，使得 Libra 能够支持搜索和导航所需信息。Libra的定量和定性评估提供的证据表明，对开发人员信息环境的全面分析确实可以为软件开发过程中的信息导航和检索提供全面的、环境有关的支持。
1.介绍
RSSE[1]提供了一份信息检索指南。它向开发者推荐相关制品，并且可以利用不同的信息源，例如，挖掘API文档和Q&A 站，从现有的代码库合成代码，提取视频教程的特定片段等。许多RSSE方法不考虑任务进行过程中的信息搜索的知识背景，相反它们依赖于从存储库中挖掘的历史信息，或者考虑那些在任务中被修改的元素。
开发人员经常在 上搜索完成任务所需的信息片段。按照迭代式方法，他们检查资源，直到达到一定的知识水平来解决给定任务。这个过程可以被描述为寻找、理解和关联信息的搜索循环。它也可以被看作是寻宝游戏，随着地图中的提示被逐渐揭开。人们搜索地图的当前区域以获得新的提示，解答谜题来开启新地图，最终找到宝藏。当前RSSE仅使用地图的一些小块（例如，仅知道开发者在IDE中做什么）指出“候选宝藏”（例如，Stack Overflow上的一个讨论版块）来快捷该过程。但是，地图的所有部分都是必不可少的。已有的地图是开发人员的知识背景，并通过他们仔细阅读新资源或修改现有代码时不断扩张。在我们的愿景中，推荐系统应该为开发人员提供持续的建议，指导他们的信息搜索过程，同时考虑他们正在进行的工作以及他们已经在阅读的内容。在当前背景下（开发人员已有的知识，或者说已展示的地图），推荐系统应及时向开发人员建议相关的制品。
我们建议使用LIBRA[2]，这是一个全面推荐系统，为开发人员提供Web浏览器中信息导航的实时支持。LIBRA在Web浏览器和IDE中监视开发人员的活动，以跟踪Web搜索结果，浏览页面以及开发人员编写和修改的代码。LIBRA通过考虑所有这些资源来模拟开发人员的知识背景，并构建其内容的整体元信息模型。LIBRA的分析并未将资源内容仅视为文本，而是考虑其异构组合，包括代码片段、XML、JSON等交换格式。通过全面分析知识上下文的内容，LIBRA通过考虑给定资源的突出性以及结果与收集的知识上下文的互补性，帮助开发人员从 络搜索中选择相关结果。我们通过两项不同的研究评估了LIBRA，以评估其在开发活动中的实用性及其在工业环境中的适用性。两项研究都表明，对开发人员信息环境的全面分析可以为开发过程中的信息导航和检索提供全面的，情境化的支持。
2.LIBRA
LIBRA是一个推荐系统，旨在扩展和集成两个主要的现代软件开发工具— IDE和Web浏览器，以支持信息搜索。
A. User Interface
Fig. 1. The LIBRA user interface
图1显示了Web浏览器中显示的LIBRA用户界面。它包括三个组件，提供导航搜索引擎的信息空间的功能。每当开发人员在浏览器中编写查询时， 页右侧会出现一个双轴气泡图（1）。每个气泡代表左侧结果列表（2）中的条目。将鼠标悬停在气泡上会突出显示结果列表中的相应条目，并淡化其他条目。开发人员可以通过单击结果列表中的相应条目或LIBRA图表中的相关气泡来访问搜索结果的URL。URL将在新的选项卡中被打开，同时使用新的上下文信息更新图表，访问的URL成为开发人员上下文的一部分，上下文还包括最近导航的所有资源以及她最近在IDE中编写的代码。该图通过可视化以下信息为导航信息空间提供了额外的支持：
气泡颜色：资源按域分组并分配特定颜色。图的底部包含一个交互式图例， 告结果集中找到的所有域。开发人员可以单击域以突出显示其结果，淡出其他域。
上下文互补性：y轴表示搜索结果相对于当前上下文提供的信息的互补性。资源的位置越高，它与开发人员的上下文的互补性越高，因此可以在扩大上下文或坚持与已经被仔细阅读的资源类似的资源之间做出决定。例如，在图1中，在youtube.com（a）上浏览的资源具有高互补性（但突出程度低）。
结果突出：x轴允许区分搜索引擎返回的结果。图表右侧的结果越多，其在结果集2中的突出程度就越高。开发人员可以使用此轴来避免超出范围的结果，或者其信息是更重要资源的子集的结果。例如，在raywenderlich.com（b）上浏览的资源具有很高的突出性（但互补性较低）。
气泡直径：它表示资源相对于整个结果集提供的信息量。 在10到25个像素之间的范围内，直径在最大信息含量值上标准化。 例如，x轴上的大红色（半）圆圈指的是vogella.com上的资源，提供比小圆圈中显示的其他资源（例如，黄色youtube.com圈子）更多的信息量。
开发人员可以利用上述功能来选择最适合信息搜索过程中下一步的资源。 LIBRA还提供了一个选项面板（3），开发人员可以在其中访问有关应用程序状态的基本信息，并管理可以免费跟踪的域的白名单（开发者上下文的一部分）。 LIBRA的示例已被公开。
B. Architecture
图2显示了LIBRA的体系结构，并使用两种类型的箭头来表示由LIBRA执行的两个不同阶段：实线箭头表示跟踪事件，而虚线箭头表示由开发人员与LIBRA的交互引起的事件。
Fig. 2. The LIBRA architecture.
LIBRA由三个主要组件组成：（1）IntelliJ IDEA集成开发环境的插件，用于跟踪修改和访问的源代码;（2）Google Chrome扩展程序，用于跟踪开发人员浏览的 页和扩充程序使其带有LIBRA用户界面的Google搜索结果 页，以及（3）托管LIBRA分析器及其数据的后端服务。 使用Google搜索引擎，IntelliJ IDEA和Google Chrome是我们为方便起见而采用的实践选择。
页跟踪器会跟踪开发人员打开的URL，并充当服务的“远程爬虫”。实际上，该组件不是要求跟踪服务抓取某个URL，而是将整个呈现的内容发送到Libra服务，以便可以将其解析，建模并存储为上下文资源。
与LIBRA交互的开发人员将被分配由Libra插件或Libra Extension生成的ID。两个组件都需要具有同步ID以标识同一用户：发送到服务的每个请求都需要在IDE Synchronizer和Web Browser Synchronizer之间进行检查，以在两端设置相同的会话ID（请参见图2中的双箭头）。该解决方案允许LIBRA在有或没有IDE的情况下工作。当且仅当打开的URL的域与选项面板中开发人员指定的白名单列表匹配时，跟踪服务才会执行其操作。此限制不适用于Web搜索跟踪器，它跟踪在LIBRA运行期间从Google搜索中打开的任何资源。 这可确保气泡图中可视化的资源与搜索结果列表中 告的资源相同。
与Libra交互：Web搜索跟踪器负责检测Google的结果页面，以便LIBRA知道开发人员何时点击结果。发生这种情况时，会在新选项卡中打开相应的URL，并将URL发送到跟踪服务以成为上下文资源的一部分。 然后，Web搜索跟踪器会通知Search Service创建和分析新的上下文图，并将结果发送到Context-Aware Visualization，以向开发人员显示更新的信息。同样，无论是从LIBRA的用户界面打开结果还是从IDE跟踪新代码，浏览器中的Context Aware Visualization和IDE中的Code Tracker都会通知Search Service。在这样做时，可视化总是更新到最后一个可用的上下文。
3.HOLISTIC APPROACH
我们详细介绍了LIBRA用于处理和分析 络搜索返回结果的方法。我们讨论如何解析和模拟制品中的信息，以及我们如何设计HoliRank，这是PageRank[3]的扩展，旨在以整体方式分析结果的互补性和突出性。
A. Content Parsing and Meta-Information Model
制品被发送到跟踪服务时，使用StORMeD[4]岛解析器解析内容，能够识别完整和不完整的多语言元素—例如，Java、JSON、XML、Stack Traces-自然语言段落，并将这些内容建模为允许访问和操作的异构抽象语法树（H-AST）。
在之前的工作中，我们开发了元信息系统的概念，允许对信息的特定方面进行建模。遵循相同的蓝图，我们设计了以下元信息来模拟LIBRA处理的每个资源的内容：
Types: 它表示资源中提到的Java类型集。我们认为所有H-AST节点都匹配引用类型（完全限定或简单名称）和基本类型（例如，int、double）。
Variable Declarations：与变量和类字段声明匹配的所有H-AST节点。
Method Declaration：与方法声明匹配的所有H-AST节点。
Method Invocations：方法调用匹配的所有H-AST节点以及调用方法的名称。
Identifiers：所有H-AST节点匹配可在任何提取的构造中访问的标识符（例如，完整方法和类声明）。
XML Elements: 所有H-AST节点都匹配XML元素，如单个标记（即<tagname />或<tagname>）或双标记（例如，<tagname> </ tagname>）。
JSON Members：与JSON成员匹配的所有H-AST节点（即“field”：element）。
Natural Language: 我们用纯文本信息补充元信息，例如可以重复用于计算的术语频率图，例如像tf-idf这样的文本相似性度量。
B. HoliRank: Holistic PageRank
PageRank算法识别链接页面图中的突出页面，例如万维 。为了计算页面 络中页面的相关性，PageRank模拟“随机冲浪者”的行为，即随机浏览 页的用户和“不断点击链接，从不返回最终感到无聊并从另一个随机页面开始“。
PageRank将表示页面之间的超链接的有向图G作为输入，并返回概率分布P，其中每个pi表示随机冲浪者访问页面i的概率。 与页面关联的概率表示其在 络中的中心性。
在我们的方法中，我们需要在资源图中计算资源的中心性。由于缺少像页面中的URL或链接之类的显式引用，因此无法重构显式链接，因此需要以不同方式量化两个资源之间的连接。具体来说，我们使用相似性图。诸如LexRank–[5]（基于PageRank的无监督摘要算法）之类的方法使用tf-idf[6]相似性图作为输入，其中当且仅当文本相似性高于给定阈值时，两个句子之间存在一条边。LexRank在相似性图表上运行PageRank，并选择具有较高中心性的句子来撰写摘要。
LexRank在相似性图上计算PageRank的方式可以用于LIBRA。与LexRank不同，图中的顶点必须是原始PageRank中的资源（搜索引擎返回的 页），而不是句子。由于上下文包括异构资源，即来自IDE的源代码、 页和搜索引擎返回的其他文档（例如，PDF文件），依靠纯文本相似性降低了可用元信息系统的丰富性。我们还需要考虑信息的异质性：LIBRA跟踪的资源提供文本信息，但也有用于估计资源之间连接的代码信息。我们设计了一个整体相似度函数来利用元信息系统提供的附加信息层，而不是像LexRank中那样处理纯文本相似性：LIBRA使用可变数量的元信息类型对每个资源进行建模，具体取决于它内容。
考虑两个资源Rx和Ry。 令Tx, y为资源之间的共享类型的元信息的集合，并且用
M(R, t)表示资源R的类型t的元信息。我们将相似性向量Vx, y定义为：
其中，向量Vx, y的每个元素vi表示两个齐次元信息之间的相似度值，范围属于[0,1]。 我们用向量V的平均值表示两个资源R1和R2之间的一般相似度：
它给出的值在[0,1]范围内。我们在PageRank算法中使用此相似性函数来计算资源的相似性图中资源的中心性。我们将此方法称为“holistic PageRank”或HoliRank。
C. Analyzing Context Resources
我们的方法基于度量上下文互补性，结果突出性和信息量。
上下文互补性测量资源在开发者当前上下文中提供的信息量。我们使用HoliRank来构建最近使用的上下文资源（最近在IDE中编写/修改的代码和最近导航的 页）的相似性图CG。LIBRA认为开发人员在过去四个小时内处理的是“最近”。这是一个可设置的参数。对于搜索引擎结果集中的每个资源R，我们通过将R添加到CG的顶点集来创建另外的相似性图CGR，并且对于CG中的每个顶点VCG，我们添加从R到VCR的边，其权重等于fsim (R,VCG）。对于每个图CGR，我们运行HoliRank来计算资源R的中心性，范围为[0,1]。图中R的中心性越高，上下文互补性越低：中心性越高意味着与上下文的许多资源的紧密关系，表明R的信息摄取量低，因为R类似于已经构成上下文的内容。我们将上下文互补定义为：
结果突出显示搜索引擎结果集中的显著结果。 即使由查询匹配的一组结果可能或多或少相关，但是不同制品提供的信息经常出现重叠。 例如，制品是关于特定主题的教程，而另一个制品解决了同一主题的编程问题。 如果结果与许多其他结果重叠，那么它的内容中更可能提供多样化的信息。 如果我们对结果集的相似性图进行建模，结果R的信息与RS中的其他结果的高重叠将导致图中R的更突出（中心）位置。 我们构建了包含结果集RS中的所有结果R的相似性图GRS。 我们使用HoliRank来估计图GRS中资源R的中心性：
信息数量总结了我们的元信息系统识别的“元素”的数量。 例如，对于自然语言元信息，我们考虑术语的总量（在文本预处理之后），我们将方法声明元信息识别的声明符的数量与由变量声明元信息识别的那些加起来， 计数信息元素允许区分具有相同大小但具有不同内容的两个资源。例如，考虑具有相同字符数量的两个资源R1和R2，以及在预处理之后相同的术语。 但是，R1仅提供文本，而R2提供文本和代码。 在这种情况下，我们认为R2的信息量高于R1的信息量。
4.结论
现代软件开发中的一项重要活动是获取信息。这些作品位于不同的地方，具有高度异质性。我们不是手动梳理通用搜索引擎的结果或听取目前提出的推荐系统的单色建议，而是通过开发一种基于元信息系统的全面方法解决问题，该方法能够处理异构性质的 络资源。我们的方法在名为LIBRA的工具中实现，可帮助开发人员与建议进行交互，并无缝地融入他们的工作流程。对天秤座的实证评估提供了证据，即对开发人员的信息环境进行全面分析可以为软件开发过程中的信息导航和检索提供整体的，情境化的支持。LIBRA可从 站http://libra.inf.usi.ch/下载试用。
参考文献
[1] M. Robillard, R. Walker, and T. Zimmermann, “Recommendation systemsfor software engineering,” IEEE Software, vol. 27, no. 4, pp. 80–86, 2010.
[2] http://libra.inf.usi.ch/
[3] S. Brin and L. Page, “The anatomy of a large-scale hypertextual web search engine,” in Proceedings of WWW 1998 (7th International Conference on World Wide Web). Elsevier Science Publishers B. V., 1998, pp. 107–117.
[4] L. Ponzanelli, G. Bavota, M. Di Penta, R. Oliveto, and M. Lanza, “Mining stackoverflow to turn the IDE into a self-confident programming prompter,” in Proceedings of MSR 2014 (11th Working Conference on Mining Software Repositories). ACM, 2014, pp. 102–111.
[5] G. Erkan and D. R. Radev, “Lexrank: Graph-based lexical centrality as salience in text summarization,” Journal of Artificial Intelligence Research, vol. 22, no. 1, pp. 457–479, 2004.
[6] C. Manning, P. Raghavan, and H. Schütze, Introduction to Information Retrieval. Cambridge University Press, 2008.
致谢
此文由南京大学软件学院2018级硕士袁洋洋翻译转述。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！