【2024软考架构师自学笔记】9. 软件架构的演化和维护

---

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

9.1.1演化的重要性

1）是软件系统具备诸多好的特性的重要保障。
2）为人们宏观管控软件系统的整体复杂性和变化性提供了一条有效途径。
3）可以更好地保证软件演化的一致性和正确性。

9.1.2演化和定义的关系

软件架构包括组件 (Components)、 连接件 (Connectors) 和约束 (Constraints) 三大要素，这类软件
架构演化主要关注的就是组件、连接件和约束的添加、修改与删除等。

9.2 面向对象软件架构演化过程

9.2.1对象演化

对架构设计的动态行为产生影响的演化包括 Add Object（AO）和 Delete Object（DO）。
（1）AO 是在系统需要添加新的对象来实现某种新的功能，或需将现有对象的某个功能独立以增加架构灵活性时发生。
（2）DO 是在系统需要移除某个现有的功能，或需合并某些对象及其功能来降低架构的复杂度的时候发生。

9.2.2消息演化

消息演化包括 Add Message（AM）、Delete Message（DM）、Swap Message Order（SMO）、
Overturn Message（OM）、Change Message Module（CMM）。
（1）AM：增添一条新的消息，产生在对象之间需要增加新的交互行为的时候。
（2）DM：删除当前的一条消息，产生在需要移除某交互行为的时候。
（3）SMO：交换两条消息的时间顺序，发生在需要改变两个交互行为之间的时候。
（4）OM：反转消息的发送对象与接收对象，发生在需要修改某个交互行为本身的时候。
（5）CMM：改变消息的发送或接收对象，发生在需要修改某个交互行为本身的时候。

9.2.3复合片段演化

复合片断的演化包括 Add Fragment（AF）、Delete Fragment（DF）、Fragment Type Change
（FTC）、Fragment Condition Change（FCC）。
（1）AF：在某几条消息上新增复合片段，发生在需要增添新的控制流时。
（2）DF：删除某个现有的复合片段，发生在需要移除当前某段控制流时。
（3）FTC：改变复合片段的类型，发生在需要改变某段控制流时。
（4）FCC：改变复合片段内部执行的条件，发生在改变当前控制流的执行条件时。

9.2.4约束演化

约束演化包括 Add Constraint（AC）、Delete Constraint（DC）。
（1）AC：直接添加新的约束信息，需判断当前设计是否满足新添加的约束要求。
（2）DC：直接移除某条约束信息，发生在去除某些不必要条件的时候。

9.3 软件架构演化方式的分类

(1)按照软件架构的实现方式和实施粒度分类：基于过程和函数的演化、面向对象的演化、基于组件的演化和基于架构的演化。
(2)按照研究方法将软件架构演化方式分为4类：
第1类是对演化的支持，如代码模块化的准则、可维护性的指示(如内聚和耦合)、代码重构等；
第2类是版本和工程的管理工具，如CVS和COCOMO;
第3类是架构变换的形式方法，包括系统结构和行为变换的模型，以及架构演化的重现风格等；
第4类是架构演化的成本收益分析，决定如何增加系统的弹性。
(3)针对软件架构的演化过程是否处于系统运行时期，可以将软件架构演化分为静态演化
(Static Evolution) 和动态演化 (Dynamic Evolution), 前者发生在软件架构的设计、实现和维护
过程中，软件系统还未运行或者处在运行停止状态；后者发生在软件系统运行过程中。

9.3.1软件架构演化时期

（1）设计时演化：发生在体系结构模型与之相关的代码编译之前。
（2）运行前演化：发生在执行之前、编译之后。
（3）有限制运行时演化：只发生在某些特定约束满足时。
（4）运行时演化：发生在运行时不能满足要求时。

9.3.2软件架构静态演化

（1）静态演化需求：设计时演化需求、运行前演化需求。
（2）静态演化的一般过程：软件理解→需求变更分析→演化计划→系统重构→系统测试
（3）静态演化的原子演化操作。
1）与可维护性相关的架构演化操作：AMD（Add Module Dependence）、RMD（Remove Module
Dependence）、AMI（Add Module Interface）、RMI（Remove Module Inferface）、AM（Add Module）、RM（Remove Module）、SM（Split Module）、AGM（Aggregate Modules）。
2）与可靠性相关的架构演化操作：AMS（Add Message）、RMS（Remove Message）、AO（Add
Object）、RO（Remove Object）、AF（Add Fragment）、RF（Remove Fragment）、CF（Change Fragment）、AU（Add Use Case）、RU（Remove Use Case）、AA（Add Actor）、RA（Remove Actor）。

9.3.3软件架构动态演化

（1）动态演化需求：软件内部执行所导致的体系结构改变、软件系统外部的请求对软件进行的重配置。
（2）动态演化的类型。
1）软件动态性的等级：交互动态性、结构动态性、架构动态性。
2）动态演化的内容：属性改名、行为变化、拓扑结构改变、风格变化。
（3）动态软件架构（DSA）。
1）基于 DSA 实现动态演化的基本原理是运行时刻体系结构相关信息的改变可用来触发、驱动系统自身的动态调整。
2）DSA 描述语言：基于行为视角的 π-ADL、基于反射视角的 Pilar、基于协调视角的 LIME。
3）DSA 演化工具：使用反射机制、基于组件操作、基于 π 演算、利用外部的体系结构演化管理器
（4）动态软件架构应用实例—PKUAS：包括容器系统、公共服务、工具和微内核 4 种类型。
（5）动态重配置。
1）动态重配置模式：主从模式、中央控制模式、客户端/服务器模式、分布式控制模式。
2）例子：可重用、可配置的产品线架构。
3）动态配置难点：约束定义困难、性能约束难以静态衡量、难以管理所有方面、需同时保证组件系统完整性和重配置策略的正确和安全性。

9.4 软件架构演化原则

软件结构包括 18 种可持续演化原则：
（1）演化成本控制原则：演化成本要控制在预期的范围之内。
（2）进度可控原则：架构演化要在预期的时间内完成。
（3）风险可控原则：架构演化中的经济风险、时间风险、人力风险、技术风险和环境风险在可控范围内。
（4）主体维持原则：软件演化的平均增量的增长须保持平稳，保证软件系统主体行为稳定。
（5）系统总体结构优化原则：使演化后的软件系统整体结构（布局）更加合理。
（6）平滑演化原则：软件的演化速率趋于稳定。
（7）目标一致原则：架构演化的阶段目标和最终目标要一致。
（8）模块独立演化原则：软件中各模块自身的演化最好相互独立。
（9）影响可控原则：如果一个模块发生变更，给其他模块带来的影响在可控范围内。
（10）复杂性可控原则：必须控制架构的复杂性，保障软件的复杂性在可控范围内。
（11）有利于重构原则：使演化后软件架构便于重构。
（12）有利于重用原则：演化最好能维持，甚至提高整体架构的可重用性。
（13）设计原则遵循性原则：架构演化最好不能与架构设计原则冲突。
（14）适应新技术原则：软件要独立于特定的技术手段，可运行于不同平台。
（15）环境适应性原则：架构演化后的软件版本比较容易适应新的硬件环境和软件环境。
（16）标准依从性原则：演化不违背相关质量标准（国际标准、国家标准、行业标准等）。
（17）质量向好原则：使所关注的某个质量指标或质量指标的综合效果变更好。
（18）适应新需求原则：很容易适应新的需求变更。

9.5 软件架构演化评估方法

（1）演化过程已知的评估。
评估流程：将架构度量应用到演化过程中，通过对演化前后的不同版本的架构分别进行度量，得到度量结果的差值及其变化趋势，并计算架构间质量属性距离，进而对相关质量属性进行评估。
（2）演化过程未知的评估，见书354页图。

9.6大型网站系统架构演化实例

第一阶段：单体架构。
应用程序、数据库、文件等所有资源都在一台服务器上。
第二阶段：垂直架构。
将应用和数据分离，整个网站使用 3 台服务器：应用服务器、文件服务器、数据服务器。
第三阶段：使用缓存改善网站性能。
包括在应用服务器上的本地缓存和在专门的分布式缓存服务器上的远程缓存。
第四阶段：使用服务集群改善网站并发处理能力。
通过负载均衡调度服务器，将来自用户浏览器的访问请求分发到应用服务器集群中的任何一台服务器上，解决高并发、海量数据问题。
第五阶段：数据库读写分离。
应用服务器在写数据时，访问主数据库，主服务器通过主从复制机制将数据更新同步到从服务器。在应用服务器读数据时，访问从数据库。
第六阶段：使用反向代理和 CDN 加速网站响应。CDN 和反向代理的基本原理都是缓存。
（1）CDN 部署在网络提供商的机房，用户在请求网站服务时，可在距离最近的网络提供商机房获取数据。
（2）反向代理部署在网站的中心机房，用户请求到达中心机房后，先访问反向代理服务器。
第七阶段：使用分布式文件系统和分布式数据库系统。
进行业务分库，将不同业务的数据部署在不同的物理服务器上。
第八阶段：使用 NoSQL 和搜索引擎。
第九阶段：业务拆分。
将一个网站拆分成许多不同的应用，每个应用独立部署。
第十阶段：分布式服务。

9.7 软件架构维护

软件架构维护过程包括软件架构知识管理、软件架构修改管理、软件架构版本管理等。
（1）软件架构知识管理。
1）架构知识的定义：架构知识=架构设计+架构设计决策。
2）架构知识管理的含义：侧重于软件开发和实现过程所涉及的架构静态演化，在架构文档等信息来源中捕捉架构知识，提供架构的质量属性及其设计依据进行记录和评价。
3）架构知识管理的需求：防止关键的设计知识“沉没”在软件架构中。
（2）软件架构修改管理。
主要是建立一个隔离区域，保障该区域中任何修改对其他部分影响最小。
（3）软件架构版本管理。
为软件架构演化的版本演化控制、使用和评价提供可靠依据。
（4）软件架构可维护性度量实践。
架构可维护性的 6 个度量指标：圈复杂度（CNN）、扇入扇出度（FFC）、模块间耦合度（CBO）、
模块的响应（RFC）、紧内聚度（TCC）、松内聚度（LCC）。