poi文档api_基于API知识的智能化软件开发支持彭鑫（复旦大学软件学院副院长、教授）...

文章整理自TiD2019质量竞争力大会 彭鑫(复旦大学软件学院副院长、教授) 《基于API知识的智能化软件开发支持》演讲 TiD2019质量竞争力大会邀请了复旦大学软件学院副院长彭鑫给参会者带来《基于API知识的智能化软件开发支持》的主题分享。  

我们在大量的文档和各种开发论坛和我们的通讯工具里我们分享了很多的知识，但其实很多的知识并没有在实际应用过程中得到收集和利用。即使我们通过检索的方式都不能很好的找到相关的知识，更不用说通过自动化的方式辅助我们的开发过程。所以当我们面对体系庞杂的软件开发知识，我们能否通过某种方式加以收集和利用，显得尤为重要。带着对 API相关开发问题的疑问，彭鑫开始了正式的主题分享。 为了便于说明和理解，彭鑫以围绕API作为切入点进行了详细说明。

API知识

API的类型有很多，包括标准的程序库、第三方软件包、还有操作系统及开发框架等所提供的软件开发接口。我们整个软件开发过程多个环节都涉及到API知识，在规划实践方案的时候，就会考虑到需要用什么API，应该选择哪一个API更合适。在使用API出现问题后，比如报错了，有一些API的问题或者异常性能问题等怎么调试解决这个问题，包括后期维护过程中，有没有随之升级，或者爆出严重的漏洞，我们怎么进行问题的解决。API的知识贯穿了软件开发功能很多不同的环节。比如API的用法，能提供什么功能，具有什么特性？API使用会发生哪些异常，包括出现漏洞和缺陷？API什么时候引入？例如，安卓有很多版本，相关API都是什么时候引入的，后续什么时候废弃或替换升级等等。理解API知识还需要大量的背景知识。我们大学里经过系统的计算机专业学习，背后很多的专业的知识，比如计算机系统结构和操作系统相关的、网络相关的，编程语言相关的，这些都是我们理解API功能和约束等知识的基础。此外，我们知道API之间存在依赖链。例如，在Java开发中我们所引入的第三方Jar包还可能依赖其他Jar包，从而构成很复杂的依赖链。 以上这些API相关知识可以从不同的来源获得。 例如，很多API库有标准的Javadoc文档，格式是非常规范的，给我们提供了基本的定义结构、功能和特性描述。我们还可以通过API实现和使用代码获取API约束和使用知识，通过通用知识图谱获得相关背景知识，通过构建脚本获取API库之间的依赖信息等。 这里展示的是软件开发问答网站 Stack Overflow上程序员问的三个问题，内容涉及如何找一个API来读取文件数据、如何比较两个API的区别、关于API的使用方式等。这三个问题确实都可以在API文档中找到答案，但程序员还是选择去提问，这说明API文档中的相关知识并没有得到有效利用。

API知识获取和利用的主要困难

既然我们文档里有那么多的知识，为什么我们还经常遇到API相关的问题并到处求助呢？这就涉及到我们在获取和利用API知识的时候所遇到的主要困难。 首先是因为我们要解决的、特定的问题所相关的知识散布在很多地方，而且是非常碎片化的。 你解决问题可能获得信息需要散布在好几个不同的文档里，你想找齐是非常困难的。 第二，我们 开发人员遇到问题跟API自身知识的表述是存在鸿沟的。 即使你有完整的文档库，你去搜不一定搜得到。 第三，这些知识是缺少有效性关联的。 我们人的思考，跟概念是有关联的，我们从1想到2，从2想到3。很多知识一环套一环的。

 

API知识库的构建及应用

我们希望构造一个API的知识库，主要内容包括两个部分， API知识图谱和API相关资源 。知识图谱，通过结构化的方式把很多API相关的知识组织起来。但是大量的知识内容来自各种各样的API文档。比如整个的代码片断，或者误用的案例，历史上有很多缺陷是因为API用错了导致的，我们通过加以整理，整个案例就都可以用做开发资源。还有各种问题的讨论，文本里噪音非常多，如果我们去解析它，效果就不是很好。但我们可以把整个问答当成开发资源，组织起来以后会基于API知识图谱加一个标注或者关联，就可以用来支撑我们各种各样的智能化的应用。比如API的推荐和API的使用辅助编码。你可以给一个查询，我们告诉你哪些满足你的需要。我们可以基于API的知识告诉你怎么用，包括API问题的回答，辅助代码的理解。

例如，对于辅助代码理解，可以把代码分为算法密集型、API密集型和业务逻辑型，其中API密集型代码的理解很大程度上可以基于API功能描述的组合来实现。对于API使用缺陷查找与修复，可以通过各种挖掘手段，对照文档里的知识来查找对应的使用缺陷。还有风险评估涉及到第三方的API库，我们发现很多软件第三方API库也像我们传统供应链一样一环套一环，我们称之为软件供应链。这些都是我们API智库的应用。   

API知识图谱的构建

API知识图谱是怎么构建的呢？ 分成这么几块： 首先从我们API文档中来的大量的是文本性的知识，我们可以抽取一部分的内容，另外抽取相关的概念和关系，加以融合之后得到我们API的知识图谱。而我们从开源库里收集到的代码，也可以收集到变更的案例，是作为我们的开发资源。修复代码里用另外的API修复。我们没有办法百分之百的理解API讨论中每一句话是什么意思，但是我们至少支持知道你在讨论什么API的哪个方面。   API知识图谱的构建我们再说一下，首先我们从API参考文档，从半结构化的信息抽取API的定义结构形成骨架，然后再附加各种描述性知识。我们可以进一步分析文档中的句子。这些句子有的谈论API的功能，有的谈论API的特性，有的谈论API的约束或者警告。这三类要通过句子进行理解，来支持API知识抽取。再进一步的API的教程，面向问题场景告诉你怎么使用相关的API，比如说蓝牙的功能有哪些API，有哪些教程讲这些事情。 对于API的理解，我们需要两块背景知识，一块是技术的背景知识，跟计算机网络有关的背景知识。还有一块是业务的背景知识，如果你的API和特定的业务领域有关，例如电信领域的就相对于业务的背景知识了。技术的背景知识是通用的，但是业务背景知识就比较困难了，例如电子商务等领域已经建立了自己的背景知识库那么就可以用于辅助API和代码的理解。

基于通用知识图谱的API描述性知识融合

API都有一个功能描述，一部分是通用概念，有一部分是跟计算机通用概念有关的，ADK、安卓等，可以建立起一个映射。把在计算机相关抽取到的文档中的概念和通用的概念进行一个链接，就能额外获得知识内容。 图中所示是安卓的API的知识图谱的片断，有API的实体和通用概念的链接。通常会从几个不同的方面做处理，骨架抽取是比较简单的，包括功能描述，特性描述和约束等等。 在抽取之后做深入的研究，比如功能描述，API也好，和大量的软件功能动词是功能描述很重要的元素。 我们常用动词不是很多的 ，比如调研过安卓的功能描述，动词经过归类之后不超过100种就能够覆盖大多数的功能动词。大量的功能可以从图片格式和音频的格式转化的，但是有几个同义词，把这些归类成一类的话，动词不超过一百种，所以完全可以基于动词描述模板规范化。另外从特性的描述也做了归纳和总结，有的针对API整体的描述，有一些读文件特别快，这么一个功能的特定描述，我们整理了很多模板进行抽取。还有约束，有的是参数的约束，有的是针对API使用的方式，这是细化的抽取。

 

API知识图谱应用

有了API图谱之后可以在以下几方面应用： 1

API的摘要

我们在解决具体问题的时候，我们需要相关的API，左边和右面是两个案例，红色的部分是我们输入的你们任务。左边的这个如何把一个特定的行号写到具体的文本文件里去？底下推荐出相应的方法，并且把文档里面跟你的功能实现特别相关的几个文本的内容摘出来。比如告诉你怎么寻找相应的行号。拿到这个行号针对你当时的开发任务，围绕你的本次开发任务需要来做一个精简的摘要。

 2

API的比较与选取

例如，开发人员希望了解 StringBuilder和StringBuffer的区别 ，我们可以基于知识图谱自动生成 API比较的结果，其中 涉及它们的共性(例如，都属于字符序列，都是可追加的字符串等)以及区别(例如一个是线程安全的另一个则不是)。还有一些句子直接推荐你什么时候用这个什么时候用另一个 API 。 3

API的问答

我们很多是关于警告的。有的是限定性的，什么时候抛出异常，警告的信息，我们可以抽取到我们API的知识图谱里去。这是一种约束的表达。基于这样的知识可以回答这样的问题，比如什么情况下会导致异常？这个问题本身会做概念的解析和识别，因为这句话会提到很多相关的概念，我们利用知识图谱查找相关的问题，给出相关的答案。  4

API误用模式挖掘与检测

软件项目的代码修改中有很多是跟缺陷修复有关的，我们通过代码提交说明中的关键字等手段识别缺陷修复相关的代码修改然后再比较修改前后的代码变化。如果改的是API使用方式，例如API的前置条件，或者整个API发生了替换，我就认为这是API使用方式上的问题，我们发现这种类似的模式特别多，如果出现一两次是偶然，不代表普遍意义上的API的误用。如果次数比较多，就是有意义的误用。我们还能进一步检测，我们API的参数设置是否正确？有多个类似的API你是不是选择最合适的？还有API的返回值是否进行了必要的反问值的判断。我们通过我们挖的模式找到了44个API误用相关的缺陷，我们都提交了相关的反馈，其中37个是性能缺陷、7个是空指针引用缺陷，目前已经有18个被确认并修复了。5

API知识与资源汇聚

我们做了一个项目，有一些开源的项目，比如说当时针对的是一个开源的Office文档接口POI，很多文档是缺失的，所以我们通过我们的知识图谱把各种资源汇聚在一起，比如说代码和问答，我们形成针对这个API库的我们生成之后的API文档，还发了相关的概念解释，还有汇聚到的代码和讨论等等。整体上构成了自动生成的完善的文档。 6

辅助代码理解

我们做代码推荐的时候，我们有一个代码推荐的工具，我们可以提供一些解释，我们以前做过试验，有时候我们推荐的是对的，但是用户说我怎么知道哪个是对的？我们需要通过知识图谱给一个解释。我们来辅助API的大脑的理解。我们提供解释，也可以为大脑的特征定位来匹配。传统的方法是信息检索准确率比较差。

第三方API库知识图谱

第三方的API的库的供应链风险， 通过调研，分析发现1.3万多个库被人用到，有78%的第三方库是很少被用到的，大量使用API库是很少的，包括单元测试、日志和Java核心库等。 23%的Java开源项目对第三方库的更新延迟在30天内，51%的Java开源项目对第三方库的更新延迟超过60天。另外32%的第三方库有严重的缺陷等。这就导致了很多问题，一个项目会依赖几十上百个第三方库，而很多是间接的。通过多种信息来源挖掘第三方库的关系，汇聚多方知识建设知识图谱，支持多种追诉分析目标：使用这些库的开源项目，他们是怎么样做升级的，代码做了什么修改和替换？都可以进入到知识库里来。在这样的第三方库的基础上，建立知识图谱的知识，多种追诉分析目标。包括缺陷预警和侧重点的分析等。

 

总结与展望

我们今天讲的是我们怎么样构建API知识库，包括主要来自API文档和知识图谱。对各种通过挖掘得到的API开发资源加一个语音标注。构成了我们整个的API知识库。在这个知识库的基础上，我们支撑各种应用，包括API推荐和辅助编码和API的问答等。 未来我们将会在精准和完整的API知识抽取和表示，基于知识的API开发资源聚集、给予任务上下文的API知识问答及资源推荐、基于API知识的代码精确理解及辅助生成等方面继续深入持续地做研究和探索。

大会简介

质量竞争力大会，英文名称TiD，是研发创新顶级峰会，由中关村智联软件服务业质量创新联盟主办，中国软件行业协会系统与软件过程改进分会、北京软件和信息服务业协会智能分会协办。TiD质量竞争力大会秉承追求行业高度(Top)、技术创新(innovation)、专业深度(Depth)的目标，致力于打造最具影响力的国内软件研发创新者顶级交流平台。

推 荐 阅 读

《自动的自动化测试智能化一站式API测试服务》--陈磊(新奥集团中台质量总监)

     《四两拨千斤-基于微创新的工程效能改进在大型软件企业的落地实践》--茹炳晟(Dell EMC 资深质量架构师)

《天猫双十一大促持续集成》--李程(天猫技术有限公司 测试开发专家)

《在游戏中学习系统思考，探秘心智模式》--秦可(中兴通讯 敏捷教练)

      点击“