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.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 事件系统 | 进程通信是消息传递，事件系统是广播/触发 |