第10章 软件架构的演化和维护

软件架构周期：初始设计、实际使用、修改完善(这就是演化)、退化弃用。

演化和维护的目的：为了使软件能够适应环境的变化而进行的纠错性修改和完善性修改等，而且这个过程是一个不断迭代的过程。

架构演化的重要性、演化过程、演化分类、演化原则、演化评估(完成后也需要评估的)

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

10.1.1演化的重要性

为了适应用户的新需求、业务环境和运行环境的变化等，软件架构需要不断地进行自身的

演化，也就是说软件架构的演化就是为了维持软件架构自身的有用性。

演化是软件整体结构的演化，涵盖整个软件架构的全生命周期，包含需求获取、架构文档、架构建模、实现、维护等等

演化的重要意义：

1.软件架构作为软件系统的骨架支撑着整个软件系统，是软件系统具备诸多好的特性的重要保障。

2.其次，软件架构作为软件蓝图为人们宏观管控软件系统的整体复杂性和变化性提供了一条

有效途径，而且基于软件架构进行的软件检测和修改成本相对较低，所以要刻画复杂的软件演

化，并对演化中的影响效应进行观察和控制，从软件架构演化出发更加合理。

3.软件架构的演化可以更好地保证软件演化的一致性和正确性，而且明显降低软件演化的成本，并且软件架构演化使得软件系统演化更加便捷

10.1.2演化和定义的关系

根据具体定义具体说明。

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

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

假设软件架构对应到具体的架构风格或模式，以面向对象软件架构为例。

10.2.1对象演化

顺序图中，组件的实体为对象。组件本身包含了众多属性，如接口、类型、语义等，这些属性的演化是对象自身的演化，对于描述对象间的交互并无影响。因此，会对架构设计的动态行为产生影响的演化只有 括AddObject(AO)和DeleteObject(DO)两种。

10.2.2消息演化

消息是顺序图中的核心元素，包含了名称、源对象、目标对象、时序等信息。

消息自身的属性如接口、类型等变化不会影响到对象间交互，但是包含的信息发生变化将会影响与之交互的其他对象或消息，从而对架构正确性或时态属性产生影响。

消息演化分类：AddMessage (AM)、DeleteMessage(DM)、SwapMessageOrder(SMO)、OverturnMessage(OM)、 ChangeMessageModule(CMM)5种。

objl和obj2分别为产生变化 的两个对象，用ml、m2来表示消息的一一对应关系。

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

消息与约束关联：

• 消息与约束直接相关，消息的演化会直接影响到对象之间的交互行为，但不一定会违背约束。

• 我们可以将这种演化分为3类。第1类演化与当前约束无关，如AddMessage在大多数情况下与当前的约束无关，这些演化不会对架构设计的正确性或时态属性产生影响。
• 第2类演化与约束直接关联但不会违背约束，如ChangeMessageModule后的消息不会违背“在某处产生”的约束，这些演化同样不会对架构设计的正确性或时态属性产生影响。
• 第3类演化与约束直接 关联并会违背约束，如DeleteMessage删除的某条消息是某条约束的内容之一，这种演化后的架 构违背了约束，其是不正确的演化。

消息是顺序图的核心内容，消息演化是顺序图演化的核心。对象的演化会伴随着消息演化， 否则没有意义。

复合片段和约束均基于消息存在，二者的演化也直接受到消息演化的影响。因此，对其他演化进行分析研究的同时，也要对相关联的消息演化进行分析。

10.2.3复合片段演化

复合片段是对象交互关系的控制流描述，表示可能发生在不同场合的交互，与消息同属于连接件范畴。

复合片段本身的信息包括类型、成立条件和内部执行序列，其中内部执行序列的演化等价于消息序列演化。

复合片段的演化分为AddFragment(AF)、DeleteFragment(DF)、FragmentTypeChange(FTC)

和FragmentConditionChange(FCC)。

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

复合片段的演化对应着对象之间交互流程的变化，因此会对架构设计的正确性及其他时态

属性产生影响。需要验证演化是否会违背约束。

10.2.4约束演化

顺序图中的约束信息以文字描述的方式存储于对象或消息中，如通常可以用LTL来描述时态属性约束。

约束演化即直接对约束信息进行添加和删除。

• AC(Add Constraint)直接添加新的约束信息，会对架构设计产生直接的影响，需要判断当前设计是否满足新添加的约束要求。
• DC(Delete Constraint)直接移除某条约束信息，发生在去除某些不必要条件的时候，一般而言架构设计均会满足演化后的约束。

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

没有标准的演化分类，有三种较典型的分类：

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

基于过程和函数的演化、面向对象的演化、基于组件的演化和基于架构的演化。

(2)按照研究方法将软件架构演化方式分为4类(Jeffrey M.Barnes等人的分类方法):

第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软件架构静态演化

1.静态演化需求

静态演化广泛存在，主要2个方面：

(1)设计时演化需求。在架构开发和实现过程中对原有架构进行调整，保证软件实现与架

构的一致性以及软件开发过程的顺利进行。

(2)运行前演化需求。软件发布之后由于运行环境的变化，需要对软件进行修改升级，在

此期间软件的架构同样要进行演化。

架构静态演化和适应该静态演化的应用实例——正交软件架构，以及软件开发过程中的架构静态演化。

2.静态演化的一般过程

静态就是系统停止运行期间的修改和更新，一般意义上的软件修复和升级。

三类维护方法：更正性维护、适应性维护、完善性维护。

静态演化5步骤：

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

软件功能的变更和环境变化带来元素的增删改替换拆分操作，需要对这些操作对其他组件和系统本身带来的影响进行分析。通过对组件间的影响关系进行建模，按照可达矩阵的方式即可计算出每种组件变更操作所影响的范围。

3.静态演化的原子演化操作

一次完整的架构演化可看作一系列的原子演化操作组合而成。啥叫原子演化操作？基于UML模型标识的软件架构 ，在逻辑语义上粒度最小的架构修改操作。

原子演化操作理解：并非是物理上不可分割，模块的增加认为是原子粒度。架构每经过一次原子演化操作，架构会产生一个中间版本Ai，对于不同的质量属性度量和评估，影响该质量属性变化的原子演化操作类型不同，形成软件架构的中间版本序列A0,Al,A2,…,An也不同。

例如，假设我们需要度量软件架构的可维护性和可靠性，就应该讨论影响可维护性和可靠性的度量结果的各种原子演化操作。

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

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

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

•  AM/RMI:模块间的接口表示模块间的调用方式，模块通过接口直接提供相应可执行功能，对接口的修改可直接改变模块间的调用关系和调用方式，并可能导致具体的执行事件的顺序和方式发生更改。
•  AMRM:在架构中，模块封装了一系列逻辑耦合度高或部署紧密的子模块，用来表达完整的功能。模块的增加、删除不仅仅表示软件功能的更改，该模块与其他模块的耦合方式可能使得架构整体组织结构的变化，从而引入AMD和RMD操作。过多的耦合会造成修改影响范围增大，不利于软件的维护以及持续演化。另外模块本身内部设计的正确性、合理性等问题将会影响软件潜在风险。
• SM/AGM:拆分和聚合模块通常发生在软件调整过程中，对模块的拆分和聚合可直接影响软件的内聚度和耦合度，从而影响软件整体复杂性。

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

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

• AMS/RMS:模块间的消息交互体现在UML顺序图中。消息变化包含增加消息、删除消息和修改消息。消息的修改可能为顺序更改、交互对象更改等，该变化可通过删除原消息和增加新的消息等操作组合而成，因而这里只讨论原子粒度的增加消息和删除消息两种操作。消息的删减导致交互过程中时序复杂度的变化，可能引入运行时风险。

• AO/RO:在顺序图中增加或删除交互对象将引入AMS/DMS操作，即与该对象相关的消息将同时被增加或删除，同时，在部署图中还须将该模块添加到相关站点或从相关站点删除该模块。由于一个执行场景的可靠性直接取决于组件和连接件的可靠性，交互对象的增减将直接影响一个或多个包含该模块的场景的交互复杂性。
• AF/RF/CF:消息片段为顺序图中一组交互消息的循环调用，消息片段的增加、删除或者调用次数的修改将影响交互过程的复杂度，从而影响该场景的执行风险。
• AU/RU:为参与者增加或删除可执行用例，表示参与者执行权限的变化，一般来说可执行用例越多的参与者其权限越高。用户在运行系统时以某一参与者的身份执行用例，由于其参与的执行事件的增加或者事件执行方式的多样化，将导致系统运行更为复杂，运行时风险增加。
• AA/RA:增加或删除某一参与者意味着执行权限的增加或减少，该操作将引入AU/RU操作。参与者的增减虽然不会导致软件结构上的变化，然而不同的参与者有不同的执行方式，因而会导致系统动态交互上的变化，对程序运行时的风险有影响。

4.静态演化实例：正交软件架构(Orthogonal Software Architecture)

通过对功能进行分层和线索化，可以形成正交体系结构，同一层次中的组件不允许相互调用，故每个变动仅影响一条线索，如图10-5所示。

正交体系的演化过程概括如下：

①需求变动归类，使需求的变化和现有组件及线索相对应，判断重用情况；

②制订架构演化计划；

③修改、增加或删除组件；

④更新组件之间的相互作用；

⑤产生演化后的软件架构，作为系统更新的详细设计方案和实现基础。

10.3.3软件架构动态演化

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

一些长期运行，不能停机或者停机代价太高的系统，为适应系统需求变化或环境变化，因静态体系结构缺乏表示动态更新的机制，很难用其分析、描述这样的系统，更不能用它来指导系统进行动态演化，所以动态演化架构诞生。

1.动态演化的需求

架构的动态演化主来2类需求：

1).软件内部执行所导致的体系结构的改变。如许多服务器端软件会在客户请求到达时创建新的组件来响应用户需求。

2).软件系统外部的请求对软件进行的重配置。如OS升级无需重启。

2.动态演化的类型

1)软件动态性的等级

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

目前多在1、2级别，3很少。

2)动态演化的内容 (根据所修改的内容)  

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

●行为变化：在运行过程中，用户需求变化或系统自身服务质量的调节都将引发软件行为的变化。诸如，为了提高安全级别而更换加密算法；将HTTP协议改为HTTPS协议；组件和连接件的替换和重新配置。

●拓扑结构改变：如增删组件，增删连接件，改变组件与连接件之间的关联关系等。

●风格变化：一般软件演化后其架构风格应当保持不变，如果非要改变软件的架构风格，也只能将 架构风格变为其衍生风格，如将两层C/S结构调整为三层C/S结构或C/S与B/S的混合结构，将“1对1”的请求响应结构改为“1对N”的请求响应结构，以实现负载的平衡。

实现软件架构动态演化的技术主要有两种：

采用动态软件架构(Dynamic Soffware Architecture,DSA)：DSA是指在运行时刻会发生变化的系统框架结构，允许在运行过程中通过框架结构的动态演化实现对架构的修改。

进行动态重配置(Dynamic  Reconfiguration,DR)：DR从组件和连接件的配置入手，允许在运行过程中增删组件，增删连接件，修改连接关系等操作。

我们将DSA归结为架构动态性，将DR归结为结构动态性。

3.动态软件架构

软件架构的3个方向：软件架构风格、软件架构连接件、DSA。

DSA定义：可修改自身的架构，并在系统执行期间进行修改。

DSA意义：减少系统开发的费用和风险；增强用户自定义性和可扩展性，并可为用户提供更新系统属性的服务。

1)基于DSA实现动态演化的基本原理

基本原理：

使DSA在可运行应用系统中以一类有状态、有行为、可操作的实体显式地表示出来，并且被整个运行环境共享，作为整个系统运行的依据。也就是说，运行时刻体系结构相关信息的改变可用来触发、驱动系统自身的动态调整。此外，对系统自身所做的动态调整结果可反映在体系结构这一抽象层面上。

为动态演化提供相关功能：

①须提供保存当前软件架构信息(拓扑结构、组件状态和数目等)的功能；

②实施动态演化还须设置一个监控管理机制，对系统有无需求变化进行监视。当发现有需求变化时，应能分析并判断可否实施演化，以及何时演化和演化范围，并最终分析或生成演化策略。

③还应保证演化操作原子性，即在动态变化过程中，如果其中之一的操作失败了，整个操作集都要被撤销，从而避免系统出现不稳定的状态。

DSA实施动态演化大体遵循以下4步：

①捕捉并分析需求变化；

②获取或生成体系结构演化策略；

③根据步骤2得到的演化策略，选择适当的演化策略并实施演化；

④演化后的评估与检测。

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

2)DSA描述语言

①基于行为视角的π-ADL,使用进程代数来描述具有动态性的行为；

②基于反射视角的Pilar,利用反射理论显式地为元信息建立模型；

③基于协调视角的LIME,注重计算和协调部分的分离，利用协调论的原理来解决动态性交互。

3)DSA演化工具

动态演化的工具需要支持系统在演化过程中与其软件架构的一致性检查，并能够对架构演

化过程进行管理。

使用反射机制：K-Component框架元模型，

基于组件操作：SACDRE。

基于π演算：SAAM

利用外部的体系结构演化管理器；Argo

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

5.动态重配置

基于软件动态重配置的软件架构动态演化主要是指在软件部署之后对配置信息的修改，常常被用于系统动态升级时需要进行的配置信息修改。一般来说，动态重配置可能涉及的修改有：

①简单任务的相关实现修改；

②工作流实例任务的添加和删除；

③组合任务流程中的个体修改；

④任务输入来源的添加和删除；

⑤任务输入来源的优先级修改；

⑥组合任务输出目标的添加和删除；

⑦组合任务输出目标的优先级修改等。

1)动态重配置模式

4种重配置模式：

(1)主从(Master-Slave)模式：

在主从模式中，主组件接收客户端的服务请求，它将工作划分给从组件，然后合并、解释、总结或整理从组件的响应。当主组件没有对从组件分配工作时，从组件处于空闲(Idle)状态，并会在新的任务分配时被重新激活。主从模式由主操作重配置状态图描述，其中包含两个正交的图，即主操作状态图和主重配置状态图，主操作状态图定义了主组件的操作状态，主重配置状态图描述了主组件如何安排重配置的过程。

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

中央控制模式广泛应用于实时系统之中。在该模式中，一个中央控制器会控制多个组件，其状态图会维持两个状态，分别标识中央控制器是否处于空闲状态。

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

客户端/服务器模式中的客户端组件需要服务器组件所提供的服务，二者通过同步消息进行交互，在客户端/服务器重配置模式中，当客户端发起的事务完成之后可以添加或删除客户端组件；当顺序服务器(Sequential Server)完成了当前的事务，或者并发服务器(Concurrent Server)完成了当前事务的集合，且将新的事务在服务器消息缓冲中排队完毕之后，可以添加或删除服务器组件。

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

分布式控制模式下系统的功能整合在多个分布式控制组件之中。该模式广泛用于分布式应用之中，且有着多种相似的类型，如环形(Ring)模式和顺序(Serial)模式。环形模式中每个组件有着相同的功能，且在其左右均有一个组件(称为前驱和后继)与之交互；顺序模式中每个组件使用相同的连接与自己的前驱和后继交互，每个组件向自己的前驱发送请求并获得响应。

2)例子：可重用、可配置的产品线架构

3)动态重配置的难点

Tamura等人提出了在带有服务质量(Quality of Service,QoS)约束的情况下，基于扩展图进

行架构重配置的方法。针对此类重配置说明了动态重配置的4个难点：

①约束定义困难；

②性能约束难以静态衡量，需要在软件运行时进行评估；

③某些重配置方案能够解决性能约束的某一方面，但是难以管理所有方面； 

④重配置需要同时保证两个方面，即维持组件系统的完整性和重配置策略的正确和安全性。

10.4软件架构演化原则

1.演化成本控制原则Evolution Cost Control,ECC

●原则解释：演化成本要控制在预期的范围之内，也就是演化成本要明显小于重新开发成本。

●原则用途：用于判断架构演化的成本是否在可控范围内，以及用户是否可接受。

●度量方案：CoE<<CoRD。

●方案说明：CoE为演化成本，CoRD为重新开发成本，CoE远小于CoRD最佳。

2.进度可控原则Schedule Control

●原则解释：架构演化要在预期时间内完成，也就是时间成本可控。

●原则用途：根据该原则可以规划每个演化过程的任务量；体现一种迭代、递增(持续演化)的演化思想。

●度量方案：ttask=|Ttask-Ttask|。

●方案说明：某个演化任务的实际完成时间(Ttask)和预期完成时间(T'task)的时间差，时间差ttask越小越好。

3.风险可控原则Risk Control

●原则解释：架构演化过程中的经济风险、时间风险、人力风险、技术风险和环境风险等必须在可控范围内。

●原则用途：用于判断架构演化过程中各种风险是否易于控制。

●度量方案：分别检验。

●方案说明：时间风险、经济风险、人力风险、技术风险都不存在。

4.主体维持原则

●原则解释：对称稳定增长(the Average Incremental Growth,AIG)原则所有其他因素必须与软件演化协调，开发人员、销售人员、用户必须熟悉软件演化的内容，从而达到令人满意的演化。因此，软件演化的平均增量的增长须保持平稳，保证软件系统主体行为稳定。

●原则用途：用于判断架构演化是否导致系统主体行为不稳定。

●度量方案：计算AIG即可，AIG=主体规模的变更量/主体的规模。

●方案说明：根据度量动态变更信息(类型、总量、范围)来计算。

5.系统总体结构优化原则Optimization of Whole Structure

●原则解释：架构演化要遵循系统总体结构优化原则，使得演化之后的软件系统整体结构(布局)更加合理。

●原则用途：用于判断系统整体结构是否合理，是否最优。

●度量方案：检查系统的整体可靠性和性能指标。

●方案说明：判断整体结构优劣的主要指标是系统的可靠性和性能。

6.平滑演化原则Invariant Work Rate,IWR

●原则解释：在软件系统的生命周期里，软件的演化速率趋于稳定，如相邻版本的更新率相对固定。

●原则用途：用于判断是否存在剧烈架构演化。

●度量方案：计算IWR即可，IWR=变更总量/项目规模。

●方案说明：根据度量动态变更信息(类型、总量、范围等)来计算。

7.目标一致原则Objective Conformance

●原则解释：架构演化的阶段目标和最终目标要一致。

●原则用途：用于判断每个演化过程是否达到阶段目标，所有演化过程结束是否能达到最终目标。

●度量方案：otask=|Otask-O'task|。

●方案说明：阶段目标的实际达成情况(Otask)和预期目标(O'task)的差，Otask越小越好。

8.模块独立演化原则/修改局部化原则(Local Change)

●原则解释：软件中各模块(相同制品的模块，如Java的某个类或包)自身的演化最好相互独立，或者至少保证对其他模块的影响比较小或影响范围比较小。

●原则用途：用于判断每个模块自身的演化是否相互独立。

●度量方案：检查模块的修改是否是局部的。

●方案说明：可以通过计算修改的影响范围来进行度量。

9.影响可控原则Impact Limitation

●原则解释：软件中一个模块如果发生变更，其给其他模块带来的影响要在可控范围内，也就是影响范围可预测。

●原则用途：用于判断是否存在对某个模块的修改导致大量其他修改的情况。

●度量方案：检查影响的范围是否可控。

●方案说明：可以通过计算修改的影响范围来进行度量。

10.复杂性可控原则Complexity Controllability

●原则解释：架构演化必须要控制架构的复杂性，从而进一步保障软件的复杂性在可控范围内。

●原则用途：用于判断演化之后的架构是否易维护、易扩展、易分析、易测试等。

●度量方案：CC<某个阈值；方案说明：CC增长可控。

11.有利于重构原则Useful for Refactoring

●原则解释：架构演化要遵循有利于重构原则，使得演化之后的软件架构更便于重构。

●原则用途：用于判断架构易重构性是否得到提高。

●度量方案：检查系统的复杂度指标。

●方案说明：系统越复杂越不容易重构。

12.有利于重用原则Useful for Reuse

●原则解释：架构演化最好能维持，甚至提高整体架构的可重用性。

●原则用途：用于判断整体架构可重用性是否遭到破坏。

●度量方案：检查模块自身的内聚度、模块之间的耦合度。

●方案说明：模块的内聚度越高，该模块与其他模块之间的耦合度越低，越容易重用。

13.设计原则遵从性原则Design Principles Conformance

●原则解释：架构演化最好不能与架构设计原则冲突。

●原则用途：用于判断架构设计原则是否遭到破坏(架构设计原则是好的设计经验总结，要保障其得到充分使用)。

●度量方案：RCP=|CDP//DP]。

●方案说明：冲突的设计原则集合(CDP)和总的设计原则集合(DP)的比较，RCP越小越好。

14.适应新技术原则Technology Independence,TI

●原则解释：软件要独立于特定的技术手段，这样才能够让软件运行于不同平台。

●原则用途：用于判断架构演化是否存在对某种技术依赖过强的情况。

●度量方案：TI=1-DDT,其中DDT=1依赖的技术集合/用到的技术合集]。

●方案说明：根据演化系统对关键技术的依赖程度进行度量。

15.环境适应性原则Platform Adaptability

●原则解释：架构演化后的软件版本能够比较容易适应新的硬件环境与软件环境。

●原则用途：用于判断架构在不同环境下是否仍然可使用，或者容易进行环境配置。

●度量方案：硬件/软件兼容性。

●方案说明：结合软件质量中兼容性指标进行度量。

16.标准依从性原则Standard Conformance

●原则解释：架构演化不会违背相关质量标准(国际标准、国家标准、行业标准、企业标准等)。

●原则用途：用于判断架构演化是否具有规范性，是否有章可循；而不是胡乱或随意地演化。

●度量方案：需要人工判定。

17.质量向好原则Quality Improvement,QI

●原则解释：通过演化使得所关注的某个质量指标或某些质量指标的综合效果变得更好或者更满意，例如可靠性提高了。

●原则用途：用于判断架构演化是否导致某些质量指标变得很差。

●度量方案：EQI≥Q。

●方案说明：演化之后的质量(EQI)比原来的质量(SQ)要好。

18.适应新需求原则New Requirement Adaptability

●原则解释：架构演化要很容易适应新的需求变更；架构演化不能降低原有架构适应新需求的能力；架构演化最好可以提高适应新需求的能力。

●原则用途：用于判断演化之后的架构是否降低了架构适应新需求的能力。

●度量方案：RNR=IANR/NR|。

●方案说明：适应的新需求集合(ANR)和实际新需求集合(NR)的比较，RNR越小越好。

10.5软件架构演化评估方法

根据演化过程是否已知可将评估过程分为：演化过程已知的评估和演化过程未知的评估。

10.5.1演化过程已知的评估

评估其目的：通过对架构演化过程进行度量，比较架构内部结构上的差异以及由此导致的外部质量属性上的变化，对该演化过程中相关质量属性进行评估。

1.评估流程

基本思路：是将架构度量应用到演化过程中，通过对演化前后的不同版本的架构分别进行度量，得到度量结果的差值及其变化趋势，并计算架构间质量属性距离，进而对相关质量属性进行评估。

2.架构演化中间版本度量

3.架构质量属性距离

4.架构演化评估

基于度量的架构演化评估方法，其基本思路在于通过对演化前后的软件架构进行度量，比较架构内部结构上的差异以及由此导致的外部质量属性上的变化。基于度量的架构演化评估，可以帮助我们分析架构内部结构的修改对外部质量属性所产生的影响、监控演化过程中架构质量的变化、归纳架构演化趋势，并有助于开发和维护等相关工作开展，具体包括如下几个方面：

①架构修改影响分析：为了更好地归纳和说明架构演化的相关规律，本节对演化进行分类，比较不同类型的演化操作对架构相关质量属性的影响。通过将演化过程拆分成粒度很细的原子演化操作序列，具体分析架构内部逻辑结构和交互过程的修改会对哪些相关外部质量属性产生影 响，并分析修改影响范围，进一步分析架构版本距离和相关质量属性距离的关联。

②监控演化过程：通过对架构演化过程中的中间版本架构进行度量，我们可以得到架构相关质量属性随时间推移的变化曲线。通过对架构演化过程中质量属性的监控，将有利于保持架构健康持续地演化。

③分析关键演化过程：架构质量属性距离评估不同版本的架构在质量属性上的差异。从质量属性距离形成的曲线可以观察到架构质量发生较大改变的时刻，在该时刻架构的逻辑依赖或交互过程可能发生重大改变，在开发和维护过程中应该予以重视，这将有利于架构维护及故障定位等。

10.5.2演化过程未知的评估

根据架构演化前后的度量结果逆向推测出架构发生架构度量架构度量了哪些改变，并分析这些改变与架构相关质量属性的关联关系。

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

10.6.1第一阶段：单体架构

10.6.2第二阶段：垂直架构

10.6.3第三阶段：使用缓存改善网站性能

网站使用的缓存可以分为两种：缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服

务器上的远程缓存。

●本地缓存的访问速度更快一些，但是受应用服务器内存限制，其缓存数据量有限，而且会出现和应用程序争用内存的情况。

●远程分布式缓存可以使用集群的方式，部署大内存的服务器作为专门的缓存服务器，可以在理论上做到不受内存容量限制的缓存服务。

10.6.4第四阶段：使用服务集群改善网站并发处理能力

应用服务器实现集群是网站可伸缩架构设计中较为简单成熟的一种。

通过负载均衡调度服务器，可以将来自用户浏览器的访问请求分发到应用服务器集群中的任何一台服务器上，如果有更多用户，就在集群中加入更多的应用服务器，使应用服务器的压力不再成为整个网站的瓶颈。

10.6.5第五阶段：数据库读写分离

10.6.6第六阶段：使用反向代理和CDN加速网站响应

● CDN部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据。

●反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。

10.6.7第七阶段：使用分布式文件系统和分布式数据库系统

任何强大的单一服务器都满足不了大型网站持续增长的业务需求。数据库经过读写分离后，从一台服务器拆分成两台服务器，但是随着网站业务的发展依然不能满足需求，这时需要使用分布式数据库。文件系统也一样，需要使用分布式文件系统。分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候才使用。不到不得已时，网站更常用的数据库拆分手段是业务分库，将不同业务的数据部署在不同的物理服务器上。

10.6.8第八阶段：使用NoSQL和搜索引擎

随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂，网站需要采用一些非关系数据库技术如NoSQL和非数据库查询技术如搜索引擎。NoSQL和搜索引擎都是源自互联网的技术手段，对可伸缩的分布式特性具有更好的支持。应用服务器则通过一个统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。

10.6.9第九阶段：业务拆分

大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段将整个网站业务分成不同的产品线。如大型购物交易网站都会将首页、商铺、订单、买家、卖家等拆分成不同的产品线，分归不同的业务团队负责。

具体到技术上，也会根据产品线划分，将一个网站拆分成许多不同的应用，每个应用独立部署。应用之间可以通过一个超链接建立关系(在首页上的导航链接每个都指向不同的应用地址),也可以通过消息队列进行数据分发，当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。

10.6.10第十阶段：分布式服务

随着业务拆分越来越小，存储系统越来越庞大，应用系统的整体复杂度呈指数级增加，部署维护越来越困难。由于所有应用要和所有数据库系统连接，在数万台服务器规模的网站中，这些连接的数目是服务器规模的平方，导致数据库连接资源不足，拒绝服务。

既然每一个应用系统都需要执行许多相同的业务操作，比如用户管理、商品管理等，那么可以将这些共用的业务提取出来，独立部署。由这些可复用的业务连接数据库，提供共用业务服务，而应用系统只需要管理用户界面，通过分布式服务调用共用业务服务完成具体业务操作。

大型网站的架构演化到这里，基本上大多数的技术问题都得以解决，诸如跨数据中心的实时数据同步和具体网站业务相关的问题也都可以通过组合改进现有技术架构解决。

10.7软件架构维护

10.7.1软件架构知识管理

1.架构知识的定义

架构知识=架构设计+架构设计决策。即需要说明在进行架构设计时采用此种架构的原因。

2.架构知识管理的含义

架构知识管理侧重于软件开发和实现过程所涉及的架构静态演化，从架构文档等信息来源中捕捉架构知识，进而提供架构的质量属性及其设计依据以进行记录和评价。架构知识管理不仅要涵盖架构的解决方案，也要涵盖产生该方案的架构设计决策、设计依据与其他信息，以有助于架构进一步的演化。

3.架构知识管理的需求

架构知识的可获得性能够极大地提升软件开发流程。如果对架构知识不进行管理的话，那么关键的设计知识就会“沉没”在软件架构之中，如果开发组人员发生变动，那么“沉没”的架构知识就会“腐蚀”。

4.架构知识管理的现状

侧重于对架构信息的整理、存储和恢复。动机不足、成本高、短期兴趣高于长远的架构知识、缺乏培训，不能充分分享。

10.7.2软件架构修改管理

在软件架构修改管理中，一个主要的做法就是建立一个隔离区域(Region of Quiescence),

保障该区域中任何修改对其他部分的影响比较小，甚至没有影响。为此，需要明确修改规则、

修改类型，以及可能的影响范围和副作用等。

10.7.3软件架构版本管理

软件架构版本管理为软件架构演化的版本演化控制、使用和评价等提供了可靠的依据，并

为架构演化量化度量奠定了基础。

10.7.4软件架构可维护性度量实践

这是个例子。