【系统架构设计师】十四、软件架构的演化和维护(演化和定义|面向对象软件架构演化过程|软件架构演化方式的分类)-CSDN博客

                (1)对系统的软件架构进行的形式化、可视化表示提高了软件的可构造性，便于软件演化。
                (2)软件架构设计方案涵盖的整体结构信息、配置信息、约束信息等有助于开发人员充分考虑未来可能出现的演化问题、演化情况和演化环境。
                (3)架构设计时对系统组件之间的耦合描述有助于软件系统的动态调整。

软件架构定义是 SA={components,connectors,constraints}, 也就是说，软件架构包括组件 (Components)、连接件 (Connectors)和约束 (Constraints)三大要素，这类软件架构演化主要关注的就是组件、连接件和约束的添加、修改与删除等。

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

2.1 对象演化

        对象演化：在顺序图中，组件的实体是对象，会对架构设计的动态行为产生影响的演化只包括Add Object(AO)和Delete Object(DO)两种。
        AO 表示在顺序图中添加一个新的对象。这种演化一般是在系统需要添加新的对象来实现某种新的功能，或需要将现有对象的某个功能独立以增加架构灵活性的时候发生。
        DO 删除顺序图中现有的一个对象。这种演化一般在系统需要移除某个现有的功能，或需要合并某些对象及其功能来降低架构的复杂度的时候发生。

2.2 消息演化

消息演化分为 Add Message(AM)、Delete Message(DM)、Swap Message Order(SMO)、Overturn Message(OM)、Change Message Module(CMM) 5 种。

        A M 增添一条新的消息，产生在对象之间需要增加新的交互行为的时候。
        D M 删除当前的一条消息，产生在需要移除某个交互行为的时候，是A M 的逆向演化。
        SMO 交换两条消息的时间顺序，发生在需要改变两个交互行为之间关系的时候。
        O M 反转消息的发送对象与接收对象，发生在需要修改某个交互行为本身的时候。
        CMM 改变消息的发送或接收对象，发生在需要修改某个交互行为本身的时候。

2.3 复合片段演化

复合片断的演化分为 Add Fragment（AF）、Delete Fragment（DF）、Fragment Type Change（FTC）、Fragment Condition Change（FCC）4 种。

        AF：在某几条消息上新增复合片段，发生在需要增添新的控制流时。
        DF：删除某个现有的复合片段，发生在需要移除当前某段控制流时。
        FTC：改变复合片段的类型，发生在需要改变某段控制流时。
        FCC：改变复合片段内部执行的条件，发生在改变当前控制流的执行条件时。

2.4 约束演化

约束演化包括 Add Constraint（AC）、Delete Constraint（DC）。

AC：直接添加新的约束信息，需判断当前设计是否满足新添加的约束要求。
DC：直接移除某条约束信息，发生在去除某些不必要条件的时候。

三、软件架构演化方式的分类

3种较典型的分类方法：

(1)按照软件架构的实现方式和实施粒度分类：基于过程和函数的演化、面向对象的演化、基于组件的演化和基于架构的演化。

        (2)按照研究方法将软件架构演化方式分为4类(Jeffrey M.Barnes等人的分类方法)：
                第1类是对演化的支持，如代码模块化的准则、可维护性的指示(如内聚和耦合)、代码重构等；
                第2类是版本和工程的管理工具，如CVS 和COCOMO;
                第3类是架构变换的形式方法，包括系统结构和行为变换的模型，以及架构演化的重现风格等；
                第4类是架构演化的成本收益分析，决定如何增加系统的弹性。

(3)针对软件架构的演化过程是否处于系统运行时期，可以将软件架构演化分为静态演化
(Static Evolution)和动态演化 (Dynamic Evolution)，前者发生在软件架构的设计、实现和维护
过程中，软件系统还未运行或者处在运行停止状态；后者发生在软件系统运行过程中。

软件架构的演化时期包括：设计时演化、运行前演化、有限制运行时演化、运行时演化软件。

3.1 软件架构静态演化

架构静态演化主要是在设计时演化以及运行前演化。与此相对应的维护方法有3 类：更正性维护、适应性维护和完姜性维护。

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

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

一次完整软件架构演化过程可以看作经过一系列原子演化操作组合而成。所谓原子演化操作是指基于UML 模型表示的软件架构，在逻辑语义上粒度最小的架构修改操作。每经过一次原子演化操作架构会形成一个演化中间版本。

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

架构演化的可维护性度量基于组件图表示的软件架构，在较高层次上评估架构的某个原子修改操作对整个架构所产生的影响。这些原子修改操作包括增加/删除模块间的依赖、增加/删除模块间的接口、增加/删除模块、拆分/聚合模块等，如下图所示：

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

架构演化的可靠性评估基于用例图、部署图和顺序图，分析在架构模块的交互过程中某个
原子演化操作对交互场景的可靠程度的影响。这些原子修改操作包括增加/删除消息、增加/删
除交互对象、增加/删除/修改消息片段、增加/删除用例执行、增加/删除角色等，如下图所示：

3.3 软件架构动态演化

动态演化是在系统运行期间的演化，需要在不停止系统功能的情况下完成演化，较之静态演化更加困难。具体发生在有限制的运行时演化和运行时演化阶段。

3.3.1 动态演化需求

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

3.3.2 动态演化的类型

        软件的动态性分为3个级别:
                ①交互动态性(Interactive Dynamism)，要求数据在固定的结构下动态交互；
                ②结构动态性(Structural Dynamism)，允许对结构进行修改，通常的形式是组件和连接件实例的添加和删除，这种动态性是研究和应用的主流；
                ③架构动态性 (Architectural Dynamism)，允许软件架构的基本构造的变动，即结构可以
被重定义，如新的组件类型的定义。

根据所修改的内容不同，软件的动态演化主要包括以下4个方面：

                属性改名：目前所有的ADL都支持对非功能属性的分析和规约，而在运行过程中，用户可能会对这些指标进行重新定义(如服务响应时间)。
                行为变化：在运行过程中，用户需求变化或系统自身服务质量的调节都将引发软件行为的变化。
                拓扑结构改变：如增删组件，增删连接件，改变组件与连接件之间的关联关系等。
                风格变化：一般软件演化后其架构风格应当保持不变，如果非要改变软件的架构风格，也只能将架构风格变为其衍生风格，如两层C/S到三层C/S。

3.4 动态软件架构

目前，实现软件架构动态演化的技术主要有两种：采用动态软件架构 (Dynamic Software Architecture,DSA)和进行动态重配置 (Dynamic Reconfiguration,DR)。DSA是指在运行时刻会发生变化的系统框架结构，允许在运行过程中通过框架结构的动态演化实现对架构的修改；DR 从组件和连接件的配置入手，允许在运行过程中增删组件，增删连接件，修改连接关系等操作。在此，我们将DSA 归结为架构动态性，将DR 归结为结构动态性。

3.4.1 动态软件架构DSA

实现软件架构动态演化的基本原理是使 DSA 在可运行应用系统中以一类有状态、有行为、
可操作的实体显式地表示出来，并且被整个运行环境共享，作为整个系统运行的依据。也就是
说，运行时刻体系结构相关信息的改变可用来触发、驱动系统自身的动态调整。

由于动态演化实现起来比静态演化复杂得多，系统必须提供 S A动态演化的一些相关功能。
①系统必须提供保存当前软件架构信息(拓扑结构、组件状态和数目等)的功能。
②实施动态演化还须设置一个监控管理机制，对系统有无需求变化进行监视。
③保证演化操作原子性。

        DSA 实施动态演化大体遵循以下4步：
                ①捕捉并分析需求变化；
                ②获取或生成体系结构演化策略；
                ③根据步骤2得到的演化策略，选择适当的演化策略并实施演化；
                ④演化后的评估与检测。

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

3.4.2 动态重配置DR

        基于软件动态重配置的软件架构动态演化主要是指在软件部署之后对配置信息的修改，常常被用于系统动态升级时需要进行的配置信息修改。一般来说，动态重配置可能涉及的修改有：
        ①简单任务的相关实现修改；
        ②工作流实例任务的添加和删除；
        ③组合任务流程中的个体修改；
        ④任务输入来源的添加和删除；
        ⑤任务输入来源的优先级修改；
        ⑥组合任务输出目标的添加和删除；
        ⑦组合任务输出目标的优先级修改等。

动态重配置模式：主从模式、中央控制模式、客户端/服务器模式、分布式控制模式。

动态配置难点：约束定义困难、性能约束难以静态衡量、难以管理所有方面、需同时保证
组件系统完整性和重配置策略的正确和安全性。

3.5 软件架构的演化原则

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