【新版】系统架构设计师 - 软件架构的演化与维护

在这里插入图片描述

个人总结，仅供参考，欢迎加好友一起讨论

文章目录

架构 - 软件架构的演化与维护
考点摘要
软件架构演化和定义
面向对象软件架构演化
- 对象演化
- 消息演化
- 复合片段演化
- 约束演化
软件架构演化方式
- 静态演化
- 动态演化
软件架构演化原则
软件架构演化评估方法
大型网站架构的演化
- 第一阶段：单体架构
- 第二阶段：垂直架构
- 第三阶段：使用缓存改善网站性能
- 第四阶段：使用服务集群改善网站并发处理能力
- 第五阶段：数据库读写分离
- 第六阶段：使用反向代理和CDN加速网站响应
- 第七阶段：使用分布式文件系统和分布式数据库系统
- 第八阶段：使用NoSQL和搜索引擎
- 第九阶段：业务拆分
- 第十阶段：分布式服务
软件架构维护
- 软件架构知识管理
- 架构修改管理
- 架构版本管理

架构 - 软件架构的演化与维护

考点摘要

软件架构演化和定义（★）
面向对象软件架构演化（★★）
软件架构演化方式（★★）
软件架构演化原则（★★）
软件架构演化评估（★★）
大型网站架构演化（★★）
软件架构维护（★）

第二版架构新教材里新增加内容，对应第10章，新增的内容是关于架构的演化和维护阶段，偏理论多，而且不像架构风格、质量属性那块容易出题。个人认为会出几个选择题，甚至到案例题中有内容涉及。

软件架构一般会经历初始设计、实际使用、修改完善和退化弃用的过程，其中修改完善的过程实际上就是软件架构的演化和维护过程，演化和维护的目的就是为了使软件能够适应环境的变化而进行的纠错性修改和完善性修改等。软件架构的演化和维护过程是一个不断迭代的过程，通过演化和维护，软件架构逐步得到完善，以满足用户需求。

软件架构演化和定义

软件架构的演化就是软件整体结构的演化，演化过程涵盖软件架构的全生命周期，包括软件架构需求的获取、软件架构建模、软件架构文档、软件架构实现以及软件架构维护等阶段。

软件架构演化的重要性体：

架构是整个系统的骨架，是软件系统具备诸多好的特性的保障
软件架构作为软件蓝图为人们宏观管控软件系统的整体复杂性和变化性提供了一条有效途径。

软件架构的演化能降低软件演化的成本的原因：

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

软件架构的定义包含组件、连接件、约束三大要素，这类软件架构演化主要关注的就是这三者之间的添加、修改和删除等。

面向对象软件架构演化

假设软件架构对应到具体的架构风格或模式，我们就可以讨论演化的各种具体操作了。面向对象软件架构，结合UML顺序图来进一步讨论各种演化操作。

对象演化

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

AO表示在顺序图中添加一个新的对象。这种演化一般是在系统需要添加新的对象来实现某种新的功能，或需要将现有对象的某个功能独立以增加架构灵活性的时候发生。
DO删除顺序图中现有的一个对象。这种演化一般在系统需要移除某个现有的功能，或需要合并某些对象及其功能来降低架构的复杂度的时候发生。

消息演化

消息是顺序图中的核心元素，包含了名称、源对象、目标对象、时序等信息。消息演化是将消息演化分为AddMessage（AM）、DeleteMessage（DM）、SwapMessageOrder（SMO）、OverturnMessage（OM）、ChangeMessageModule（CMM）5种。

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

复合片段演化

复合片段演化是对象交互关系的控制流描述，表示可能发生在不同场合的交互，与消息同属于连接件范畴。复合片段的演化分为AddFragment（AF）、DeleteFragment（DF）、FragmentTypeChange（FTC）和FragmentConditionChange（FCC）。

FCC改变复合片段内部执行的条件，发生在改变当前控制流的执行条件时。自动机中与控制流执行条件相对应的转移包括两个，一个是符合条件时的转移，另一个是不符合条件时的转移，因此每次发生FFC 演化时会同时修改这两个转移的触发事件。
AF在某几条消息上新增复合片段，发生在需要增添新的控制流时。复合片段所产生的分支是不同类型的。
DF删除某个现有的复合片段，发生在需要移除当前某段控制流时。DF与AF互为逆向演化过程。
FTC改变复合片段的类型，发生在需要改变某段控制流时。类型演化意味着交互流程的改变，一般伴随着条件、内部执行序列的同时演化，可以视为复合片段的删除与添加的组合。

约束演化

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

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

软件架构演化方式

3种典型的分类方法：

按照软件架构的实现方式和实施粒度分类：基于过程和函数的演化、面向对象的演化、基于组件的演化和基于架构的演化。
按照研究方法将软件架构演化方式分为4类：第1类是对演化的支持，如代码模块化的准则、可维护性的指示（如内聚和祸合）、代码重构等；第2类是版本和工程的管理工具；第3类是架构变换的形式方法，包括系统结构和行为变换的模型，以及架构演化的重现风格等；第4类是架构演化的成本收益分析，决定如何增加系统的弹性。
针对软件架构的演化过程是否处于系统运行时期，可以将软件架构演化分为静态演化和动态演化。

软件架构演化时期：

设计时演化
运行前演化
有限制运行时演化
运行时演化

静态演化

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

软件的静态演化一般包括如下5个步骤：

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

架构演化的可维护性度量基于组件图表示的软件架构。

架构演化的可靠性评估基于用例图、部署图和顺序图。

动态演化

动态演化是在系统运行期间的演化，需要在不停止系统功能的情况下完成演化，较之静态演化更加困难。

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

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

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

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

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

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

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

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

DSA实施动态演化大体遵循以下4 步：①捕捉并分析需求变化；②获取或生成体系结构演化策略；③根据步骤2得到的演化策略，选择适当的演化策略并实施演化；④演化后的评估与检测。
进行动态重配置（DR）：DR从组件和连接件的配置入手，允许在运行过程中增删组件，增删连接件，修改连接关系等操作。主要是指在软件部署之后对配置信息的修改，常常被用于系统动态升级时需要进行的配置信息修改。

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

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

软件架构演化原则

演化成本控制原则

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

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

架构演化要在预期时间内完成，也就是时间成本可控。

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

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

用于判断架构演化过程中各种风险是否易于控制。
主体维持原则

保证软件系统主体行为稳定。

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

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

用于判断系统整体结构是否合理，是否最优。
平滑演化原则

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

用于判断是否存在剧烈架构演化。
目标一致原则

架构演化的阶段目标和最终目标要一致。

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

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

用于判断每个模块自身的演化是否相互独立。
影响可控原则

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

用于判断是否存在对某个模块的修改导致大量其他修改的情况。
复杂性可控原则

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

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

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

用于判断架构易重构性是否得到提高。
有利于重用原则

架构演化最好能维持，甚至提高整体架构的可重用性。

用于判断整体架构可重用性是否遭到破坏。
设计原则遵从性原则

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

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

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

用于判断架构演化是否存在对某种技术依赖过强的情况。
环境适应性原则

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

用于判断架构在不同环境下是否仍然可使用，或者容易进行环境配置。
标准侬从性原则

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

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

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

用于判断架构演化是否导致某些质量指标变得很差。
适应新需求原则

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

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

软件架构演化评估方法

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

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

基于度量的架构演化评估方法，其基本思路在于通过对演化前后的软件架构进行度量,比较架构内部结构上的差异以及由此导致的外部质量属性上的变化。具体包括:架构修改影响分析、监控演化过程、分析关键演化过程。
当演化过程未知时，我们无法像演化过程已知时那样追踪架构在演化过程中的每一步变化，只能根据架构演化前后的度量结果逆向推测出架构发生了哪些改变，并分析这些改变与架构相关质量属性的关联关系。