软考高级架构 —— 第十章 软件架构演化与维护

第十章 软件架构演化与维护

软件架构的演化和维护就是对软件架构进行修改和完善 的过程，其目的是让软件架构适应环境变化，满足用户需求。软件架构的演化是贯穿软件架构全生命周期的过程，包括需求获取、建模、文档编制、实现与维护。

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

1、演化的目的

• 纠错性修改：修复架构设计缺陷。
• 完善性修改：改进架构性能和功能。
• 适应性修改：调整架构以应对技术或业务环境的变化。

2、演化的重要性

• 软件架构作为系统骨架，直接影响系统的：性能、可靠性、安全性、可维护性。
• 宏观控制工具：架构蓝图简化了复杂系统的管理，降低了演化成本。
• 一致性与效率：通过架构明确模块间关系，确保演化过程有序推进。
• 软件架构的演化能够降低软件演化的成本

3、演化的三大要素

• 组件（Components）：系统的基本单元，如模块或功能块，变化体现在增删改

• 连接件（Connectors）：组件之间的交互关系，演化体现在交互消息的变化

• 约束（Constraints）：定义组件和连接件之间的拓扑关系或配置参数。

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

面向对象软件架构的演化过程主要结合 UML 顺序图，从 对象演化（构件） 、消息演化（连接） 、复合片段演化（连接） 和 约束演化 四个方面展开。

1、对象演化

对象演化的两种操作：新增与删除

1. AddObject (AO)：在顺序图中新增一个对象。例如需要增加新功能，或将某功能从现有对象中独立出来。

2. DeleteObject (DO)：在顺序图中删除一个对象。例如移除无用功能，或合并多个对象以简化架构。

2、 消息演化

消息的五种演化操作：新增、删除、调整顺序、反转、修改。

1. AddMessage (AM)：新增对象间的交互消息，例如添加新的功能或增强现有行为

2. DeleteMessage (DM)：删除对象间的一条交互消息

3. SwapMessageOrder (SMO)：调整两条消息的顺序。

4. OverturnMessage (OM)：反转消息的发送者与接收者（反方向）。

5. ChangeMessageModule (CMM)：修改消息的发送或接收对象。

3、复合片段演化

复合片段用于描述对象间交互的控制流，演化操作主要有以下四种：新增、删除、修改类型、修改执行条件。

1. AddFragment (AF)：新增 一个复合片段（如 ref、loop、alt 等）

2. DeleteFragment (DF)：删除现有的复合片段

3. FragmentTypeChange (FTC)：改变复合片段的类型 （如 loop 改为 par）

4. FragmentConditionChange (FCC)：改变复合片段的执行条件。

4、约束演化

约束反映架构的配置或系统属性，通常以 LTL（时态逻辑）描述。演化包括：

1. AddConstraint (AC)：新增约束

2. DeleteConstraint (DC)：删除约束

演化之间的关系与影响

1. 对象与消息：对象演化通常伴随消息演化。
2. 消息与约束：消息演化可能触发或违背约束条件。
3. 复合片段与消息：复合片段的变化会引发消息序列的变化，需验证逻辑正确性。
4. 全局验证：每种演化都可能改变架构的时态属性和正确性，需通过形式化验证工具检测潜在问题。

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

以下列举了三种较为典型的分类方式：

(1) 按照软件架构的实现方式和实施粒度分类

• 基于过程和函数的演化：演化基于具体的功能逻辑或过程实现，适用于传统的过程化编程。
• 面向对象的演化：演化通过对象及其属性、行为的调整来实现，适用于面向对象的编程范式。
• 基于组件的演化：演化以独立的功能模块（组件）为单位，关注组件间接口与协作方式的变化。
• 基于架构的演化：演化以系统的整体架构为视角，关注架构风格和模式的调整。

(2) 按照研究方法分类（了解）

对演化的支持、版本和工程管理工具、架构变换的形式方法、架构演化的成本收益分析。

(3) 按照演化过程是否发生在系统运行期间分类（重点）

1、软件架构演化时期

静态：设计时演化、运行前演化

动态：有限制运行时演化、运行时演化

2、软件架构静态演化

**维护方法：**更正性维护、适应性维护、完善性维护

步骤：

1. 软件理解：查阅软件文档,分析软件架构,识别系统组成元素及其之间的相互关系,提取系统的抽象表示形式。
2. 需求变更分析：静态演化往往是由于用户需求变化、系统运行出错和运行环境发生改变等原因所引起的,需要找出新的软件需求与原有的差异。
3. 演化计划：分析原系统,确定演化范围和成本,选择合适白的演化计划
4. 系统重构：根据演化计划对系统进行重构,使之适应当前的的需求。
5. 系统测试：对演化后的系统进行测试,查找其中的错误和不足之处

原子演化操作

1、定义

• 概念 ：逻辑语义上粒度最小的架构修改操作，无法再拆分。
  • 示例：增加模块会同时影响模块间依赖关系和内部类、接口，但整体视为一个原子操作。
• 影响：每次原子操作生成一个新的架构中间版本 AiA_i，通过序列 A0,A1,A2,...,AnA_0, A_1, A_2, \dots, A_n 达成演化目标。

2. 与可维护性相关的原子操作

架构演化的可维护性度量基于组件图表示的软件架构，在较高层次上评估架构的某个原子
修改操作对整个架构所产生的影响。

3. 与可靠性相关的原子操作

架构演化的可靠性评估基于用例图、部署图和顺序图，分析在架构模块的交互过程中某个
原子演化操作对交互场景的可靠程度的影响。

4. 正交软件架构

通过功能分层和线索化组织架构，确保同层组件不相互调用，降低修改影响范围。能够限制组件间耦合，降低演化复杂度，提高可维护性。

3、软件架构动态演化

需求来源

1. **软件内部执行的影响：**如服务器端软件在客户请求到达时动态创建组件响应需求。
2. **外部请求的重配置：**如操作系统升级无需重启，直接在运行中修改体系结构。

动态性分类

1. **交互动态性：**数据在固定结构下进行动态交互。
2. 结构动态性：允许组件和连接件的实例动态添加或删除，是动态性研究的主流。
3. 架构动态性：允许重新定义架构基本构造，如定义新的组件类型。

动态演化的主要内容

1. **属性改名：**用户在运行时重新定义非功能属性（如服务响应时间）。
2. **行为变化：**由于用户需求变化或系统服务质量调节，导致软件行为动态调整。
3. 拓扑结构改变：动态增加/删除组件和连接件，改变组件与连接件的关联关系。
4. 风格变化：架构风格通常保持不变，但可在必要时转为衍生风格（如两层 C/S 转为三层 C/S）。

1、动态软件架构 (Dynamic Software Architecture, DSA)

在运行时系统框架结构动态变化，通过框架：动态演化实现架构修改。

功能要求：

1. 保存当前软件架构信息。
2. 设置监控机制，监测系统需求变化。
3. 确保演化操作的原子性。

流程：

1. **捕捉并分析需求变化：**识别和确认需要进行架构动态调整的触发点。
2. 获取或生成演化策略：根据需求变化制定动态演化的策略。
3. 选择并实施演化策略：执行具体的架构调整操作。
4. 评估与检测：对演化后的架构进行验证和性能评估。

2、动态重配置 (Dynamic Reconfiguration, DR)：

从组件和连接件配置入手，在运行中实现组件和连接件的增删或关系修改。

模式

1. 主从模式：主节点控制，其他节点为从属。
2. 中央控制模式：中央管理整个系统的动态变化。
3. 客户端/服务器模式：基于请求-响应的架构动态调整。
4. 分布式控制模式：多节点协同实现动态演化，无集中控制点。