软件分析的实例（examples of software analytics）在线视频

现在，我将展示一个关于代码搜索的软件分析的例子。

我们都知道，有时候编程不是一件容易的事。

开发人员经常想知道要写什么代码。

他们经常会遇到不熟悉的问题或者不熟悉的API。

在微软做的一个问卷调查中，很多人都提到

他们在学习API的时候会遇到问题。

另一方面，多年来的软件开发

生产了大量源代码。我们知道

很多大型的开源项目网站，如

GitHub、SourceForge、CodePlex等。

这些网站上有成百上千的

开源项目。一个软件公司也可以

生产大量源代码。

我们的愿景是搜索和复用之前

写的代码来帮助完成新的编程任务。

在微软亚洲研究院，我们开发了CodeHow。

它是一个在代码库中搜索可复用的代码的工具。

给定一个用户查询，CodeHow搜索

代码库并返回

能够回应查询请求的相关代码片段。

现在，CodeHow同时支持

自然语言查询和API查询。

我们已经收录了大约

26,000个从GitHub上下载的C#项目。

这些项目包含约830万个源代码文件。

给定一个.NET API，

CodeHow可以返回这个API的示例使用代码。

例如，

如果开发人员不知道如何使用API

来引入在Datatable类中定义的importrow这个API，她可以简单地

输入Datatable.importrow。然后CodeHow将返回

所有使用了这个API的代码。

让我们来看看首先返回的代码片段。

这个代码片段包含importrow这个API的用法，

其中还展示了这个开源项目的链接。

以及许可和源代码文件。

CodeHow还支持自然语言查询。

如果开发人员不知道如何完成一个编程任务，

她可以简单地

输入自由形式的查询请求，如怎么把一个图像保存

为jpg文件，如何导出为Excel？红黑树或者快速排序。

然后，CodeHow将返回能够回应查询请求的代码片段。

现在，我简要展示一下CodeHow是怎么响应自然语言的查询请求的。

基本上，CodeHow在检索代码时

会同时考虑文本的相似度

和API的相似度。对于文本的相似度，

CodeHow会提取在文本相似度方面能够

匹配查询请求的代码片段。CodeHow

把源代码作为纯文本来

来匹配文本的相似度。

CodeHow也会考虑API。

它获得与查询请求最有

可能相关的K个API。

然后，CodeHow提取包含API的代码片段。

CodeHow将构建一个扩展查询，其中同时包含

文本查询和API查询。

CodeHow基于扩展后的查询和代码片段

之间的相似度提取代码片段。

相似度的值使用这一页中展示的

扩展的布尔模型计算。

如果想了解更详细的信息，请参考我们在ASE 2015上发表的论文。

这幅图展示了CodeHow的总体结构。

目前，CodeHow运行在微软的Azure上。

我们下载了大量的开源项目并把它们保存在

Azure上。然后，我们使用Elastic Search来索引

这些开源代码。当开发人员遇到了问题时，

她可以发出一个查询请求。

CodeHow将会列出这个查询请求并进行代码检索。

因为原始的代码片段可能是冗长且不易阅读的。

所以CodeHow会进行程序切片

并把简短、可读的代码返回给开发人员。

CodeHow已经转换成了

可作为开发助手的Visual Studio的插件。

开发助手允许Visual Studio的用户

搜索可复用的代码。

这个消息是在2015年5月的Build 2015大会上发布的。

到目前为止，这个插件已经被下载了超过16万次。

你们可以访问这个链接来下载这个工具。

CodeHow集成在了

GitHub中，作为开发人员的辅助工具。

它已经在一些媒体上出现了，如MSDN的博客、

GitHub的博客，这些上面都有

关于在开发者辅助工具中集成GitHub的报道。

现在，我想举另一个关于软件分析的例子，

这个例子是关于崩溃报告分桶的。

尽管开发人员花费了巨大的努力

来提高软件质量，

发布的软件中仍然会有很多缺陷。

在使用操作系统、桌面应用

或者移动应用时，软件崩溃

是软件缺陷一种最致命的表现。你们也许看到过软件崩溃。

软件崩溃会严重影响用户体验。

有时还会对关键系统带来巨大的损失。

因此，崩溃性的缺陷通常会被给予更高的

优先级来解决。为了方便调试，有很多

崩溃报告系统，如Windows错误报告（WER）。

开发WER是为了在发生崩溃时

从用户那里自动收集崩溃报告。

这幅图展示了WER系统是如何工作的。

当用户的Windows平台中发生崩溃时，

如果用户允许，崩溃信息

会被自动发送给服务器。

然后，WER服务会检查重复的崩溃报告

并把它们分成桶。在理想情况下，这个系统

应该把由相同缺陷导致的崩溃报告

分在一组。WER会计算

每个桶中的崩溃报告的数量。

当这个数量足够多的时候，

就会生成一个缺陷报告并发送给开发人员以方便调试。

通常情况下，每天都会收到几百万个崩溃报告。

只要用户的Windows崩溃了，WER就会生成崩溃报告。

通常情况下，崩溃报告数据包括

崩溃时间、应用模块的名字、

应用模块的版本以及崩溃堆栈跟踪。

崩溃堆栈中包含崩溃时记录

的所有帧序列的列表。

在发出一个函数调用时，调用堆栈中的每一帧都包含

一个模块名称和一个函数名称。

这页中的表展示了一个崩溃堆栈跟踪的例子。

堆栈中有7个帧，其中最近

执行的函数在最上面，最近最少

执行的函数在最下面。

每个帧的序列的顺序表示

函数之间的调用关系。

WER对微软产品团队有很大价值。

在十年的运行中，

WER收集了数十亿崩溃报告。

这些崩溃报告帮助开发人员诊断问题。

为了将崩溃报告分桶，WER已经实施了500多次启发式探索。

这些启发式探索主要基于应用

名称和版本、模块名称和版本以及模块的偏移。

在理想情况下，分桶算法应该把

由相同的缺陷引发的崩溃报告放到一个

桶中。然而，在一些情境下，

WER分桶的启发式

算法可能会把由相同的缺陷

引发的崩溃报告分到多个桶中。

这就是所谓的二桶问题。

据报道，对于像PowerPoint 2010这样的产品，

约36%的崩溃报告都被分配到了第二个桶中了。

二桶问题会使得我们需要在

调试方面花费额外的努力，因为很多缺陷可能包含

由于相同的缺陷引发的崩溃报告。

为了提高分桶的准确度，

我们提出了重新分桶。

这是一个基于调用堆栈的相似度对崩溃报告进行聚类的工具。

为了计算两个调用堆栈之间的相似度，

我们提出了位置依赖模型（PDM）

这个新的相似度测量方法。

PDM基于两个调用堆栈中的函数数量

计算两个调用堆栈之间的相似度。

用户函数与顶层框架之间的距离

和匹配的函数之间的偏移距离。

如果想了解更多信息，请参考我们在ICSE 2012上发表的论文。

这页中的图展示了重新分桶的总体结构。

对于最新到达的崩溃报告，

重新分桶首先对它们进行预处理，提取

简化后的调用堆栈。然后，它使用PDM模型

计算调用堆栈之间的相似度。

最后，它使用层次化的聚类方法

把崩溃报告聚类成相应的桶。

我们使用从5个流行的微软产品中

收集的崩溃数据来评价重新分桶算法。

结果显示，重新分桶的性能是值得期待的。

这页中的图展示了

由重新分桶和WER产生的桶的数量。

为了保密起见，

表示桶的数量的标签被去掉了。

从图中我们可以看到，在应用了

重新分桶之后，桶的数量减少了。

例如，对于产品A，

重新分桶产生的桶的数量比WER产生的桶的数量减少了25%。

结果表明，重新分桶确实可以

减少二桶问题。

现在，我想举另一个软件分析的例子。这个例子是关于

交互式探索软件工程数据的。

为了进行软件分析，用户可能需要

了解数据库、数据挖掘、编程方法

或者与领域相关的查询语言。

虽然这些技术是有效的，

但是使用这些技术需要大量的知识和技能。

这些技术通常都是由数据科学家使用的。

像开发人员、市场人员、

经理、测试人员等普通用户，

想要亲自应用这些技术

快速地挖掘数据并

获得洞见是非常困难的。

这些方法有很高的进入壁垒，

会增加普通用户

挖掘数据的成本。我们相信，

为了帮助普通用户分析和理解

他们的数据，软件分析应当使用

更多的可视化分析技术。

为了方便普通用户进行数据挖掘，

我们开发了MetroEyes，它是一个为

交互式数据挖掘提供的可视化分析工具。

MetroEyes的基本概念已经被应用到

微软的PowerBI这个

商务智能工具中了。这个工具已经被重构了。

在MetroEyes中，数据被表示为一个可视化的对象，如

饼图中的块和条形图中的条。

数据操作能够通过

对可视化对象进行直接操作来实现。它提供了像

拖拽这样的少量广为人知的手势

来完成各种可视化对象交互

和支持不同类型的数据挖掘任务，

如数据过滤和数据切片。

在MetroEyes中，用户通过选择可视化对象来进行数据挖掘。

并且，把它拖拽到另一个对象中去。

本质上，这种操作是通过数据库的可视化查询

实现的。然后，这个查询可以被转换成标准的数据库查询，

如提取数据的SQL查询。

高层的数据挖掘任务，如过滤

比较和分类，可以由

这些可视化操作构成。

用户可以执行这些任务来

交互式地挖掘数据和回答与数据有关的问题。

这被认为是软件分析的一个典型任务。

GitHub项目的分析。

Github已经托管了约650万个项目。

在研究中，我们随机

从GitHub上选取了70万个项目。

我们收集了项目的元数据，包括项目的名称、

编程语言、所有者、创建日期和星级等。

这页中的表展示了GitHub项目数据

的一个样本。我们可以使用MetroEyes来回答

很多关于GitHub项目的问题。

例如，找出GitHub项目使用最多的

三种编程语言。

找出2014年创建的

星级最高的Java项目。

让我们来看一段简短的展示，了解MetroEyes

是怎样通过可视化操作来回答查询请求的。

除了刚才介绍的工作之外，微软亚洲研究院的软件分析团队

还开发了其他技术。

其中很多技术都成功地转移到了产品团队

并应用到了实践中。

例如，我们开发了一个克隆分析器，它可以检测

程序中的重复代码。

这个克隆分析器在Visual Studio 2012中发布了。

我们还开发了StackMine，

它可以帮助改进Windows的调试。我们还开发了

一个服务分析工具，它可以帮助减少

服务恢复的时间。

StackMine被部署到了

世界上的很多数据中心。所有这些例子证明了

软件分析技术在实践中的有用性。

还有很多软件分析的应用。

例如，缺陷预测基于历史缺陷数据

预测一个软件模块的缺陷倾向。

缺陷定位基于通过的和失败的

执行痕迹预测

缺陷的位置。

我们可以基于缺陷报告进行缺陷定位。

日志分析基于日志来帮助诊断问题。我们可以看到，

软件分析有很多应用。

软件分析技术可以被用来

提高软件开发的

效率和质量。

它对于解决很多软件工程问题都是很重要的。

所有这些方法都是基于对源代码、

缺陷报告、崩溃数据、度量数据等

软件数据的挖掘。我们可以使用

不同技术来挖掘这些数据，

如数据挖掘、机器学习、信息可视化

和大数据计算技术。

然后，我们可以从数据中提取

知识并使用这些知识来帮助

提高软件开发的效率和质量。

软件分析是软件工程领域中

一个活跃的研究主题。

你们会发现这个领域中有很多论文。

我只是展示了一些与这次课相关的论文。你们可以

从这些论文中找到更多信息。

总结一下，在这次课中，我简要介绍了软件分析的概念。

我还举了几个软件分析的例子，

包括代码搜索，错误报告分桶和

软件工程数据的交互式挖掘。我希望你们

会对软件分析的研究感兴趣。

让我们一起来做软件分析并努力做出大的影响。

如果你们有任何关于软件分析的问题和建议，

请随时与我联系。谢谢观看。