SECTION 01
软件架构演化和定义的关系
理解"为什么要演化" + "演化改了什么"
一、演化的重要性
- 保障软件系统具备诸多好的特性。
- 有效管控软件系统的整体复杂性和变化性，降低软件检修和修改成本。
- 保证软件系统演化的一致性和正确性，增加便捷性。
二、演化和定义的关系
软件架构包括 组件、连接件、约束 三大要素。因此，软件架构演化主要关注这三者的 添加、修改、删除。
考点
记住三要素 = 组件 + 连接件 + 约束；演化的操作 = 添加 / 修改 / 删除。
SECTION 02
面向对象软件架构演化过程
四类元素：对象 · 消息 · 复合片段 · 约束
一、对象演化
| 操作 | 含义 | 发生场景 |
|---|---|---|
| Add Object | 添加新对象 | 系统需添加新对象实现新功能，或需将现有对象的某功能独立以增加架构灵活性时 |
| Delete Object | 删除现有对象 | 系统需移除某现有功能，或需合并某些对象及其功能以降低架构复杂度时 |
二、消息演化（5 种）
AM 增添
DM 删除
SMO 交换顺序
OM 反转
CMM 改变收发对象
| 操作 | 全称 | 含义 / 场景 |
|---|---|---|
| AM | Add Message | 增添一条新消息——对象之间需增加新的交互行为时 |
| DM | Delete Message | 删除当前一条消息——需移除某交互行为时 |
| SMO | Swap Message Order | 交换两条消息的时间顺序——需改变两个交互行为之间的顺序时 |
| OM | Overturn Message | 反转消息的发送对象与接收对象——需修改某个交互行为本身时 |
| CMM | Change Message Module | 改变消息的发送或接收对象——需修改某个交互行为本身时 |
区分
OM 是"对调"发送方和接收方；CMM 是"换掉"其中一方。两者都属于修改交互行为本身。
三、复合片段演化（4 种）
AF
DF
FTC 类型
FCC 条件
| 操作 | 全称 | 场景 |
|---|---|---|
| AF | Add Fragment | 在某几条消息上新增复合片段——需增添新的控制流时 |
| DF | Delete Fragment | 删除某个现有的复合片段——需移除当前某段控制流时 |
| FTC | Fragment Type Change | 改变复合片段的类型——需改变某段控制流时 |
| FCC | Fragment Condition Change | 改变复合片段内部执行条件——改变当前控制流执行条件时 |
四、约束演化（2 种）
| 操作 | 含义 | 注意 |
|---|---|---|
| AC | 直接添加新的约束信息 | 需判断当前设计是否满足新添加的约束要求 |
| DC | 直接移除某条约束信息 | 发生在去除某些不必要条件时 |
SECTION 03
软件架构演化方法的分类
演化时期 · 静态演化 · 动态演化
一、软件架构演化时期（4 个时期）
T1
设计时演化
发生在体系结构模型与之相关的代码编译之前
T2
运行前演化
发生在执行之前、编译之后
T3
有限制运行时演化
只发生在某些特定约束满足时
T4
运行时演化
发生在运行时不能满足要求时
二、软件架构静态演化
① 静态演化需求
- 设计时演化需求
- 运行前演化需求
② 静态演化的一般过程
软件理解
→
需求变更分析
→
演化计划
→
系统重构
→
系统测试
③ 静态演化的原子演化操作
A · 与可维护性相关的架构演化操作（8 个）
AMD 加模块依赖
RMD 删模块依赖
AMI 加模块接口
RMI 删模块接口
AM 加模块
RM 删模块
SM 拆分模块
AGM 聚合模块
B · 与可靠性相关的架构演化操作（11 个）
AMS / RMS 消息
AO / RO 对象
AF / RF / CF 片段
AU / RU 用例
AA / RA 参与者
Add / Remove Message、Object、Fragment（含 Change Fragment）、Use Case、Actor
三、软件架构动态演化
① 动态演化需求
- 软件内部执行所导致的体系结构改变
- 软件系统外部的请求对软件进行的重配置
② 动态演化的类型
| 维度 | 分类 |
|---|---|
| 软件动态性等级 | 交互动态性 · 结构动态性 · 架构动态性 |
| 动态演化的内容 | 属性改名 · 行为变化 · 拓扑结构改变 · 风格变化 |
③ 动态软件架构（DSA）
基于 DSA 实现动态演化的基本原理：运行时刻体系结构相关信息的改变，可用来 触发、驱动系统自身的动态调整。
| 项目 | 内容 |
|---|---|
| DSA 描述语言 |
基于行为视角的 π-ADL · 基于反射视角的 Pilar · 基于协调视角的 LIME
|
| DSA 演化工具 | 使用反射机制 · 基于组件操作 · 基于元演算 · 利用外部的体系结构演化管理器 |
④ 动态软件架构应用实例：PKUAS
- PKUAS 是一个符合 Java EE 规范的组件运行支撑平台。
- 包括 4 种类型：容器系统 · 公共服务 · 工具 · 微内核
⑤ 动态重配置
| 项目 | 内容 |
|---|---|
| 重配置模式（4） | 主从模式 · 中央控制模式 · 客户端/服务器模式 · 分布式控制模式 |
| 典型例子 | 可重用、可配置的产品线架构 |
| 动态配置难点 |
① 约束定义困难 ② 性能约束难以静态衡量 ③ 难以管理所有方面 ④ 需同时保证组件系统完整性和重配置策略的正确与安全性 |
高频考点
4 种动态重配置模式名称需熟记；4 个动态配置难点常出选择题。
SECTION 04
软件结构演化原则
软件结构可持续演化的 18 条原则
01
演化成本控制原则
演化成本要控制在预期的范围之内
02
进度可控原则
架构演化要在预期的时间内完成
03
风险可控原则
经济、时间、人力、技术、环境 5 类风险在可控范围
04
主体维持原则
软件演化的平均增量增长保持平稳，保证主体行为稳定
05
系统总体结构优化原则
演化后系统整体结构（布局）更加合理
06
平滑演化原则
软件的演化速率趋于稳定
07
目标一致原则
阶段目标和最终目标要一致
08
模块独立演化原则
各模块自身的演化最好相互独立
09
影响可控原则
一个模块变更给其他模块带来的影响在可控范围内
10
复杂性可控原则
必须控制架构的复杂性
11
有利于重构原则
使演化后软件架构便于重构
12
有利于重用原则
维持甚至提高整体架构的可重用性
13
设计原则遵循性原则
不能与架构设计原则冲突
14
适应新技术原则
独立于特定技术手段，可运行于不同平台
15
环境适应性原则
容易适应新的软硬件环境
16
标准依从性原则
不违背相关质量标准（国际、国家、行业）
17
质量向好原则
所关注的质量指标变得更好
18
适应新需求原则
很容易适应新的需求变更
记忆法
"3 控 + 1 持 + 14 好"：成本控、进度控、风险控 → 主体维持 → 其余 14 条都是"让架构变得更好"的方向（结构、平滑、目标、独立、影响、复杂性、重构、重用、设计原则、新技术、新环境、标准、质量、新需求）。
SECTION 05
软件架构演化评估方法
演化过程 已知 / 未知 两种场景
一、演化过程已知的评估
评估流程：将架构度量应用到演化过程中 → 对演化前后的不同版本架构分别度量 → 得到度量结果的差值及变化趋势 → 计算架构间质量属性距离 → 评估相关质量属性。
关键要点
- 架构演化中间版本度量
- 架构质量属性距离：
- 可维护性距离计算
- 可靠性距离计算
- 非相邻版本的架构质量属性距离
- 架构演化评估
核心思路 基于度量的架构演化评估方法 —— 通过对演化前后的软件架构进行度量，比较 架构内部结构上的差异 以及由此导致的 外部质量属性上的变化。
二、演化过程未知的评估
当演化过程未知时，无法追踪架构在演化过程中的每一步变化，只能根据架构 演化前后的度量结果，逆向推测出架构发生了哪些改变，并分析这些改变与架构相关质量属性的关联关系。
对比记忆
已知 → 顺向跟踪 + 计算距离；未知 → 逆向推测 + 分析关联。
SECTION 06
大型网站系统架构演化实例
10 个阶段循序渐进 —— 案例题高频
| 阶段 | 架构 | 核心特征 |
|---|---|---|
| ① | 单体架构 | 应用程序、数据库、文件等所有资源都在一台服务器上 |
| ② | 垂直架构 | 将应用和数据分离 → 3 台服务器：应用 / 文件 / 数据 |
| ③ | 使用缓存改善网站性能 | 应用服务器上的本地缓存 + 专门的分布式缓存服务器上的远程缓存 |
| ④ | 使用服务集群改善并发处理能力 | 通过负载均衡调度服务器，将浏览器请求分发到应用服务器集群任一台，解决高并发、海量数据问题 |
| ⑤ | 数据库读写分离 | 写访问主库 → 主从复制同步到从库 → 读访问从库 |
| ⑥ | 反向代理 + CDN | CDN 部署在网络提供商机房（就近获取） 反向代理（Nginx）部署在网站中心机房 |
| ⑦ | 分布式文件系统 + 分布式数据库 | 进行业务分库，不同业务的数据部署在不同物理服务器上 |
| ⑧ | NoSQL + 搜索引擎 | 引入非关系型存储与全文检索能力 |
| ⑨ | 业务拆分 | 将一个网站拆分成许多不同的应用，每个应用独立部署 |
| ⑩ | 分布式服务 | 面向服务化的最终阶段 |
案例题
记住演化顺序 + 每一阶段解决的核心问题（性能 → 并发 → 数据库压力 → 响应速度 → 数据规模 → 数据多样性 → 业务复杂度）。
SECTION 07
软件架构维护
知识 · 修改 · 版本 · 可维护性度量
一、软件架构知识管理
架构知识 = 架构设计 + 架构设计决策
- 含义：侧重于软件开发和实现过程所涉及的架构静态演化；在架构文档等信息来源中捕捉架构知识；对架构的质量属性及其设计依据进行记录和评价。
- 需求：防止关键的设计知识 "沉没" 在软件架构中。
二、软件架构修改管理
主要是建立一个 隔离区域，保障该区域中任何修改对其他部分影响最小。
三、软件架构版本管理
为软件架构演化的 版本演化控制、使用和评价 提供可靠依据。
四、软件架构可维护性度量实践
架构可维护性的 6 个度量指标：
| 缩写 | 中文名 | 关注点 |
|---|---|---|
| CNN | 圈复杂度 | 模块内部控制流复杂度 |
| FFC | 扇入扇出度 | 模块被调用 / 调用其他模块的数量 |
| CBO | 模块间耦合度 | 模块之间的依赖紧密程度 |
| RFC | 模块的响应 | 模块响应外部请求所涉及的方法集 |
| TCC | 紧内聚度 | 模块内部紧密相关的程度 |
| LCC | 松内聚度 | 模块内部松散相关的程度 |
速记
"圈扇耦响紧松" —— 圈复杂度、扇入扇出、耦合、响应、紧/松内聚。
高内聚低耦合是目标 → TCC / LCC 越高越好；CBO 越低越好。
高内聚低耦合是目标 → TCC / LCC 越高越好；CBO 越低越好。
本章重点回顾
① 三要素（组件、连接件、约束）
② 消息演化 5 种 + 复合片段 4 种 + 约束 2 种
③ 演化时期 4 个 + 静态演化原子操作（可维护性 8 + 可靠性 11）
④ 动态重配置 4 模式 + DSA 3 描述语言（π-ADL / Pilar / LIME）
⑤ 18 条演化原则 + 6 个可维护性度量指标
⑥ 大型网站演化 10 阶段
② 消息演化 5 种 + 复合片段 4 种 + 约束 2 种
③ 演化时期 4 个 + 静态演化原子操作（可维护性 8 + 可靠性 11）
④ 动态重配置 4 模式 + DSA 3 描述语言（π-ADL / Pilar / LIME）
⑤ 18 条演化原则 + 6 个可维护性度量指标
⑥ 大型网站演化 10 阶段