系统架构设计师教程第10章 10.3 软件架构演化方式的分类笔记-CSDN博客

本文链接：https://blog.csdn.net/z2014z/article/details/142421622

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

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

10.3.1 软件架构演化时期

1.设计时演化
设计时演化 (Design-Time Evolution) 是指发生在体系结构模型和与之相关的代码编译之前的软件架构演化。
2.运行前演化
运行前演化 (Pre-Execution Evolution) 是指发生在执行之前、编译之后的软件架构演化，应用程序未执行，修改时可以不考虑应用程序的状态，但需要考虑系统的体系结构，且系统需要具有添加和删除组件的机制。
3.有限制运行时演化
有限制运行时演化 (Constrained Runtime Evolution) 是指系统在设计时规定了演化的具体条件，将系统置于“安全”模式下，演化只发生在某些特定约束满足时，可以进行一些规定好的演化操作。
4.运行时演化
运行时演化 (Runtime Evolution) 是指系统的体系结构在运行时不能满足要求时发生的软件架构演化，包括添加组件、删除组件、升级替换组件、改变体系结构的拓扑结构等。最难实现。

10.3.2 软件架构静态演化

● 需求变更分析：静态演化往往是由于用户需求变化、系统运行出错和运行环境发生改变等原因所引起的，需要找出新的软件需求与原有的差异。
● 演化计划：分析原系统，确定演化范围和成本，选择合适的演化计划。
● 系统重构：根据演化计划对系统进行重构，使之适应当前的需求。
● 系统测试：对演化后的系统进行测试，查找其中的错误和不足之处。

在系统未运行的情况下，软件功能的变更或环境变化可能会带来架构中组件元素的改动（增加、替换、删除、组合和拆分操作）。通过对组件间的影响关系进行建模，按照可达矩阵的方式即可计算出每种组件变更操作所影响的范围。

3.静态演化的原子演化操作
1)与可维护性相关的架构演化操作
架构演化的可维护性度量基于组件图表示的软件架构，在较高层次上评估架构的某个原子修改操作对整个架构所产生的影响。
原子修改操作包括增加/删除模块间的依赖、增加/删除模块间的接口、增加/删除模块、拆分/聚合模块等
2)与可靠性相关的架构演化操作
架构演化的可靠性评估基于用例图、部署图和顺序图，分析在架构模块的交互过程中某个原子演化操作对交互场景的可靠程度的影响。
原子修改操作包括增加/删除消息、增加/删除交互对象、增加/删除/修改消息片段、增加/删除用例执行、增加/删除角色等

4.静态演化实例：
正交软件架构 (Orthogonal Software Architecture)
对于复杂的应用系统，通过对功能进行分层和线索化，可以形成正交体系结构，同一层次中的组件不允许相互调用，每个变动仅影响一条线索
演化过程概括如下：
①需求变动归类，使需求的变化和现有组件及线索相对应，判断重用情况
②制订架构演化计划；
③修改、增加或删除组件；
④更新组件之间的相互作用；
⑤产生演化后的软件架构，作为系统更新的详细设计方案和实现基础。

10.3.3 软件架构动态演化

动态演化是在系统运行期间的演化，需要在不停止系统功能的情况下完成演化

1.动态演化的需求
架构的动态演化主要来自两类需求：
①软件内部执行所导致的体系结构改变，例如，许多服务器端软件会在客户请求到达时创建新的组件来响应用户需求；
②软件系统外部的请求对软件进行的重配置，例如，操作系统在升级时无须重新启动，在运行过程中就完成对体系结构的修改。
主要用于需要长期运行且具有特殊使命的系统。

2.动态演化的类型
1)软件动态性的等级
动态性分为3个级别:
①交互动态性 (Interactive Dynamism), 要求数据在固定的结构下动态交互；
②结构动态性 (Structural Dynamism), 允许对结构进行修改，通常的形式是组件和连接件实例的添加和删除，是研究和应用的主流；
③架构动态性 (Architectural Dynamism), 允许软件架构的基本构造的变动，即结构可以被重定义，如新的组件类型的定义。
2)动态演化的内容
根据修改的内容不同，软件的动态演化主要包括以下4个方面。
● 属性改名：在运行过程中，用户可能会对这些指标进行重新定义(如服务响应时间)。
● 行为变化：在运行过程中，用户需求变化或系统自身服务质量的调节都将引发软件行为的变化。如，为了提高安全级别而更换加密算法；将HTTP协议改为HTTPS协议；组件和连接件的替换和重新配置。
● 拓扑结构改变：如增删组件，增删连接件，改变组件与连接件之间的关联关系等。
● 风格变化：一般软件演化后其架构风格应当保持不变，或者将架构风格变为其衍生风格，如将两层C/S结构调整为三层C/S结构或C/S与B/S的混合结构。
目前，实现软件架构动态演化的技术主要有两种：采用动态软件架构 (Dynamic Software Architecture,DSA) 和进行动态重配置 (Dynamic Reconfiguration,DR)。
DSA是指在运行时刻会发生变化的系统框架结构，允许在运行过程中通过框架结构的动态演化实现对架构的修改；
DR从组件和连接件的配置入手，允许在运行过程中增删组件，增删连接件，修改连接关系等操作。
DSA 归结为架构动态性，将DR归结为结构动态性。

3.动态软件架构
动态软件架构 (DSA) 可以修改自身的架构，并在系统执行期间进行修改
1)基于DSA 实现动态演化的基本原理
基本原理是使 DSA在可运行应用系统中以一类有状态、有行为、可操作的实体显式地表示出来，并且被整个运行环境共享，作为整个系统运行的依据。
DSA 实施动态演化大体遵循以下4步：
①捕捉并分析需求变化；
②获取或生成体系结构演化策略；
③根据步骤2得到的演化策略，选择适当的演化策略并实施演化；
④演化后的评估与检测。
完成这4个步骤还需要DSA 描述语言和演化工具的支持。
2 ) DSA描述语言
按照描述视角可将软件动态性建模语言分为3类：①基于行为视角的π-ADL, 使用进程代数来描述具有动态性的行为；②基于反射视角的 Pilar, 利用反射理论显式地为元信息建立模型；
③ 基于协调视角的 LIME, 注重计算和协调部分的分离，利用协调论的原理来解决动态性交互。
(1) π- ADL
软件架构的描述分为两个部分：结构相关描述和行为相关描述
π-ADL 就是以π演算为基础设计的架构描述语言，它采用运行时的观点对系统进行建模，其模型包括组件、连接件和行为。所有元素都会随时间演化。是为移动系统建模设计。
(2)Pilar
对于动态架构的直观解决方案就是实现架构反射，将模型与系统相关联，模型的修改会反映到系统的修改上，系统的变化也会表现为模型的变化。
MARMOL(MetaArchitectureModel) 是将反射和架构结合起来的形式化模型，其主要思想在于：在架构描述中引入多个层次，并利用反射的概念来表示它们。是一种描述风格，它能够与其他ADL结合起来应用，如使用MARMOL描述层模型，而对于单个的层则使用其他ADL进行描述。
基于 MARMOL 的动态架构描述语言Pilar 已经出现。在 Pilar 中只有一种顶级元素一组件，而每个组件都由4部分组成，即接口、配置、具化 (Reification) 和约束。
(3)LIME
在分布式和并行系统的演化中，协调模型 (Coordination Model) 的应用广泛。它提供了增强模块性、组件复用性、移植性和语言互操作性的框架。
协调模型与DSA 的关系在于：大规模并行系统分布在许多逻辑结点上，结点的交互行为本质上是动态的。
LIME(Linda In a Mobile Environment) 是 Linda 的扩展，支持移动应用的开发。它既能描述物理移动性，也能描述逻辑移动性，通过分计算部分和协调部分使得时间、空间因素分离，简化了分布式系统的开发。
3 ) DSA 演化工具
需要支持系统在演化过程中与其软件架构的一致性检查，并能够对架构演化过程进行管理，主要方法
● 使用反射机制
● 基于组件操作
● 基于π演算
● 利用外部的体系结构演化管理器
4.动态软件架构应用实例——PKUAS
PKUAS 是一个符合Java EE规范的组件运行支撑平台，支持3种标准EJB 容器，包括无态会话容器、有态会话容器和实体容器，并支持远程接口和本地接口，提供 IOP 、JRMP 、SOAP 以及 EJBLocal互操作机制，内置命名服务、安全服务、事务服务、日志服务、数据库连接服务；通过了Java EE蓝图程序 JPS v1.1 的测试。
实体分为4种类型
(1)容器系统：容器是组件运行时所处的空间，负责组件的生命周期管理(如类装载、实例化、缓存、释放等)以及组件运行需要的上下文管理(如命名服务上下文、数据库连接等)
(2)公共服务：其实现系统的非功能性约束，如通信、安全、事务等
(3)工具：辅助用户使用和管理PKU AS 的工具集合，主要包括部署工具、配置工具与实时监控工具。
(4)微内核：上述3类实体统称为系统组件，微内核负责这些系统组件的装载、配置、卸载，以及启动、停止、挂起等状态管理。
5.动态重配置
主从模式由主操作重配置状态图描述，其中包含两个正交的图，即主操作状态图和主重配置状态图，
主操作状态图定义了主组件的操作状态，
主重配置状态图描述了主组件如何安排重配置的过程。
(2)中央控制 (Centralized Control) 模式：广泛应用于实时系统之中。在该模式中，一个中央控制器会控制多个组件，其状态图会维持两个状态，分别标识中央控制器是否处于空闲状态。
(3)客户端/服务器 (Client/Server) 模式：客户端组件需要服务器组件所提供的服务，二者通过同步消息进行交互，在客户端/服务器重配置模式中，当客户端发起的事务完成之后可以添加或删除客户端组件；当顺序服务器 (Sequential Server) 完成了当前的事务，或者并发服务器 (Concurrent Server) 完成了当前事务的集合，且将新的事务在服务器消息缓冲中排队完毕之后，可以添加或删除服务器组件。
(4) 分布式控制 (Decentralized Control) 模式：系统的功能整合在多个分布式控制组件之中。广泛用于分布式应用之中，且有着多种相似的类型，如环形 (Ring) 模式和顺序 (Serial) 模式。环形模式中每个组件有着相同的功能，且在其左右均有一个组件(称为前驱和后继)与之交互；顺序模式中每个组件使用相同的连接与自己的前驱和后继交互，每个组件向自己的前驱发送请求并获得响应。