原子标签索引：[概念×14 | 机制×2 | 流程×5 | 分类×6 | 判据×4 | 数据×4 | 案例×3] 上游：第6章（架构风格）、第7章（架构评估/ATAM）、第9章（可靠性度量） 下游：第16章（架构演化实践）
标准表述
- 软件架构的演化：为适应用户新需求、业务环境和运行环境变化，维持软件架构自身有用性而进行的修改过程；本质是软件整体结构的演化，涵盖架构需求获取、建模、文档、实现、维护全生命周期。
- "软件架构是演化来的，而不是设计来的。"
- 架构演化定义视角：若 SA={components, connectors, constraints}，演化即组件、连接件、约束的添加、修改与删除。
- 组件演化体现为模块的增加、删除或修改，会产生波及效应。
- 连接件演化体现为组件交互消息的增加、删除或改变。
- 约束演化体现为知识库中仿真数据的增加、删除或改变。
- 对象演化仅含两种影响动态行为的操作：添加对象（AO）、删除对象（DO）。
- 消息演化 5 种：添加消息（AM）、删除消息（DM）、交换消息顺序（SMO）、反转消息（OM）、改变消息模块（CMM）。
- 复合片段演化 4 种：添加（AF）、删除（DF）、类型改变（FTC）、条件改变（FCC）。
- 约束演化 2 种：添加约束（AC）、删除约束（DC）；约束修改可视为删除原约束+添加新约束。
- 静态演化：发生在软件架构的设计、实现和维护过程中（系统未运行或停止运行状态）。
- 动态演化：发生在软件系统运行过程中，需在不停止系统功能的情况下完成演化。
- 演化时期 4 种：设计时演化、运行前演化、受约束的运行时演化、运行时演化（最难实现）。
- 静态演化对应三类维护：更正性维护、适应性维护、完善性维护。
- 原子演化操作：基于 UML 模型表示的软件架构在逻辑语义上粒度最小的架构修改操作。
- 正交软件架构：对功能进行分层和线索化，同一层次中的组件不允许相互调用，每个变动仅影响一条线索。
- 动态性三级（Carlos E. Cuesta）：交互动态性→结构动态性→架构动态性；只有级别 3 才是真正的动态架构。
- 动态演化实现技术两种：动态软件架构（DSA）与动态重配置（DR）。
- 架构知识 = 架构设计 + 架构设计决策（Lago 定义）。
- 架构修改管理主要做法：建立一个隔离区域（Region of Quiescence），保障其中修改对其他部分影响极小。
- 演化评估分两类：演化过程已知的评估、演化过程未知的评估。
蒸馏笔记
概念
- 演化：软件架构为维持自身有用性而随需求/环境变化不断迭代的过程。
- 维护：使软件适应环境变化的纠错性修改和完善性修改等活动。
- 对象演化：顺序图中组件实体的增删（AO/DO），自身属性变化不算。
- 消息演化：顺序图核心元素（含名称、源对象、目标对象、时序）的 5 种变化。
- 复合片段：对象交互关系的控制流描述，与消息同属连接件范畴；分支类型有 ref、loop、break、alt、opt、par。
- 约束：组件和连接件之间的拓扑关系和配置，可用 LTL 描述时态属性。
- 静态演化：系统停止运行期间的修改更新，即一般意义上的软件修复和升级。
- 动态演化：系统运行期间的演化；需求来源：①软件内部执行导致架构改变（如服务器为客户请求创建新组件）；②外部请求的重配置（如操作系统在线升级）。
- 设计时演化：发生在架构模型和与之相关的代码编译之前。
- 运行前演化：编译之后、执行之前；修改不考虑应用状态但需考虑架构。
- 受约束的运行时演化：设计时规定了演化条件，演化只发生在特定约束满足时。
- 运行时演化：架构在运行时不能满足要求时发生，含添加/删除/升级替换组件、改变拓扑，最难实现。
- DSA（动态软件架构）：在软件运行时刻会发生变化的体系结构（Bradbury：可修改自身架构并在系统执行期间进行修改）。
- DR（动态重配置）：软件部署之后对配置信息的修改。
- 正交软件架构：静态演化的典型应用实例。
- 架构知识管理：对架构设计决策及来源进行文档化表示的活动。
机制
- 模块增/删/改 →(产生波及效应) 交互消息增/删/改 →(直接影响) 架构正确性或时态属性。
- 消息演化与约束关系分 3 类：①与当前约束无关（如多数 AM）→不影响正确性；②与约束关联但不违背（如 CMM）→不影响正确性；③与约束关联且违背（如 DM 删除约束涉及的消息）→不正确的演化。
流程
静态演化 5 步骤： 1. 软件理解：查阅文档、分析架构、识别元素及其关系，提取抽象表示。 2. 需求变更分析：找出新需求与原有需求的差异。 3. 演化计划：确定演化范围和成本，选择合适计划。 4. 系统重构：按演化计划重构，使之适应当前需求。 5. 系统测试：查找错误和不足。
正交软件架构演化过程：①需求变动归类（对应现有组件和线索，判断重用）→②制定架构演化计划→③修改、增加或删除组件→④更新组件之间的相互作用→⑤产生演化后的软件架构。
DSA 实施动态演化 4 步：①捕捉并分析需求变化→②获取或生成体系结构演化策略→③选择适当演化策略并实施演化→④演化后的评估与检测。（需 DSA 描述语言和演化工具支持；须保证演化操作原子性——一操作失败则整个操作集撤销。）
演化过程已知的评估流程：将完整演化拆为原子操作序列，得到中间版本序列 A₀,A₁,…,Aₙ →对每个版本度量得质量属性值 Q₀,Q₁,…,Qₙ →计算相邻版本质量属性距离 D(i-1,i) →计算 A₀ 与 Aₙ 间距离 D(0,n) →综合评估。
演化过程未知的评估：度量演化前后两版本→计算质量属性距离→逆向推测发生的演化操作及其位置、对象→分析各操作对质量属性的影响及高层驱动原因（修复错误、提高性能、平台移植）→判断演化结果是否符合预期。
分类体系
演化方式 3 种典型分类法： 1. 按实现方式和实施粒度：基于过程和函数的演化、面向对象的演化、基于组件的演化、基于架构的演化。 2. Jeffrey M. Barnes 等按研究方法分 4 类：①对演化的支持（模块化准则、内聚耦合、代码重构）；②版本和工程管理工具（如 CVS、COCOMO）；③架构变换的形式方法；④架构演化的成本收益分析。 3. 按是否处于运行期：静态演化 / 动态演化。
消息演化 5 种操作（封闭集合）：
| 操作 | 含义 | 发生场景 |
|---|---|---|
| AM | 增添新消息 | 对象间需增加新的交互行为 |
| DM | 删除当前消息 | 需移除某个交互行为（AM 的逆向） |
| SMO | 交换两条消息顺序 | 需改变两个交互行为之间的关系 |
| OM | 反转消息发送对象与接收对象 | 需修改某个交互行为本身 |
| CMM | 改变消息的发送或接收对象 | 需修改某个交互行为本身 |
复合片段演化 4 种：AF（新增控制流）、DF（移除控制流，AF 的逆向）、FTC（改变类型=删除+添加的组合）、FCC（改变执行条件，同时修改符合/不符合两转移的触发事件）。
动态性三级（Cuesta）：①交互动态性——数据在固定结构下动态交互；②结构动态性——组件和连接件实例的添加删除（当前研究主流）；③架构动态性——架构基本构造可被重定义（如新组件类型）。现有研究大多仅支持级别 1、2。
动态演化修改内容 4 方面：属性改名、行为变化（如换加密算法、HTTP→HTTPS）、拓扑结构改变（增删组件/连接件、改关联关系）、风格变化（只能变为衍生风格，如两层 C/S→三层 C/S 或 C/S+B/S 混合）。
DSA 描述语言按描述视角分 3 类： - 行为视角：π-ADL——基于 π 演算（进程代数），为移动系统建模，模型含组件、连接件、行为，所有元素随时间演化。 - 反射视角：Pilar——基于反射理论（MARMOL 元-基系统分层模型），组件由接口、配置、具化（Reification）、约束 4 部分组成；实际反射模型一般少于 3 层。 - 协调视角：LIME——Linda 的扩展，支持移动应用，分离计算部分和协调部分。
动态重配置 4 种模式：
| 模式 | 要点 | 适用 |
|---|---|---|
| 主从（Master-Slave） | 主组件分派工作给从组件并合并结果；从组件空闲时等待激活 | 任务分解 |
| 中央控制（Centralized Control） | 一个中央控制器控制多个组件，状态图维持两个状态标识空闲与否 | 实时系统 |
| 客户端/服务器 | 同步消息交互；客户端事务完成后可增删客户端；顺序/并发服务器在事务（集合）完成后可增删 | 分布式服务 |
| 分布式控制 | 功能整合于多个分布式控制组件；有环形（Ring，前驱+后继）和顺序（Serial）两种 | 分布式应用 |
动态重配置 4 难点（Tamura，带 QoS 约束）：①约束定义困难；②性能约束难以静态衡量，需运行时评估；③单一方案难以管理所有约束方面；④须同时保证组件系统的完整性和重配置策略的正确、安全性。
判据
可维护性相关原子演化操作（基于组件图，8 种）：AMD（增加模块间依赖）/RMD（删除）/AMI（增加模块间接口）/RMI（删除）/AM（增加模块）/RM（删除）/SM（拆分模块）/AGM（聚合模块）。
可靠性相关原子演化操作（基于用例图、部署图、顺序图，11 种）：AMS/RMS（增删消息）、AO/RO（增删交互对象）、AF/RF/CF（增删改消息片段）、AU/RU（增删用例）、AA/RA（增删参与者）。
架构演化 18 条可持续演化原则（名称+度量必须记牢）：
| # | 原则 | 度量 |
|---|---|---|
| 1 | 演化成本控制 ECC | CoE ≪ CoRD（演化成本远小于重新开发成本） |
| 2 | 进度可控 | t_task = |
| 3 | 风险可控 | 分别检验（时间/经济/人力/技术风险均不存在） |
| 4 | 主体维持（AIG） | AIG = 主体规模的变更量 / 主体的规模 |
| 5 | 系统总体结构优化 | 检查整体可靠性和性能指标 |
| 6 | 平滑演化（IWR） | IWR = 变更总量 / 项目规模，趋于稳定 |
| 7 | 目标一致 | o_task = |
| 8 | 模块独立演化（修改局部化） | 计算修改影响范围 |
| 9 | 影响可控 | 检查影响范围可控（影响可预测） |
| 10 | 复杂性可控 | CC < 某个阈值 |
| 11 | 有利于重构 | 检查系统复杂度指标（越复杂越难重构） |
| 12 | 有利于重用 | 检查内聚度（高）、耦合度（低） |
| 13 | 设计原则遵从性 | RCP = |
| 14 | 适应新技术 TI | TI = 1 - DDT，DDT = 依赖的技术集合/用到的技术集合 |
| 15 | 环境适应性 | 硬件/软件兼容性度量 |
| 16 | 标准依从性 | 人工判定（不违背国际/国家/行业/企业标准） |
| 17 | 质量向好 QI | EQI ≥ SQ（演化后质量≥原质量） |
| 18 | 适应新需求 RNR | RNR = |
可维护性 6 个子度量指标：圈复杂度 CCN、扇入扇出度 FFC、模块间耦合度 CBO、模块的响应 RFC、紧内聚度 TCC、松内聚度 LCC。
架构质量属性距离判据：D(i-1,i) 越大质量差距越大；质量属性差异与架构内部结构差异无正相关关系；原子演化的质量属性影响不具有累加性，即 D(0,n) ≠ D(0,1)+D(1,2)+…；质量属性距离应只针对同一架构的不同演化版本度量。
数据
可维护性度量公式（以 Web 读写系统实践为例）： - CCN = (totalE - totalN) + 2L（totalE/totalN 为组件图所有边/节点数，L 为组件图数目）；实践：CCN=(19-13)+2×1=8。 - FFC = CCN × (E+W) × (X+R)²（E 出边、W 提供接口、X 入边、R 使用接口）；实践：8×(1+1)×(0+1)²=32。 - RFC = S + E + R（S 内部组件数）；实践：2+1+1=4。 - CCN 为整体结果；FFC/RFC/CBO/TCC/LCC 取所有组件结果的平均值。 - 实践结论：程序规模以 CCN ≤ 10 为宜；无子组件的组件 TCC/LCC 记 "not applied"（内聚度视为最小）。
大型网站架构演化 10 阶段（案例题高频）： 1. 单体架构——应用、数据库、文件全在一台服务器。 2. 垂直架构（应用与数据分离）——3 台服务器：应用（需强 CPU）、文件（需大硬盘）、数据库（需快磁盘大内存）。 3. 使用缓存改善性能——二八定律：80% 业务访问集中在 20% 数据上；分本地缓存、远程分布式缓存。 4. 使用应用服务器集群——负载均衡调度，改善并发处理能力，实现可伸缩性。 5. 数据库读写分离——利用主从热备/主从复制；写主库、读从库，数据访问模块对应用透明。 6. 反向代理和 CDN——基本原理都是缓存；CDN 在网络提供商机房，反向代理在中心机房；尽早返回数据。 7. 分布式文件系统和分布式数据库——数据库拆分最后手段；更常用的是业务分库。 8. NoSQL 和搜索引擎——对可伸缩分布式特性支持更好；统一数据访问模块。 9. 业务拆分——按产品线拆分成不同应用独立部署，用超链接、消息队列、公共数据存储关联。 10. 分布式服务——把共用业务（用户管理、商品管理等）提取为独立部署的分布式服务；解决连接数是服务器规模平方、数据库连接资源不足的问题。
案例
- PKUAS（北京大学，Java EE 组件运行支撑平台）：基于 JMX 微内核，4 类实体=容器系统、公共服务、工具、微内核；资源层通过 MBean 接口对外提供管理属性和操作（10.3.3）。
- PuLSE（Bayer 等）产品线方法论与 Gomaa 多视角元模型（用例/静态/交互/状态机/特性模型+OCL 一致性检查）——产品线动态重配置实例（10.3.3）。
- Web 读写系统可维护性度量实践：组件图导出 XML 输入 MSAES 评估系统，CCN=8、FFC 最终值 46.154、RFC 最终值 1.615、CBO 最终值 0.219（10.7.4）。
易错点 / 边界情况
- 对象演化中：属性（接口、类型、语义）变化不算演化；AO/DO 若未伴随消息演化，则对系统无意义（不影响架构正确性或时态属性）。
- 消息是顺序图的核心，消息演化是顺序图演化的核心；复合片段和约束均基于消息存在。
- FTC（类型改变）= 复合片段删除+添加的组合，一般伴随条件、内部执行序列同时演化。
- 约束演化无自动机描述（约束信息以文字存储于对象或消息中）；修改约束 = DC + AC。
- 4 种演化时期排序：设计时→运行前→受约束的运行时→运行时；最易→最难；静态演化覆盖前两种，动态演化覆盖后两种。
- 静态演化≠只在设计时：含设计时演化和运行前演化两种需求。
- 演化后架构风格一般保持不变；要改也只能改为衍生风格。
- DSA 归结为架构动态性（级别 3 的问题），DR 归结为结构动态性（级别 2 的问题）。
- 架构知识 ≠ 架构设计：架构知识 = 架构设计 + 架构设计决策。
- 架构知识管理文档化难的原因：好处不明显成本高、利益相关者短期兴趣、开发者不反思长远影响、缺乏培训。
- D(i-1,i) 不可累加：原子操作的质量属性影响不具有累加性。
- 质量属性距离只对同一架构的不同演化版本有意义，对不同软件架构无实际意义。
- 18 原则中数字度量方向：RCP、RNR、o_task、t_task 越小越好；AIG 保持平稳；EQI≥SQ。
- 动态重配置 4 模式与架构风格区分：主从/中央控制/C-S/分布式控制是"重配置模式"，不是架构风格。
- 集群阶段要点：不要企图更换更强大的服务器，应增加服务器分担压力（可伸缩性核心思想）。