本周的软工论文题目为《Just-in-Time Prediction of Software Architectural Changes Through Commit-Level Analyses》
主要内容：
究围绕三个核心问题展开（RQ1-RQ3）：
提交级粒度分析架构变更是否有意义，其变更特征如何？
是否存在与架构变更相关的提交级度量指标，哪些指标相关性更强？
能否构建即时预测模型，有效预测提交级架构变更的程度？
研究对象：选取 30 个不同领域、提交数超 500 的开源 Java 项目，共收集 77154 次提交数据，覆盖大数据、中间件、机器学习等多个方向。
建立预测，建立针对"提交"级别导致的软件结构变化的预测。
作者认为，提交级分析虽广泛应用于缺陷预测等任务，却极少被用于架构变更研究，故从“提交”级别变更来预测软件结构变化。
he existing recovery techniques can mainly be categorized into two groups: hierarchical and non-hierarchical
聚类算法的选取
传统方法通过聚类进行架构恢复
1.从源码提取依赖 → 2. 用聚类算法聚合高内聚构件 → 3. 得到符合设计原则的软件架构（模块 / 组件划分）。
文章提到两种架构恢复方法 hierarchical and non-hierarchical,前者类树状结构，自底向上or自顶向下；后者类似k邻近算法的效果，单独成cluster并无上下关联。
文章采用FCA 快速聚类算法，下面简述该算法的步骤：
第一步：构建依赖矩阵（把代码关系变成表格）
把每个源码文件看作一个节点（A、B、C、D…）
画一个矩阵：
矩阵里写 1 = 两个文件有依赖（比如调用、引用、继承）
矩阵里写 0 = 两个文件没有依赖
例子：Cell(A,B)=1 → A 文件和 B 文件有关系
一句话：把代码之间的关系，变成一张 0/1 表格。
第二步：构建邻域度矩阵（算每个文件 “关系多不多”）
看第一步的矩阵
对每个节点（文件），数它和多少其他节点有依赖
把数量填进新矩阵 → 这就是邻域度矩阵
一句话：算每个文件 “有多少个朋友”。
第三步：选择边界节点（找 “最核心” 的文件）
根据邻域度矩阵，计算每个节点的标准化依赖值
选出值最大的那个节点
把它作为第一个聚类的起点
一句话：找到关系最多、最核心的文件，当模块老大。
第四步：寻找共聚类节点（找 “最应该在一起” 的文件）
对每个节点，找依赖最小但互相最匹配的节点
规则：
你是我依赖最小的
我也是你依赖最小的
→ 你们就是天生一对，应该放同一个簇里
找到就合并成一个簇
一句话：互相最匹配、最应该放一起的文件，合成一个小模块。
第五步：合并簇（把小模块合成大模块）
看哪些簇拥有共同节点
把它们合并
目标：
减少簇数量
让每个簇内聚更高（内部关系更紧密）
一句话：有重叠、有关系的小模块，合成更大更合理的模块。
第六步：处理未聚类的节点（孤儿文件归队）
剩下还没分组的文件
给它找依赖最近、关系最亲的簇
加进去
再根据依赖关系做最终调整
一句话：落单的文件，找到最亲的模块加入。
架构变化的衡量
文章使用a2a 指标来衡量架构的变化
a2a 指标的计算逻辑（通俗版）
a2a 的本质是 「两个架构图的最大公共子图占比」：
把提交前、提交后的架构，分别转换成两张「组件依赖图」（节点 = 模块，边 = 模块间依赖）；
找到两张图中最大的公共子结构（也就是两张图里完全一致的部分）；
用「公共子结构的大小 ÷ 两张图的总大小」，得到相似度分数（0~1 之间，也会转成百分比）：
结果
核心实验结果
RQ1：提交级架构变更的意义与特征
架构变更确实发生在提交级粒度，27% 的提交引发了不同程度的架构变更，且多数项目存在 a2a 值低于 40% 的显著架构变更提交；
架构演化并非渐进式，而是无规则的：多数提交（57.5%-88.0%）未引发架构变化，但部分提交会导致突发变更；
不同项目的架构变更分布差异显著：部分项目（如 Atlas）架构相对稳定，少数提交引发变更；部分项目（如 Kylin、Tiles）提交引发架构变更的比例高（38.83%/39.45%），甚至存在大量显著变更；
架构变更的时间趋势分三类：项目初期不稳定后趋于稳定（Pig）、中期集中重构（Knox）、全生命周期波动变化（Mina）；且绝大多数架构变更由普通代码提交引发，合并操作的影响极小。
RQ2：与架构变更相关的提交级度量指标
5 个指标与架构变更呈强负相关（|rₛ|>0.5）：字符修改数（NCC）、方法修改数（NMC）、文件修改数（NMF）、文件增删数（NAD）、文件圈复杂度变化（CFC）；
4 个指标呈中度相关（0.3<|rₛ|<0.5）：代码行修改数（LC）、修改子系统数（NMS）、修改目录数（NMD）、信息熵（Entropy）；
6 个指标无显著相关性：文件平均修改间隔（AGE）、开发者数量（NDVE）、开发者经验（EXP/REXP）、修改文件原代码行数（TLMF）、文件历史修改最大值（MNCF）；
提交目的（问题类型）与架构变更无明显关联：bug 修复、新功能、优化等类型的提交，引发架构变更的概率无显著差异，说明架构变更存在于各类开发活动中。
此外，相关性并非单纯由 “变更规模” 决定，圈复杂度变化（CFC）的强相关性表明变更的复杂性也是架构变更的重要诱因。
RQ3：提交级架构变更的即时预测模型性能
以 5 个强相关指标为特征的回归模型表现优异：随机森林模型为最优，单个项目的 R² 中位数达 0.865（67% 的项目 R²>0.75，11 个项目 R²>0.9），全数据集 R² 达 0.932；
模型预测误差低：MAE 中位数 0.653（多在 0-1 之间），RMSE 中位数 2.16（多在 0-4 之间），说明能精准量化提交引发的架构变更程度；
模型具备跨项目泛化能力，全数据集的预测性能与项目专属模型相当，可适用于不同特征的 Java 项目。