本页目录 · 10 节
- 一、分值定位
- 二、Garlan & Shaw 五类风格（总表，先背这张）
- 2.1 数据流风格
- 2.2 调用/返回风格
- 2.3 独立构件风格
- 2.4 虚拟机风格
- 2.5 仓库风格
- 三、架构视图
- 3.1 4+1 视图（Kruchten）——最高频
- 3.2 Hofmeister 4 视图（与 4+1 的区别要能说清）
- 3.3 "视角（perspective）"与"视图（view）"
- 四、风格 × 质量属性 对比矩阵（案例三维对比直接套）
- 五、案例母题拆解（这三个能覆盖 80% 的风格题）
- 母题 1：规则系统 vs 面向对象（2019 下 试题一，2022/2021 变体）
- 母题 2：仓库 vs 管道-过滤器（2020 下 试题一）
- 母题 3：C/S 层次选择（2018 下 案例一 瘦客户端）
- 六、跨年真题定位索引
- 七、典型陷阱
- 八、答题模板
- 模板 A：综合知识"某需求最适合哪种风格"（20 秒）
- 模板 B：案例"两种风格二选一 + 三维对比"（满分结构）
- 模板 C：论文"论事件驱动/分层/六边形"
- 九、自测清单
- 十、来源与可信度
知识域 02 · 架构风格与架构视图
题号指向
../01-年份索引/<年份>-套卷.md，答案以套卷为准。标记：〔核〕机构答案 /〔推〕推导 /〔存疑〕有争议。
一、分值定位
| 科目 | 频率 | 形态 |
|---|---|---|
| 综合知识 | 每套 4—8 题（6—11 分） | 风格归属、风格特征判断、视图与 UML 图对应、C/S 层次 |
| 案例分析 | 高频（与 01 域捆绑出现） | "两种风格选哪个 + 三维对比" 是固定题型 |
| 论文 | 偶考（事件驱动、六边形架构、层次架构） | 可作为论文素材 |
这个域的特点是：概念多但极稳定，十年不换骨架，只是换包装场景。属于"背了就有分"的域，但风格与质量属性的对应关系是案例拉分点。
二、Garlan & Shaw 五类风格（总表，先背这张）
| 大类 | 成员 | 构件 / 连接件 | 一句话特征 |
|---|---|---|---|
| 数据流 | 批处理、管道-过滤器 | 过滤器 / 管道（数据流） | 数据按顺序被逐步加工 |
| 调用/返回 | 主程序-子程序、面向对象、层次结构 | 构件 / 调用返回 | 有明确的控制流，自顶向下 |
| 独立构件 | 进程通信、事件驱动（隐式调用） | 构件 / 消息或事件 | 构件间松耦合，通过消息/事件交互 |
| 虚拟机 | 解释器、规则系统 | 解释引擎 / 状态与规则数据 | 用"数据+引擎"替代硬编码 |
| 仓库 | 数据库系统、超文本、黑板 | 中央数据结构 + 独立构件 / 数据访问 | 以共享数据为中心 |
2.1 数据流风格
批处理（Batch Sequential）
- 构件：独立程序；连接件：批处理管道。前一步整体完成后才启动下一步。
- 优点：整体性强、便于处理大批量数据；缺点：不支持并发、无法交互、时延大。
- 真题：2022 下 48—49、2023 下 55（批处理 vs 管道-过滤器）。
管道-过滤器（Pipe and Filter）
- 构件：过滤器（独立、无状态、增量处理）；连接件：管道（单向数据流）。
- 优点：高可复用、易维护、支持并发（各过滤器可并行）；缺点：不适合交互式应用、数据传输与格式转换开销大、错误处理困难。
- 真题：2026 下 30、2024 下 60、2024 上 23—24、2023 下 55、2020 下 试题一（仓库 vs 管道）。
2.2 调用/返回风格
主程序-子程序：单线程、层次化调用，结构化设计的典型实现。真题 2026 上 11。
面向对象：封装、继承、多态；构件是对象，连接件是方法调用。真题 2019 下 试题一（规则 vs OO）。
层次结构（分层）：每层只依赖下层，通过层间接口调用。
- 优点：可替换、可复用、支持标准化；缺点：并非所有系统都能抽象成分层、性能有损耗、层间接口设计困难。
- 真题 2023 下 71—75（英文填空：层次式体系结构）。
C/S 族（教材单列，考试极高频）
| 形态 | 结构 | 优点 | 缺点 |
|---|---|---|---|
| 两层 C/S | 客户端（表示+业务）/ 服务器（数据库） | 开发简单、响应快 | 客户端胖、维护升级困难、安全边界弱 |
| 三层 C/S | 表示层 / 功能层（业务）/ 数据层 | 瘦客户端、易维护、可伸缩、业务逻辑集中便于安全控制 | 中间层可能成为瓶颈与单点 |
| B/S | 浏览器 / Web 服务器 / 应用服务器 / 数据库 | 零安装、跨平台 | 交互能力弱于 C/S |
| 应用服务器（三层 C/S 变体） | 表示层 + 应用服务器 + 数据层 | 组件化部署 | 依赖中间件 |
- 真题：2026 上 43（两层 C/S）、2025 下 47、2025 上 34、2021 下 62—63、2020 下 51—53、2024 上 25、2018 下 案例一（瘦客户端=三层 C/S 的典型特征）、2021 下 71—75（英文：C/S 计算模式）。
2.3 独立构件风格
进程通信（消息传递）：构件通过显式消息传递交互。真题 2026 上 55、2025 下 62。
事件驱动 / 隐式调用（Event-Driven / Implicit Invocation）
- 构件：发布者、订阅者；连接件：事件总线。
- 优点：松耦合、易扩展、支持异步；缺点：控制流不确定、难以调试与测试、不能保证响应顺序、性能不可预测。
- 真题：2026 上 9、2024 上 28；论文 2025 上 论文二。
2.4 虚拟机风格
解释器（Interpreter）
- 组成：解释引擎 + 被解释的"程序/脚本/规则"数据 + 解释器内部状态。
- 优点：灵活性高（改配置不改代码）、可支持 DSL/自定义脚本；缺点：性能低、内存开销大、实现复杂。
- 真题：2018 下 51—53（"玩家自定义战役地图与对象行为"→解释器；同时考质量属性）、2025 下 56、2025 上 试题 1、2022 下 试题一。
规则系统（Rule-Based）
- 把业务规则从代码中抽出，以规则数据形式存放，由规则引擎解释执行。
- 优点：规则可动态调整、业务人员可维护；缺点：需实时解释、性能较差、规则冲突难管理。
- 真题：2021 下 51—52、2025 下 63、2022 下 48—49、2019 下 试题一（母题）。
2.5 仓库风格
| 子类 | 结构 | 适用 |
|---|---|---|
| 数据库系统 | 中央数据库 + 触发器/应用 | 数据密集型 |
| 超文本系统 | 文档 + 链接 | 浏览式 |
| 黑板（Blackboard） | 中央数据结构（黑板）+ 知识源 + 控制 | 无确定解法、需多专家协同的复杂问题（语音/图像识别、信号处理、作战决策） |
母题（2018 下 49—50，〔推〕答案 B、C）："在仓库风格中，有两种不同的构件，其中（）说明当前状态，（）在中央数据存储上执行。"
→ 中央数据结构（说明当前状态）、知识源（在中央数据存储上执行）。
陷阱：选项里有"独立构件"，但教材把执行者具体化为知识源。
真题：2024 下 19、2024 上 22、2025 上 22、2026 上 50、2020 下 试题一。
三、架构视图
3.1 4+1 视图（Kruchten）——最高频
| 视图 | 关注点 | 对应 UML 图 | 面向的干系人 |
|---|---|---|---|
| 逻辑视图 | 功能需求、对象模型 | 类图、对象图、状态图 | 最终用户、分析设计人员 |
| 进程视图（并发） | 并发、同步、性能、吞吐 | 活动图（早期也用状态图描述进程） | 系统集成人员 |
| 开发视图（实现） | 模块组织、包、构件、复用 | 构件图、包图 | 程序员、项目经理 |
| 物理视图（部署） | 软件到硬件的映射、分布 | 部署图 | 系统工程人员 |
| 场景（用例） | 串联四个视图、验证一致性 | 用例图 | 全部干系人 |
母题（2018 下 44，〔推〕答案 A）：逻辑视图、开发视图、物理视图、进程视图、统一的场景。
易错：4+1 的第五个是"场景/用例"，不是"模块视图"或"构件视图"；"模块视图"是 Hofmeister 体系的说法。
3.2 Hofmeister 4 视图（与 4+1 的区别要能说清）
| Hofmeister | 4+1 对应 |
|---|---|
| 逻辑视图 | 逻辑视图（但更强调对象模型与模块） |
| 开发视图 | 开发视图 |
| 并发视图 | ≈ 进程视图 |
| 物理视图 | 物理视图 |
| —— 无场景视图 | 有"场景"作为第 5 个 |
真题：2025 下 64（Hofmeister 4 视图）、2020 下 44—47（4+1 视图/视角）。
3.3 "视角（perspective）"与"视图（view）"
- 视图：从某一侧面对系统的结构化描述（静态切面）。
- 视角：跨视图关注的质量属性（如安全性、性能视角），是对多个视图的补充与修饰。
- 真题：2024 上 21（视角与视图的区别）。
四、风格 × 质量属性 对比矩阵（案例三维对比直接套）
| 风格 | 性能 | 可扩展/可修改 | 可复用 | 交互性 | 典型短板 |
|---|---|---|---|---|---|
| 管道-过滤器 | 中（有传输开销，可并发） | 高 | 高 | 差 | 不适合交互、错误处理难 |
| 批处理 | 高（批量） | 中 | 中 | 差 | 无并发、时延大 |
| 仓库/黑板 | 取决于知识源调度 | 中 | 高（知识源可插拔） | 中 | 控制复杂、调试难 |
| 解释器 | 低 | 高（改脚本不改码） | 高 | 中 | 性能与内存开销 |
| 规则系统 | 低（实时解释） | 高（规则动态改） | 中 | 中 | 规则冲突、性能 |
| 事件驱动 | 不确定 | 高（松耦合） | 高 | 好 | 控制流不可预测、难测试 |
| 两层 C/S | 高 | 低（客户端重装） | 低 | 好 | 客户端胖、维护难 |
| 三层 C/S | 中（多一跳） | 高（改中间层即可） | 中 | 好 | 中间层瓶颈/单点 |
| 分层 | 中（跨层开销） | 高（层内替换） | 高 | — | 分层不合理则性能差 |
五、案例母题拆解（这三个能覆盖 80% 的风格题）
母题 1：规则系统 vs 面向对象（2019 下 试题一，2022/2021 变体）
题干特征：用户等级、折扣规则"后续需要动态调整""节假日按实时消费动态调整折扣"。
答题骨架：
① 结论：更适合【基于规则的架构风格】。
② 灵活性：规则以数据形式外置，新增/修改折扣规则只需改规则库，无需改代码、无需重启。
③ 可扩展性：新增用户等级=新增规则条目；OO 需新增类并重启系统，扩展成本高。
④ 性能：OO 把规则编码在类中，直接调用，性能更好；规则系统需实时解释，性能较差。
⑤ 取舍：本系统最看重"规则变化的灵活性"，性能可通过规则缓存/预编译缓解，故选规则系统。三个维度必须逐条对写（灵活性/可扩展性/性能），且最后一句"取舍理由"是评分点。
母题 2：仓库 vs 管道-过滤器（2020 下 试题一）
题干特征：多工具围绕同一份"软件文档/数据"协作，工具可增删。
答题骨架：仓库风格以共享数据为中心，工具（知识源）可插拔 → 适合"多工具、共享数据、工具易变"；管道-过滤器要求数据单向流动、过滤器无状态，不适合多工具协同编辑同一数据。
母题 3：C/S 层次选择（2018 下 案例一 瘦客户端）
答题骨架：瘦客户端 = 三层 C/S。业务逻辑放功能层，客户端只做表示 → 升级维护只改服务器；安全性提升（业务与数据不暴露在客户端）；代价是中间层压力增大，需集群/负载均衡。
六、跨年真题定位索引
| 年份 | 题号/案例 | 考点 |
|---|---|---|
| 2026 下 | 30 | 管道-过滤器 |
| 2026 下 | 案例三 | C/S 架构 |
| 2026 上 | 9 / 11 / 43 / 49 / 50 / 55 | 事件驱动、主程序-子程序、两层 C/S、风格定义、黑板、进程通信 |
| 2026 上 | 案例一 | 质量属性 → 风格选择 |
| 2025 下 | 47 / 56 / 62 / 63 / 64 | C/S、解释器、进程通信、规则系统、Hofmeister 4 视图 |
| 2025 上 | 20 / 22 / 34 | 4+1 视图、黑板、三层 C/S |
| 2025 上 | 试题 1 | 解释器风格（案例） |
| 2024 下 | 19 / 22 / 57 / 60 | 仓库、4+1、调用返回、管道-过滤器 |
| 2024 上 | 21—26 / 28 / 30 | 视角与视图、黑板、过滤器、管道、应用服务器、风格选择、事件驱动、RUP 4+1 |
| 2023 下 | 30 / 55 / 56 / 71—75 | 架构定义、批处理 vs 管道、构件接口调用、层次式架构（英文） |
| 2022 下 | 44—45 / 48—49 | 4+1 视图、批处理与规则系统 |
| 2022 下 | 试题一 | 解释器风格（案例） |
| 2021 下 | 48 / 51—52 / 62—63 / 71—75 | 风格识别、规则系统、三层 C/S、C/S 模式（英文） |
| 2021 下 | 试题一 / 试题四 | 风格对比、家庭网关 vs 云平台 |
| 2020 下 | 44—47 / 51—53 | 4+1 视图/视角、三层 C/S |
| 2020 下 | 试题一 | 仓库 vs 管道-过滤器 |
| 2019 下 | 44—48 | UML 图与 4+1 对应、Garlan & Shaw 五类分类 |
| 2019 下 | 试题一 | 规则 vs 面向对象 |
| 2018 下 | 44 / 49—50 / 51—53 | 4+1、仓库、解释器+质量属性 |
| 2018 下 | 案例一 | 瘦客户端 C/S |
七、典型陷阱
- 4+1 的第五视图写成"模块视图/构件视图"→ 错，必须是场景/用例。
- 进程视图对应部署图→ 错，进程视图对应活动图，物理视图才对应部署图。
- 黑板风格 = 仓库的一种，但答题时若题干强调"多知识源协同求解无确定解问题"，直接答黑板更精准。
- 事件驱动 ≠ 进程通信：进程通信是显式消息传递（点对点）；事件驱动是隐式调用（发布/订阅，发布者不知道订阅者）。
- 两层 C/S 有"胖客户端"缺陷，题目给"客户端维护升级困难"就是两层 C/S 的特征描述。
- 规则系统与解释器容易混：解释器解释"程序/DSL"，规则系统解释"业务规则"；规则系统是解释器的特化。
- 管道-过滤器"支持并发"但"不适合交互"：这两句常被拆成两个选项互设陷阱。
- 分层结构不是万能的：教材明确"并非所有系统都能抽象为分层"，这句话常作为"错误说法"选项。
- 风格不是越新越好：案例结论要回到"本项目最关注的质量属性"，不能只背优缺点。
八、答题模板
模板 A：综合知识"某需求最适合哪种风格"（20 秒）
看关键词 → 定风格：
"数据逐步加工/无交互" → 管道-过滤器
"批量整体处理" → 批处理
"用户自定义/脚本/可配置" → 解释器
"业务规则频繁变" → 规则系统
"多工具共享同一数据/无确定解" → 仓库/黑板
"发布订阅/松耦合/异步通知" → 事件驱动
"升级维护只改服务端/瘦客户端" → 三层 C/S模板 B：案例"两种风格二选一 + 三维对比"（满分结构）
【结论】更适合 ______ 风格。（1 行，必须先给结论）
【维度 1 灵活性】______ 风格：……；______ 风格：……。
【维度 2 可扩展性】…… vs ……
【维度 3 性能】…… vs ……
【取舍】本项目最关注 ______（引用题干原话），且 ______ 的缺点可通过 ______ 缓解，
因此选择 ______。（必须有这一句）模板 C：论文"论事件驱动/分层/六边形"
一、项目背景与我的角色（300 字，含并发量、团队规模）
二、该风格的核心构件与连接件（300 字：列出构件、连接件、交互机制）
三、落地细节（900 字）：如何划分构件、事件如何定义与路由、如何解决
"控制流不确定/难测试/性能不可预测"三大痛点（幂等、事件溯源、死信队列、链路追踪）
四、效果（量化：扩展新业务从 X 天缩短到 Y 天，峰值吞吐提升 Z%）
五、不足与改进九、自测清单
- [ ] 默写 Garlan & Shaw 五类风格及每类成员
- [ ] 说出管道-过滤器的 3 个优点、3 个缺点
- [ ] 说出黑板风格的三个组成部分，并解释"知识源"的作用
- [ ] 区分解释器与规则系统的适用场景
- [ ] 画出 4+1 视图并写出每个视图对应的 UML 图
- [ ] 说出 Hofmeister 4 视图与 4+1 的差异
- [ ] 用模板 B 在 10 分钟内写完"规则 vs OO"的三维对比
- [ ] 说出两层 C/S 与三层 C/S 的 3 个差异
十、来源与可信度
- 风格分类以 Garlan & Shaw 分类法与《系统架构设计师教程》第 12 章为准。
- 各风格优劣表述以教材原话为基准；不同资料对"批处理是否支持并发"表述一致（不支持）。
- 2018 下部分题目无公开答案，本域引用的 44/49/50 题为〔推〕，已用教材定义交叉验证。