软件架构 on Liangweidong's blog

09-软件架构概念

Mon, 01 Jan 2024 00:00:00 +0000

09-软件架构概念（基于第9小时）

软考-系统架构设计师 | 第3篇架构设计高级知识出题形式：单项选择题 + 下午案例分析题分值占比：约 3-5 分（选择），案例题常涉及

0. 考点分析

本小时是软考系统架构设计师考试最核心、最常考的基础章节。主要内容涵盖：

软件架构定义与重要性
软件架构设计与生命周期
基于架构的软件开发方法（ABSD / ABSDM）
软件架构风格（核心重点）
软件架构复用
特定领域软件架构（DSSA）

考试特点：

选择题必考（架构风格、ADL、视图模型等概念）
案例分析题高频考点（架构风格选择、复用策略）
论文题素材来源（ABSDM 六过程、风格选择）

1. 核心知识点

1.1 软件架构定义

定义：系统的一个或多个结构，包括构件（程序模块/类/中间件）、构件的外部可见属性及其相互关系
架构设计包括：数据库设计 + 软件结构设计
关注点：通过多种视图全面描述

1.2 软件架构与生命周期

阶段	作用和意义
需求分析阶段	有利于各阶段参与者的交流，易于维护可追踪性
设计阶段	关注的最早和最多的阶段
实现阶段	有效实现从架构设计向实现的转换
构件组装阶段	可复用构件组装提高实现效率
部署阶段	组织和展示部署软硬件架构，评估部署方案
后开发阶段	主要围绕维护、演化、复用

设计阶段重点：

组成 SA 模型的基本概念（构件和连接子建模）
体系结构描述语言 ADL：Unicon、Rapide、Darwin、Wright、C2SADL、Acme、XADLOL、XYZ/ADL、ABC/ADL
多视图模型：4+1 模型、Hofmesiter 的 4 视图模型、CMU-Sei 的 Views and Beyond 模型
视图标准：IEEE 1471-2000、RM-ODP、UML、IBM Zachman

部署阶段两大作用：

提供高层体系结构视图描述部署阶段的软硬件模型
基于架构模型分析部署方案的质量属性

后开发阶段研究方向：

动态软件体系结构
体系结构恢复与重建（手工重建、工具支持、查询语言、数据挖掘）

1.3 软件架构重要性（8 大作用）

满足系统品质
使受益人达成一致目标
支持计划编制过程
对系统开发的指导性
有效管理复杂性
为复用奠定基础
降低维护费用
支持冲突分析

1.4 基于架构的软件开发方法（ABSD）

全称：Architecture-Based Software Design
驱动：构成体系结构的商业、质量和功能需求的组合驱动
三大基础：
- 功能的分解
- 通过选择体系结构风格来实现质量和商业需求
- 软件模板的使用
特点：自顶向下、递归细化、迭代每步定义清晰，降低随意性

1.5 ABSDM 开发模型（六子过程）

1

体系结构需求 → 体系结构设计 → 体系结构文档化 → 体系结构复审 → 体系结构实现 → 体系结构演化

各子过程要点：

子过程	关键活动
体系结构需求	需求获取（来自质量目标/商业目标/开发人员商业目标）+ 标识构件（生成类图→分组→打包）
体系结构设计	提模型→映射构件→分析相互作用→设计评审（必须有外部人员）
体系结构文档化	输出：体系结构规格说明 + 测试质量设计说明书
体系结构复审	外部人员（用户代表、领域专家）参与，标识风险，可搭最小化系统评估
体系结构实现	分析与设计→构件实现→构件组装→系统测试
体系结构演化	需求变化归类→演化计划→构件变动→更新相互作用→组装测试→技术评审→演化后体系结构

1.6 软件架构风格（⭐⭐⭐ 核心重点）

风格定义要素：

词汇表：包含构件和连接件
约束：定义构件和连接件的组合方式

数据流风格

风格	特点
批处理	每个处理步骤是独立程序，必须前一步结束后才能开始，数据以整体方式传递
管道-过滤器	系统分为序贯处理步骤，步骤间通过数据流连接，前一步输出是后一步输入

调用/返回风格

风格	特点
主程序/子程序	单线程控制，构件即主程序和子程序
面向对象	构件是对象（抽象数据类型的实例）
层次型	每层为上层服务并作为下层接口，仅相邻层间具有层接口
二层 C/S	客户应用程序 + 数据库服务器 + 网络；缺点：开发成本高、移植困难、维护升级难
三层 C/S	表示层 + 功能层 + 数据层（瘦客户端）
B/S	浏览器 + Web 服务器 + 数据库服务器（三层应用结构实现）

B/S 相对 C/S 的不足：动态页面支持弱、扩展能力差、安全难控、响应速度不足、数据交互性不强

以数据为中心风格

风格	特点
仓库	中央数据结构（说明当前数据状态）+ 一组独立构件（对中央数据操作）
黑板	问题求解模型，组织推理步骤、控制状态数据和问题求解知识；典型应用：信号处理（语音识别、模式识别）

虚拟机风格

风格	特点
解释器	构建虚拟机弥合程序语义与硬件语义差异；缺点是执行效率较低；典型：专家系统
规则系统	知识库 + 规则解释器 + 规则/数据选择器 + 工作内存

独立构件风格

进程通信：构件是独立过程，连接件是消息传递
事件系统：构件不直接调用过程，而是触发或广播一个或多个事件

C2 风格

通过连接件连接构件或构件组
构件与构件之间无直接连接

1.7 软件架构复用

维度	要点
复用类型	机会复用（开发中发现可复用就复用） / 系统复用（开发前规划决定复用）
复用原因	减少开发工作/时间、降低成本、提高生产力、提高产品质量、更好互操作性
可复用资产	需求、架构设计、元素、建模分析、测试、项目规划、过程+方法+工具、人员、样本系统、缺陷消除
复用形式	函数复用、库复用、面向对象中的类/接口/包复用
复用基本过程	构建/获取可复用资产→管理可复用资产→使用可复用资产

1.8 特定领域软件架构（DSSA）

维度	要点
定义	特定应用领域中为一组应用提供组织结构参考的标准软件体系结构
特征	领域性、普遍性、抽象性、可复用性
三大基本活动	领域分析、领域设计、领域实现
参与人员	领域专家、领域分析师、领域设计人员、领域实现人员
三层系统模型	① 领域开发环境 ② 领域特定应用开发环境（应用工程师在此工作） ③ 应用执行环境
建立过程（5 阶段）	① 定义领域范围 ② 定义领域特定元素 ③ 定义领域特定设计和实现约束 ④ 定义领域模型和体系结构 ⑤ 产生、搜集可重用的单元

2. 关键概念速查

概念	定义/说明	常见考点
软件架构	构件 + 外部可见属性 + 相互关系	概念辨析
ABSD	基于架构的软件设计方法	方法论三基础
ABSDM	ABSD 的六子过程开发模型	六过程名称与顺序
架构风格	描述特定领域中系统组织方式的惯用模式（词汇表 + 约束）	风格三要素（约束）
批处理	数据必须整体传递，串行无并发	与管道-过滤器区别
管道-过滤器	数据流式，步骤间通过数据流连接	Unix Shell 是经典例子
二层 C/S	客户应用 + 数据库服务器	缺点：维护升级难
三层 C/S	表示层 + 功能层 + 数据层	瘦客户端
B/S	浏览器 + Web 服务器 + 数据库	相对 C/S 的不足
仓库风格	中央数据 + 独立构件	数据为中心
黑板风格	知识源 + 黑板 + 控制	信号处理应用
解释器风格	虚拟机，执行效率低	专家系统
规则系统风格	知识库 + 规则解释器 + 工作内存	包含要素
事件系统风格	触发或广播事件，不直接调用	与调用-返回区别
C2 风格	通过连接件连接，构件间无直接连接	关键特征
ADL	体系结构描述语言，关注构件间互联机制（连接子）	与建模语言区别
4+1 视图	多视图模型代表	视图名称
DSSA	特定领域软件架构	三大活动、特征、参与人员
机会复用	开发中发现可复用就复用	vs 系统复用
体系结构恢复	手工/工具/查询语言/数据挖掘	四种方法

3. 典型例题

例题 1（架构风格定义）

题目：软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义了一类架构所共有的特征，主要包括架构定义、架构词汇表和架构（）。

A. 描述
B. 组织
C. 约束
D. 接口

答案：C

解析：软件架构风格三要素：架构定义、架构词汇表、架构约束。约束定义构件和连接件的组合方式。

例题 2（软件架构作用）

题目：以下叙述中，（）不是软件架构的主要作用。

A. 在设计变更相对容易的阶段，考虑系统结构的可选方案
B. 便于技术人员与非技术人员就软件设计进行交互
C. 展现软件的结构、属性与内部交互关系
D. 表达系统是否满足用户的功能性需求

答案：D

解析：软件架构与用户的功能性需求没有直接的对应关系。功能性需求由需求分析决定，架构关注质量属性和非功能特性。

例题 3（DSSA 三层模型）

题目：DSSA 通常是一个具有三个层次的系统模型，包括（1）环境、领域特定应用开发环境和应用执行环境，其中（2）主要在领域特定应用开发环境中工作。

（1）A. 领域需求 B. 领域开发 C. 领域执行 D. 领域应用（2）A. 操作员 B. 领域架构师 C. 应用工程师 D. 程序员

答案：B（领域开发环境）、C（应用工程师）

解析：DSSA 三层为：① 领域开发环境 ② 领域特定应用开发环境（应用工程师在此工作） ③ 应用执行环境。

例题 4（ABSDM 过程）

题目：在 ABSDM 模型中，把整个基于体系结构的软件开发过程划分为六个子过程，正确的顺序是：

A. 需求→设计→实现→文档化→复审→演化
B. 需求→设计→文档化→复审→实现→演化
C. 设计→需求→文档化→复审→实现→演化
D. 需求→设计→复审→文档化→实现→演化

答案：B

解析：ABSDM 六过程顺序：需求→设计→文档化→复审→实现→演化。复审必须在文档化之后、实现之前。

4. 高频考点

4.1 必须记住的核心要点

架构风格三要素：架构定义、词汇表、约束（必考）
ABSDM 六过程顺序：需求→设计→文档化→复审→实现→演化（必考）
DSSA 三层模型 + 人员对应：领域开发环境、领域特定应用开发环境（应用工程师）、应用执行环境
C2 风格关键特征：连接件连接、构件间无直接连接
黑板风格典型应用：信号处理（语音识别、模式识别）
解释器风格缺点：执行效率低
ADL 关注点：构件间互联机制（连接子）
常用多视图模型：4+1、4 视图、Views and Beyond
视图标准：IEEE 1471-2000、RM-ODP、UML、Zachman
后开发阶段研究方向：动态软件体系结构、体系结构恢复与重建

4.2 易混淆对比

对比项	区别
批处理 vs 管道-过滤器	批处理是整体传递，管道是流式处理
二层 C/S vs 三层 C/S	二层无功能层，三层分表示/功能/数据层
C/S vs B/S	B/S 浏览器作为客户端，跨平台但交互性差
仓库 vs 黑板	仓库是数据存储，黑板是问题求解（带控制）
解释器 vs 规则系统	解释器是通用虚拟机，规则系统包含知识库和工作内存
机会复用 vs 系统复用	机会是开发中发现，系统是开发前规划
进程通信 vs 事件系统	进程通信是消息传递，事件系统是广播/触发

10-系统质量属性与架构评估

Mon, 01 Jan 2024 00:00:00 +0000

10-系统质量属性与架构评估（基于第10小时）

软考-系统架构设计师 | 第3篇架构设计高级知识出题形式：单项选择题 + 下午案例分析题分值占比：约 8-15 分（选择），案例分析 25 分

0. 考点分析

本小时是软考分值最高、案例题最常考的章节之一。涵盖三大主题：

软件系统质量属性（开发期 + 运行期）
系统架构评估（方法、ATAM/SAAM 对比）
质量属性场景描述

考试特点：

选择题 8-15 分（概念必考）
案例分析题核心（ATAM 评估、效用树、风险/敏感点/权衡点识别）
论文题素材来源（架构评估方法、ATAM 实践）

1. 核心知识点

1.1 软件系统质量属性（开发期 + 运行期）

开发期质量属性

属性	作用及要点
易理解性	指设计被开发人员理解的难易程度
可扩展性	软件因适应新需求/需求变化而增加新功能的能力，也称灵活性
可重用性	重用软件系统或某一部分的难易程度
可测试性	对软件测试以证明其满足需求规范的难易程度
可维护性	当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度
可移植性	将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度

运行期质量属性

属性	作用及要点
性能	软件系统及时提供相应服务的能力（速度、吞吐量、容量）
安全性	软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力
可伸缩性	当用户数和数据量增加时，软件系统维持高服务质量的能力
互操作性	软件系统与其他系统交换数据和相互调用服务的难易程度
可靠性	软件系统在一定时间内持续无故障运行的能力
可用性	系统在一定时间内正常工作的时间所占比例
鲁棒性	软件系统在非正常情况（非法操作、软硬件故障）下仍正常运行的能力（也称健壮性/容错性）

1.2 面向架构评估的质量属性

评估关注的核心属性：

类别	属性	关键点
性能	性能	效率指标：处理任务所需时间或单位时间内的处理量
可靠性	容错	出现错误后仍能保证系统正确运行，且自行修正错误
	健壮性	错误不对系统产生影响，按既定程序忽略错误
	可用性	正常运行的时间比例
	安全性	系统向合法用户提供服务并阻止非法用户的能力
可维护性	可维护性	局部修复使故障对架构的负面影响最小化
可修改性	可扩展性	因松散耦合更易实现新特性/功能，不影响架构
	结构重组	不影响主体进行的灵活配置
	可移植性	适用于多样的环境（硬件平台、语言、操作系统等）
其他	功能性	需求的满足程度
	可变性	总体架构可变
	互操作性	通过可视化或接口方式提供更好的交互操作体验

1.3 提升质量属性的策略（⭐⭐⭐ 案例分析重点）

可用性策略

错误检测：心跳、Ping/Echo、异常
错误恢复：表决、主动冗余、被动冗余、重新同步、内测、检查点/回滚
错误避免：服务下线、事务、进程监控器

性能策略

资源的需求：减少处理时间对资源的占用、减少处理事件数量、控制资源使用
资源管理：并发机制、增加资源
资源仲裁：先来先服务、固定优先级、动态优先级、静态调度

可修改性策略

局部化修改：高内聚低耦合、预测变更、使模块通用
防止连锁反应：信息隐藏、维持现有接口、限制通信路径、使用中介
推迟绑定时间：运行时注册、多态、配置文件

安全性策略

抵抗攻击：用户身份验证、用户授权、维护数据机密性与完整性、限制暴露、限制访问
检测攻击：入侵检测系统
从攻击中恢复：恢复状态、识别攻击者

1.4 质量属性场景描述（6 要素）

要素	说明
刺激源（Source）	某个生成该刺激的实体（人、计算机系统或任何其他刺激器）
刺激（Stimulus）	指当刺激到达系统时需要考虑的条件
环境（Environment）	该刺激在某些条件内发生（系统可能处于过载、运行等情况）
制品（Artifact）	某个制品被激励，可能是整个系统，也可能是系统的一部分
响应（Response）	在激励到达后所采取的行动
响应度量（Measurement）	当响应发生时，应当能够以某种方式对其进行度量

1.5 系统架构评估方法分类

方法	特点	缺点
基于调查问卷或检查表	简单易行	很大程度上依赖评估人员的主观判断
基于场景	应用在 ATAM 和 SAAM 中	场景选择影响结果
基于度量	建立质量属性和度量之间的映射	难以建立映射原则

基于度量的步骤：

建立质量属性和度量之间的映射原则
在软件文档中获取度量信息
分析推导系统质量属性

1.6 架构评估重要概念（⭐⭐⭐ 必考）

概念	定义
敏感点	实现质量目标时应注意的点，是一个或多个构件的特性
权衡点	影响多个质量属性的敏感点
风险承担者/利益相关人	影响体系结构或被体系结构影响的群体
场景	确定架构质量评估目标的交互机制（刺激 + 环境 + 影响）
风险点	存在问题的架构设计决策，可能导致问题
非风险点	良好的架构设计决策

记忆口诀：

风险点 = 有问题
非风险 = 良好
敏感点 = 单个构件特性
权衡点 = 影响多个质量属性的敏感点

1.7 SAAM 评估方法

全称：Software Architecture Analysis Method
提出：1983 年，卡耐基梅隆大学软件工程研究所 Kazman 等人
特点：最早形成文档并得到广泛应用的非功能质量属性架构分析方法
输入：问题描述、需求说明、架构描述
过程：场景开发 → 架构描述 → 单个场景评估 → 场景交互 → 总体评估
特定目标：通过程序文档验证体系结构，注重发现潜在问题，可用于单系统评价或多系统比较
主要质量属性：可修改性是主要分析内容
架构描述：围绕功能、结构和分配描述

1.8 ATAM 评估方法（⭐⭐⭐ 案例题核心）

全称：Architecture Tradeoff Analysis Method（架构权衡分析法）
特点：系统开发之前，针对性能、可用性、安全性和可修改性等质量属性进行评价和折中
现代 ATAM：采用效用树对质量属性进行分类和优先级排序

传统 ATAM 四活动阶段

需求收集
架构视图描述
属性模型构造和分析
架构决策与折中

现代 ATAM 评估实践四阶段

阶段	步骤
演示（Presentation）	① 介绍 ATAM ② 介绍业务驱动因素 ③ 介绍要评估的体系结构
调查和分析	① 确定架构方法 ② 生成质量属性效用树 ③ 分析体系结构方法
测试	① 头脑风暴和优先场景 ② 分析架构方法
报告 ATAM	提供评估期间收集的所有信息，呈现给利益相关者

分析体系结构方法的 4 个主要阶段：

调查架构方法
创建分析问题
分析问题的答案
找出风险、非风险、敏感点和权衡点

1.9 SAAM 与 ATAM 对比（⭐ 案例分析重点）

项目	SAAM	ATAM
特定目标	通过程序文档验证体系结构，注重发现潜在问题，可用于评价单系统或进行多系统比较	确定在多个质量属性之间折中的必要性
评估技术	场景技术	场景技术 + 启发式分析方法
质量属性	可修改性是主要分析内容	性能、可用性、安全性和可修改性
风险承担者	所有参与者	场景和需求收集过程中的相关人
架构描述	围绕功能、结构和分配描述	五个基本结构及其映射关系
方法活动	场景开发、体系结构描述、单个场景评估、场景交互和总体评估	场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中
知识库可复用性	不涉及	有基于属性的体系模型，可复用
方法验证	空中交通管制系统、嵌入式音频系统、修正控制系统	仍处于研究中

1.10 其他评估方法

方法	特点
CBAM（成本效益分析法）	整理场景→对场景进行求精→确定场景的优先级→分配效用→架构策略涉及哪些质量属性及响应级别→使用内插法确定"期望的"质量属性响应级别的效用→计算各架构策略的总收益→根据受成本限制影响的 ROI 选择架构策略
SAEM	将软件架构看作最终产品以及涉及过程中的中间产品，从外部质量属性和内部质量属性阐述评估模型
SAABNet	辅助架构的定性评估，诊断软件问题可能原因，度量对象：架构属性、质量准则、质量因素
SACMM	软件架构修改的度量方法，基于内核定义差异度量准则计算两个软件架构之间的距离
SASAM	通过对预期架构和实际架构进行映射和比较来静态评估软件架构
ALRRA	软件架构可靠性风险评估方法，使用动态复杂度准则和动态耦合度准则
AHP	把定性分析和定量计算相结合，对各种决策因素进行处理
COSMIC+UML	针对不同表达方式的软件架构，采用统一的软件度量 COSMIC 方法

2. 关键概念速查

概念	定义/说明	常见考点
易理解性	设计被开发人员理解的难易程度	开发期属性
可维护性	识别修改点并实施修改的难易程度	开发期 vs 运行期辨析
性能	速度、吞吐量、容量	运行期核心属性
安全性	合法服务 + 阻止非授权	三大策略（抵抗/检测/恢复）
可用性	正常运行时间比例	三大策略（检测/恢复/避免）
鲁棒性	非正常情况仍正常运行（健壮性/容错性）	vs 容错的区别
敏感点	一个或多个构件的特性	单个属性
权衡点	影响多个质量属性的敏感点	多个属性
风险点	存在问题的架构设计决策	vs 非风险
SAAM	1983 年 CMU 提出，最早的架构评估方法	主要分析可修改性
ATAM	架构权衡分析法	性能/可用性/安全性/可修改性
CBAM	成本效益分析法	基于 ROI
效用树	对质量属性进行分类和优先级排序	现代 ATAM 工具
质量属性场景 6 要素	刺激源/刺激/环境/制品/响应/响应度量	6 个不能漏

3. 典型例题

例题 1（风险/敏感/权衡点辨析）

题目：识别风险、非风险、敏感点和权衡点是进行软件架构评估的重要过程。“改变业务数据编码方式会对系统的性能和安全性产生影响"是对（1）的描述，“假设用户请求的频率为每秒 1 个，业务处理时间小于 30 毫秒，则将请求响应时间设定为 1 秒钟是可以接受的"是对（2）的描述。

（1）A. 风险点 B. 非风险 C. 敏感点 D. 权衡点（2）A. 风险点 B. 非风险 C. 敏感点 D. 权衡点

答案：D（权衡点）、B（非风险）

解析：

改变业务数据编码方式同时影响性能和安全性两个属性→权衡点
请求频率 1/秒、业务时间 30ms、响应 1s 是良好的架构决策（无问题）→非风险

例题 2（效用树案例）

题目：某电子商务公司升级在线交易系统，需要构建质量属性效用树。题干描述中（a）-（m）各对应不同质量属性场景。

已知：

(a) 正常负载 0.5s 内响应
(b) 信用卡支付 99.999% 安全性
(d) 网络失效 2 分钟内发现并启用备用
(e) 高峰负载 10s 内完成支付
(h) 30 人·月添加事务中间件
(j) 主站点断电 3s 内重定向备用
(k) 用户信息数据库 99.999% 可用
(l) 4 人·月完成 Web 界面修改

答案：

编号	质量属性
(1)	性能
(2)	可修改性
(3)	(e) 高峰负载 10s 内完成
(4)	(j) 主站点断电 3s 内重定向
(5)	(l) Web 界面修改 4 人·月
(6)	(k) 数据库 99.999% 可用

解析：效用树主要关注性能、可修改性、可用性、安全 4 个方面。

例题 3（风险/敏感/权衡点识别）

题目：题干描述中，关于风险/敏感/权衡点的描述：

(f) 系统拟采用新的加密算法，会提高安全性，但会降低性能
(g) 对交易请求处理时间的要求将影响系统数据传输协议和交易处理过程的设计
(i) 现有架构设计中的支付部分与第三方支付平台紧耦合，当系统需要支持新的支付平台时，会导致支付部分代码的修改，影响系统的可修改性

答案：

(f) → 权衡点（同时影响安全性和性能）
(g) → 敏感点（对处理时间的要求影响多个构件的设计）
(i) → 风险（紧耦合导致修改困难，存在问题的架构决策）

例题 4（SAAM 与 ATAM 区别）

题目：以下关于 SAAM 和 ATAM 的描述中，错误的是：

A. SAAM 是最早形成文档的架构分析方法
B. ATAM 主要分析性能、可用性、安全性和可修改性
C. SAAM 主要分析可修改性
D. ATAM 的质量属性评估比 SAAM 少

答案：D

解析：ATAM 评估多个质量属性（性能/可用性/安全性/可修改性），SAAM 主要分析可修改性，ATAM 评估范围更广。

4. 高频考点

4.1 必须记住的核心要点

质量属性分类：
- 开发期：易理解、可扩展、可重用、可测试、可维护、可移植
- 运行期：性能、安全性、可伸缩、互操作性、可靠性、可用性、鲁棒性
三大质量策略：
- 可用性：检测/恢复/避免
- 性能：资源需求/管理/仲裁
- 可修改性：局部化/防连锁/推迟绑定
- 安全性：抵抗/检测/恢复
场景 6 要素：刺激源/刺激/环境/制品/响应/响应度量
风险/敏感/权衡点：
- 风险 = 有问题
- 非风险 = 良好
- 敏感点 = 单个构件特性
- 权衡点 = 影响多个质量属性的敏感点
SAAM vs ATAM 关键区别：
- SAAM：1983 年、场景技术、可修改性、多系统比较
- ATAM：性能/可用/安全/可修改、效用树、五个基本结构、可复用知识库
现代 ATAM 四阶段：演示→调查和分析→测试→报告
效用树关注 4 大属性：性能、可修改性、可用性、安全

4.2 易混淆对比

对比项	区别
敏感点 vs 权衡点	敏感点影响一个属性，权衡点影响多个属性
风险 vs 非风险	风险是有问题的决策，非风险是良好的决策
SAAM vs ATAM	SAAM 主分析可修改性，ATAM 分析 4 大属性（含权衡）
容错 vs 健壮性	容错是错误后修正，健壮性是错误不影响系统
性能 vs 可伸缩性	性能是单次响应能力，可伸缩是负载增加时维持服务质量
可用性 vs 可靠性	可用性是时间比例，可靠性是无故障运行能力
可维护性 vs 可修改性	可维护性是修复缺陷的难易，可修改性是架构层面的修改难易

12-软件架构演化与维护

Mon, 01 Jan 2024 00:00:00 +0000

12-软件架构演化与维护（基于第12小时）

软考-系统架构设计师 | 第3篇架构设计高级知识出题形式：单项选择题 + 下午案例分析题分值占比：约 3-5 分（选择），案例分析 25 分

0. 考点分析

本小时专注于软件架构的演化和维护，包括基本概念、演化类型、原则、评估方法和维护手段。

考试特点：

选择题 3-5 分（演化原则、动态/静态演化、原子操作）
案例分析题核心（大型网站架构演化路径、演化评估）
论文题高频素材（架构演化、维护管理）

1. 核心知识点

1.1 软件架构演化的重要性

保障软件系统具备诸多好的特性
有效管控软件系统的整体复杂性和变化性，降低软件检修和修改成本
保证软件系统演化的一致性和正确性，增加便捷性

1.2 演化和定义的关系

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

1.3 面向对象软件架构演化过程（4 类操作）

对象演化

操作	含义	触发场景
AO（Add Object）	添加新对象	系统需要添加新功能或增加架构灵活性时
DO（Delete Object）	删除对象	系统需要移除现有功能或降低架构复杂度时

消息演化（5 种操作）

操作	含义	触发场景
AM（Add Message）	增添一条新消息	对象之间需要增加新的交互行为
DM（Delete Message）	删除当前消息	需要移除某交互行为
SMO（Swap Message Order）	交换两条消息的时间顺序	需要改变两个交互行为之间顺序
OM（Overturn Message）	反转消息的发送对象与接收对象	需要修改某个交互行为本身
CMM（Change Message Module）	改变消息的发送或接收对象	需要修改某个交互行为本身

复合片段演化（4 种操作）

操作	含义	触发场景
AF（Add Fragment）	新增复合片段	需要增添新的控制流
DF（Delete Fragment）	删除复合片段	需要移除某段控制流
FTC（Fragment Type Change）	改变复合片段类型	需要改变某段控制流
FCC（Fragment Condition Change）	改变复合片段内部执行条件	改变当前控制流的执行条件

约束演化

操作	含义	触发场景
AC（Add Constraint）	添加新约束	需判断当前设计是否满足新约束
DC（Delete Constraint）	移除约束	去除某些不必要条件

1.4 软件架构演化方式的分类

按演化时期分（4 类）

类型	时机	特点
设计时演化	体系结构模型与代码编译之前	早期阶段
运行前演化	编译之后、执行之前	中间阶段
有限制运行时演化	特定约束满足时	受限运行
运行时演化	运行时不能满足要求时	动态调整

记忆口诀：设计时→运行前→有限制运行时→运行时（从早到晚）

静态演化 vs 动态演化

维度	静态演化	动态演化
需求	设计时演化、运行前演化	软件内部执行导致架构改变、外部请求重配置
过程	软件理解→需求变更分析→演化计划→系统重构→系统测试	实时调整
动态性等级	-	交互动态性、结构动态性、架构动态性
演化内容	-	属性改名、行为变化、拓扑结构改变、风格变化

注意：动态演化不包括"格式变化"（考题陷阱）

静态演化的原子操作

与可维护性相关（7 种）：

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）— 聚合模块

与可靠性相关（10 种）：

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.5 动态软件架构（DSA）

实现动态演化的基本原理

运行时刻体系结构相关信息的改变可用来触发、驱动系统自身的动态调整

DSA 描述语言（按视角分）

视角	语言
行为视角	π-ADL
反射视角	Pilar
协调视角	LIME

DSA 演化工具（4 种）

使用反射机制
基于组件操作
基于 π 演算
利用外部的体系结构演化管理器

动态软件架构应用实例 — PKUAS

4 种类型：容器系统、公共服务、工具和微内核

动态重配置

4 种模式：

主从模式
中央控制模式
客户端/服务器模式
分布式控制模式

应用实例：可重用、可配置的产品线架构

动态配置难点：

约束定义困难
性能约束难以静态衡量
难以管理所有方面
需同时保证组件系统完整性和重配置策略的正确和安全性

1.6 软件结构演化原则（18 大原则）

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

关键原则对比：

原则	vs
主体维持	平均增量平稳
平滑演化	演化速率趋于稳定
目标一致	阶段目标和最终目标一致
系统总体结构优化	整体结构布局合理

1.7 软件架构演化评估方法

演化过程已知的评估

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

演化过程未知的评估

教材图 12.3 展示评估过程
通过反向工程等技术恢复架构信息

1.8 大型网站系统架构演化实例（10 阶段）

阶段	架构	关键点
第一阶段	单体架构	应用程序、数据库、文件等所有资源都在一台服务器上
第二阶段	垂直架构	应用和数据分离，3 台服务器：应用、文件、数据
第三阶段	使用缓存改善性能	本地缓存 + 远程分布式缓存
第四阶段	使用服务集群改善并发	负载均衡调度服务器，分发请求到集群
第五阶段	数据库读写分离	主库写、从库读，主从复制机制同步
第六阶段	反向代理和 CDN 加速	CDN 部署在网络提供商机房（距离最近）；反向代理部署在中心机房
第七阶段	分布式文件系统和分布式数据库	业务分库，不同业务部署不同物理服务器
第八阶段	使用 NoSQL 和搜索引擎	解决海量数据检索
第九阶段	业务拆分	一个网站拆分成多个应用，独立部署
第十阶段	分布式服务	服务化、SOA/微服务

核心演化逻辑：

解决性能 → 缓存、集群、读写分离
解决高可用 → 集群、读写分离、CDN
解决扩展性 → 业务拆分、分布式服务
解决海量数据 → 分布式文件系统、NoSQL

1.9 软件架构维护

维护过程（3 大内容）：

软件架构知识管理
软件架构修改管理
软件架构版本管理

软件架构知识管理

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

软件架构修改管理

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

软件架构版本管理

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

架构可维护性度量（6 指标）

指标	缩写
圈复杂度	CNN
扇入扇出度	FFC
模块间耦合度	CBO
模块的响应	RFC
紧内聚度	TCC
松内聚度	LCC

2. 关键概念速查

概念	定义/说明	常见考点
AO/DO	对象的添加/删除	对象演化
AM/DM/SMO/OM/CMM	消息的增/删/换序/反转/改模块	消息演化 5 种
AF/DF/FTC/FCC	复合片段的增/删/改类型/改条件	复合片段演化
AC/DC	约束的添加/删除	约束演化
设计时演化	编译之前	4 时期最早
运行前演化	编译之后、执行之前	4 时期
有限制运行时演化	特定约束满足时	4 时期
运行时演化	运行时不能要求时	4 时期最晚
主体维持	平均增量平稳	18 原则
平滑演化	演化速率趋于稳定	18 原则
目标一致	阶段目标和最终目标一致	18 原则
系统总体结构优化	整体结构布局合理	18 原则
DSA 描述语言	π-ADL（行为）/Pilar（反射）/LIME（协调）	3 种视角
动态重配置 4 模式	主从/中央控制/C-S/分布式控制	4 种模式
大型网站 10 阶段	单体→垂直→缓存→集群→读写分离→CDN→分布式→NoSQL→业务拆分→分布式服务	演化路径
架构维护 3 内容	知识/修改/版本管理	必考
架构可维护性 6 指标	CNN/FFC/CBO/RFC/TCC/LCC	缩写含义

3. 典型例题

例题 1（演化原则辨析）

题目：在软件系统的生命周期里，软件的演化速率趋于稳定，如相邻版本的更新率相对稳定。此描述是软件架构演化的（）原则。

A. 主体维持
B. 系统总体结构优化
C. 平滑演化
D. 目标一致

答案：C

解析：

主体维持：平均增量增长平稳
系统总体结构优化：整体结构布局合理
平滑演化：演化速率趋于稳定 ✓
目标一致：阶段目标和最终目标一致

例题 2（架构维护内容）

题目：软件架构维护过程不包括（）。

A. 架构知识管理
B. 架构修改管理
C. 架构版本管理
D. 架构构件管理

答案：D

解析：软件架构维护过程包括架构知识管理、架构修改管理、架构版本管理，不包括架构构件管理。

例题 3（演化时期辨析）

题目：下列软件架构演化时期，（）是在系统设计时规定了演化的具体条件，将系统置于"安全"模式下，演化只发生在某些特定约束满足时，可以进行一些规定好的演化操作。

A. 设计时演化
B. 运行前演化
C. 有限制运行时演化
D. 运行时演化

答案：C

解析：

设计时演化：编译之前
运行前演化：编译之后、执行之前
有限制运行时演化：只发生在某些特定约束满足时 ✓
运行时演化：运行时不能满足要求时

例题 4（动态演化内容）

题目：根据所修改的内容不同，软件的动态演化不包括（）。

A. 属性改名
B. 行为变化
C. 拓扑结构改变
D. 格式变化

答案：D

解析：动态演化的内容包括：属性改名、行为变化、拓扑结构改变、风格变化。格式变化不属于动态演化内容。

4. 高频考点

4.1 必须记住的核心要点

架构 3 要素：组件、连接件、约束（演化关注这 3 要素的增删改）
对象演化 2 种：AO、DO
消息演化 5 种：AM、DM、SMO、OM、CMM
复合片段演化 4 种：AF、DF、FTC、FCC
约束演化 2 种：AC、DC
演化 4 时期（从早到晚）：设计时→运行前→有限制运行时→运行时
动态演化 4 内容：属性改名、行为变化、拓扑结构改变、风格变化（不含格式变化）
DSA 描述语言 3 视角：行为（π-ADL）/反射（Pilar）/协调（LIME）
动态重配置 4 模式：主从/中央控制/C-S/分布式控制
PKUAS 4 类型：容器系统、公共服务、工具、微内核
架构 4 大演化原则对比：
- 主体维持：平均增量平稳
- 平滑演化：演化速率稳定
- 目标一致：阶段目标和最终目标一致
- 系统总体结构优化：整体结构合理
大型网站 10 阶段演化路径（必考）
架构维护 3 内容：知识/修改/版本管理（不含构件管理）
可维护性 6 指标：CNN/FFC/CBO/RFC/TCC/LCC
架构知识 = 架构设计 + 架构设计决策

4.2 易混淆对比

对比项	区别
AO vs AM	AO 是对象的添加，AM 是消息的添加
AC vs AF	AC 是约束的添加，AF 是复合片段的添加
主体维持 vs 平滑演化	主体维持强调增量稳定，平滑演化强调速率稳定
目标一致 vs 系统总体结构优化	目标一致是目标，结构优化是布局
静态演化 vs 动态演化	静态是预先规划的演化，动态是运行时刻的演化
设计时 vs 运行前	设计时是编译之前，运行前是编译之后
双机热备 vs 服务集群	热备是2 台服务器，集群是多节点通过 LAN 互连
架构知识管理 vs 修改管理	知识管理是捕捉记录，修改管理是隔离变更