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

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

接依赖库及其版本 (第 1 行). 接着, 调用 resolveDepFile 函数解析其他工具的依赖文件, 并将结果存储在哈希表
otherToolMap 中 (第 2 行). 然后, 算法遍历依赖树 DT 中深度为 1 的直接依赖库 dep (第 3 行), 并将每个直接依赖
库的名称 dep.depName 和版本 dep.depVer 添加到哈希表 currentToolMap 中 (第 4 行). 完成依赖树的遍历后, 算法
通过调用 difference 函数计算当前工具与其他工具之间的差异, 并将结果赋值给不一致的直接依赖库集合 JS (第
6 行). 最后, 算法结束, 返回 Maven 和 Gradle 下的不一致依赖库.
8) 类别 2.1 构建工具配置缺失 (如算法 A8 所示)

算法 A8. 构建工具配置缺失检测.

输入: BI: 基本信息;
输出: MC: 项目是否缺失构建工具配置.
1. buildToolConfigs ⇐ parseConfigFile(BI.builtToolConfigPath)
2. MC ⇐ buildToolConfig.empty()

算法接受基本信息 BI 作为输入, 并输出项目是否缺失构建工具配置的标志 MC. 算法的工作流程如下: 首先,
调用 parseConfigFile 函数解析构建工具配置文件, 获取配置结果并存储在 buildToolConfigs 中 (第 1 行). 接着, 算
法通过检查 buildToolConfigs 是否为空来确定项目是否缺失构建工具配置, 并将结果赋值给标志 MC (第 2 行). 最
后, 算法结束, 返回项目缺失构建工具配置的状态.
9) 类别 2.2 构建工具启动器 JAR 缺失 (如算法 A9 所示)

算法 A9. 构建工具封装器 JAR 缺失检测.

输入: BI: 基本信息;
输出: MJ: 项目是否缺失构建工具封装器 JAR.
1. buildToolConfigs ⇐ parseConfigFile(BI.builtToolConfigPath)
2. wrapperJAROnline ⇐ buildToolConfigs[‘onlineWrapperJAR’].empty()
3. wrapperJAROffline ⇐ BI.defaultWrapperJAR.exist()
4. MJ ⇐ wrapperJAROnline or wrapperJAROffline

该算法接受基本信息 BI 作为输入, 并输出项目是否缺失构建工具封装器 JAR 的标志 MJ. 算法的工作流程如
下: 首先, 调用 parseConfigFile 函数解析构建工具配置文件, 并将结果存储在 buildToolConfigs 中 (第 1 行). 接着,
算法检查在配置文件是否指定了在线下载封装器 JAR 是否为空, 并将结果赋值给布尔变量 wrapperJAROnline (第
2 行). 随后, 算法检查默认本地封装器 JAR 是否存在, 并将结果存储在布尔变量 wrapperJAROffline 中 (第 3 行). 最
后, 算法通过逻辑或运算将两个布尔值结合, 确定项目是否缺失构建工具封装器 JAR, 并将结果赋值给标志 MJ
(第 4 行).
10) 类别 2.3 构建工具启动器 JAR 异常 (如算法 A10 所示)

算法 A10. 构建工具封装器 JAR 异常检测.

输入: BI: 基本信息;
输出: AC: 项目构建工具封装器是否与构建工具版本一致.
1. buildToolConfigs ⇐ parseConfigFile(BI.builtToolConfigPath)
2. buildToolVer ⇐ buildToolConfigs[‘builtToolVersion’]