《系统架构设计师教程（第2版）》第10章-软件架构的演化和维护-03-软件架构演化方式的分类

目前，软件架构演化方式没有一种公认的分类法，分类方法很多，以下举例说明3种较典型的分类方法：

• 按照软件架构的实现方式和实施粒度分类
  • 基于过程和函数的演化
  • 面向对象的演化
  • 基于组件的演化
  • 基于架构的演化
• 针对软件架构的演化过程是否处于系统运行时期
  • 静态演化(Static Evolution) ：
    • 发生在软件架构的设计、实现、维护过程中
    • 此时，软件系统还未运行或停止状态
  • 动态演化 (Dynamic Evolution)：发生在软件系统运行过程中

1. 软件架构演化时期

1.1 设计时演化

• 概念
  • Design-Time Evolution
  • 发生在体系结构模型和与之相关的代码编译之前的软件架构演化

1.2 运行前演化

• 概念：
  • Pre-Execution Evolution
  • 发生在执行之前、编译之后的软件架构演化，
• 注意点
  • 修改时可以不考虑应用程序的状态
  • 需要考虑系统的体系结构
  • 系统需要具有添加和删除组件的机制

1.3 有限制运行时演化

• 概念：
  • Constrained Runtime Evolution
  • 系统在设计时就规定了演化的具体条件
  • 在此约束条件下，进行规定好的演化操作

1.4 运行时演化

• 概念：
  • Runtime Evolution
  • 系统的体系结构在运行时不能满足要求时发生的软件架构演化
  • 包括：添加组件、删除组件、升级替换组件、改变体系结构的拓扑结构等
  • 难度最高

2. 软件架构静态演化

2.1 静态演化需求

• 设计时演化需求
  • 在架构开发和实现过程中对原有架构进行调整
  • 保证软件实现与架构的一致性以及软件开发过程的顺利进行
• 运行前演化需求
  • 软件发布之后由于运行环境的变化，需要对软件进行修改升级
  • 对应的维护方法：更正性维护、适应性维护、完善性维护

2.2 静态演化的一般过程

1）软件理解

查阅软件文档，分析软件架构，识别系统组成元素及其之间的相互关系，提取系统的抽象表示形式。

2）需求变更分析

找出新需求与原有需求的差异

3）演化计划

分析原系统，确定演化范围和成本，选择合适的演化计划

4）系统重构

根据演化计划对系统进行重构，使之适应当前的需求

5）系统测试

对演化后的系统进行测试，查找其中的错误和不足之处。

2.3 静态演化的原子演化操作

• 概念：

  • 指基于UML模型表示的软件架构，在逻辑语义上粒度最小的架构修改操作

  • 注意：这些操作并非是物理结构上的不可分

    如，新增模块，必然导致模块间依赖关系的增加

  • 每经过一次原子演化操作，架构会形成一个演化中间版本

2.3.1 与可维护性相关的架构演化操作

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

1）对模块依赖关系的修改

• 包括：AMD、RMD
• 模块间的依赖关系：
  • 体现了模块逻辑组织结构和控制关系
  • 包含模块对其他模块的直接依赖和间接依赖
• 修改的影响
  • 改变了模块的控制关系以及逻辑响应
  • 从整体上影响了架构的组织结构
  • 可能导致架构的外部质量属性发生变化

2）对模块间接口的修改

• 包括：AMI/RMI
• 模块间的接口：
  • 表示模块间的调用方式
• 修改的影响：
  • 可直接改变模块间的调用关系和调用方式
  • 可能导致具体的执行事件的顺序和方式发生更改

3）对模块的修改（增删）

• 包括：AM/RM
• 模块：
  • 封装了一系列逻辑耦合度高或部署紧密的子模块
  • 用来表达完整的功能
• 修改的影响：
  • 软件功能的更改
  • 可能使得架构整体组织结构的变化
• 注意：
  • 过多的耦合会造成修改影响范围增大，不利于软件的持续演化

4）对模块的拆分、聚合

• 包括：SM/AGM
• 通常发生在软件调整过程中
• 修改的影响
  • 直接影响软件的内聚度和耦合度
  • 影响软件整体复杂性

2.3.2 与可靠性相关的架构演化操作

• 架构演化的可靠性评估
  • 基于用例图、部署图、顺序图
  • 分析在架构模块的交互过程中某个原子演化操作对交互场景的可靠程度的影响
• 这些原子修改操作如表10-2所示：

1）模块交互信息的修改

• 包括：AMS/RMS
• 体现在UML顺序图中
• 消息变化包含增加消息、删除消息和修改消息
• 修改的影响：
  • 交互过程中时序复杂度变化，可能引入运行时风险

2）交互对象的修改

• 包括：AO/RO
• 修改的影响：
  • 引起AMS/DMS操作
    • 在部署图中添加或删除相关模块
  • 影响含该模块的场景的交互复杂性

3）消息片段的修改

• 包括：AF/RF/CF
• 消息片段：消息片段为顺序图中一组交互消息的循环调用
• 修改的影响
  • 影响交互过程的复杂度
  • 增加该场景的执行风险

4）用例的修改

• 包括：AU/RU
• 表示参与者执行权限的变化
  • 一般来说可执行用例越多的参与者其权限越高
• 修改的影响：
  • 将导致系统运行更为复杂，运行时风险增加。

5）参与者的修改

• 包括：AA/RA
• 意味着执行权限的增加或减少
• 引起系统动态交互的变化，影响程序运行时的风险

2.4正交软件架构

• 概念

  • Orthogonal Software Architecture
  • 目的：为高效地对修改进行分析和管理
  • 适用：复杂的应用系统
  • 构建：对功能进行分层和线索化，以形成正交体系结构
  • 特点：同一层次中的组件不允许相互调用，故每个变动仅影响一条线索
    

• 演化过程：

  • 需求变动归类，使需求的变化和现有组件及线索相对应，判断重用情况
  • 制订架构演化计划
  • 修改、增加或删除组件
  • 更新组件之间的相互作用
  • 产生演化后的软件架构，作为系统更新的详细设计方案和实现基础

3. 软件架构动态演化

• 适用：
  • 需要长期运行且具有特殊使命的系统，停止运行会产生高额的费用和巨大的风险
  • 如：航空航天、生命维持、金融、交通等

3.1 动态演化的需求

• 需求来源

  • 软件内部执行所导致的体系结构改变

  例如，许多服务器端软件会在客户请求到达时创建新的组件来响应用户需求

  • 软件系统外部请求对软件进行的重配置

  例如，操作系统在升级时无须重新启动，在运行过程中就完成对体系结构的修改。

3.2 动态演化的类型

3.2.1 软件动态性的等级

1. 交互动态性（级别1）
   • InteractiveDynamism
   • 要求数据在固定的结构下动态交互
2. 结构动态性（级别2）
   • Structural Dynamism
   • 允许对结构进行修改
   • 通常：组件、连接件实例的添加和删除
3. 架构动态性（级别3）
   • Architectural Dynamism
   • 允许软件架构的基本构造的变动
   • 如：重定义结构，定义新的组件类型

3.2.2 动态演化的内容

软件的动态演化主要包括以下4个方面：

• 属性改名：目前所有的ADL都支持对非功能属性的分析和规约，而在运行过程中，用户可能会对这些指标进行重新定义(如服务响应时间)。

• 行为变化

  • 引起的原因：需求变化或系统自身服务质量的调节
  • 如：
    • 为了提高安全级别而更换加密算法
    • 将HTTP协议改为HTTPS协议
    • 组件和连接件的替换和重新配置

• 拓扑结构改变：

  • 如：增删组件，增删连接件，改变组件与连接件之间的关联关系等

• 风格变化：

  • 限制：仅能演化为原风格的衍生风格
  • 如：
    • 将两层C/S结构调整为三层C/S结构或C/S与B/S的混合结构
    • 将“1对1”的请求响应结构改为“1对N” 以实现负载

3.2.3 主要技术

• 采用动态软件架构

  • 动态软件架构（DSA）
    • Dynamic SoftwareArchitecture
    • 运行时刻会发生变化的系统框架结构
    • 该架构允许在运行过程中通过框架结构的动态演化实现对架构的修改
  • 架构动态性

• 进行动态重配置

  • 动态重配置（DR）
    • Dynamic Reconfiguration
    • 从组件和连接件的配置入手，允许在运行过程中增删组件，增删连接件，修改连接关系等操作
  • 结构动态性

3.3 动态软件架构（DSA）

• 概念： 可以修改自身的架构，并在系统执行期间进行修改
• 意义：
  • 能够减少系统开发的费用和风险
  • 增强用户自定义性和可扩展性

3.3.1 基本原理

• 原理：
  • 使DSA在可运行应用系统中以一类有状态、有行为、可操作的实体显式地表示出来
  • 并且被整个运行环境共享，作为整个系统运行的依据
  • 对系统自身所做的动态调整结果可反映在体系结构这一抽象层面上

3.3.2 系统必须提供架构动态演化的功能

• 系统必须提供保存当前软件架构信息的功能

• 设置监控管理机制，对系统有无需求变化进行监视

  当发现有需求变化时，应能分析并判断可否实施演化，以及何时演化和演化范围，并最终分析或生成演化策略

• 保证演化操作原子性

  在动态变化过程中，如果其中之一的操作失败了，整个操作集都要被撤销，从而避免系统出现不稳定的状态

3.3.2 演化步骤

1. 捕捉并分析需求变化
2. 获取或生成体系结构演化策略
3. 选择适当的演化策略并实施演化
4. 演化后的评估与检测

完成以上4个步骤还需要DSA描述语言和演化工具的支持。

3.3.3 DSA描述语言

该小节仅做了解

1) π-ADL

• π演算：目前主流的进程代数语言之一
• π-ADL：
  • 使用π演算来描述具有动态性的行为的描述语言
  • 它基于行为视角
  • 其模型包括组件、连接件、行为
• 应用：为移动系统建模

2) Pilar

• 概述
  • 基于反射视角
  • 利用反射理论显式地为元信息建立模型
• 原理
  • 将模型与系统相关联
    • 模型的修改会反映到系统的修改上
    • 系统的变化也会表现为模型的变化
• 形式化的反射模型
  • 基于层的模型
  • 元-基系统对：
    • 基系统 (Base-System)：
      • 基层即其基系统
      • 描述了系统如何感知或修改自身
    • 元系统 (Meta System)：
      • 每一层都称为基层的“元系统”
      • 提供常规的应用操作和结构
• Pilar
  • 基于 MARMOL 的动态架构描述语言

  MARMOL：Meta Architecture Model，第一个试图将反射和架构结合起来的形式化模型

  • 组成
    • 顶级元素
    • 组件
      • 组件组成：接口、配置、具化 (Reification) 、约束

3）LIME

• 概述
  • 基于协调视角
  • 注重计算和协调部分的分离，利用协调论的原理来解决动态性交互
• 适用范围：移动应用的开发
• 优势：简化了分布式系统的开发

3.3.4 DSA演化工具

该小节仅做了解

• 要求
  • 需要支持系统在演化过程中与其软件架构的一致性检查
  • 对架构演化过程进行管理
• 实现方法
  • 使用反射机制
  • 基于组件操作
  • 基于π演算
  • 利用外部的体系结构演化管理器

3.4 动态软件架构应用实例——PKUAS

3.4.1 概述

• 是一个符合Java EE规范的组件运行支撑平台
• 支持3种标准EJB容器：无态会话容器、有态会话容器、实体容器
• 支持远程接口、本地接口

3.4.2 实体类型

基于Java虚拟机， PKUAS将平台自身的实体划分为如下4种类型：

1）容器系统

• 容器：是组件运行时所处的空间，负责组件的生命周期管理、组件运行需要的上下文管理
• 容器系统：
  • 一个容器实例管理一个EJB组件的所有实例
  • 一个应用中所有EJB组件的容器实例组成一个容器系统
• 优点：有利于实现特定于单个应用的配置和管理

如，不同应用使用不同的通信端口、认证机制与安全域

2）公共服务

• 实现系统的非功能性约束

如通信、安全、事务等

• 公共服务可通过微内核动态增加、替换和删除
  • 供容器使用的服务：必须开发相应的截取器作为容器调用服务的执行点
  • 供组件使用的服务：必须在命名服务中加以注册

3）工具

辅助用户使用和管理PKUAS 的工具集合：

• 部署工具：可热部署整个应用，也可热部署单个组件，从而实现应用的在线演化
• 配置工具：允许用户配置整个服务器或单个应用
• 实时监控工具：允许用户实时观察系统的运行状态并做出相应调整

4）微内核

• 作用：
  • 上述3类实体统称为系统组件
  • 微内核负责这些系统组件的装载、配置、卸载，以及启动、停止、挂起等状态管理
• 优点：继承了JMX可移植、伸缩性强、易于集成其他管理方案、有效利用现有Java技术、可扩展等优点

3.5 动态重配置

• 概述
  • 主要是指在软件部署之后对配置信息的修改
  • 修改的内容：
    • 简单任务的相关实现修改
    • 工作流实例任务的添加和删除
    • 组合任务流程中的个体修改
    • 任务输入来源的添加和删除
    • 任务输入来源的优先级修改
    • 组合任务输出目标的添加和删除
    • 组合任务输出目标的优先级修改等。

3.5.1 动态重配置模式

1）主从 (Master-Slave) 模式

• 工作模式：

  • 主组件接收客户端的服务请求
  • 将工作划分给从组件
  • 合并、解释、总结或整理从组件的响应

  当主组件没有对从组件分配工作时，从组件处于空闲 (Idle) 状态，并会在新的任务分配时被重新激活。

• 主操作重配置状态图

  • 作用：描述主从模式
  • 包含两个正交的图：
    • 主操作状态图：定义了主组件的操作状态
    • 主重配置状态图：描述了主组件如何安排重配置的过程

2）中央控制 (Centralized Control) 模式

• 应用范围：实时系统
• 工作模式：一个中央控制器会控制多个组件，其状态图会维持两个状态，分别标识中央控制器是否处于空闲状态

3）客户端/服务器 (Client/Server) 模式

• 客户端和服务端通过同步消息进行交互
• 客户端/服务器重配置模式：
  • 添加或删除客户端组件：客户端发起的事务完成
  • 添加或删除服务器组件
    • 顺序服务器 (Sequential Server) 完成了当前的事务
    • 并发服务器 (Concurrent Server) 完成了当前事务的集合

4）分布式控制 (Decentralized Control) 模式

• 适用范围：分布式应用
• 类型：
  • 环形(Ring) 模式：
    • 每个组件有着相同的功能
    • 在其左右均有一个组件(称为前驱和后继)与之交互
  • 顺序 (Serial) 模式
    • 每个组件使用相同的连接与自己的前驱和后继交互
    • 每个组件向自己的前驱发送请求并获得响应

3.5.2 示例（产品线架构）

• 产品线架构：可重用、可配置的架构
• 软件产品线：
  • 一种软件开发和配置的方法论
  • 优点：促进了软件的有效开发
  • 不足：
    • 配置复杂性高
    • 用户可定制的弹性不足
    • 关注点有所偏移：从产品转移到了领域
• PuLSE 方法论
  • Product Line Software Engineering
  • 能够在各种企业环境中进行软件产品线构想和部署
  • 实现：
    • 核心关注点：产品
    • 包括：组件的可定制性、增量(组件)导入的能力、结构演化的成熟度，以及主要产品开发过程的适应性调整等。
      

3.5.3 动态重配置的难点

• 约束定义困难
• 性能约束难以静态衡量

  需要在软件运行时进行评估

• 某些重配置方案能够解决性能约束的某一方面，但是难以管理所有方面
• 重配置需要同时保证如下两个方面：
  • 维持组件系统的完整性
  • 重配置策略的正确和安全性

---