Page 135 - 《软件学报》2026年第7期
P. 135

2820                                                       软件学报  2026  年第  37  卷第  7  期


                    ● RQ1: CAnalyzer 的参数如何影响  TPL  检测能力? 通过统计    100 个项目的参数    α (公式  (4)) 、β (公式  (5)) 和  θ (公
                 式  (6)) 的数据, 设定合理的参数范围, 并设置不同的参数组合, 对其余              100  个项目进行分析.
                    ● RQ2: CAnalyzer 的  TPL  检测能力与相关工具相比表现如何? 我们使用            100  个项目, 分别通过   CAnalyzer、
                 CENTRIS [13] 、TPLite [14] 和  OSSFP [15] 进行检测, 并对比检测结果与标准集数据, 分析精确率和召回率.
                    ● RQ3: CAnalyzer 的特征库预处理和     TPL  识别算法的改进对     SCA  能力有何影响? 我们设置了        3  种特征库和
                 两种成分识别方法的       6  种组合, 并在  100  个项目上进行了检测, 分析这些改进对检测精确率和召回率的影响.
                    ● RQ4: CAnalyzer 是否能准确检测文件集之间的依赖关系? 通过解析                   OpenHarmony 4.0  中  14 783  个
                 BUILD.gn  文件, 获得  1 784  对文件集为标准数据, 评估    CAnalyzer 在直接和间接依赖检测方面的准确性.
                    ● RQ5: CAnalyzer 的检测效率与相关工具相比表现如何? 我们使用                 100  个项目, 分别通过     CAnalyzer、
                 CENTRIS [13] 、TPLite [14] 和  OSSFP [15] 进行执行效率分析, 包括: 特征提取和  TPL  检测的执行时间.
                  4.1   标准集构建

                    我们从   GitHub  随机筛选了包含    TPL  复用结构 (如   arangodb/3rdParty/abseil-cpp) 的项目. 同时, 为了验证工具
                 在实际场景中的有效性, 我们特别关注了             OpenHarmony 4.0  的真实项目, 筛选出具有明确构建配置 (如         BUILD.gn)
                 和依赖声明 (如    README.OpenSource) 的项目, 并通过分析其目录结构和配置文件构建标准集. 在库粒度复用的
                 场景中, 开发者通常采用特定的组织方式来存放复用的                  TPL  代码, 如“arangodb/3rdParty/abseil-cpp”. 我们将这种映
                 射关系 (如  arangodb  与  abseil-cpp) 视为标准集数据, 表示  arangodb  复用了组件  abseil-cpp.
                    (1) 排除非源代码目录. 若子目录仅包含头文件或其他语言文件, 则认定该映射关系无效并排除.
                    (2) 版权文件存在. 如果相应目录下存在版权信息 (如 LICENSE、COPYING 文件) , 通常包括供应商名称、作
                 者名称和库名称, 则认为该映射关系有效, 并将其视为标准集数据.
                    (3) 自述文件存在. 如果相应目录下存在          TPL  的  README  文件, 同样认定映射关系有效. OpenHarmony 4.0    的
                 真实项目使用     README.OpenSource 文件来标识软件复用, 记录了复用组件名称, 这为我们提供了一组映射关系
                 作为标准集数据. 根据上述过程和规则, 我们审查了               1 000  多个  C/C++项目, 筛选出  200  个可用于构建标准集的软
                 件项目, 并识别出     515  组复用关系 (见表   3).

                                                      表 3 实验标准集

                          项目来源         项目总数      BUILD.gn数量    构建模块数量       依赖关系数量       复用TPL数量
                      Gitee/OpenHarmony  100        14 873       12 277        1 784
                                                                                            515
                           GitHub        100          －            －            －
                     注: “－”表示不适用. GitHub实验项目仅用于TPL复用检测评估, 不涉及BUILD.gn文件、构建模块及依赖关系统计

                    需要指出的是, 我们在标准集构建中优先采纳了“显式声明来源”的外部依赖, 如目录结构、版权文件或自述
                 文件中直接标识出的复用关系, 能够确保标准集的可靠性和可验证性, 避免因人工推断或不确定性信息而引入噪
                 声. 然而, 这一策略可能会遗漏部分未显式声明的              TPL, 例如, 某些开发者直接拷贝了第三方库的部分代码片段但
                 未在目录或说明文件中保留来源标识. 我们在“有效性威胁”中明确讨论了该问题.
                  4.2   评估指标
                    评估中, 我们采用以下指标全面衡量            CAnalyzer 工具的性能.
                    (1) 真阳性 (TP): CAnalyzer 正确检测出的     TPL  成分, 这些成分在标准集中明确标记; 或工具正确识别出
                 source 模块依赖于  dep  模块的关系, 与标准集一致.
                    (2) 假阳性 (FP): CAnalyzer 检测到的  TPL  成分, 但这些成分在标准集中未被标记为            TPL; 或工具错误地表示
                 dep  模块依赖于  source 模块的关系, 而标准集中并不存在该依赖.
                    (3) 假阴性 (FN): 标准集中明确标记的       TPL  成分, 但  CAnalyzer 未能检测到; 或工具未能识别标准集中记录的
                 模块间依赖关系.
                                                 TP
                    (4) 精确率 (Precision):  Precision =  , 该指标衡量  CAnalyzer 识别  TPL  成分或检测依赖关系的准确性,
                                               TP+FP
   130   131   132   133   134   135   136   137   138   139   140