-
摘要:
软件开发者在开发过程遇到应用程序编程接口（application programming interface，API）使用问题时，通常希望能够得到有效的API使用模式建议，从而帮助其学习和使用. 传统的API推荐方法会挖掘和学习代码库中API的使用知识，然后给开发者推荐与上下文相关的API. 然而由于上下文信息表征不够充分，以及推荐列表中冗余项和同质化内容的出现影响了推荐性能. 针对这一问题，构建项目和方法与API的API层次调用图（API hierarchy call graph，AHCG）模型以更好地表达API上下文关系，充分利用API结构信息和语义信息来减少冗余项和降低同质化内容被推荐的可能性，进而提出基于上下文感知并面向多样性的API推荐（context-aware based API recommendation with diversity, CAPIRD）方法. 该方法中引入相关性度量和关联性度量，最大限度地保留相关结果，同时平衡已选API与候选API的关联性，以尽可能挖掘到合理的初选API列表. 最后结合最大边缘相关算法，在标准模式数据集上学习相关性和关联性的最佳权重组合，并进行多样性重排推荐. 在2210个项目构成的3类数据集上进行实验并验证推荐性能，实验结果表明，CAPIRD在基于上下文的API推荐场景下能够有效提高推荐性能. 在所有数据集的API推荐中，平均精度（mean average precision，MAP）指标平均提升值约9%，在Top-1的推荐中，成功率（success rate）指标平均提升约13%.
Abstract:When facing API usage problems during the development process, software developers usually hope to get effective suggestions on API usage patterns to help them learn and use. Traditional API recommendation methods mine the usage knowledge of APIs in the codebase, and then recommend context-sensitive APIs to developers. However, several aspects affect the performance of the recommendation, such as the insufficient representation of contextual information, the appearance of redundant and homogeneous contents in the recommendation list. Focus on those problems, we propose an approach named as context-aware based API recommendation with diversity (CAPIRD), in which we build an API hierarchy call graph (AHCG) model of projects, methods, and APIs to represent API contextual relationships better. According to AHCG model, we can fully use API structural and semantic information to reduce redundant and homogenous contents. In addition, the measurement of relevance and correlation parts are introduced into the approach, which are used to maximize the relevant results, while balancing the correlation of selected APIs and candidate APIs, so as to dig out a reasonable list of APIs. Finally, we reorder the above relevant and correlated results using the optimal weight combination to increase the diversity. The optimal weight is learned on the standard patterns datasets combined with the maximal marginal relevance algorithm. Experiments are implemented on 3 datasets, which are consisted of 2210 projects, to verify the recommendation performance of CAPIRD. The experimental results show that CAPIRD performs better in context-based scenarios of API usage recommendation. In detail, compared with the baseline approaches, the average improvement of MAP (mean average precision) is about 9%. In the Top-1 success rate, the average improvement is about 13%.
-
Keywords:
- API recommendation /
- API usage pattern /
- graph model /
- diversity recommendation /
- reordering
-
基于软件复用和模块化开发的原则，现代软件系统的开发通常需要使用外部库. 开发者基于一些基础库、第三方库或者一些常用框架，能够快速地构建编程环境、实现编程任务、提高开发效率. 有研究表明[1]，在超过5000个软件项目的研究中，45%的应用程序编程接口（application programming interface，API）是直接从第三方库导入的.
因此，在软件开发过程中，开发者常常面临API使用问题. 在不熟悉的编程任务面前，开发者可能不知道使用哪些API能对编程任务更有帮助. 除此之外，如果缺乏相关的编程经验，开发者也可能不了解一些API的具体使用方法. 在这些情况下，开发者可能会查阅官方帮助文档，或者通过代码开源平台和相关论坛查询、搜索代码示例，从而学习API的使用. 然而当前很多官方文档存在质量问题[2-3]，且通常只提供API的描述信息而不提供代码示例[4]. 利用一些非正式的平台或者论坛进行检索和学习也会面临许多障碍[5]，并且这些返回的搜索结果可能是错误的、不完整的[6]. 开发者需要花大量时间去筛选和测试才能找到自己需要的API及其使用示例.
近年来，研究者们提出了各种方法为开发者推荐合适的API及其使用模式，从而促进开发者对API的学习和使用. API使用的模式推荐方法通常是从大型代码库中挖掘API的使用模式，然后通过有显式或者无显式的查询匹配这些使用模式[7]，最终推荐符合条件的API元素或者代码片段.
API使用模式推荐的关键是API的预测与推荐. 主要有基于序列模式挖掘的方法、基于自然语言处理的方法以及基于机器学习的方法. 基于序列模式挖掘的方法主要是利用序列模式挖掘算法挖掘API调用序列[8-10]，根据API使用频率进行预测，但是得到的模式通常包含很多重复子序列和无关子项，造成结果的冗余，即存在模式爆炸问题[11]. 此后有研究人员提出使用图结构来表示API调用序列[12]，并利用N-Gram语言模型思想计算子图的生成概率，从而预测对应的API. 但是当上下文信息变得复杂时，子图的生成效率变低，也容易出现长距离依赖问题. 有研究人员提出基于神经网络的方法来解决自然语言处理的长依赖问题. 例如利用深度学习模型RNN学习API调用序列[13-14]，从而预测下一步API出现的概率. 也有利用图深度学习模型GCN融合拓扑信息和API文本属性[15]学习图结构的表示，从而预测潜在的API. 这些方法主要利用API上下文结构信息学习API的特征表示，然而API之间细粒度的关系表示还不够充分，导致难以区分API之间的差异性.
文献[8-15]方法在基于上下文的API推荐场景中，以当前正在编写程序的项目或者方法中的API调用信息作为上下文，然后利用上下文的结构信息或语义信息对API进行预测. 利用结构信息的方法通常结合API调用序列或者上下文结构进行分析，然后基于API使用频率对候选API进行预测. 利用语义信息的方法主要对上下文的语义特征进行分析，然后根据候选API与上下文的语义相似性进行预测，最后根据候选API预测值大小进行排序推荐. 然而这些方法形成的推荐列表，由于上下文信息考虑不充分，会导致推荐列表中冗余项和同质化内容的出现，影响推荐性能. 主要有3种情况出现：
1）基于API序列结构的方法通常只考虑API之间的调用关系，导致一些与上下文语义不相关的API也被预测和推荐. 例如，假定API元素A，B，C能够组成2组序列模式L1=（A,B）和L2=（A,C），结合上下文的API调用序列进行预测，当推荐A时，根据使用频率，B，C也将被预测成为候选API. 如果L1与上下文语义相关，那么C为冗余项. 当冗余项变得越来越多时，一些使用频率较高但与上下文语义无关的API因为预测值大而排在推荐列表前面，推荐性能受到影响.
2）基于上下文结构的方法通常会考虑上下文的语义关系而不考虑API之间的调用关系，导致推荐结果容易出现模式冗余. 例如，由1）中2组序列模式L1=（A,B）和L2=（A,C）可知，如果L1和L2都与上下文语义相关，那么将同时推荐L1和L2组成的API使用模式. 由于B，C不是有效的使用关系，同时推荐B，C容易造成模式冗余，其中，C为模式L1的冗余项，B为模式L2的冗余项. 这种情况造成一些不存在使用关系的API作为使用模式被推荐在列表中也会影响推荐性能.
3）当前基于语义信息的推荐方法通常考虑的是项目与API或者方法与API的语义关系，缺乏API之间细粒度关系的考量. 当推荐列表中存在能够实现相同功能的API时，且这些API之间具有类似的属性，那么API之间差异性小，由于不区分API之间的差异性，容易造成部分结果同质化. 当一些具有类似属性的同质化API也被推荐系统考虑而占用了推荐列表位置时，会影响推荐性能.
针对这3种情况，本文从不同粒度考虑API的使用关系，充分利用上下文结构和语义信息，对现有不同粒度的研究方法进行改进，使它们能够利用更多的特征信息，得到更好的推荐结果；然后再对这些方法推荐的相关结果配以关联性分析结果后进行重排，减少推荐列表中前排冗余项和同质项，从而增加推荐列表中有效API的比例，提高推荐准确率和平均精度. 本文以图模型为对象，提出一种基于上下文感知并面向多样性的API推荐方法， （context-aware based API recommendation with diversity, CAPIRD） .
本文的主要贡献有4点：
1） 提出一种名为AHC (GAPI hierarchy call graph)的API层次调用图模型，从不同粒度上表示API的上下文关系，为相关性和关联性的分析服务；
2） 基于AHCG模型分别构造项目上下文和方法上下文的协同信号，进而感知相似的API上下文，缩小候选API的范围，减少上下文冗余项的出现，并度量相关性；
3） 基于AHCG模型构建API关联图，考虑细粒度的API结构关系，挖掘已选API的关联模式，减少模式冗余项的产生，并度量关联性；
4） 提出一种相关性与关联性的线性组合算法，并从标准模式中学习最佳权重组合，对候选API进行重排推荐，降低推荐列表中同质化API出现的可能性，提高推荐结果的准确率.
1. 相关工作
研究人员提出了许多API推荐方法和工具，来帮助开发者搜索和学习API的使用. 根据API推荐场景，目前主要有2类方式，即有显式查询推荐和无显式查询的推荐[7].
1.1 有显式查询的API推荐
有显式查询方法主要是根据关键字或者自然语言显式地表达开发者的意图，然后进行代码或API的搜索，最终推荐相关的API使用模式. 例如，RACK[16]，NLP2API[17]通过自然语言查询Stack Overflow上Q&A中的API使用知识. DeepAPI[14]将用户查询作为源语言，API调用序列作为目标语言，利用RNN编码-解码器模型解决问题. CODEnn[18]将自然语言描述和代码片段嵌入到高维的向量空间，使用户可以通过自然语言查询相关的代码片段. BIKER[19]融合Stack Overflow上的Q&A和API文档来弥补自然语言和代码之间的词法和知识代沟. SSAPIR[20]将API描述信息和查询信息构建为同一向量空间模型，利用TF-IDF算法计算向量空间中每个词袋的语义特征，然后基于语义相似度匹配API使用模式. GeAPI[21]使用图嵌入技术学习API图的语义表示，根据用户查询返回相似的子图. PreMA[22]提取了API文档中的功能性词汇用于计算用户查询和功能语句的相似性. BRAID[23]利用开发者的反馈信息，通过主动学习和学习排序（LTR）技术，使得推荐结果更稳定.
1.2 无显式查询的API推荐
无显式查询方法主要是从API上下文中研究开发者的编程意图，从而挖掘或者预测相关的API信息. 一些经典的工具如MAPO[8]，UPMiner[9]，PAM[10]，分别通过序列挖掘算法、聚类算法和EM算法挖掘API调用序列并用于API推荐. 文献[24]通过将API使用对象和共现关系构建为关系网，将网络中相似对象的使用作为相似API使用模式. SALAD[25]使用隐马尔可夫模型学习API调用序列，从而根据上下文中的API调用序列预测下一步候选API被使用的概率. FOCUS[26]将客户端方法视为用户，将API调用视为物品，利用协同过滤算法推荐相似的API使用模式. HiRec[27]通过分析API调用之间的层次结构，利用层次推理模型预测可能匹配的API. APIRec-CST[28]利用门控图神经网络（GG-NNs）学习结构信息的向量表示，利用序列神经网络（如LSTM）学习文本信息的向量表示，连接GG-NNs和LSTM，然后对目标Hole位置的API进行预测. GAPI[15]融合API调用的结构信息和API的文本属性，利用图学习技术从API的调用关系中捕捉高阶协同信号，从而发现与API上下文相似的候选API.
2. 相关定义
API使用模式推荐示意如图1所示，假设开发者编写到光标处时遇到API使用问题，不知道调用哪些API或者怎么使用这些API才能完成当前客户端方法myWork中的剩余编程任务. 记开发者编程现场的上下文信息为Q. 相关定义为：
定义1. 实体. 表示遇到API使用问题时所涉及的研究对象，有3种，即项目实体、方法实体和API实体.
开发人员在编程环境中正在编写的项目称为活动项目，正在编写的客户端方法称为活动方法，活动方法所在项目即为活动项目.
定义2. 上下文信息. 用来刻画某状态下的实体关系和属性信息，用四元组Q=（E，V，R，T）来表示. 其中，E表示上下文中所研究的实体；V表示上下文中实体的属性；R表示实体间的关系；T表示时间，反映某一时刻编程现场的上下文信息.
定义3. 上下文相关性. 表示上下文信息与API存在逻辑关系，定义为R1={（Q,i）｜sim1（Q,i）≥λ1，i∈Ei}. 其中，Q表示上下文信息，i表示API实体，Ei表示API实体集合，λ1表示阈值，sim1表示逻辑推断函数.
定义4. API关联性. 表示API之间的逻辑联系，通过API实体之间的共同使用关系或属性信息标识，其定义为R2={（mi,mj）｜sim2（mi,mj）≥λ2，mi,mj∈Ei}，R2表示API实体mi和mj具有相似的使用关系或语义信息，mi和mj存在关联性. 其中，Ei表示API实体集合，λ2表示阈值，sim2表示相似性函数.
定义5. API层次调用图（ API hierarchy call graph，AHCG）. 定义GAHCG={V,E}，其中节点集合V有3种类型的节点，包括项目、方法和API；边集合E表示项目和方法，以及方法和API之间的层次关系. 项目节点包括语料库项目和客户端项目；方法节点表示项目中定义的方法声明；API节点表示方法中的API调用，其包括内置API调用、第三方API调用和本地方法调用.
3. 面向多样性的API推荐框架
基于开发者活动项目的上下文信息，本文提出CAPIRD，整体框架如图2所示. CAPIRD模型主要由4个模块组成：元数据结构提取模块、相关性分析模块、关联性分析模块和重排推荐模块. 元数据结构提取模块主要是从项目源码库中提取项目、方法与API的层次结构，并基于这些信息构建AHCG图；相关性分析模块主要从项目和方法粒度上，计算上下文的特征表示，然后基于特征相似性感知相似的上下文，进而推断与上下文相关API，并度量相关性；关联性分析模块从API的粒度上，构建API之间的细粒度使用关系，然后从中挖掘频繁使用模式作为API关联图以获得更充分的API结构关系，并从图中度量关联性；API多样性重排从多样性角度将相关性和关联性进行线性组合，提升推荐性能.
3.1 AHCG图模型构建
AHCG图用来表达API与项目和方法之间的层次关系，从而能够更好地利用元数据集中API的结构信息对客户端项目进行建模，并从不同粒度上表达API在项目中的结构特性.
利用静态分析工具解析每个项目的类文件信息，将提取的方法名称、方法参数、方法体、API名称、API参数作为元数据集. 对于给定项目元数据集，AHCG图的构建过程为：
1）确定图的项目节点集合P. 确定元数据集中涉及的项目文件，并对不同项目进行编号，添加到P中.
2）确定方法节点集合U，以及项目和方法的关系边E1. 从项目起始编号开始，获取项目所有类中定义的方法声明，然后对这些方法进行编号，添加到U中，最后再建立该项目和方法的关系边. 例如，项目p解析后提取了方法u，那么p和u存在一条边，即e1=（p,u），e1∈E1.
3）确定API节点集合I，以及方法和API的关系边E2. 从方法起始编号开始，依次提取方法中涉及的API调用. 然后判断该API是否存在，不存在，则添加新的API节点编号到I中；否则从I中取出已存在的API节点编号. 最后建立方法和API的关系边. 例如方法u中提取了API节点i，那么u和i存在一条边，即e2=（u,i），e2∈E2.
根据1）~3）步骤构建的结果示例如图3所示，节点Pi （i=0,1,2,3）表示项目节点，节点Uj （j=0,1,…,4）表示方法节点，节点Ik （k=1,2,…,7）表示API节点，关系边E1和E2都表示层次关系. E1表示P到U这一类边的集合，E2表示U到I这一类边的集合.
3.2 相关性分析
相关性分析模块主要是基于上下文相似性对API进行预测，并尽可能减少冗余项的出现. 上下文信息的分析包括活动项目上下文和活动方法上下文的分析.
2个项目的相似性可由项目特征项的集合进行计算[29]，因此可以根据活动项目上下文的特征集合感知相似的项目集合，从而缩小候选API搜索范围. 此外，为了给活动方法提供相关的API使用建议，还需要研究活动方法上下文的API使用信息.
基于AHCG的图模型可知，项目节点和方法节点这2类节点包含的API使用信息规模不同，因此针对这2类节点的上下文信息，分别使用不同的特征提取方法提取特征. 然后从相似项目集合中计算活动方法与目标API的相似性.
3.2.1 基于项目上下文的特征提取
项目上下文反映项目中的API使用情况，本文通过评估不同项目中API的被使用情况反映项目上下文的特征，利用TF-IDF算法进行计算. 其中，特征TF表示API在当前项目中的使用频率，特征IDF反映API在整个项目源码库中的普遍性.
从AHCG中的项目节点开始，通过层次遍历能够得到API节点集合. 给定项目的API节点集合p ={i1,i2,…,in}，API节点ik的特征TF计算如式（1）所示：
TFik=Tikn∑m=1Tim， (1) 其中n表示集合p中API节点的数量，Tik表示API节点ik的出现次数.
API节点ik的特征IDF计算如式（2）所示：
IDFik=log(|P|1+aik)， (2) 其中|P|表示AHCG中项目节点的数量，aik表示AHCG中使用了ik的项目节点数量.
在整个项目源码库的体系下，API节点ik在项目p中的被使用情况ϕik的计算公式为
ϕik=TFik×IDFik. (3) 给定项目集合p，那么p的特征可以用API被使用情况的向量表示，即{{\boldsymbol{\phi}} _p} = ({\phi _{{i_1}}},{\phi _{{i_2}}},…,{\phi _{{i_k}}},…).
3.2.2 基于方法上下文的特征提取
方法上下文反映了方法中的API使用情况，同时以方法为单位的程序在一定程度上隐含了代码的语义信息，因此考虑方法和API的文本属性应该能够增强上下文的语义表示. 图卷积神经网络（GCN）[30]利用图结构信息和节点属性信息，能够学习图的特征表示. 本文利用GCN进行方法上下文的特征提取，其网络结构主要由3部分组成：输入层、图卷积层和输出层.
1）输入层. AHCG图的结构信息、节点初始化特征表示为 {{\boldsymbol{e}}^0} ，如式（4）所示.
{{\boldsymbol{e}}^0} = Encode(x,{\varTheta ^{{\rm{in}}}}) \text{，} (4) 其中 x 代表节点文本属性信息，{\varTheta ^{{\rm{in}}}}是编码函数Encode(\cdot)待学习的参数， {{\boldsymbol{e}}^0} 是编码后的节点向量表示，分为方法u节点表示 {\boldsymbol{e}}_u^0 和API i节点表示 {\boldsymbol{e}}_i^0 .
2）图卷积层. 其主要目的是聚合邻居节点的协同信号，从而实现消息传递. 主要任务是协同信号的获取和节点向量的更新.
协同信号的获取公式为
{\boldsymbol{e}}_{N(u)}^k = \sum\limits_{v \in N(u)} {p \cdot \left({{\boldsymbol{W}}^k}{\boldsymbol{e}}_v^{k - 1} + {{\boldsymbol{b}}^k}\right)} \text{，} (5) 其中p = {\raise0.7ex\hbox{$1$} \mathord{\left/ {\vphantom {1 {\sqrt {|{N(u)}| \cdot |{N(v)}|} }}}\right.} \lower0.7ex\hbox{${\sqrt {|{N(u)}| \cdot |{N(v)}|} }$}}是信号强度系数， |{N(u)}| 和 |{N(v)}| 分别表示节点u和节点v的度， {N(u)} 表示AHCG中与节点 u 具有层次关联的邻居节点， {\boldsymbol{e}}_v^{k - 1} 表示k−1层节点v的特征表示，W和b是待学习的参数.
根据聚合函数的消息传递机制，AHCG中节点最新的特征表示通过与邻居节点的聚合更新得到，如式（6）所示：
{\boldsymbol{e}}_u^k = f\left({\boldsymbol{e}}_u^{k - 1},{\boldsymbol{e}}_{N(u)}^{k - 1}\right) \text{，} (6) 其中聚合函数 f( \cdot ) 使用ReLU函数实现.
3）输出层. 其获得方法节点 u 和API节点 i 的最终特征表示如式（7）所示. 通过线性转换层输出 k 层卷积层的节点表示，然后对API节点进行预测.
\left\{ \begin{gathered} {{\boldsymbol{z}}_u} = {{\boldsymbol{W}}_u}[concat({\boldsymbol{e}}_u^1,{\boldsymbol{e}}_u^2,…,{\boldsymbol{e}}_u^k)] + {{\boldsymbol{b}}_u}{\text{,}} \\ {{\boldsymbol{z}}_i} = {{\boldsymbol{W}}_i}[concat({\boldsymbol{e}}_i^1,{\boldsymbol{e}}_i^2,…,{\boldsymbol{e}}_i^k)] + {{\boldsymbol{b}}_i}, \\ \end{gathered} \right. (7) 其中连接函数 concat( \cdot ) 将每一层节点的特征表示顺序连接.
3.2.3 相关性度量
相关性度量的主要目的是根据上下文提取的不同粒度特征对目标API进行预测，预测值越大，则API与上下文越相关. 因此，定义函数context（·）作为相似性度量的计算方法，从而适应不同粒度的研究方法. 输入是上下文信息Q和目标API i，返回值是Q与i的相关性，如式（8）所示：
si{m_1}(Q,i) = context(Q,i) . (8) 若Q是项目上下文信息，context（·）采用缺失评分算法[31]实现API的预测并返回预测结果；若Q是方法上下文信息，根据式（7）中方法节点 u 和API节点 i 的向量内积进行预测，即sim(u,i) = {\boldsymbol{z}}_u^{\rm{T}}{{\boldsymbol{z}}_i}.
3.3 关联性分析
关联性分析模块的主要目的是从相似上下文中获取API关联信息，并分别从结构和语义上分析API之间的相似性. 从另一个角度看，相似API可以反映相似的上下文[32]，因此相似的上下文中有可能隐含相似API. 本文基于活动方法上下文和AHCG图模型构建API关联图，增强细粒度的API结构表征，并从中挖掘API的关联模式；再基于关联模式，分别从结构关系和语义信息上度量API之间的关联强度.
基于AHCG图模型，API关联性分析模块的分析对象是方法节点和API节点.
3.3.1 关系构建
基于方法特征的向量表示，利用余弦相似性计算活动方法与其他方法的相似性，将相似性值大于0的方法作为相似方法. 将这些相似方法中使用的API作为节点、共现关系作为边，构建API关联图. 如图4左图所示，节点I表示API，边表示2个API在方法中具有共同使用关系，边权重表示2个API在方法中的共现次数. 为了挖掘目标API在相似上下文中的关联程度，本文基于AHCG图模型将关联关系保存在图数据库中，如式（9）所示：
![]()
图 4 关联目标节点的子图挖掘示意图Figure 4. Illustration of subgraph mining for associated target nodesD = \{ {g_{{U_i}}} = \left({V_{{U_i}}},{E_{{U_i}}}\right)|i = 1,2,…,n\} \text{，} (9) 其中 {U_i} 为AHCG中第i个相似的方法节点， {g_{{U_i}}} 表示节点 {U_i} 构建的API关联图， {V_{{U_i}}} 和 {E_{{U_i}}} 分别表示 {U_i} 中的API节点和共现关系构成的边.
3.3.2 关联模式挖掘
基于AHCG图模型，本文将API之间关联关系的发现转化为频繁子图的挖掘. 为了避免图匹配过程的子图同构问题[33]和挖掘的模式出现冗余问题，本文锁定目标节点避免子图任意扩展，将挖掘的关联模式覆盖在目标节点关联的子图上避免冗余输出，进而提出关联目标节点的子图挖掘方法. 首先将目标节点作为初始节点，基于AGM算法[34]思想，通过添加新节点产生候选子图，为防止候选子图任意扩展，对目标节点的高阶邻居节点进行剪枝，使挖掘的子图作为目标节点关联的子图. 记录目标节点关联新节点的2阶子图的支持度，丢弃支持度不符合条件的候选2阶子图，针对图4（a）关联图的挖掘结果如图4右图所示.
具体的关联目标节点的子图挖掘算法如算法1所示，主要有4个步骤：
1）首先设定支持度阈值，然后从相似的数据集合中构建关联图数据库，将不同的API节点进行编号；
2）在目标节点上添加新节点进行子图扩展，对目标节点的高阶邻居进行剪枝，只保留与目标节点有直接关联关系的目标子图；
3）计算目标节点与新节点构成的2阶子图的支持度，将未达到阈值的子图丢弃；
4）将满足条件的2阶子图添加到目标子图上，当所有节点都被访问时，生成最终的关联目标节点的子图 d(i) ，其中i表示目标API节点.
最终，API关联子图d中包含了API之间各种可能的使用模式，可以为开发者展示更多可能性.
算法1. 关联目标节点的子图挖掘算法.
输入：上下文信息Q，API节点i，支持度minsup；
输出：节点i关联的子图G_i .
① getTargetSubgraph（Q, i, minsup）；
② let S = getSimilarDatas（Q）；
/* 获得相似的上 下文数据集 */ ③ let D, I = buildGraphDatabase（S）； /* 从相似数 据集中构建API关联图G，返回图数据库D 和已编号的API节点集合I */
④ let G = {V={},E={}}； /* 初始化目标子图 */
⑤ for k in I do /* 依次读取集合I中节点编号 */
⑥ if k not in G.v and e（i,k） in D then
⑦ g = {v={i,k},e=（i,k）} ；/* 获取2阶子图 */
⑧ if e（i,k） ≥ minsup then
⑨ G = G ∪ g； /* 子图扩展 */
⑩ else
⑪ 丢弃g；
⑫ end if
⑬ else
⑭ 剪枝；
⑮ end if
⑯ end for
⑰ return Gi.
3.3.3 关联性度量
关联性度量的主要目的是度量2个API之间的相似性，分别从结构关系和语义关系上进行度量. 关联性越强，说明2个API相似的可能性越大. 本文定义函数correlation（·）作为关联性度量的计算方法，从而融合不同类型关系表示的研究方法. 输入是2个API节点i和j，返回值是i和j的关联性，如式（10）所示：
si{m_2}(i,j) = correlation(i,j) . (10) 若度量API的结构关系，correlation（·）计算节点i与j的权重系数，由节点i和j的2阶子图的支持度与图数据库数量的比值得出；若度量API的语义关系，利用图嵌入技术[15]将图d中i节点的特征表示zi和节点j的特征表示zj进行内积，从而计算2个节点的语义相似性，即sim(i,j) = {\boldsymbol{z}}_i^{\rm{T}}{{\boldsymbol{z}}_j}.
3.4 API多样性重排推荐
API多样性重排推荐的目的是优化有效API在推荐列表中的排名，减少冗余项和同质化内容的产生，使得推荐结果在保障推荐性能的前提下具有更好的多样性.
根据最大边缘相关（MMR）算法[35]的思想，通过结合查询内容的相关性和推荐内容的新颖性能够增加推荐结果的多样性. 新颖性反映了推荐内容之间的差异性程度，若推荐内容之间差异性小容易造成内容同质化，即相同结构关系或功能属性的API同时被推荐. 适当调整一些同质化内容在推荐列表中的排名，能够改变推荐内容的多样性.
本文在保持上下文相关性的同时，协调推荐内容之间的差异性来增加推荐结果的多样性. 推荐内容之间的差异性可以通过API之间的关联性进行度量，调整相关性和关联性权重能够使推荐列表展示更多可能的情况. 因此，重排推荐的目标是找到合适的平衡参数，从而降低推荐列表中同质化内容出现的可能性，提升有效API被推荐的可能性. 相关性分析模块和关联性分析模块分别度量了上下文与API之间的相关性和与API的关联性. 利用式（11）之间将相关性和关联性进行线性组合来度量每个API被推荐的可能性：
MMR(Q,R) = \mathop {arg\max }\limits_{i \in R\backslash S}^N \left[\lambda si{m_1}(i,Q) - (1 - \lambda )\mathop {\max }\limits_{j \in S} si{m_2}(i,j)\right] \text{，} (11) 其中Q表示上下文信息，R表示候选API集合，S表示R中已被选择的API集合，R\S表示R中未被选择的API集合；1用于上下文信息和API之间相关性的度量，用于API之间关联性的度量，参数 \lambda 用来度量sim1和sim2的权重.
根据式（11），当参数 \lambda =1时，MMR表示标准的相关性API推荐结果；当参数 \lambda =0时，MMR表示最大的多样性推荐结果. 这些API推荐结果是一种线性组合，本文利用算法2所示方法从标准模式的训练数据集中获取能够平衡相关性和关联性的最佳参数.
算法2. Top-N参数优化算法.
输入：上下文信息Q，API候选集合R；
输出：Top-N（N=1,5,10,15,20）的最佳参数topNLambdas.
① getTopNOptimumParameters（Q, R, N）；
② let topNLambdas = 1；
③ for i = 0 to numIter do
④ maxEvalScore = 0；
⑤ maxLambda = 0；
⑥ for lambda = 1 to 0 by step = −0.1 do
/* 使用最新的采样参数lambda进行多 样性重排序并评价输出结果 */
⑦ score = evaluate（lambda；MMR（Q,R））；
⑧ if score > maxEvalScore then
⑨ maxEvalScore = score；
⑩ maxLambda = lambda；
⑪ end if
⑫ end for
⑬ topNLambdas = maxLambda；
⑭ end for
⑮ return topNLambdas.
给定训练数据集，首先计算相关性条件下的性能指标，并以该指标作为该训练集的基准. 然后结合API多样性重排算法计算不同参数下Top-N的评价指标，迭代计算每一次参数采样的评分，选择评分最优时Top-N取得的参数作为该数据集的最佳参数.
4. 实验与结果
为了验证所提API推荐方法的有效性，本文使用真实的软件项目模拟开发者的编程场景，并在3个不同的数据集上进行实验验证，且与方法FOCUS和GAPI进行对比实验.
本文实验的硬件和系统环境为Intel Xeon Gold 6148处理器、256.0 GB RAM、Nvidia V100 GPU的Linux 64位服务器；Intel® CoreTM i7-10700 2.90 GHz处理器、16.0 GB RAM的Windows 10 64位操作系统；使用的软件环境有JDK 1.8，Python3，PyTorch等.
4.1 数据集
本文采用文献[26]中所使用的开源数据集，其中数据集SHL是从Github软件遗产存储库中任意提取的610个Java项目；数据集SHS是在SHL中筛选出的200个最小项目；数据集MV是从Maven中央仓库中提取的1600个JAR项目，且不同版本的同一JAR项目只保留其中一个版本.
基于原始数据集，首先解析项目源码库构建元数据集，并从中构建AHCG模型，提取初始特征. 表1详细统计了上述3个数据集的相关信息，包括用于上下文模型输入的项目特征和方法特征. 其中项目特征指每个项目中API的TF-IDF特征，由于每个项目的API不同，本文统计了每个项目平均调用的API数作为该数据集的平均项目特征数. 方法特征采用文献[15]的方法，利用驼峰式拆分法将方法名称和API名称拆分为单词序列并作为节点的文本属性，这些单词在相同的向量空间中进行编码和对齐，方法节点的特征维度与单词数有关，因此统计数据集中不同单词数作为方法特征数.
表 1 实验元数据集统计数据Table 1. Meta Datasets Statistics for Experiments数据集 项目节点数 方法节点数 API节点数 层次关系数 关联关系数 项目平均特征数 方法特征数 SHS 200 15531 20866 77168 263819 308 5351 SHL 610 1032888 643162 5243380 19044976 6902 30576 MV 1600 111732 194965 1638360 12338006 954 30442 4.2 实验设置
为了评价本文方法的有效性并与其他方法形成对比，遵循前人的研究方法对实验进行离线评估. 实验将软件项目中的部分代码抽取出来，从而模拟开发者编程现场及API上下文的使用情况. 具体规则是：将项目节点P下的方法节点U按照编号顺序排成数组，然后按照不同比例划分为训练集和测试集. 测试集中每个方法节点下的API节点按照编号顺序排成数组，然后保留前4个API节点来模拟开发者已完成的代码，剩余的API节点作为该测试方法的标准数据，用以验证在当前开发情景下的推荐性能.本文使用10折交叉验证法，将数据集划分成10份. 每一份进行1轮训练与验证，并且每一轮验证的时候，将其中9份数据作为训练集，1份作为测试集. 最后取这10轮测试结果的平均值作为该数据集的最终实验结果.
4.3 评价指标
API使用模式推荐场景中，一般通过Top-N的API排名情况评价推荐结果的有效性. 本文使用成功率（S@k），精确度（P@k），召回率（R@k）和平均精度（MAP）来评价方法在Top-N上的推荐性能. 给定测试集合M，其中的测试项表示方法节点，用来模拟当开发者遇到API使用问题时，给该方法节点对应的方法声明提供API使用建议，推荐列表中将包含开发者接下来可能调用的API. 设RECk（q）表示本文CAPIRD模型在一个测试项q中输出Top-N的API推荐结果集合，GT（q）表示一个测试项q的标准API集合.
S@k反映测试集预测成功的比例.
S@k = \frac{\mathop{count}\limits_{{q \in M}}\left(|GT(q) \cap RE{C_k}(q)| \gt 0\right)}{{|M|}} \text{，} (12) 其中count表示满足条件的测试项数量.
P@k 反映在推荐列表中有效API的占有比例.
P@k = \frac{{|GT(q) \cap RE{C_k}(q)|}}{k} . (13) R@k 反映推荐列表中有效API的数量在标准列表中的比例.
R@k = \frac{{|GT(q) \cap RE{C_k}(q)|}}{{|GT(q)|}} . (14) MAP的计算公式为
MAP = \frac{{\displaystyle\sum_{q \in M} {\displaystyle\sum_{k = 1}^N {(R@(k) - R@(k - 1))P@(k)} } }}{{|M|}} . (15) 4.4 基线方法
为了更好地评价本文方法，设计了2个对比实验，分别与相同场景下的2个基线方法进行比较.
1） FOCUS. FOCUS发表于2019年，是近3年高被引用的方法. FOCUS基于项目上下文，使用协同过滤技术挖掘并推荐API使用模式. 它将方法声明视为用户，将API调用视为物品. 因此，FOCUS能够推荐相似项目中类似的API使用模式，从而缩小搜索范围，减少冗余.
2） GAPI. GAPI发表于2021年，是目前公开文献中在相同实验数据集下实验效果最好的方法. GAPI是一种基于方法上下文和GNN技术的API使用模式推荐方法. 它利用项目中方法与API的交互关系，融合API文本属性，从拓扑网络上学习API的Embedding表示，从而给相似的方法推荐相似的API使用模式.
4.5 实验结果分析
从推荐性能和多样性表现2个方面进行实验设计，针对提出的2个研究问题，依次进行实验验证与分析.
问题1：本文CAPIRD模型在API推荐性能上表现如何.
为了检验CAPIRD在API推荐上的效果，本文在3个数据集上分别比较Top-N推荐结果在不同指标上的性能表现. 实验前，对比实验设置了相同的实验环境；实验时，针对不同类型上下文的基线方法FOCUS和GAPI，在CAPIRD相关性分析中实现不同类型基线方法的相关性计算，计算结果作为基线各自的相关性分析结果，并将该结果作为后续重排模块的参数优化基准. 然后再融合CAPIRD方法的关联性推荐和重排推荐，最终将推荐结果分别记为CAPIRD-FOCUS和CAPIRD-GAPI. 根据最终结果验证CAPIRD融合基线方法在API多样性推荐上的有效性. 在3个数据集上S@k和MAP的实验结果分别如表2~4所示.
表 2 SHS数据集上S@k和MAP对比结果Table 2. Comparison Result of S@k and MAP on SHS Data Set方法 S@1 S@5 S@10 S@20 MAP FOCUS 0.195 0.255 0.310 0.355 0.0188 CAPIRD-FOCUS
（本文）0.215 0.280 0.315 0.360 0.0216 GAPI 0.377 0.692 0.822 0.910 0.2924 CAPIRD-GAPI
（本文）0.577 0.813 0.886 0.973 0.3709 表 3 SHL数据集上S@k和MAP对比结果Table 3. Comparison Results of S@k and MAP on SHL Data Set方法 S@1 S@5 S@10 S@20 MAP FOCUS 0.302 0.389 0.420 0.456 0.0699 CAPIRD-FOCUS
（本文）0.323 0.402 0.425 0.467 0.0750 GAPI 0.493 0.799 0.896 0.951 0.3531 CAPIRD-GAPI
（本文）0.519 0.825 0.912 0.960 0.3610 表 4 MV数据集上S@k和MAP对比结果Table 4. Comparison Results of S@k and MAP on MV Data Set方法 S@1 S@5 S@10 S@20 MAP FOCUS 0.670 0.803 0.849 0.885 0.2674 CAPIRD-FOCUS
（本文）0.698 0.808 0.856 0.888 0.2755 GAPI 0.574 0.851 0.949 0.971 0.3971 CAPIRD-GAPI
（本文）0.578 0.854 0.948 0.977 0.3973 由表2~4结果中的MAP指标可以看出，CAPIRD在MAP的表现明显优于基线方法. 尤其是在SHS数据集上，在GAPI方法的基础上融合本文方法后，MAP由0.2924提升至0.3709，其推荐的平均精度提升约27%，在S@1 上由0.377提升至0.577，提升了约53%. 而在数据集MV上相对来说并不太显著，尤其是在以图学习模型为基础的GAPI上MAP及S@k 上提升相对较小. 这是因为随着数据量的增加，图学习机制作用显著，能够捕捉更多高阶协同信号，使得API推荐的多样性也增加. 而融合本文方法依然有小幅度提升，说明CAPIRD依然能够在保持原有多样性推荐结果的基础上，通过增加候选结果的差异性，使得推荐性能较原推荐性能有所提升. 在以传统协同过滤算法为基础的FOCUS上融合CAPIRD后的MAP提升在3%~15%，在大数据集上相对稳定. 因此，在3类不同的数据集上，本文CAPIRD模型在MAP指标上都得到了有效提升.
在实际的开发场景中，假设开发人员遇到API使用问题，当系统为其提供合适的API推荐列表时，那么开发人员更希望列表中靠前的API是对其有帮助的. 为了体现CAPIRD模型在这种场景中的推荐性能优势，需要分析S@1 和S@5，同时结合S@20 的成功率和MAP，分析模型的有效性.
由表2~4所示，CAPIRD模型在S@1 和S@5 相比S@20 具有显著效果. 在S@1 上，CAPIRD模型在所有数据集上平均提升约13%，说明第1个推荐的API与上下文最相关且又能够区别于其他已使用的API，因此也更可能是开发者在当前编程场景下想使用的API. S@5在所有数据集上平均提升约6%，其中CAPIRD在SHS数据集和基线方法GAPI比，S@5由0.692提升到0.813，提升约17.5%.
在S@20上，所有数据集相差不大，平均提升仅约2%，说明在Top-20推荐列表中，CAPIRD模型推荐的API与基线方法推荐的API差异不大，而结合CAPIRD改变了原有推荐结果的排序，在所有数据集的MAP指标上平均提升约9%. 说明Top-20推荐列表中有效API的排名得到提升，达到本文多样性重排推荐的预期. 因此，CAPIRD模型在API使用模式推荐场景中能够有效提高S@k，同时提高有效API在推荐列表中的排名.
问题2：CAPIRD模型中决定相关性和关联性推荐所占比重的参数对结果的影响如何.
在API多样性重排模块，本文利用MMR算法将相关性和关联性进行线性组合. 以方法CAPIRD-FOCUS为例，当参数 \lambda = 1 时，方法CAPIRD-FOCUS与基线方法FOCUS的结果是一样的，因为此时关联性度量的权重为0. 实验通过调整参数 \lambda ，使得关联度的权重发生变化，观察在不同参数\lambda 下模型的表现能力. 采用等间距的控制重排采样样本调节参数 \lambda ，观察MAP在不同参数\lambda 下的影响. MAP在不同数据集上的变化趋势如图5~7所示.
图5~7中，横轴表示参数 \lambda 的取值，纵轴表示该数据集上的MAP. 实线表示基线方法，由于不需要进行重排，因此基线的曲线不发生变化. 虚线表示增加重排后的结果，在3个不同数据集上其对应曲线都发生了变化.
图5~7中，虚线对应曲线整体上都表现出了类似的变化趋势，即随着 \lambda 的增大，对应的MAP值整体呈现先增后减的趋势. 虚线对应曲线位于实线对应曲线上方的部分表示增加重排后的MAP优于基线方法的MAP. 由图5~7中的6个曲线图可以看出，MAP在这个部分能够达到某个峰值，该峰值对应 \lambda 的值为该样本空间内的最佳参数. 例如在图5(b)的曲线图中， \lambda 取值在0.7~0.8之间时，MAP的值达到峰值. 说明 \lambda 在该区间内，关联性的度量发挥了最大作用.
当\lambda 发生变化即关联性的权重发生变化，MAP也发生变化，说明推荐列表中候选API的排名也发生了变化. 进一步观察3类数据集最佳参数的取值，发现随着测试集数据量的增加，达到最佳参数的取值越接近1，说明数据量越大，要达到MAP最优时的关联性权重越小. 这是由于数据量变大时，API之间关联性的差异性变小，使得MAP提升的表现并不明显，但是推荐结果仍发生变化.
综合以上分析，本文提出的CAPIRD模型，能够通过关联性分析增加候选API的多样性，同时也能够保证推荐结果的有效性，提高推荐性能.
5. 结 论
本文为了提高API推荐性能，提出了基于上下文感知并面向多样性的API推荐方法CAPIRD. CAPIRD是一种结合上下文相关性和API关联性的推荐方法. 通过相关性分析，发现上下文相关API，然后度量相关性值；通过关联性分析，挖掘API的关联模式，发现与目标API关联的其他API，然后度量关联性值；最后利用MMR算法线性组合相关性和关联性，协调纯相关API与纯关联API的比重，增加候选API中的差异性，提高推荐性能.
采用3个数据集进行验证实验，在与2个基线方法的对比实验中，CAPIRD在MAP，S@1，S@5都有提升，其中在MAP的平均提升率约为9%，S@1的平均提升率约13%. 实验结果充分表明，CAPIRD在API使用模式推荐场景中具有更好的表现.
CAPIRD利用的上下文信息有限，如何更充分地利用上下文信息来推断开发者的编程意图，是未来工作需要探索和思考的.
作者贡献声明： 赖宝强负责论文方法的设计与实现，并撰写论文；李征负责论文整体结构的审核；赵瑞莲负责论文的指导与校对；郭俊霞提供方法和实验指导，并修改和审核论文.
-
![]()
图 4 关联目标节点的子图挖掘示意图
Figure 4. Illustration of subgraph mining for associated target nodes
表 1 实验元数据集统计数据
Table 1 Meta Datasets Statistics for Experiments
数据集 项目节点数 方法节点数 API节点数 层次关系数 关联关系数 项目平均特征数 方法特征数 SHS 200 15531 20866 77168 263819 308 5351 SHL 610 1032888 643162 5243380 19044976 6902 30576 MV 1600 111732 194965 1638360 12338006 954 30442 
下载: 导出CSV
表 2 SHS数据集上S@k和MAP对比结果
Table 2 Comparison Result of S@k and MAP on SHS Data Set
方法 S@1 S@5 S@10 S@20 MAP FOCUS 0.195 0.255 0.310 0.355 0.0188 CAPIRD-FOCUS
（本文）0.215 0.280 0.315 0.360 0.0216 GAPI 0.377 0.692 0.822 0.910 0.2924 CAPIRD-GAPI
（本文）0.577 0.813 0.886 0.973 0.3709
下载: 导出CSV
表 3 SHL数据集上S@k和MAP对比结果
Table 3 Comparison Results of S@k and MAP on SHL Data Set
方法 S@1 S@5 S@10 S@20 MAP FOCUS 0.302 0.389 0.420 0.456 0.0699 CAPIRD-FOCUS
（本文）0.323 0.402 0.425 0.467 0.0750 GAPI 0.493 0.799 0.896 0.951 0.3531 CAPIRD-GAPI
（本文）0.519 0.825 0.912 0.960 0.3610
下载: 导出CSV
表 4 MV数据集上S@k和MAP对比结果
Table 4 Comparison Results of S@k and MAP on MV Data Set
方法 S@1 S@5 S@10 S@20 MAP FOCUS 0.670 0.803 0.849 0.885 0.2674 CAPIRD-FOCUS
（本文）0.698 0.808 0.856 0.888 0.2755 GAPI 0.574 0.851 0.949 0.971 0.3971 CAPIRD-GAPI
（本文）0.578 0.854 0.948 0.977 0.3973
下载: 导出CSV
-
[1] Qiu Dong, Li Bixin, Leung H. Understanding the API usage in Java[J]. Information and Software Technology, 2016, 73: 81−100 doi: 10.1016/j.infsof.2016.01.011
[2] Treude C, Robillard M P. Augmenting API documentation with insights from stack overflow[C] //Proc of the 38th Int Conf on Software Engineering (ICSE). Piscataway, NJ: IEEE, 2016: 392−403
[3] Aghajani E, Nagy C, Vega-Márquez O L, et al. Software documentation issues unveiled[C] //Proc of the 41st Int Conf on Software Engineering (ICSE). Piscataway, NJ: IEEE, 2019: 1199−1210
[4] Li Hongwei, Li Sirui, Sun Jiamou, et al. Improving API caveats accessibility by mining API caveats knowledge graph[C] //Proc of the 34th IEEE Int Conf on Software Maintenance and Evolution (ICSME). Piscataway, NJ: IEEE, 2018: 183−193
[5] Bhasin T, Murray A, Storey M A. Student experiences with GitHub and stack overflow: An exploratory study[C] //Proc of the 13th Int Workshop on Cooperative and Human Aspects of Software Engineering (CHASE). Piscataway, NJ: IEEE, 2021: 81−90
[6] Uddin G, Robillard M P. How API documentation fails[J]. IEEE Software, 2015, 32(4): 68−75 doi: 10.1109/MS.2014.80
[7] Yu Haibo, Song Wenhao, Mine T. Apibook: An effective approach for finding APIs[C] //Proc of the 8th Asia-Pacific Symp on Int[J]. New York: ACM, 2016: 45−53
[8] Zhong Hao, Xie Tao, Zhang Lu, et al. MAPO: Mining and recommending API usage patterns[C] //Proc of the 23rd European Conf on Object-Oriented Programming. Berlin: Springer, 2009: 318−343
[9] Wang Jue, Dang Yingnong, Zhang Hongyu, et al. Mining succinct and high-coverage API usage patterns from source code[C] //Proc of the 10th Working Conf on Mining Software Repositories (MSR). Piscataway, NJ: IEEE, 2013: 319−328
[10] Fowkes J, Sutton C. Parameter-free probabilistic API mining across GitHub[C] //Proc of the 24th ACM SIGSOFT Int Symp on Foundations of Software Engineering. New York: ACM, 2016: 254−265
[11] 李正,吴敬征,李明树. API使用的关键问题研究[J]. 软件学报,2018,29(6):1716−1738 doi: 10.13328/j.cnki.jos.005541 Li Zheng, Wu Jingzheng, Li Mingshu. Study on key issues in API usage[J]. Journal of Software, 2018, 29(6): 1716−1738 (in Chinese) doi: 10.13328/j.cnki.jos.005541
[12] Nguyen A T, Nguyen T N. Graph-based statistical language model for code[C] //Proc of the 37th IEEE Int Conf on Software Engineering. Piscataway, NJ: IEEE, 2015: 858−868
[13] Raychev V, Vechev M, Yahav E. Code completion with statistical language models[C] //Proc of the 35th ACM SIGPLAN Conf on Programming Language Design and Implementation. New York: ACM, 2014: 419−428
[14] Gu Xiaodong, Zhang Hongyu, Zhang Dongmei, et al. Deep API learning[C] //Proc of the 24th ACM SIGSOFT Int Symp on Foundations of Software Engineering. New York: ACM, 2016: 631−642
[15] Ling Chunyang, Zou Yanzhen, Xie Bing. Graph neural network based collaborative filtering for API usage recommendation[C] //Proc of the 28th Int Conf on Software Analysis, Evolution and Reengineering (SANER). Piscataway, NJ: IEEE, 2021: 36−47
[16] Rahman M M, Roy C K, Lo D. RACK: Automatic API recommendation using crowdsourced knowledge[C] //Proc of the 23rd Int Conf on Software Analysis, Evolution, and Reengineering (SANER). Piscataway, NJ: IEEE, 2016: 349−359
[17] Rahman M M, Roy C. Effective reformulation of query for code search using crowdsourced knowledge and extra-large data analytics[C] //Proc of the 34th Int Conf on Software Maintenance and Evolution (ICSME). Piscataway, NJ: IEEE, 2018: 473−484
[18] Gu Xiaodong, Zhang Hongyu, Kim S. Deep code search[C] //Proc of the 40th Int Conf on Software Engineering (ICSE). Piscataway, NJ: IEEE, 2018: 933−944
[19] Huang Qiao, Xia Xin, Xing Zhenchang, et al. API method recommendation without worrying about the task-API knowledge gap[C] //Proc of the 33rd Int Conf on Automated Software Engineering (ASE). Piscataway, NJ: IEEE, 2018: 293−304
[20] 张云帆,周宇,黄志球. 基于语义相似度的API使用模式推荐[J]. 计算机科学,2020,47(3):34−40 doi: 10.11896/jsjkx.190300053 Zhang Yunfan, Zhou Yu, Huang Zhiqiu. Semantic similarity based API usage pattern recommendation[J]. Computer Science, 2020, 47(3): 34−40 (in Chinese) doi: 10.11896/jsjkx.190300053
[21] Ling Chunyang, Zou Yanzhen, Lin Zeqi, et al. Graph embedding based API graph search and recommendation[J]. Journal of Computer Science and Technology, 2019, 34(5): 993−1006 doi: 10.1007/s11390-019-1956-2
[22] Xie Wenkai, Peng Xin, Liu Mingwei, et al. API method recommendation via explicit matching of functionality verb phrases[C] //Proc of the 28th ACM Joint Meeting on European Software Engineering Conf and Symp on the Foundations of Software Engineering. New York: ACM, 2020: 1015−1026
[23] Zhou Yu, Yang Xinying, Chen Taolue, et al. Boosting API recommendation with implicit feedback[J]. IEEE Transactions on Software Engineering, 2021, 48(6): 2157−2172
[24] Niu Haoran, Keivanloo I, Zou Ying. API usage pattern recommendation for software development[J]. Journal of Systems and Software, 2017, 129: 127−139 doi: 10.1016/j.jss.2016.07.026
[25] Nguyen T T, Pham H V, Vu P M, et al. Learning API usages from bytecode: A statistical approach[C] //Proc of the 38th Int Conf on Software Engineering (ICSE). Piscataway, NJ: IEEE, 2016: 416−427
[26] Nguyen P T, Di Rocco J, Di Ruscio D, et al. FOCUS: A recommender system for mining API function calls and usage patterns[C] //Proc of the 41st Int Conf on Software Engineering (ICSE). Piscataway, NJ: IEEE, 2019: 1050−1060
[27] Xie Rensong, Kong Xianglong, Wang Lulu, et al. HiRec: API recommendation using hierarchical context[C] //Proc of the 30th Int Symp on Software Reliability Engineering (ISSRE). Piscataway, NJ: IEEE, 2019: 369−379
[28] Chen Chi, Peng Xin, Xing Zhenchang, et al. Holistic combination of structural and textual code information for context based API recommendation[J]. IEEE Transactions on Software Engineering, 2022, 48(8): 2987−3009 doi: 10.1109/TSE.2021.3074309
[29] Di N T, Mirizzi R, Ostuni V C, et al. Linked open data to support content-based recommender systems[C/OL] //Proc of the 8th Int Conf on Semantic Systems. New York: ACM, 2012[2022-09-12].https://doi.org/10.1145/2362499.2362501
[30] Kipf T N, Welling M. Semi-supervised classification with graph convolutional networks[J]. arXiv preprint, arXiv: 1609.02907, 2016
[31] Chen Annie. Context-aware collaborative filtering system: Predicting the user’s preference in the ubiquitous computing environment[C] //Proc of the 1st Int Symp on Location-and Context-Awareness. Berlin: Springer, 2005: 244−253
[32] Nguyen T D, Nguyen A T, Phan H D, et al. Exploring API embedding for API usages and applications[C] //Proc of the 39th Int Conf on Software Engineering (ICSE). Piscataway, NJ: IEEE, 2017: 438−449
[33] Ullmann J R. An algorithm for subgraph isomorphism[J]. Journal of the ACM, 1976, 23(1): 31−42 doi: 10.1145/321921.321925
[34] Inokuchi A, Washio T, Motoda H. An Apriori-based algorithm for mining frequent substructures from graph data[C] //Proc of the 4th European Conf on Principles of Data Mining and Knowledge Discovery. Berlin: Springer, 2000: 13−23
[35] Carbonell J, Goldstein J. The use of MMR, diversity-based reranking for reordering documents and producing summaries[C] //Proc of the 21st Annual Int ACM SIGIR Conf on Research and Development in Information Retrieval. New York: ACM, 1998: 335−336
计量
- 文章访问数: 154
- HTML全文浏览量: 40
- PDF下载量: 97
