文章目录
分类
按照软件架构的实现方式和实施粒度分类
- 基于过程和函数的演化
- 面向对象的演化
- 基于组件的演化
- 基于架构的演化
按照研究方法分类
- 对演化的支持
- 代码模块化的准则
- 可维护性的指示（如内聚和耦合）
- 代码重构
- 版本和工程管理工具
- CVS和COCOMO
- 架构变换的形式方法
- 系统结构和行为变换的模型
- 架构演化的重现风格
- 架构演化的成本收益分析
- 决定如何增加系统的弹性
针对软件架构的演化过程是否处于系统运行时期
- 静态演化
- 动态演化
软件架构演化时期
- 设计时演化：发生在体系结构模型和与之相关的代码编译之前。
- 运行前演化：发生在执行之前、编译之后的软件架构演化，可以不考虑应用程序的状态，但需要考虑系统的体系结构。
- 有限制运行时演化：在设计时就规定了演化的具体条件，满足要求才能演化，系统较“安全”。
- 运行时演化：运行时不能满足要求时的演化，最难实现。
软件架构演化原则
| 原则名称 | |
| 原则解释 | |
| 原则用途 | |
| 度量方案 | |
| 方案说明 |
1.演化成本控制原则
| 原则名称 | 演化成本控制原则（Evolution Cost Control，ECC） |
| 原则解释 | 演化成本要控制在预期的范围之内，也就是演化成本要明显小于重新开发成本。 |
| 原则用途 | 用于判断架构演化的成本是在可控范围内，以及用户是否可接受。 |
| 度量方案 | CoE<<CoRD |
| 方案说明 | CoE为演化成本，CoRD为重新开发成本，CoE远小于CoRD为最佳。 |
2.进度可控原则
| 原则名称 | 进度可控原则（Schedule Control） |
| 原则解释 | 架构演化要在预期时间内完成，也就是时间成本可控。 |
| 原则用途 | 根据该原则可以规划每个演化过程的任务量；体现一种迭代、递增（持续演化）的演化思想。 |
| 度量方案 | ttask=|Ttask-T’ask| |
| 方案说明 | 某个演化任务的实际完成时（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=变更总量/项目规模。 |
| 方案说明 | 根据度量动态变更信息（类型、总量、范围等）来计算。 |
7.目标一致原则
| 原则名称 | 目标一致原则（Objective Conformance） |
| 原则解释 | 架构演化的阶段目标和最终目标要一致。 |
| 原则用途 | 用于判断每个演化过程是否达到阶段目标，所有演化过程结束是否能达到最终目标。 |
| 度量方案 | otask=|Otask-O’task| |
| 方案说明 | 阶段目标的实际达成情况（Otask）和预期目标（O’task）的差，otask越小越好。 |
8.模块独立演化原则
| 原则名称 | 模块独立演化原则，或称修改局部化原则（Local Change） |
| 原则解释 | 软件中各模块自身的演化最好相互独立，或者至少保证对其他模块的影响比较小或影响范围比较小。 |
| 原则用途 | 用于判断每个模块自身的演化是否相互独立。 |
| 度量方案 | 检查模块的修改是否是局部的。 |
| 方案说明 | 可以通过计算修改的影响范围来进行度量。 |
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=1-DDT，其中DDT=|依赖的技术集合|/|用到的技术集合| |
| 方案说明 | 根据演化系统对关键技术的依赖程度进行度量。 |
15.环境适应性原则
| 原则名称 | 环境适应性原则（Platform Adaptability）） |
| 原则解释 | 架构演化后的软件版本能够比较容易适应新的硬件环境与软件环境。 |
| 原则用途 | 用于判断架构在不同环境下是否仍然可使用，或者容易进行环境配置。 |
| 度量方案 | 硬件/软件兼容性。 |
| 方案说明 | 结合软件质量中兼容性指标进行度量。 |
16.标准依从性原则
| 原则名称 | 标准依从性原则（Standard Conformance） |
| 原则解释 | 架构演化不回违背相关质量标准。 |
| 原则用途 | 用于判断架构演化是否具有规范性，是否有章可循，而不是胡乱或随意地演化。 |
| 度量方案 | 需要人工判定。 |
17.质量向好原则
| 原则名称 | 质量向好原则（Quality Improvement） |
| 原则解释 | 通过演化使得关注的某个质量指标或某些质量指标的综合效果变得更好或者更满意。 |
| 原则用途 | 用于判断架构演化是否导致某些质量指标变得很差。 |
| 度量方案 | EQI≥SQ |
| 方案说明 | 演化之后的质量（EQI）比原来的质量（SQ）要好。 |
18.适应新需求原则
| 原则名称 | 适应新需求原则（New Requirement Adaptability）） |
| 原则解释 | 架构演化要很容易适应新的需求变更，架构演化不能降低原有架构适应新需求的能力；架构演化最好可以提高适应新需求的能力。 |
| 原则用途 | 用于判断演化之后的架构是否降低了架构适应新需求的能力。 |
| 度量方案 | RNR=|ANR|/|NR| |
| 方案说明 | 适应的新需求集合（ANR）和实际的新需求集合（NR）的比较，RNR越小越好。 |
大型网站系统架构演化实例
- 单体架构
- 单个服务器处理全部业务。
- 存在单点故障的问题。
- 垂直架构
- 垂直拆分为多个服务器，应用服务器、文件服务器、数据库服务器
- 热点数据访问速度慢。
- 使用缓存改善网站性能
- 引入远程分布式缓存。
- 并发处理性能差。
- 使用服务集群改善网站并发能力
- 引入分布式服务器。
- 数据库读写性能差。
- 数据库读写分析
- 引入主从数据库。
- 网站响应速度慢。
- 使用反向代理和CDN加速网站相应
- 单机数据库/文件系统性能差。
- 使用分布式文件系统和数据库系统
- 数据搜索性能差。
- 使用NoSQL和搜索引擎
- 业务耦合。
- 业务拆分
- 拆分后许多服务器都会查询数据库，数据库压力增大。
- 分布式拆分
- 引入分布式服务器，在构件中统一处理数据库查询请求。
软件架构维护
可维护性度量指标
- 圈复杂度
- 扇入扇出度
- 模块间耦合度
- 模块的响应
- 紧内聚度
- 松内聚度
扫一扫
1416
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
