演化的重要性：① 保障软件系统具备诸多好的特性；② 有效管控软件系统的整体复杂性和变化性，降低软件检修和修改成本；③ 保证软件系统演化的一致性和正确性，增加便捷性。
演化的对象：软件架构包括组件、连接件、约束三大要素，架构演化主要关注三要素的添加、修改和删除。面向对象视角下的演化过程分四类：
| 演化类别 | 包含操作（英文缩写必背） |
|---|---|
| ① 对象演化 | AO（Add Object 添加对象——新增功能或独立现有功能）、DO（Delete Object 删除对象——移除功能或合并对象降低复杂度） |
| ② 消息演化 | AM 增添消息、DM 删除消息、SMO 交换两条消息的时间顺序、OM 反转消息的发送对象与接收对象、CMM 改变消息的发送或接收对象 |
| ③ 复合片段演化 | AF 新增复合片段（增添新控制流）、DF 删除复合片段、FTC 改变片段类型（改变控制流）、FCC 改变片段内部执行条件 |
| ④ 约束演化 | AC 直接添加新约束（需判断当前设计是否满足）、DC 直接移除约束 |
1. 按演化时期分 4 类：
| 时期 | 发生时点 |
|---|---|
| 设计时演化 | 体系结构模型与相关代码编译之前 |
| 运行前演化 | 执行之前、编译之后 |
| 有限制运行时演化 | 只发生在某些特定约束满足时（系统置于"安全"模式，只做规定好的演化操作） |
| 运行时演化 | 发生在运行不能满足要求时 |
2. 静态演化（离线演化）：发生在软件部署之前（设计时、运行前）。
3. 动态演化（在线演化）：软件在运行期间的演化。需求来源：① 软件内部执行所导致的体系结构改变；② 软件系统外部请求对软件进行的重配置。
重点掌握常考的几条，其余理解即可：
| 原则 | 含义 |
|---|---|
| 演化成本控制 | 演化成本控制在预期范围之内 |
| 进度可控 | 架构演化要在预期时间内完成 |
| 风险可控 | 经济/时间/人力/技术/环境风险可控 |
| 主体维持 | 演化平均增量增长平稳，保证主体行为稳定 |
| 系统总体结构优化 | 演化后系统整体结构（布局）更合理 |
| 平滑演化 | 软件的演化速率趋于稳定（如相邻版本更新率相对稳定） |
| 目标一致 | 阶段目标和最终目标一致 |
| 模块独立演化 | 各模块自身演化最好相互独立 |
| 影响可控 | 模块变更给其他模块带来的影响可控 |
| 复杂性可控 | 保障架构复杂性在可控范围内 |
| 有利于重构 / 有利于重用 | 演化后便于重构；维持甚至提高可重用性 |
| 设计原则遵循性 | 演化不与架构设计原则冲突 |
| 适应新技术 / 环境适应性 | 独立于特定技术手段；易适应新的软硬件环境 |
| 标准依从性 | 不违背国际/国家/行业质量标准 |
| 质量向好 | 关注的质量指标变更好 |
| 适应新需求 | 容易适应新的需求变更 |
演化评估方法：① 演化过程已知：对演化前后不同版本的架构分别进行度量，得到度量结果的差值及变化趋势，计算架构间质量属性距离进而评估；② 演化过程未知：先对演化前后的架构进行 CMG 度量（度量获取），再采用共享度量元比较，分析偏差，评估演化影响。
架构维护过程 3 项（不含"架构构件管理"——真题陷阱）：
| 过程 | 要点 |
|---|---|
| ① 架构知识管理 | 架构知识 = 架构设计 + 架构设计决策；侧重开发和实现过程涉及的架构静态演化，在架构文档等信息来源中捕捉架构知识，对质量属性及其设计依据进行记录和评价；需求：防止关键设计知识"沉没"在软件架构中 |
| ② 架构修改管理 | 建立一个隔离区域，保障该区域中任何修改对其他部分影响最小 |
| ③ 架构版本管理 | 为软件架构演化的版本演化控制、使用和评价提供可靠依据 |
架构可维护性 6 个度量指标（必背缩写）：圈复杂度（CNN）、扇入扇出度（FFC）、模块间耦合度（CBO）、模块的响应（RFC）、紧内聚度（TCC）、松内聚度（LCC）。