Page 135 - 《软件学报》2025年第7期

3056 软件学报 2025 年第 36 卷第 7 期

而 RQ4 则侧重于探索性发现, 旨在揭示 JDepAna 在实际、复杂的项目环境中对新问题的检测能力. 这两部分不仅
相互形成对比, 还互为佐证, 全面展示了检测工具的性能.

4.1 RQ3: 有效性

4.1.1 实验设置
我们对实证研究中收集到的 47 个问题报告进行了进一步筛选, 排除其中两类不属于我们检测对象的问题报
告: 第 1 类是报告中的依赖异味是下游项目使用中遇到的问题, 而不是当前项目; 第 2 类是由于时间跨度较大, 报
告对应版本的项目已无法获取当时的依赖库, 导致无法进行正常构建和构建调用图. 最终我们得到了 28 个问题报
告, 其中 16 个与 Maven 相关, 12 个与 Gradle 相关.
为了对 JDepAna 的检测结果进行精细评估, 我们从问题报告对应的修复中提取了相应的依赖异味实例. 这些
实例被定义为包含依赖异味特征的最小单元, 以元组<项目, 模块, 依赖异味编号, 问题说明>来表示, 分别代表了
异味出现的项目和模块、所属类别以及具体信息. 依赖异味实例的引入能够避免宽泛的检测标准, 确保工具不仅
能识别问题的存在, 还能细致检测呈现出依赖异味特征的具体依赖库. 以图 8 中#ASJV-4539 [48] 为例, 项目 aws-sdk-
java-v2 中的模块 core/auth 中出现了依赖异味未声明依赖, 其中两个依赖库 software.amazon.awssdk:http-auth-spi
和 soft-ware.amazon.awssdk:checksums 都被使用但未在配置文件中声明. 若没有依赖异味实例的细分, JDepAna 只
需检测出未声明依赖即可视为成功. 然而, 基于依赖异味实例的划分, 该问题实际包含两个实例<aws-sdk-java-v2,
core/auth, 1.4, software.amazon.awssdk:http-auth-spi>和<aws-sdk-java-v2, core/auth, 1.4, software.amazon.awssdk:
checksum>, 这意味着 JDepAna 需分别检出这两个具体依赖库的未声明特征, 才能算作全面检测. 这些实例中 aws-
sdk-java-v2 对应于项目名, core/auth 代表出现依赖异味的具体模块, 1.4 对应于未声明依赖的异味编号, software.
amazon.awssdk:http-auth-spi 和 soft-ware.amazon.awssdk:checksums 对应于问题说明也即被使用但未被声明的具体
依赖库. 值得注意的是, 不同类别的依赖异味虽然都会被划分为依赖异味实例, 但在问题说明中的描述方式有所不
同. 例如对于外部类冲突这类异味, 当多个依赖库中存在冲突类时, 问题说明会列出所有包含这些冲突类的依赖
库, 并将其作为一个实例处理; 而在异味 1.4 未声明依赖中, 问题说明则对应于使用但未声明的具体依赖库.

两个依赖异味实例

图 8 依赖异味实例

按照以上流程, 我们最终提取出了 16 个 Maven 相关问题报告中的 125 个实例和 12 个 Gradle 相关问题报告
中的 22 个实例, 这 147 个实例构成了我们的基准集, 覆盖了 13 个异味类别中的 10 类. 对于基准集中的依赖异味