27.软件架构演化(概念、定义、分类)

大家好！今天我们继续细说软考高级架构知识点。本节我们学习软件架构演化的内容

1. 软件架构演化的定义

软件架构演化是为适应新需求、业务与运行环境变化，持续对软件架构开展调整迭代，以此维持架构自身有用性；本质是软件整体结构的演化，贯穿软件架构全生命周期，涵盖架构需求获取、建模、实现、维护等阶段，通过组件、连接件、约束的增删改，完成纠错性、完善性修改，让软件持续适配环境变化、满足用户需求。

2. 软件架构演化的重要性

1.支撑系统核心质量特性

2.管控系统复杂度，降低变更成本

3.保障演化一致性、正确性，提升可构建性

a.架构形式化、可视化描述提升系统可构造性；

b.架构完整的结构、配置、约束信息，便于提前预判未来演化场景；

c.架构定义的组件耦合关系，支撑系统动态调整。

3. 软件架构演化和架构定义的关系

1.软件架构存在上百种不同定义，不同定义规定了架构组成要素与规则，理解架构演化必须结合对应的架构定义。

2.以经典定义

为例：架构由组件、连接件、约束三大要素构成，架构演化本质就是对这三类要素执行增加、修改、删除操作：

组件演化：模块增删改，带来交互消息连锁变化；

连接件演化：组件间交互消息新增、删除、调整；

约束演化：架构拓扑、配置、参数的调整。

3.组件、连接件、约束任意一类发生变更，都会产生波及效应，划分出受变更影响、不受变更影响的架构元素，所有元素共同构成演化后的全新架构。

4.面向对象软件架构演化过程（基于 UML 顺序图）

面向对象软件架构演化分为四大类：对象演化、消息演化、复合片段演化、约束演化

4.1 对象演化

仅两类会影响架构动态行为：

1.AO（AddObject）新增对象

场景：系统需要新增功能，或者把现有对象的功能拆分独立出来，提升架构灵活性。

举例：订单系统新增「退款对象」，独立处理退款业务。

2.DO（DeleteObject）删除对象

场景：移除废弃功能、合并对象降低架构复杂度。

举例：删除旧版积分结算对象，统一合并到会员对象。

补充说明：单纯增删对象若无交互消息，则对架构无实质影响，对象演化一般伴随消息演化。

4.2 消息演化（共 5 种）

消息代表对象间交互行为，直接影响架构正确性与时序属性

AM（AddMessage）增添消息

举例：用户对象新增向日志对象发送操作记录消息。

DM（DeleteMessage）删除消息（AM 逆操作）

举例：移除支付对象向旧通知组件发送的短信消息。

SMO（SwapMessageOrder）交换两条消息时序

举例：调整系统为先扣库存、再生成订单，修改原有消息执行顺序。

OM（OverturnMessage）反转消息收发对象

举例：原本 A 推送数据给 B，改为 B 主动向 A 拉取数据。

CMM（ChangeMessageModule）修改消息收发对象

举例：消息接收方由旧版推送组件更换为消息队列组件。

消息演化分为三类：不涉及约束、涉及约束但不违反、违反约束（非法演化）。

4.3 复合片段演化

复合片段描述对象交互控制流，属于连接件范畴，主要 4 种操作：

AF（AddFragment）新增复合片段

场景：增加新控制流程；

举例：在交互流程增加 loop 循环片段，实现轮询重试。

DF（DeleteFragment）删除复合片段，AF 逆操作

举例：删除 alt 分支判断片段，取消可选流程。

FCC（FragmentConditionChange）修改执行条件

举例：修改 alt 分支条件，从 “金额> 1000” 调整为 “金额 > 5000”。

FTC（FragmentTypeChange）修改片段类型

举例：将普通顺序片段修改为 par 并行片段，实现并发调用。

提示：复合片段演化改变交互流程，需要验证，防止违反系统约束。

4.4 约束演化

顺序图约束一般使用 LTL 描述时态属性，分为两种基础操作：

AC（AddConstraint）新增约束

举例：增加约束「订单提交后 3s 内必须调用支付接口」，需要校验现有流程是否满足约束。

DC（DeleteConstraint）删除约束

举例：取消 “所有请求必须串行执行” 的时序约束。

补充：约束没有可视化图形；修改约束等价执行：DC 删除旧约束 + AC 添加新约束。

5.软件架构演化方式（演化时期、静态演化、动态演化）

5.1按照演化所处时期划分 4 类

5.1.1设计时演化

概念：发生在架构模型建立、代码编译之前的架构调整。

举例：概要设计阶段，发现模块耦合过高，重新划分组件接口。

5.1.2运行前演化

概念：编译完成、程序正式执行之前进行架构修改，程序尚未启动，无需考虑运行状态，但要保证组件增删机制可用。

举例：应用打包完成、上线启动前，替换其中一个第三方适配组件。

5.1.3有限制运行时演化

概念：系统预先定义演化条件，只有满足指定约束、进入安全模式时，才能执行规定的变更操作。

举例：后台系统设定凌晨低峰时段，才允许动态更新报表组件。

5.1.4运行时演化

概念：系统正在运行，现有架构无法满足需求时在线调整架构，支持增删、替换组件、调整拓扑结构；实现难度最高。

举例：微服务系统不停机扩容、替换故障服务实例。

5.2静态演化

概念：系统处于停止运行状态下开展修改与更新，就是常规意义上软件修复、版本升级。

需求来源

①设计时演化需求：开发阶段调整架构，保证实现与架构一致；

②运行前演化需求：软件发布后，环境变化带来版本升级改造。

标准过程（5 步循环迭代）

软件理解 → 需求变更分析 → 演化计划 → 系统重构 → 系统测试

举例

软件下线停机维护，重构数据库访问层架构，重新打包、测试后部署新版本。

5.3动态演化

概念：系统正常持续运行期间，不停止服务，在线完成架构调整；对应上面的【有限制运行时演化】与【运行时演化】。

特点

需要保障演化过程中系统持续可用，复杂度远高于静态演化。

举例

微服务架构使用灰度发布，不停止整个系统，逐步替换旧版本订单服务组件。

区分小结：

静态演化：停机变更；动态演化：不停机在线变更

补充知识点：软件架构演化的 3 种经典分类方法

1.按照软件架构实现方式和实施粒度划分

分为：基于过程和函数的演化、面向对象的演化、基于组件的演化、基于架构的演化。

举例：传统 C 语言面向过程模块调整属于基于过程演化；Java 系统类与对象调整属于面向对象演化；微服务组件热替换属于基于组件演化。

2.Jeffrey M. Barnes 分类方法（四类）

① 演化支持：代码模块化准则、内聚与耦合、代码重构等；

② 版本和工程管理工具：CVS、COCOMO 模型；

③ 架构变换形式化方法：系统结构、行为变换模型、架构演化重现风格；

④ 架构演化成本收益分析，用来判断如何提升系统弹性。

3.按照系统是否处于运行状态

静态演化、动态演化（前面已经详细讲解）

6.思维导图

非常感谢大家一直以来的支持与陪伴！如果这期内容对你有收获、有帮助，欢迎点赞、关注，持续解锁更多IT架构干货，我们下期再见！