软件架构的演化和维护
12.1 软件架构演化和定义的关系
- 演化的重要性
-
- 保障软件系统具备诸多好的特性
-
- 有效管控软件系统的整体复杂性和变化性,降低软件检修和修改成本
-
- 保证软件系统演化的一致性和正确性,增加便捷性。
- 演化和定义的关系
软件架构包括组件、连接件和约束三大要素,此软件架构演化蛀牙关注组件、连接件和约束的添加修改和删除。
12.2 面向对象软件架构演化过程
- 对象演化
对机构设计的动态行为产生影响的演化包括Add Object(AO)和Delete Object(DO)
-
- AO是在系统需要添加新的对象来实现某种新的功能,或需将现有对象的某个功能独立以增加架构的灵活性时发行。
-
- DO是在系统需要转移某个现有的功能,或需合并某些对象及其某些功能来降低架构的复杂度的时候发生。
- 消息演化
消息演化包括Add Message(AM)和Delete Message(DM)、Swap Massage Order(AMO)、Overturn Message(OM)、Change Message Module(
CMM)。
AM:添加一条新的消息,产生在对象之间需要增加新的交互行为的时候。
DM:删除当前的一条消息,产生在需要移除某交互行为的时候。
SMO:交换两条消息的时间顺序,发生在需要改变两个交互行为之间的时候
OM:反转消息的发送对象和接收对象,发生在需要修改某个交互行为本身的时候。
CMM:改变消息的发送 或接收对象,发生在需要修改某个交互行为本身的时候。
- 符合片段演化
符合片段的演化包括Add Fragment(AF)、Delete Fragment(DF)、Fragment Type Change(FTC)、Fragment Condition Change(FCC)
-
- AF:在某几条消息上新增复合片段,发生在需要曾天新的控制流时。
-
- DF:删除某个现有的符合片段,发生在需要移除当前某个控制流时。
-
- FTC: 改变某个符合片段的类型,发生在需要改变某段控制流时。
-
- FCC:改变符合片段内部执行的条件,发生在改变当前控制流的执行条件时。
- 约束演化
约束演化包括Add Constraint(AC)、Delete Constraint(DC) - AC:直接添加新的约束信息,需判断当前设计是否满足新添加的约束要求。
- DC: 直接移除某条约束信息,发生在去除某些不必要条件的时候。
12.3 软件架构演化方式的分类
- 软件架构演化时期
-
- 设计时演化:发生在体系结构模型与之相关的代码编译之前。
-
- 运行前演化:发生在执行之前、编译之后。
-
- 有限制运行时演化:只发生在某些特定约束满足时
-
- 运行时演化:发生在运行时不能满足要求时
- 软件架构静态演化
-
- 静态演化需求:设计时演化需求、运行前演化需求
-
- 静态演化的一般过程:软件理解 -> 需求变更分析 -> 演化计划 -> 系统重构 -> 系统测试
-
- 静态演化的原子演化操作:
a. 与可维护相关的架构演化操作:AMD(Add Module Dependence)、RMD(Remove Module Dependence)、AMI(Add Module Interface)、
RMI(Remove Module Interface)、AM(Add Module)、RM(Remove Module)、SM(Split Module)、AGM(Aggregate Modules)
b. 与可靠性相关的架构演化操作: AMS(Add Message)、RMS(Remove Message)、AO(Add Object)、RO(Remove Message)、AF(Add
Fragement)、
RF(Remove Message)、CF(Change Fragment)、AU(Add Use Case)、RU(Remove Use Case)、AA(Add Actor)、RA(Remove Actor)
- 静态演化的原子演化操作:
- 软件架构动态演化
-
- 动态演化需求:软件内部执行导致的体系结构的改变、软件系统外部的请求对软件进行重配置
-
- 动态演化的类型
- a.软件动态性的等级:交互动态性、结构动态性、架构动态性
- b.动态演化的内容:属性改名、行为变化、拓扑结构改变、风格变化
-
- 动态软件架构(DSA)
- a. 基于DSA实现动态演化的基本原理是运行时刻体系结构相关信息的改变可以用来触发、驱动系统自身的动态调整。
- b. DSA描述语言:基于行为视角的π-ADL、基于反射视角的Pilar、基于协调视角的LIME
- c. DSA演化工具:使用反射机制、基于组件操作、基于π演算、利用外部的体系结构演化管理器
-
- 动态软件架构应用实例-PKUAS:包括容器系统、公共服务、工具和微内核4种类型
-
- 动态重配置
- a. 动态重配置模式:主从模式、中央控制模式、客户端/服务器模式、分布式控制模式。
- b. 例子:可重用、可配置的产品线架构
- c. 动态配置难点:约束定义困难、性能约束难以静态衡量、难以管理所有的方面、需要同时保证组件系统的完整性和重配置策略的正确和安全性。
12.4 软件架构演化原则
软件架构包括18种可持续演化原则
- 演化成本控制原则
- 进度可控原则
- 风险可控原则
- 主体维持原则
- 系统总体结构优化原则
- 平滑演化原则
- 目标一致原则
- 模块独立演化原则
- 影响可控原则
- 复杂性可控原则
- 有利于重构原则
- 有利于重用原则
- 设计原则遵循性原则
- 适应新技术原则
- 环境适应性原则
- 标准依从性原则
- 质量向好原则
- 适应新需求原则
12.5 软件架构演化评估方法
- 演化过程已知的评估
评估流程:将架构度量应用到演化过程中,通过对演化前后的不同版本的架构分别进行度量,得到度量结果的差值及其变化趋势,并计算框架间质量属性距离,进而对
相关质量属性进行评估。 - 演化过程未知的评估,其架构演化评估过程如下图:
12.6 大型网站系统架构演化实例
第一阶段:单体架构
应用程序、数据库、文件等所有资源都在一台服务器上。
第二阶段:垂直架构。
将应用和数据分离,整个网站使用 3 台服务器:应用服务器、文件服务器、数据服务器。
第三阶段:使用缓存改善网站性能。
包括在应用服务器上的本地缓存和在专门的分布式缓存服务器上的远程缓存。
第四阶段:使用服务集群改善网站并发处理能力。
通过负载均衡调度服务器,将来自用户浏览器的访问请求分发到应用服务器集群中的任何一台服务器上,解决高并发、海量数据问题。
第五阶段:数据库读写分离。
应用服务器在写数据时,访问主数据库,主服务器通过主从复制机制将数据更新同步到从服务器。在应用服务器读数据时,访问从数据库。
第六阶段:使用反向代理和 CDN 加速网站响应。CDN 和反向代理的基本原理都是缓存。
(1)CDN 部署在网络提供商的机房,用户在请求网站服务时,可在距离最近的网络提供商机房获取数据。
(2)反向代理部署在网站的中心机房,用户请求到达中心机房后,先访问反向代理服务器。
第七阶段:使用分布式文件系统和分布式数据库系统。
进行业务分库,将不同业务的数据部署在不同的物理服务器上。
第八阶段:使用 NoSQL 和搜索引擎。
第九阶段:业务拆分。
将一个网站拆分成许多不同的应用,每个应用独立部署。
第十阶段:分布式服务。
12.7 软件架构维护
软件架构维护过程包括软件架构知识管理、软件架构修改管理、软件架构版本管理等。
- 软件架构知识管理
-
- 架构知识的定义:架构知识=架构设计+架构设计决策
-
- 架构知识管理的含义: 侧重于软件开发和实现过程所涉及的架构静态演化,在架构文档等信息来源中捕捉知识架构,提供加工后的质量属性及其设计依据进行记录和评价。
-
- 架构知识管理的需求:防止关键的设计知识“沉没”在软件架构中。
- 软件架构修改管理
主要是建立一个隔离区域,保障该区域中任何修改对其他部分影响最小。 - 软件架构版本管理
为软件架构演化的版本演化控制、使用和评价提供可靠依据 - 软件架构可维护性度量实践
架构可维护性的6个度量指标:圈复杂度(CNN)、扇入扇出度(FFC)、模块间耦合度(CBO)、模型的响应(RFC)、紧内聚度(TCC)、松内聚度(LCC)