本页目录 · 5 节
第 7 章 系统架构设计基础知识
对应大纲:科目 1-6 系统架构设计基础知识|教材 P248–P270|优先级 ★★★★★|综合知识估分 7~9 分
读法:本章是案例与论文的「共同母本」。先背死三个骨架(架构三要素、ABSD 六步、风格五大类),再用「一句话特征+例子+优缺点」横向串风格,最后把 DSSA 当名词解释背。
一、知识框架
系统架构设计基础知识
├─ 7.1 软件架构概念
│ ├─ 定义:构件 + 连接件 + 约束
│ ├─ 设计与生命周期:需求分析→设计→文档化→实现→演化维护
│ └─ 重要性:交流平台|决策载体|质量基础|复用单元
├─ 7.2 基于架构的软件开发方法 ABSD
│ ├─ 术语:视角/视图、组合视图、质量场景
│ ├─ 六步:需求→设计→文档化→复审→实现→演化
│ └─ 每步的输入、活动、输出
├─ 7.3 软件架构风格
│ ├─ 数据流:批处理、管道-过滤器
│ ├─ 调用返回:主程序-子程序、面向对象、层次结构、C2
│ ├─ 以数据为中心:仓库、黑板
│ ├─ 虚拟机:解释器、规则系统
│ └─ 独立构件:进程通信、事件驱动
├─ 7.4 软件架构复用
│ ├─ 分类:机会复用/系统复用
│ ├─ 原因、复用对象与形式
│ └─ 基本过程:构造→管理→使用→反馈
└─ 7.5 特定领域软件体系结构 DSSA
├─ 三层次:领域开发环境/领域应用开发环境/应用执行环境
├─ 五活动:范围→元素→约束→模型架构→可复用产品
├─ 四角色:领域专家/分析师/设计师/实现人员
└─ 建立过程与产出
二、必背要点
7.1 软件架构概念
定义(三要素):软件架构 = 构件 + 连接件 + 约束。
| 要素 | 内涵 | 举例 |
|---|---|---|
| 构件 | 承担计算或数据存储的单元 | 类、服务、模块、数据库 |
| 连接件 | 构件之间的交互机制 | 方法调用、消息、管道、事件总线 |
| 约束 | 组合规则、拓扑与语义限制 | 分层只能上层调下层、接口契约 |
架构设计与生命周期(5 阶段)
| 阶段 | 主要活动 | 产出 |
|---|---|---|
| 需求分析 | 提炼功能、质量、业务需求 | 架构需求规格 |
| 架构设计 | 选风格、映射构件、分析交互、评审 | 架构模型与视图 |
| 文档化 | 编写多视图文档、记录决策 | 架构文档 |
| 实现 | 构件开发、组装、测试 | 可运行系统 |
| 演化维护 | 变更归类、演化计划、构件替换 | 新版本架构 |
重要性四条:架构是风险承担者的交流平台;是早期决策载体(越晚改代价越大);是质量属性的决定因素;是收益最大的复用单元。
7.2 基于架构的软件开发方法 ABSD
定义:以架构为核心驱动全生命周期,由功能、质量、业务需求共同驱动;用视角与视图描述架构,用质量场景描述质量目标,采用自顶向下、递归细化的方法。
| 术语 | 含义 |
|---|---|
| 视角 | 观察架构的维度或关注点(结构、行为、部署) |
| 视图 | 视角的具体表达,如逻辑、进程、开发、物理视图 |
| 组合视图 | 多视图整合,检查视图间的一致性 |
| 质量场景 | 质量需求的可度量描述,分目标、需求、案例三类 |
开发模型六步
| 步骤 | 核心活动 | 输出 |
|---|---|---|
| 体系结构需求 | 需求获取、标识构件、需求评审 | 需求规格、初选构件表 |
| 体系结构设计 | 提出架构模型、映射构件、分析交互、设计评审 | 架构视图 |
| 体系结构文档化 | 编写多视图文档、记录设计决策 | 架构文档 |
| 体系结构复审 | 审查需求满足度、识别风险与敏感点 | 复审报告 |
| 体系结构实现 | 复审架构、复合构件、分配任务、编码、打包、测试 | 可运行系统 |
| 体系结构演化 | 需求变化归类、演化计划、构件变动、更新交互、组装、演化后评审 | 新架构版本 |
开发模型特点:以架构为中心组织全部活动;阶段之间可迭代返工,不是一次性瀑布;需求、设计、实现、演化形成闭环;架构文档是各阶段成果的载体与交接依据。
六步记忆要点:需求阶段解决「有哪些构件」,设计阶段解决「构件怎么连」,文档化解决「怎么表达」,复审解决「对不对」,实现解决「怎么落地」,演化解决「怎么变」。
7.3 软件架构风格
定义:架构风格 = 构件类型 + 连接件类型 + 约束 + 语义解释,是一类架构反复使用的「惯用解法」。共五大类。
(1)数据流风格
| 风格 | 一句话特征与例子 | 优缺点 |
|---|---|---|
| 批处理 | 整批数据按顺序处理、无交互;如工资计算、ETL | 简单、吞吐高;延迟大、错误定位难 |
| 管道-过滤器 | 数据流经一串独立过滤器逐级变换;如 Unix pipe、编译器 | 可组合、易复用;不适合交互、传输有开销 |
(2)调用返回风格
| 风格 | 一句话特征与例子 | 优缺点 |
|---|---|---|
| 主程序-子程序 | 单线程层次调用;如传统 C 程序 | 结构清晰、易调试;耦合较强 |
| 面向对象 | 对象封装状态与行为,方法调用交互;如 Java 业务系统 | 封装多态、易复用;对象耦合与开销 |
| 层次结构 | 分层且只依赖下层;如 OSI、三层架构 | 关注点分离、可替换;层多影响性能 |
| C2 | 构件经连接件异步消息交互,不可直接调用;如 GUI 协作系统 | 松耦合、支持异构;消息开销、难调试 |
(3)以数据为中心风格
| 风格 | 一句话特征与例子 | 优缺点 |
|---|---|---|
| 仓库 | 中心数据结构,构件独立读写;如数据库、IDE | 数据共享、构件独立;中心成为瓶颈 |
| 黑板 | 共享黑板加知识源,控制构件调度求解;如语音识别、专家系统 | 适合无固定算法问题;控制复杂、性能难保证 |
(4)虚拟机风格
| 风格 | 一句话特征与例子 | 优缺点 |
|---|---|---|
| 解释器 | 解释执行自定义语言或字节码;如 JVM、Python | 可移植、易扩展语法;执行效率低 |
| 规则系统 | 事实库加规则库,由推理引擎匹配;如风控规则引擎 | 规则与代码分离、易改;规则冲突、难调试 |
(5)独立构件风格
| 风格 | 一句话特征与例子 | 优缺点 |
|---|---|---|
| 进程通信 | 独立进程显式消息或共享内存交互;如微服务、消息队列 | 隔离性好、可分布;通信开销、一致性复杂 |
| 事件驱动 | 发布事件、订阅者被隐式调用;如 GUI 事件、消息总线 | 松耦合、易扩展;控制流不直观、难调试 |
7.4 软件架构复用
- 定义:在开发中重复使用已有软件资产,包括架构、构件、需求、设计、测试用例和文档。
- 分类:机会复用(开发中偶然发现可复用)与系统复用(有计划的领域工程);按粒度分代码、构件、架构、领域复用。
- 原因:降成本、缩周期、提质量、降风险、增强互操作与标准化。
- 复用对象与形式:对象为需求、架构、设计、构件、测试、文档;形式为继承、组合、框架、设计模式、构件库、产品线。
- 基本过程:构造或获取资产 → 分类存储管理 → 检索评估适配使用 → 反馈改进。
7.5 特定领域软件体系结构 DSSA
定义:在一个特定应用领域中,为一组应用提供组织结构参考的软件架构,是领域工程的核心产物。
三层次模型
| 层次 | 使用者 | 作用 |
|---|---|---|
| 领域开发环境 | 领域工程师 | 开发领域模型与 DSSA |
| 领域特定应用开发环境 | 应用工程师 | 基于 DSSA 派生应用架构 |
| 应用执行环境 | 最终用户 | 运行派生出的应用 |
五项基本活动
| 活动 | 主要工作 |
|---|---|
| 定义领域范围 | 明确领域边界、应用类型与目标 |
| 定义领域特定元素 | 识别共性与可变性,建立术语与特征模型 |
| 定义设计与实现约束 | 技术栈、标准、接口、平台限制 |
| 定义领域模型和架构 | 形成参考架构、构件与连接件 |
| 产生搜集可复用产品 | 构件库、模板、生成器入库 |
四类参与人员:领域专家(提供领域知识)、领域分析师(分析与建模)、领域设计师(架构与构件设计)、领域实现人员(开发可复用资产)。
建立过程:定义范围 → 定义元素 → 定义约束 → 定义模型与架构 → 产生并搜集可复用产品,每步均需评审并形成领域资产。
三、易混淆概念对比
| A | B | 关键区别 |
|---|---|---|
| 软件架构 | 架构风格 | 架构是具体系统的结构;风格是一类架构的抽象惯用模式 |
| 视角 | 视图 | 视角是观察维度;视图是视角的文档化表达 |
| 构件 | 连接件 | 构件负责计算与存储;连接件负责交互 |
| ABSD | 瀑布模型 | ABSD 以架构为中心、递归细化、含演化;瀑布按阶段线性推进 |
| 批处理 | 管道-过滤器 | 批处理整批无交互;管道-过滤器流式、可组合、可增量 |
| 仓库 | 黑板 | 仓库构件自主读写;黑板由控制构件调度知识源协作 |
| 解释器 | 规则系统 | 解释器执行语言或字节码;规则系统按事实与规则推理 |
| 事件驱动 | 进程通信 | 事件驱动隐式调用、发布者不知订阅者;进程通信显式指定目标 |
| 架构复用 | 代码复用 | 架构复用粒度大、影响质量与演化;代码复用影响局部 |
| DSSA | 软件产品线 | DSSA 是领域参考架构资产;产品线是组织级复用体系 |
四、常见考法与出题角度
| 题型 | 出题角度 | 典型问法 | 答题要点 |
|---|---|---|---|
| 单选 | 风格识别 | 「编译器采用哪种风格」 | 管道-过滤器;按数据流逐级变换判断 |
| 单选 | 风格优缺点 | 「下列属于层次结构缺点的是」 | 层次多带来性能损耗、跨层调用破坏结构 |
| 单选 | ABSD 步骤 | 「架构文档化之后是哪一步」 | 复审;六步顺序不能乱 |
| 单选 | 术语含义 | 「质量场景分为哪三类」 | 目标场景、需求场景、案例场景 |
| 单选 | DSSA | 「DSSA 三层次不包括」 | 领域开发、领域应用开发、应用执行三环境 |
| 简答 | 架构定义 | 「什么是软件架构」 | 构件、连接件、约束三要素齐全 |
| 简答 | 风格对比 | 「仓库与黑板有何不同」 | 从控制权、数据共享、适用问题作答 |
| 案例题角度 | 架构风格选型 | 给出业务场景问「采用什么风格、为什么」 | 先答风格名,再答构件/连接件,最后扣质量属性 |
| 论文可用角度 | 正文举例 | 「论文写电商架构时怎么用本章」 | 可写:「订单风控链路采用管道-过滤器风格,各过滤器独立部署、可插拔,新增规则不影响主流程。」 |
五、速记与自测
速记
- 架构三件套:构、连、约
- 生命周期五步:需、设、文、实、演
- ABSD 六步:需设文审实演
- 风格五类:数调仓虚独
- DSSA 五活动:范、元、约、模、产
- DSSA 三环境:开发、应用开发、执行
自测
- 软件架构的三个基本要素是什么?
- ABSD 中「视角」和「视图」的区别是什么?
- 仓库风格与黑板风格的核心区别是什么?
答案:1. 构件、连接件、约束;2. 视角是观察维度,视图是该维度的具体文档表达;3. 仓库由构件自主读写共享数据,黑板由控制构件调度知识源协作求解。