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

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

(a) 危害 11 将 lib 升级到 v2.0.0 版本时
包含 依赖于 需要修改多个配置文件
修改 维护成本增加
修改
项目 pr 模块 mod1 依赖库 lib: v1.0.0
依赖于
未集中管理
模块 mod2 依赖库 lib: v1.0.0
图 A15 异味 2.4 可能危害与对应触发场景

13) 类别 2.5 模块间库冲突
模块间库冲突的危害和模块间库重复类似, 同样会增加项目维护成本, 并可能增加下游项目出现依赖冲突的
概率.
(1) 依赖库维护难度增加: 其触发场景为项目对未集中管理的依赖库进行版本升级. 以图 A16(a) 为例, 项目中
的模块 mod1 和 mod2 分别依赖于依赖库 lib 的 1.0.0 和 2.0.0 版本. 在试图将 lib 升级至 3.0.0 版本时, 需要将修改
同步至所有模块, 这就导致项目维护成本的增加.

(a) 危害 11 将 lib 升级到 v3.0.0 版本时
需要修改多个配置文件
包含 依赖于
修改
修改 维护成本增加
项目 pr 模块 mod1 依赖库 lib: v1.0.0
依赖于 冲突
模块 mod2 依赖库 lib: v2.0.0
图 A16 异味 2.5 可能危害与对应触发场景

A3 依赖异味检测算法
在正文中, 我们已经介绍了异味 1.6 依赖范围误用的检测算法, 下文将继续介绍剩余异味对应的检测算法.
1) 类别 1.1 内外类冲突 (如算法 A1 所示)
算法 A1. 内外类冲突检测.

输入: DJ: 依赖包集合; BI: 基本信息;
输出: JS: 出现内外类冲突的依赖库集合.
1. JS ⇐ {}
2. moduleClasses ⇐ BI.sourceClasses
3. for depJar ∈ DJ do
4. depClasses ⇐ depJar.sourceClasses
5. for depclass ∈ depClasses do
6. if depclass ∈ moduleClasses then
7. JS.add(depJar)
8. end if
9. end for
10. end for

该算法接受依赖包集合 DJ 和基本信息 BI 作为输入, 并输出出现内外类冲突的依赖库集合 JS. 算法的工作流
程如下: 首先, 初始化依赖库集合 JS (第 1 行). 接着, 从基本信息 BI 中获取模块的类集合 moduleClasses (第 2 行).
然后, 算法遍历依赖包集合 DJ 中的每一个依赖包 depJar (第 3 行), 并提取该依赖包的类集合 depClasses (第 4 行).
接下来, 算法遍历依赖包 depClasses 中的每一个类 depclass (第 5 行). 如果当前类 depclass 存在于模块的类集合
moduleClasses 中, 算法将依赖包 depJar 加入集合 JS (第 6–8 行). 最终, 算法结束对依赖包的遍历 (第 9 行), 并完成
内外类冲突的检测.