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

孙伟杰 等: Java 依赖异味的实证研究与统一检测技术 3085

3. wrapperJAROffline ⇐ BI.defaultWrapperJAR
4. if not wrapperJAROffline.exist() then
5. Return
6. end if
7. localChecksum ⇐ calculateLocalChecksum(wrapperJAROffline)
8. officialChecksum ⇐ getOnlineChecksum(buildToolVer)
9. AC ⇐ localChecksum == officialChecksum

该算法接受基本信息 BI 作为输入, 并输出项目构建工具封装器是否与构建工具版本一致的标志 AC.算法的
工作流程如下: 首先, 调用 parseConfigFile 函数解析构建工具配置文件, 并将结果存储在 buildToolConfigs 中 (第
1 行). 接着, 算法从配置中提取构建工具版本, 并将其赋值给变量 buildToolVer (第 2 行). 随后, 算法获取默认封
装器 JAR, 并将其存储在变量 wrapperJAROffline 中 (第 3 行). 接下来, 算法检查 wrapperJAROffline 是否存在, 若不
存在则提前返回, 结束算法 (第 4–6 行). 如果存在, 算法计算本地封装器 JAR 的校验和, 并将结果存储在变量
localChecksum 中 (第 7 行). 然后, 算法获取对应版本的官方校验和, 并存储在变量 officialChecksum 中 (第 8 行).
最后, 算法通过比较本地校验和与官方校验和来确定构建工具封装器是否一致, 并将结果赋值给标志 AC (第
9 行).
11) 类别 2.4 模块间库重复 (如算法 A11 所示)
算法 A11. 模块间库重复检测.

输入: BI: 基本信息;
输出: JS: 未统一版本管理的依赖库集合.

1. JS ⇐ {};
2. moduleDirectDepsCnt ⇐ {}
3. for module ∈ BI.modules do
4. for dep ∈ resolveDepFile(module.depFile) do
5. moduleDirectDepsCnt[dep] += 1
6. end for
7. end for
8. controlledDeps ⇐ BI.managedDeps
9. for dupDep ∈ moduleDirectDepsCnt.keys do
10. if moduleDirectDepsCnt[dupDep] > 1 and not dupDep ∈ controlledDeps then
11. JS.add(dupDep)
12. end if
13. end for

该算法接受基本信息 BI 作为输入, 并输出未统一版本管理的依赖库集合 JS. 算法的工作流程如下: 首先, 初
始化集合 JS 用于存储未统一版本管理的依赖库 (第 1 行). 接下来, 创建一个字典 moduleDirectDepsCnt 用于记录
各个依赖库在模块中的直接依赖计数 (第 2 行). 算法遍历多模块项目中的每个模块 (第 3 行), 并对每个模块的依
赖文件调用 resolveDepFile 函数以解析其依赖 (第 4 行). 对于每个解析到的依赖 dep, 算法将其计数加 1 (第 5 行).
完成模块遍历后, 算法从基本信息中获取受控依赖集合, 并将其赋值给变量 controlledDeps (第 8 行). 随后, 算法遍
历 moduleDirectDepsCnt 字典中的每个重复依赖 dupDep (第 9 行), 并检查该依赖的计数是否大于 1 且不在受控依
赖集合中 (第 10 行). 如果条件满足, 算法将该依赖 dupDep 添加至集合 JS 中 (第 11 行).