跳转至

软件架构演化和维护

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

  1. 演化的重要性保障软件系统具备诸多好的特性。
  2. 保障软件系统具备诸多好的特性。
  3. 有效管控软件系统的整体复杂性和变化性，降低软件检修和修改成本。

  4. 保证软件系统演化的一致性和正确性，增加便捷性。

  5. 演化和定义的关系

软件架构包括组件、连接件和约束三大要素，此软件架构演化主要关注组件、连接件和约束的添加、修改和删除。

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

对象演化

对架构设计的动态行为产生影响的演化包括 Add Object（AO） 和 Delete Object（DO）。

  1. AO 是在系统需要添加新的对象来实现某种新的功能，或需将现有对象的某个功能独立以增加架构灵活性时发生。
  2. DO 是在系统需要移除某个现有的功能，或需合并某些对象及其功能来降低架构的复杂度的时候发生。

消息演化

消息演化包括 Add Message（AM）、Delete Message（DM）、Swap Message Order（SMO）、Overturn Message（OM）、Change Message Module（CMM）。

  1. AM：增添一条新的消息，产生在对象之间需要增加新的交互行为的时候。
  2. DM：删除当前的一条消息，产生在需要移除某交互行为的时候。
  3. SMO：交换两条消息的时间顺序，发生在需要改变两个交互行为之间的时候。
  4. OM：反转消息的发送对象与接收对象，发生在需要修改某个交互行为本身的时候。
  5. CMM：改变消息的发送或接收对象，发生在需要修改某个交互行为本身的时候。

复合片段演化

复合片断的演化包括 Add Fragment（AF）、Delete Fragment（DF）、Fragment Type Change（FTC）、Fragment Condition Change（FCC）。

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

约束演化

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

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

软件架构演化方式的分类

软件架构演化时期

  1. 设计时演化：发生在体系结构模型与之相关的代码编译之前。
  2. 运行前演化：发生在执行之前、编译之后。
  3. 有限制运行时演化：只发生在某些特定约束满足时。
  4. 运行时演化：发生在运行时不能满足要求时。

软件架构静态演化

  1. 静态演化需求：设计时演化需求、运行前演化需求。
  2. 静态演化的一般过程：软件理解→需求变更分析→演化计划→系统重构→系统测试
  3. 静态演化的原子演化操作。
  4. 与可维护性相关的架构演化操作：AMD（Add Module Dependence）、RMD（Remove Module Dependence）、AMI（Add Module Interface）、RMI（Remove Module Inferface）、AM（Add Module）、RM（Remove Module）、SM（Split Module）、AGM（Aggregate Modules）。
  5. 与可靠性相关的架构演化操作：AMS（Add Message）、RMS（Remove Message）、AO（Add Object）、RO（Remove Object）、AF（Add Fragment）、RF（Remove Fragment）、CF（Change Fragment）、AU（Add Use Case）、RU（Remove Use Case）、AA（Add Actor）、RA（Remove Actor）。

软件架构动态演化

  1. 动态演化需求：软件内部执行所导致的体系结构改变、软件系统外部的请求对软件进行的重配置。
  2. 动态演化的类型。
  3. 软件动态性的等级：交互动态性、结构动态性、架构动态性。
  4. 动态演化的内容：属性改名、行为变化、拓扑结构改变、风格变化。
  5. 动态软件架构（DSA）。
    1. 基于 DSA 实现动态演化的基本原理是运行时刻体系结构相关信息的改变可用来触发、驱动系统自身的动态调整。
    2. DSA 描述语言：基于行为视角的 π-ADL、基于反射视角的 Pilar、基于协调视角的 LIME。
    3. DSA 演化工具：使用反射机制、基于组件操作、基于 π 演算、利用外部的体系结构演化管理器
  6. 动态软件架构应用实例—PKUAS：包括容器系统、公共服务、工具和微内核 4 种类型。
  7. 动态重配置。
    1. 动态重配置模式：主从模式、中央控制模式、客户端/服务器模式、分布式控制模式。
    2. 例子：可重用、可配置的产品线架构。
    3. 动态配置难点：约束定义困难、性能约束难以静态衡量、难以管理所有方面、需同时保证组件系统完整性和重配置策略的正确和安全性。

软件架构演化原则

软件结构包括 18 种可持续演化原则：

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

软件架构演化评估方法

  1. 演化过程已知的评估

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

  2. 演化过程未知的评估

    演化过程未知时的架构演化评估过程示意图

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

  • 第一阶段：单体架构

    应用程序、数据库、文件等所有资源都在一台服务器上。

  • 第二阶段：垂直架构

    将应用和数据分离，整个网站使用 3 台服务器：应用服务器、文件服务器、数据服务器。

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

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

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

    通过负载均衡调度服务器，将来自用户浏览器的访问请求分发到应用服务器集群中的任何一台服务器上，解决高并发、海量数据问题。

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

    应用服务器在写数据时，访问主数据库，主服务器通过主从复制机制将数据更新同步到从服务器。在应用服务器读数据时，访问从数据库。

  • 第六阶段：使用反向代理和 CDN 加速网站响应。CDN 和反向代理的基本原理都是缓存。

    1. CDN 部署在网络提供商的机房，用户在请求网站服务时，可在距离最近的网络提供商机房获取数据。

    2. 反向代理部署在网站的中心机房，用户请求到达中心机房后，先访问反向代理服务器。

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

    进行业务分库，将不同业务的数据部署在不同的物理服务器上。

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

  • 第九阶段：业务拆分。

    将一个网站拆分成许多不同的应用，每个应用独立部署。

  • 第十阶段：分布式服务。

软件架构维护

软件架构维护过程包括 软件架构知识管理、软件架构修改管理、软件架构版本管理 等。

  1. 软件架构知识管理

    1. 架构知识的定义：架构知识=架构设计+架构设计决策。
    2. 架构知识管理的含义：侧重于软件开发和实现过程所涉及的架构静态演化，在架构文档等信息来源中捕捉架构知识，提供架构的质量属性及其设计依据进行记录和评价。
    3. 架构知识管理的需求：防止关键的设计知识“沉没”在软件架构中。

  2. 软件架构修改管理

    主要是建立一个隔离区域，保障该区域中任何修改对其他部分影响最小。

  3. 软件架构版本管理

    为软件架构演化的版本演化控制、使用和评价提供可靠依据。

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

    架构可维护性的 6 个度量指标：圈复杂度（CNN）、扇入扇出度（FFC）、模块间耦合度（CBO）、模块的响应（RFC）、紧内聚度（TCC）、松内聚度（LCC）。

遗留系统（高频考点）

2013 综合知识 28

遗留系统的演化可以采用 淘汰、继承、改造和集成 四种策略。

淘汰策略 适用于技术含量较低，且具有较低的业务价值的遗留系统，即通过全面重新开发新的系统以代替遗留系统。

若遗留系统的技术含量较低，能满足企业运作的功能或性能要求，但具布较高的商业机制，目前企业的业务上紧密依赖该系统，这种遗留系统的演化策略为 继承。在开发新系统时，需要完全兼容遗留系统的功能模型和数据模型。为了保证业务的连续性，新老系统必须并行运行一段时间。

对于技术含量较高，本身还有极大的生命力，又具有较高的业务价值，基本上能够满足企业业务运作和决策支持需要的遗留系统，采用 改造策略 进行演化。改造包括 系统功能的增强 和 数据模型的改造 两个方面。

遗留系统的技术含量较高，但其业务价值较低，可能只完成某个部门（或子公司）的业务管理。这种系统在各自局部领域里工作良好，但对于整个企业来说，存在多个这样的系统，不同的系统基于不同的平台、不同的数据模型，形成了一个个信息孤岛。对于这种遗留系统的演化策略为 集成。