2015 IEEE/ACM 37th IEEE International Conference on Software Engineering Assert Use in GitHub Projects 周星宇.

Presentation on theme: "2015 IEEE/ACM 37th IEEE International Conference on Software Engineering Assert Use in GitHub Projects 周星宇."— Presentation transcript:

1 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering Assert Use in GitHub Projects 周星宇

2 Introduction 简单回顾了断言出现的历史。 断言的用途 使用断言的合理性 实证分析 运行时检查 提升易读性 自动验证
开发者更少犯错 更快隔离错误 实证分析 100个项目，69个使用断言，4.6%的方法包含断言 断言和bug密度的相关性 Call graph 应用领域

3 Research goal 研究断言在实践中的使用情况，尤其是和断言相关过程的输出结 果。 RQ1：断言与缺陷发现的相关性
RQ3：call graph中函数的网络位置与断言位置的相关性 RQ4：应用领域和断言的相关性

4 RQ1：断言与缺陷发现的相关性 基于Wiki-Python中的论断 断言以捕获bug为目标 程序员用于判断系统的内部状态的系统化方法
断言适用于发现错误的假设、接口的滥用 断言作为行内文档提升易读性

5 RQ2：断言与软件工程协作方面的相关性 参与度、经验、committer数量 协作是一个历史性研究课题 现代版本控制系统使得研究成本可接受

6 RQ3： call graph中函数的位置与断言所在位置的相关性
断言位置在主观上容易受软件构造和工作元素的影响 软件有很多属性和软件元素，大小、复杂度、内聚、耦合 Call graph是一个用于捕获程序中模块依赖关系的有效抽象方法 多态、继承等OO属性可能导致call graph不能正确运行->C项目 网络科学有大量代数方法从网络中心点的角色中获取数值化的度 量

7 RQ4：应用领域和断言的相关性 研究小组把收集的项目划分为普遍但不相关的类 从主观因素考虑，不同类别代码差异大，断言使用可能很不一样
该研究小组之前的研究中未发现应用领域和代码质量存在相关性

8 Related Work 断言使用情况 使用断言对软件质量的影响 Chalin，200-80%，85Eiffel Projects。
Jone，21 Projects，缩放，不易更改，前后置条件 自动生成的断言不能完全替代人工编写断言 本文扩展研究范围C/C++，过滤掉过高比例使用断言的项目，不针对只包含断言 的提交 使用断言对软件质量的影响 语法变异->代码范围 JML，Java断言库 内部系统无效状态 本文更细粒度专注于bug 规模更大

9 方法论-研究内容 剔除使用断言少于10处以及高于30000处的项目

10 方法论-数据收集 git log –U1 –w 无关代码 测试文件 Error、fix等关键字定义修复bug的提交
Assert关键字用于断言统计，分类器设计 抽取100个随机片段，验证分类器 统计数据分类-方法/开发者 call graph LLVM’s clang tool 读取函数名 Cscope database记录依赖关系 -U1下载commit补丁，-w输出新增代码的方法名 Gcc:gcc_assert/debug_assert

11 方法论-统计学方法 回归模型 线性回归 阈值回归-负二项式回归 逻辑回归 方差分析

12 RQ1：断言与缺陷发现的相关性 第一个断言为阈值，建立回归模型，进行逻辑回归
之后的阈值/计数调研哪些commit历史中至少有一个bug fix和新增 断言的方法 基于断言数计算缺陷数 准泊松分布

13 RQ1：断言与缺陷发现的相关性 结论： 数量模型影响不显著 以Linux和Mysql两个项目为例

14 RQ2：断言与软件工程协作方面的相关性 绘制箱图 将ownership验证应用于method级。
Experience统计开发者对每个方法贡献次数的中位数。

15 RQ3： call graph中函数的网络位置与断言位置的相关性
探索性研究 评估一个函数的网络中心是否和断言位置相关 基于网络中心度量和断言位置假设 出度、入度、中介中间性、枢纽值、权威性 权威值和枢纽值相关性在不同项目集中各不相同 开发者倾向于在枢纽值高的函数中加入断言。

16 RQ4：应用领域和断言的相关性 Applications、Code Analyzer、Database、Framework、Library和 Middleware六大类 以Applications为参照 限制代码行、开发者年龄和人数 在不同领域断言的使用没有明显关系

17 Threats Bug判定-使用commit中的信息，而不是bug数据库，希望聚焦于 由交互式编程引起的bug fix commit。
调用图-使用Cscope，不是绝对可靠 断言判定-基于字符串匹配，用户自定义的断言无法判定。 一般性因素-开发者在开源和商业项目中使用断言的方式不同，商 业系统一般有硬性规定，而本论文也不能给开源项目下定论，关 于领域的分类不客观。

18 Conclusions 断言对自动验证有很大价值，但是大部分开发者在实践中很少使 用，断言主要被用于快速检测和报告无效的系统状态。在这种条 件下，本文认为添加断言和缺陷的减少有相关性。 断言有助于提升代码质量，开发者对自己参与度高的方法更容易 添加断言。 文章支持了关于断言的民间观点：断言对软件质量存在有益影响， 在协作开发中有益。

19 Exception 希望验证断言是否能够更容易发现和修复真实的bug，而不是简 单的在研究中重新bug。
能在更深的层次上分类断言，在相关位置确定和创建有效的断言

20 谢谢