系统架构师-第10章-软件架构的演化和维护-学习笔记

软件架构一般会经历初始设计、实际使用、修改完善和退化弃阳的过程，其中修改完善的过程实际上就是软件架构的演化和维护过程，演化和维护的H 的就是为f 侦软件能够适应环境的变化而进行的纠铺性修改和完善性修改等。

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

演化的重要性

为什么软件架构演化如此重要?

首先，软件架构作为软件系统的骨架支撑着鞍个软件系统，是软件系统具备诸多好的特性的重要保障。因为最终软件系统的性能、可靠性、去全性和易维护性等是软件系统J7t重要的质母和功能属性，是决定软件系统是否被用户接受、是否具有市场竞争力、是否具有进一步战造升级的可能性、是否具有较长生命周期的重要肉萦: 软件架构自身的好坏直接影响着它们是否满足用户需求，而软件架构演化正是为了保障这些方面向人们预期的方向发展的革要措施。
其次，软件架构作为软件蓝图为人们宏观管控软件系统的整体复杂性和变化性提供了一条有效途径，而且基于软件架构进行的软件检测和修改成本相对较低，所以要刻画复杂的软件演化，井对演化中的影响效应进行观察和控制，从软件架构演化出发更加合理。

软件架构消化使得软件系统消化更加便捷，这里主要有3 个原肉。
(1)对系统的软件架构进行的形式化、可视化表示提高了软件的时构造性，便于软件演化。
(2) 软件架构设计方泉涌盖的整体结构信息、配置信息、约束信息等有助于开发人员充分考虑未来时能出现的演化问题、演化情况和演化环境。
(3)架构设计时对系统组件之间的稿合描述有助于软件系统的动态调整.

演化和定义的关系

软件架构定义是SA=（components ， connectors, constraints} ，

软件架构包括组件( Components ) 、连接件( Connectors ) 和约束( Constraints) 三大要素，

这类软件架构演化主要关注的就是组件、连接件和约束的添加、修改与删除等。

组件是软件架构的基本要素和结构单元，表示系统中主要的计算元素、数据存储以及一些重要模块，当需要消除软件架构存在的缺陷、增加新的功能、适应新的环境时几乎都涉及组件的演化

连接件是组件之间的交互关系，大多数情况下组件的演化牵涉到连接件的演化。

约束是组件和连接件之间的拓扑关系和配置，它为组件和连接件提供额外数据支撑，可以是架构的约束数据，也可以是架构的参数。

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

对象演化

会对架构设计的动态行为产生影响的演化只包括AddObject ( AO) 和DeleteObject （ DO ) 两种

消息演化

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

消息演化分为AddMessage( AM ) 、DeleteMc ssage ( DM ) 、SwapM 巳ssageOrder (S MO ) 、OverturnMc ssage (OM) ,ChangeMessageModule (CMM) 5 种

AM 增添一条新的消息，产生在对象之间需要增加新的交互行为的时候。

DM 删除当前的一条消息，产生在需要移除某个交互行为的时候，是AM 的逆向演化。

SMO 交换两条消息的时间顺序，发生在需要改变两个交互行为之间关系的时候。

OM 反转消息的发送对象与接收对象，发生在需要修改某个交互行为本身的时候。

CMM 战变消息的发送或接收对象，发生在需要修改某个交互行为本身的时候。

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

演化分为3 类。

第1类演化与当前约束无关 AM

第2 类演化与约束直接关联但不会违背约束 CMM

第3 类演化与约束直接关联并会边背约束 DM

消息是顺序图的核心内容，消息演化是)顺序图演化的核心

复合片段演化

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

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

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

DF 与AF 互为逆向演化过程。
FTC 改变复合片段的类型，发生在需要改变某段控制流时。

约束演化

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

软件架构演化方式的分类

3 种较典型的分类方法:
(1)按照软件架构的实现方式和实施粒度分类:

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

(2) 按照研究方法将软件架构演化方式分为4 类:

第1类是对演化的支持，如代码模块化的准则、可维护性的指示(如内聚和精合〉、代码结构:

第2 类是版本和工程的管理工具

第3 类是架构变换的形式方法，包括系统结构和行为变换的模型，以及架构演化的重现风格等

第4 类是架构演化的成本收益分析，决定如何增加系统的弹性。
(3) 针对软件架构的演化过程是否处于系统运行时期

静态演化( Static Evo lution )

动态演化( Dynamic Evolution)

前者发生在软件架构的设计、实现和维护过程中，软件系统连未运行或者处在运行停止状态; 后者发生在软件系统运行过料中。

软件架构演化时期

设计时演化（Design-Time Evolution) 是指发生在体系结构模刷刷与之相关的代码编译之前的软件架构演化.

运行前演化( Pre-Execution Evolution) 是指发生在执行之前、编译之后的软件架构演化

有限制运行时演化（Constrained Runtime Evolution) 是指系统在设计时就规定了演化的具体条件，将系统置于"安全"模式下， i演化只发生在某些特定约束满足时，可以进行一些规定好的演化操作。

运行时演化CRuntime Evolution) 是指系统的体系结构在运行时不能满足要求时发生的软件架构演化，包括添加组件、删除组件、升级替换组件、改变体系结构的拓扑结构等。

软件架构静态演化

软件架构静态演化指的是软件架构在时间上的变化，不涉及到运行时的行为。在软件开发过程中，软件架构可能会随着需求变化、技术进步、业务扩展等因素而发生改变。软件架构静态演化可以分为三个方面的变化：

1. 结构变化：指软件架构中各个组件之间的关系和连接方式发生变化。例如，一个新的组件被加入到系统中，原有的组件被修改或删除。

2. 接口变化：指软件架构中各个组件之间的接口发生变化。例如，接口参数、返回值等发生改变。

3. 外部依赖变化：指软件架构与外部系统、组件、库之间的依赖关系发生变化。例如，系统升级到新的操作系统，新的库被引入到系统中，旧的库被替换或删除等。

软件架构静态演化对于软件系统的健康发展和维护非常重要，因为它可以避免软件系统的腐化和技术债务的积累，保证系统的可扩展性、可维护性和可重用性。

1. 静态演化需求

(1)设计时演化需求。在架构开发和实现过程"，对原有架构进行调整，保证软件实现与架构的一致性以及软件开发过梧的顺利进行。
(2) 运行前演化需求。软件发布之后由丁运行环境的变化，需要对软件进行修改升级，在此期间软件的架掏同样要进行演化。

2. 静态演化的一般过程

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

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

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

一次完辑软件架构演化过程可以看作经过一系列原子演化操作组合而成。

所谓原子演化操作是指基于UML 模型表示的软件架构，在逻辑语义上粒度最小的架构修改操作。

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

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

这些原子修改操作包括增加/删除棋块间的依赖、增加/删除模块间的接门、增加/删除模块、拆分/聚合模块等

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

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

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

这些原子修改操作包括增加/删除消息、增加/ 删除交互对象、增加/删除/修改消息片段、增加/删除用例执行、增加/删除角色等

AMS/RMS: 模块间的消息交互体现在UML顺序图中。消息变化包含增加消息、删除消息和修改消息。
AO/RO: 在顺序闺中增加或删除交互对象将引入AMS/DMS操作，即与该对象相关的消息将同时被增加或删除，同时，在部署图中还须将该模块添加到相关站点或从相关站点删除该模块。
AFIRF/CF: 消息片段为顺序图中一组交互消息的循环调用，消息片段的增加、删除或者调用次数的修改将影响交互过程的复杂度，从而影响该场景的执行凤险.
AU/RU : 为参与者增加或删除可执行用例，表示参与者执行权限的变化，般来说可执行用例越多的参与者其权限越高。
AA/RA: 增加I或删除某一参与者意味着执行权限的增加或减少，该操作将引人AU/RU操作。

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

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

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

②制订架构演化计划;

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

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

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

软件架构动态横化

1. 动态演化的需求

架构的动态演化主要来自两类需求:

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

②软件系统外部的请求对软件进行的重配置，例如，操作系统在升级时无须重新启动，在运行过料中就完成对体系结构的修改。

2. 动态演化的类型

1)软件动态性的等级

软件的动态性分为3 个级别

①交互动态性( Interactive Dynamism) ，要求数据在固定的结构下动态交互:

②结构动态性(Structural Dynamism) ，允许对结构进行修改，通常的形式是组件和连接件实例的添加和删除，这种动态性是研究和应用的主流:

③架构动态性(Architectura1 Dynamism) ，允许软件架构的基本构造的变动，即结构可以被重定义，如新的组件类型的定义。

2) 动态演化的内容

根据所修改的内容不同，软件的动态演化主要包括以下4 个方面。
        · 属性改名: 目前所有的ADL都支持对非功能属性的分析和规约，而在运行过程中，用户可能会对这些指标进行重新定义(如服务响应时间〕。
        · 行为变化: 在运行过程中，用户需求变化成系统自身服务质量的调节都将引发软件行为的变化。诸如，为了提高安全级别而更换加密算法; 将HTTP协议改为HTTPS协议;组件和连接件的替换和重新配置。
        · 拓扑结构改变:如增删组件，增删连接件，改变组件与连接件之间的关联关系等。
        · 风格变化: 一般软件演化后其架构风格应当保持不变，如果非要改变软件的架构风格，也只能将架构风格变为其衍生风格，如将两层C/S结构调整为三层C/S结构或C/S与B/S 的说合结构，将" I 对1 " 的请求响应结构改为"1 对N" 的请求l响应结构，以实现负载的平衡.

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

采用动态软件架构( Dynamic Software Architecture, DSA )

进行动态重配置( Dynamic Reconfiguration, DR).

DSA 是指在运行时刻会发生变化的系统框架结构，允许在运行过程中通过框架结构的动态演化实现对架构的修改;
DR 从组件和连按件的配置入手，允许在运行过程中增删组件，增删连接件，修改连接关系等操作。

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

3. 动态软件架构

软件架构中最为重要的3 个研究方向，即软件架构风格、软件架构连接件和DSA .

DSA 指那些在软件运行时刻会发生变化的体系结构。

软件架构的动态'性指巾于系统需求、技术、环境、分布等因素的变化而导致软件架构在软件运行时刻的变化，主要地过软件架构的动态演化来体现。

DSA 的意义主要在于能够减少系统开发的费用和风险。DSA 能增强用户自定义性和可扩展性，并可为用户提供更新系统属性的服务.

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

实现软件架构动态演化的基本原理是使DSA 在可运行应用系统中以一类有状态、有行为、可操作的实体显式地表示出来，并且被整个运行环境共享，作为整个系统运行的依据。

动态演化实现起来比静态消化复杂得多，系统必须提供SA动态演化的一些相关功能。

首先，系统必须提供保存当前软件架构信息〈拓扑结构、组件状态和数日等)的功能:

其次，实施动态、演化还须设置一个监控管理机制，对系统有无需求变化进行监视。

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

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

①捕捉并分析需求变化:

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

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

④演化后的评估与检测。

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

2) DSA 描述语言

按照描述视角可将软件动态性建模语言分为3 类:

①基于行为视角的π-ADL 使用进程代数来描述具有动态性的行为;
②基于反射视角的Pilar，利用反射理论显式地为元信息建立模型;
③基于协调视角的LIME，注重计算和协调部分的分离，利用协调论的原理来解决动态性交互。

3) DSA 演化工具

动态演化的工具要支持系统在演化过程中与其软件架构的一致性检查，并能够对架构演化过程进行管理，主要街以下几种方法。
· 使用反射机制:
· 基于组件操作: 此类工具用于支持基于组件的系统构架进行动态演化。
· 基于π演tt : π演算是在CCS ( Calculus of Communicating System ) 的基础上提出的、基于命名概念的进程代数并发通信行为演算方法，
· 利用外部的体系结构演化管理器:

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

基于Java虚拟机，PKUAS 将乎台自身的实体划分为如下4 种类础。
(1)容器系统
(2) 公共服务:
(3)工具:辅助用户使用和管理PKUAS 的工具集合，主要包括部署工具、配置工具与实时监控工具。其中部署工具既可热部署整个应用，也可热部署单个组件，从而实现应用的在线演化:配置工具允许用户配置整个服务器或单个应用:而实时监控工具允许用户实时观察系统的运行状态井做出相应调整。
(4) 微内核

5. 动态重配置

基于软件动态重配置的软件架构动态演化主要是指在软件部署之后对配置信息的修改

动态重配置可能涉及的修改有:
①简单任务的相关实现修改;
②工作流实例任务的添加和删除:
③组合任务流程中的个体修改:
④任务输入来源的添加和删除;
⑤任务输入来说的优先级修改;
⑥组合任务输出目标的添加和删除;
⑦组合任务输出目标的优先级修改等。

1 )动态重配置模式

4 种重配置模式。
(1) 主从(Master-Slave) 模式:在主从模式中，主组件接收容户端的服务请求，它将工作划分给从组件，然后合并、解释、总结或整理从组件的响应。
(2) 中央控制(Centralized Control) 模式: 中央控制模式广泛应用于实时系统之中。
(3) 客户端/ 服务器(Client Server ) 模式:客户端/ 服务器模式中的客户端组件前要服务器组件所提供的服务，气者通过同步消息进行交互，在客户端/ 服务器南配置模式中，当客户端发起的事务完成之后可以添加或删除客户端组件: 当顺序服务器(Sequential Server) 完成了当前的事务，或者井发服务器(Concurrent Server ) 完成了当前事务的集合，且将新的事务在服务器消息缓冲中排队完毕之后，可以添加或删除服务器组件。
(4) 分布式控制( Decentτalized Control ) 模式: 分布式控制模式下系统的功能整合在多个分布式控制组件之中。

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

3 )动态重配置的难点

动态重配置的4 个难点:
①约束定义困难;
②性能约束难以静态衡量，需要在软件运行时进行评估:
③某些重配置方案能够解决性能约束的某一方面，但是难以管理所有方面;
④重配置需要同时保证两个方面，即维持组件系统的完整性和重配置策略的正确和安全性。

软件架构演化原则

1. 演化成本控制原则
· 原则名称: 演化成本;抑制（Evolution Cost Control, ECC ) 原则。
· 原则解释: 演化成本提控制在预期的地回之内，也就是消化成本要明显小于新开发成本。
· 原则用途: 用于判断架构演化的成本盐否在可控范围内，以及用户是否可接受.
· 度量方案: CoE<<CoRD 。
· 方案说明: CoE为演化成本， CoRD为重新开发成本， CoE远小于CoRD最佳。

2. 进度可控原则
· 原则名称: 进度可控( Schedule Control ) 原则。
· 原则解释: 架构演化要在预期时间内完成，也就是时间成本可控。
· 原则用途:根据该原则可以规划每个演化过程的任务量;体现一种地代、递增(持续演化)的演化思想。
· 度量方案: ttask=ITtask- T'taskl 。
· 方案说明:某个演化任务的实际完成时间( Ttask) 和预期完成时间(T'task) 的时间差，时间差ttask越小越好。

3. 风险可控原则
· 原则名称: 风险可控( Risk ControJ) 原则。
· 原则解释: 架构演化过程中的经济风险、时间风险、人力风险、技术风险和环境风险等必须在可控范围内。
· 原则用途:用于判断架构演化过程中各种风险是否易于控制。
· 度量方案: 分别检验。
· 方案说明: 时间凤院、经济风险、人力风险、技术风险都不存在。

4. 主体维持原则
· 原则名称: 主体维持原则。
· 原则解释: 对称稳定增长( the Average Incremental Growth. AIG ) 原则所有其他因素必须与软件演化协调，开发人员、销售人员、用户必须熟悉软件演化的内容，从而达到令人满意的演化。因此，软件演化的平均增量的增氏须保持平稳，保证软件系统主体行为稳定。
· 原则用途:用于判断架构演化是否导致系统主体行为不稳定。
· 度量方案: 计算AIG即可，A1G=主体规模的变更量/主体的规模。
· 方案说明:根据度量动态变更信息(类型、总量、范围)来计算。

5. 系统总体结构优化原则
· 原则名称:系统总体结构优化(Optimization ofWhole Structure ) 原则。
· 原则解释: 架构梢化要遵循系统总体结构优化原则，使得演化之后的软件系统整体结构(布局)更加合理。
· 原则用途: 用于判断系统整体结构是否合理，是否最优.
· 度量方案:检任系统的整体可靠性和性能指标。
· 方案说明: 判断整体结构优劣的主要指标是系统的可靠性和性能。

6. 平滑演化原则
· 原则名称: 平滑演化（Invariant Work Rate, IWR ) 原则.
· 原则解释: 任软件系统的生命周期里，软件的演化速率趋于稳定，如相邻版木的更新率相对间应.
· 原则用途: 用于判断是台存在剧烈架构演化。
· 度量方案:计算IWR 即可， IWR=变更总量/项目规模。
· 方案说明:根据度结动态变旦信息(类型、总量、范围等)来计算。

7. 目标-致原则
· 原则名称: 目标- 蚁( 0战jective COnfOmlanCe) 原则。
· 原则解释:架构演化的阶段日标和最终目标要一致。
· 原则用途:用于判断每个演化过程是否达到阶段目标，所有演化过相结束是否能达到最终目标。
· 度量方案: otask=IOt出k-O'taskl 。
· 方案说明: 阶段日标的实际达成情况（Otask ) 和预期忖标( O'task ) 的差，Otask越小越好。

8. 模块独立演化原则
· 原则名称: 模块独立演化原则，或称为修改局部化原则(Local Change ) 。
· 原则解释: 软件中各模块(相同制品的模块，如Java的某个类或包〉自身的演化最好相互独立，或者至少保证对其他模块的影响比较小或影响范围比较小。
· 原则用途: 用于判断每个模块自身的演化是否相互独立。
· 度量方案: 检查模块的修改是否是局部的。
· 方案说明: 可以通过计算修改的影响范围来进行度量。

9 . 影晌可控原则
· 原则名称: 影响可控( Impact Limitation) 原则。
· 原则解释: 软件中一个模块如果发生变更，其给其他模块带来的影响要在可控范围内，也就是影响范围可预测。
· 原则用途: 用于判断是否存在对某个模块的修改导致大量其他修改的情况。
· 度量方案: 检查影响的范围是否可控。
· 方案说明: 可以通过计算修改的影响范围来进行度量。

10. 复杂性可控原则
· 原则名称: 复杂性可控( Complexity Controllability )原则。
· 原则解择: 架构演化必须要控制架构的复杂性，从而进一步保障软件的复杂性在可控范围内。
· 原则用途: 用于判断演化之后的架构是否易维护、易扩展、易分析、易测试等。
· 度量方案: CC<某个阙值: 方案说明; CC增长可控。

11. 有利于重构原则
· 原则名称: 有利于重构( Useful for Refactoring ) 原则。
· 原则解释: 架构演化要遵循有利于重构原则，使得演化之后的软件架构更便于重构。
· 原则用途: 用于判断架构易重构性是否得到提高。
· 度量方案: 检查系统的复杂度指标。
· 方案说明: 系统越复杂越不容易重构。

12. 有利于重用原则
· 原则名称: 有利于重用( Usefu l for Reuse ) 原则。
· 原则解释: 架构演化最好能维持，甚至提高整体架构的可重用性。
· 原则用途: 用于判断整体架构可重用性是否遭到破坏。
· 度量方案: 检查模块自身的内聚度、模块之间的棋合度。
· 方案说明: 模块的内聚度越高，该模块与其他棋块之间的稠合度越低，越容易重用。

13. 设计原则遵从性原则
· 原则名称: 设计原则遵从性（Design Principles Confonnance ) 原则.
· 原则解释: 架构演化最好不能与架构设计原则冲突。
· 原则用途: 用于判断架构设计原则是否遭到破坏( 架构设计原则是好的设计经验总结，要保障其得到充分使用）。
· 度盘方案: RCP=ICDPI~DPI 。
· 方案说明:冲突的设计原则集合C CDP ) 和总的设计原则集合C DP ) 的比较， RCP越小越好。

14. 适应新技术原则
· 原则名称: 适应新技术( Tcchnology Independence, Tl)原则。
· 原则解膀: 软件桌独立于特定的技术手段，这样才能够让软件运行于不同平台。
· 原则剧途: 用于)~IJ 断架构演化是舌存在开j 某种技术依赖过强的悄况。
· 度最方来: Tl= I -DDT，其中DDT=I依赖的技术集合111用到的技术合集| 。
· 方案说明: 根据悄化系统对关键技术的依赖程度进行度址。

15. 环境适应性原则
· 原则名称: 环境适应性( Platfonn Adaptability )原则。
· 原则解释: 架构演化后的软件版本能够比较容易适应新的硬件环境与软件环境。
· 原则用途: 用于判断架构在不同环境下是否仍然可使剧，或者容易进行环境配置。
· 度量方案: 硬件/软件兼容性。
· 方案说明: 结合软件质量巾兼容性指标进行度量。

16. 标准依从性原则
· 原则名称: 标准依从忡: ( Standard Conformance ) 原则。
· 原则解释: 架构演化不会违背相关质量标准(国际标准、国家标准、行业标准、企业标准等)
· 原则用途: 用判断架构演化是否具有规范性，是否有章可循: 而不赴胡乱成随怠地演化。
· 度量方案:需要人工判定。

17. 质量向好原则
· 原则名称: 质量向好( Quality lmprovement, QI) 原则.
· 原则解释: 通过演化使得所关注的某个质量指标或某些质量指标的综合敛祟变得更好或者更满意。
· 原则剧途: 刷子判断架构演化是否导致某些质量指标变得很差.
· 度量方案: EQI >= Q 。
· 方案说明:演化之后的质量CEQI)比原来的质量CSQ) 要好。

18. 适应新需求原则
· 原则名称:适应新需求CNew Requirement Adaptability) 原则。
· 原则解释:架构演化要很容易适应新的需求变更:架构演化不能降低原有架构适应新需求的能力:架构演化最好可以提高适应新需求的能力。
· 原则用途: 用于判断演化之后的架构是否降低了架构适应新需求的能力。
· 度最方案: RNR=IANRIII网。
· 方案说明:适应的新需求集合CANR) 和实际新需求集合(NR) 的比较， RNR越小越好。

软件架构演化评估方法

根据演化过程是否己知可将评估过程分为:
演化过程己知的评估
演化过程未知的评估。

演化过程己知的评估

1. 评估流程

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

3. 架构质量属性距离

        架构质量属性距离D (i-l, i)用来评估相邻版本架构问质量属性的差异.
        1 )可维护性距离计算方法
        2) 可靠性距离计算方法
        3 )非相邻版本的架构质量属性距离

4. 架构演化评估

基于度量的架构演化评估方法，其基本思路在于通过对演化前后的软件架构进行度量，比较架构内部结构上的差异以及由此导致的外部质量属性上的变化。

基于度量的架构演化评估，可以帮助我们分析架构内部结构的修改对外部质量属性所产生的影响、监控演化过程中架构质量的变化、归纳架构演化趋势，并有助于开发和维护等相关工作开展

主要包括：
①架构修改影响分析: 为了更好地归纳和说明架构演化的相关规律，本节对演化进行分类，比较不同类型的演化操作对架构相关质量属性的影响。
②监控演化过程: 通过对架构演化过程中的中间版本架构进行度量，我们可以得到架构相关质量属性随时间推移的变化曲线。通过对架构演化过程中质量属性的监控，将有利于保持架构健康持续地演化。
③分析关键演化过程: 架构质量属性距离评估不同版本的架构在质量属性上的差异。

演化过程未知的评估

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

第一阶段:单体架构

单体架构（Monolithic Architecture）是一种传统的软件架构风格，将整个应用程序构建为单个大型代码库或单个可执行文件。在单体架构中，应用程序的所有功能都在同一个代码库或可执行文件中实现，通常使用同一种编程语言和技术栈进行开发。单体架构的优点包括实现和部署相对简单、易于维护和扩展。然而，随着应用程序变得越来越复杂，单体架构的缺点也变得越来越明显，包括难以维护、可扩展性差、代码库过于庞大等。近年来，微服务架构逐渐流行，被认为是替代单体架构的一种更加灵活和可扩展的架构风格。

第二阶段:垂直架构

垂直架构（Vertical Architecture）是一种传统的计算机架构设计模式，主要特点是把系统按照功能划分为多个层次，每一层次由不同的硬件或软件实现。垂直架构通常包括操作系统、应用程序、数据库管理系统和硬件等。这种架构模式一般适用于大型企业级应用程序和计算机系统，可以提供高性能、高可靠性和高安全性。

垂直架构的缺点在于它不够灵活，难以适应快速变化的市场需求和技术趋势。同时，垂直架构的成本也较高，需要大量的硬件和软件开发资源。随着云计算和虚拟化技术的发展，水平架构（Horizontal Architecture）逐渐成为了一种更为流行的架构模式，它能够更好地支持快速迭代和弹性扩展，并能够降低整体成本。

· 应用服务器需要处理大量的业务逻辑，囚此需要更快更强大的处理器速度。
· 数据库服务器需要快速磁盘检索和数据缓存，因此需要更快的磁盘和更大的内存。
· 文件服务器需要存储大量用户卜传的文件，因此需要更大容量的硬盘。

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

缓存在应用服务器上的木地缓存和缓存在专门的分布式缓存服务器上的远程缓存。

第四阶段:使用服务集群改善网站并发处地能力

第五阶段:数据库读写分离

数据库读写分离是指将数据库读操作和写操作分别分配到不同的数据库服务器上，以提升数据库的性能和稳定性。在读写分离模式下，写操作通常集中在主数据库上，读操作则可以分散到多个从数据库上，以分担主数据库的读压力。

优点：
1. 提高数据库性能和扩展性
2. 改善应用性能和用户体验
3. 改善数据库的可靠性和容错能力
4. 提高系统的可维护性和可扩展性

缺点：
1. 增加系统架构复杂度
2. 配置和维护成本较高
3. 需要保证数据的一致性和同步性
4. 从服务器可能延迟数据更新

要使用数据库读写分离，需要对数据库架构进行设计和调整，并且需要对应用程序进行相应的开发和配置。同时，需要注意保证数据一致性和同步性，以避免数据出现错误和丢失。

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

• CDN部署在网络提供商的机房，使用户在请求阙站服务时，可以从距离自己最近的网络提供商机房获取数据。
· 反向代理则部署在同站的小心机房，当用户请求到达中心机房'后，首先访问的服务器是反向代理服务器，如果反向代理服务器中绥在着用户请求的资源，就将其直接返回给用户。

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

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

第九阶段:业务拆分

业务拆分是指将企业的业务进行分解，将其拆分成不同的部分或子业务。这通常是为了更好地管理和组织企业的各个业务部门，使其更加灵活和高效。业务拆分可以帮助企业更好地适应市场需求，并更快地推出新产品或服务。同时，业务拆分也可以帮助企业更好地实现资源优化，减少浪费，提高效率和利润。常见的业务拆分包括产品拆分、地域拆分、客户群拆分等。

第十阶段:分布式服务

分布式服务是一种使用多个独立的计算机系统共同工作来提供单个应用程序或功能的服务。这些计算机系统可以位于不同的地理位置，但通过网络连接在一起。分布式服务通常由多个单独的服务组成，每个服务负责特定的任务，并通过协调相互通信实现整个应用程序的功能。分布式服务常用于需要高可用性和可伸缩性的应用程序，例如电子商务、金融交易和社交媒体平台。

软件架构维护

软件架构的开发和维护是基于架构软件生命周期中的关键环节，与之相关的步骤包括导出架构需求、架构开发、架构文档化、架构分析、架构实现和架构维护。

软件架构维护过程一般涉及架构知识管理、架构修战管理和架构版本管理

软件架构知识管理

1 . 架构知识的定义

Lago 等人给山了架构知识的定义: 架构知识= 架构设计+架构设计决策。即需要说明在进行架构设计时采用此种架构的原因。

2. 架构知识管理的含义

架构知识管理侧重于软件开发和实现过程所涉及的架构静态演化，从架构文挡等信息来源中捕捉架构知识，进而提供架构的质量属性及其设计依据以进行记录和评价。

3. 架构知识管理的需求

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

4. 架构知识管理的现状

架构知识管理是一种重要的知识管理方式，它主要通过管理和整合组织内部的架构知识，使组织内部的各项业务和项目能够更加高效地运行。目前，架构知识管理的现状主要可以从以下几个方面进行描述：

1.应用领域广泛：架构知识管理不仅在软件开发领域得到广泛应用，还在制造业、汽车行业、金融业等多个领域中被应用。

2.技术手段多样：架构知识管理的技术手段包括知识图谱、本体论、语义网络等多种技术手段，并且随着技术的发展，新的技术手段也在不断涌现。

3.团队重视程度有所提高：越来越多的企业和团队开始重视架构知识管理，建立知识库、知识分享平台等架构知识管理系统，以提高组织内部的协作和效率。

4.知识内容丰富：架构知识管理的知识内容也越来越丰富，不仅包括技术知识和经验，还包括行业知识、商业模式、市场趋势等多个方面。

总之，架构知识管理已经成为一种重要的知识管理方式，在未来的发展中，它将在技术手段、应用领域、知识内容等方面不断迭代和创新，为组织内部的创新和发展提供更加有力的支持。

软件架构修改管理

软件架构是软件系统设计的核心，它的合理性和稳定性直接关系到软件系统的质量和可维护性。因此，在软件开发过程中，必须对软件架构进行合理的修改和管理。

下面是软件架构修改管理的一些步骤：

1. 确定需求变更：软件开发过程中，需求变更是不可避免的。开发团队应该尽早发现并确认需求变更，并与客户进行沟通，了解具体变更内容和影响范围。

2. 评估影响：对于需要修改软件架构的需求变更，应当进行评估它对系统结构和功能的潜在影响。评估结果应该用于确定架构修改的可行性和优先级。

3. 制定修改计划：在评估了需求变更后，制定软件架构修改计划。计划应该包括修改的时间、范围、人员和资源等。

4. 实施修改：根据修改计划，实施软件架构的修改。确保修改符合系统规范，并及时更新系统文档和说明。

5. 测试和验证：在软件架构修改完成后，进行内部测试和验证，确保修改不会影响系统的稳定性、可靠性和性能。

6. 部署和发布：如果测试和验证工作没有问题，则将修改后的软件架构部署和发布到系统中。

7. 跟踪和反馈：关注修改后软件架构的运行情况，根据运行情况收集用户反馈和问题，并及时进行跟踪和调整。

以上是软件架构修改管理的一些基本步骤，执行这些步骤可以确保软件架构的修改是有序、科学、有效的。

软件架构版本管理

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

软件架构版本管理是指对软件架构的不同版本进行管理和维护的过程。软件架构是一种抽象的设计，包括系统的组成部分、它们之间的关系和交互方式等，它为软件开发提供了基础和指导。而软件架构版本管理则是为了满足不同需求和应用场景，对软件架构进行变更和更新，并记录和维护这些变更和更新的历史记录。通过软件架构版本管理，可以追踪不同版本之间的变化，方便进行版本控制和代码维护，同时也提供了一种可追溯的开发过程，保证了软件的可靠性和稳定性。常见的软件架构版本管理工具包括Git、SVN等。