文章目录
-
- 目录
- 六、「4+1」视图与多视图
- 七、软件架构的概念
- 八、软件架构评估
-
- [质量效用树 · 关于优先级的不正确说法（选非）](#质量效用树 · 关于优先级的不正确说法（选非）)
- [【扩展】与 ATAM 的关系](#【扩展】与 ATAM 的关系)
- [ATAM · 测试阶段头脑风暴场景（21）（22）](#ATAM · 测试阶段头脑风暴场景（21）（22）)
- [敏感点 / 权衡点 / 风险点 / 非风险点](#敏感点 / 权衡点 / 风险点 / 非风险点)
- 基于场景的架构评估（24）（25）
- [ATAM 与 SAAM · 特定场景与四阶段（27）（28）](#ATAM 与 SAAM · 特定场景与四阶段（27）（28）)
- 九、架构描述语言（ADL）
- 十、特定领域软件架构（DSSA）
-
- 【考生回忆版】领域分析阶段的目标
- [DSSA 参与人员角色（47）（48）](#DSSA 参与人员角色（47）（48）)
- 答案速查表
面向：系统架构设计师 / 软件体系结构 综合题备考。
本篇范围： 六、「4+1」视图与多视图 ... 十、特定领域软件架构（DSSA）。题干、选项、知识点、答案与解析均收于此篇。
姊妹篇（一至五类）： 软件架构-综合题-上册（一至五类·含解析）.md
编排说明： 题干、选项 按题库截图原文收录（标点、空格与截图一致处优先保留）。解析 与 【扩展】 为备考整理补充，非截图原文。
目录
- 六、「4+1」视图与多视图（Kruchten；Hofmeister 四视图；回忆版 45/46）
- 七、软件架构的概念（辨别错误表述；词汇表与约束、语义特征）
- 八、软件架构评估（ATAM/SAAM；质量效用树；ATAM 测试阶段场景类型；敏感点/权衡点/风险点/非风险点；基于场景的描述）
- 九、架构描述语言（ADL）（三要素；常见 ADL；非 ADL：ABSD）
- 十、特定领域软件架构（DSSA）（领域分析/设计/实现；人员角色）
六、「4+1」视图与多视图
单选 · Kruchten「4+1」典型组成
题干： 在体系结构描述中，典型的4+1视图模型包括（ ）。
选项：
A. 逻辑视图、进程视图、开发视图、物理视图和场景
B. 逻辑视图、进程视图、开发视图、部署视图和场景
C. 逻辑视图、进程视图、开发视图、物理视图和类视图
D. 逻辑视图、进程视图、开发视图、物理视图和部署视图
知识点： 软件架构设计 > 「4+1」视图
答案：A
解析：
Philippe Kruchten 的 「4+1」模型用多视图描述架构，便于不同干系人沟通、做一致性检查与质量属性评估。四个核心视图加分场景为：
- 逻辑视图 ：终用户可见的功能与领域结构。
- 进程视图 ：运行行为------并发、同步、性能相关。
- 开发视图 ：开发环境中的静态组织（模块、子系统、层次）。
- 物理视图 ：软件到硬件/网络的映射（节点、部署拓扑）。
- +1 场景 （常用例/用例驱动）：把上述四视图串起来的典型路径。
易错项 B ：Classic 4+1 第四视图中标准名称为 物理视图 ；「部署视图」在部分 UML/教材中与物理含义相近，但本题考点是 Kruchten 固定五项表述 。C、D 将 +1 误作类视图或再叠一层部署视图，均不符合「场景作粘合剂」的定义。
【考生回忆版】Kruchten「4+1」· 物理视图与进程视图（45）（46）
题干： 【考生回忆版】Kruchten提出了「4+1」视图模型。「4+1」视图模型从5个不同的视角来描述软件体系结构。每个视图只关心系统的一个方面，5个视图结合在一起才能反映软件体系结构的全部内容。其中，（45）主要考虑如何把软件映射到硬件上；（46）侧重于系统的运行特性。
（45）
请作答：第 45 题
选项： A. 场景 B. 模块视图 C. 开发视图 D. 物理视图
知识点： 软件架构设计 > 「4+1」视图
答案：D（物理视图）
解析：
物理视图 （UML 中常对应部署视图 ）关注软件到硬件的映射、拓扑与通信等。
（46）
请作答：第 46 题
选项： A. 进程视图 B. 实现视图 C. 逻辑视图 D. 部署视图
知识点： 软件架构设计 > 「4+1」视图
答案：A（进程视图）
解析：
进程视图 关注运行时特性 、并发与非功能需求（性能、可用性等）。开发视图又称模块视图/实现视图，侧重模块组织，勿与进程视图混淆。
【考生回忆版】Hofmeister 四视图
题干： 【考生回忆版】Hofmeister的4视图模型是从概念视图、模块视图、( )，以及代码视图来描述软件体系结构的。
选项： A. 逻辑视图 B. 执行视图 C. 部署视图 D. 用例视图
知识点： 软件架构设计 > 其它（多视图）
答案：B（执行视图）
解析：
Hofmeister 四视图 ：概念视图、模块视图、执行视图、代码视图。
【扩展】多视图描述 SA（节选）
多视图体现关注点分离 ；典型方案除 Kruchten「4+1」、Hofmeister 四视图外，还有 CMU-SEI Views and Beyond （如模块视图、构件-连接子视图、分配视图）等；工业侧尚有 IEEE 1471-2000 、RM-ODP 、UML 、Zachman 等实践。
七、软件架构的概念
单选 · 错误表述
题干： 下列关于软件架构的说法中，（ ）是错误的。
选项：
A. 软件架构的设计需遵循特定的架构风格
B. 软件架构的设计对于控制成本具有决定性作用
C. 软件架构的设计有助于支撑项目的计划和管理工作
D. 软件架构的设计是确保产品按时交付和满足需求的重要因素
知识点： 软件架构设计 > 软件架构的概念
答案：A
解析：
借鉴某种架构风格 有助于做出一致的设计决策，但并不意味着 架构设计必须遵循 某一种「特定」风格；应结合应用场景与需求灵活选择 方案。故 A 表述过于绝对 ，是本题唯一错误项。B、C、D 在该题语境下作为架构对经济、计划管理与交付保障的积极作用表述，通常判为正确。
双空 · 体系结构风格 · 词汇表与语义（31）（32）
题干： 软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。一个体系结构定义了一个词汇表和一组（31）。架构风格反映领域中众多系统所共有的结构和（32）。
（31）
请作答：第 31 题
选项： A. 约束 B. 连接件 C. 拓扑结构 D. 规则
知识点： 软件架构设计 > 软件架构的概念
答案：A（约束）
解析：
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。体系结构风格定义一个系统家族 ，即一个体系结构定义一个词汇表 和一组约束 ；词汇表中含构件和连接件类型，约束 指出如何将这些构件与连接件组合起来。易错项 C。
（32）
请作答：第 32 题
选项： A. 语义特征 B. 功能需求 C. 质量属性 D. 业务规则
知识点： 软件架构设计 > 软件架构的概念
答案：A（语义特征）
解析：
体系结构风格反映领域中众多系统所共有的结构 和语义特性 （选项为「语义特征」），并指导如何把各模块与子系统组织成完整系统；对风格的研究与实践促进设计重用 。易错项 C。
八、软件架构评估
质量效用树 · 关于优先级的不正确说法（选非）
题干： 下面关于效用树中优先级的说法不正确的是（ ）。
选项：
A. 系统安全性场景属于高优先级场景
B. 效用树中的优先级基于相对排名：高（H），中（M）和低（L）
C. 效用树沿着两个维度排列优先顺序：每个场景对系统成功的重要性以及实现该场景（从架构师的角度来看）的难度估计
D. (H, L) 的场景代表该场景对系统成功的重要性较高，该场景的实现难度较低
知识点： 软件架构设计 > 软件架构评估 > 质量效用树
答案：A
解析：
效用树中叶节点场景的优先级通常记为 (重要性, 难度) 一类的二元标注 ，取值为 H / M / L 的相对排序（B 对）。优先序由「对系统成功有多关键」与「做成的难易」综合 得到（C 对）。(H, L) 即高重要、低难度（D 对）。
A 错误原因： 不能把「凡是安全类 场景」一律 等同于「高优先级 」。是否高优先级要看具体场景 在业务上的重要性与实现难度等综合权衡 ；安全很重要，但效用树里仍须逐场景 评定，不能整类拍脑袋定为高优先级。易错项 D：若误记 (H, L) 的行列顺序，会错判。
【扩展】与 ATAM 的关系
架构权衡分析方法（ATAM）等评估中常用质量效用树细化质量属性场景并标注 (H/M/L) 优先级，上述题干即该脉络下的考点。
ATAM · 测试阶段头脑风暴场景（21）（22）
题干： 在ATAM的测试阶段，引入更多利益相关者参与其中，此阶段头脑风暴使用的场景中，（21）代表了架构发展的方式，而（22）的利益相关者是最终用户。
（21）
请作答：第 21 题
选项： A. 用例场景 B. 增长场景 C. 探索场景 D. 环境场景
知识点： 软件架构设计 > 软件架构评估
答案：B（增长场景）
解析：
在 ATAM 测试阶段 的头脑风暴和优先场景 步骤中：增长场景 代表架构发展的方式 ，描述架构如何随时间扩展与演变 。用例场景 的利益相关者是最终用户 ，描述用户与系统的交互。探索性（探索）场景 代表架构中极端的 增长形态。易错项 C。
（22）
请作答：第 22 题
选项： A. 用例场景 B. 增长场景 C. 探索场景 D. 环境场景
知识点： 软件架构设计 > 软件架构评估
答案：A（用例场景）
解析：
见上：（22）明确对应利益相关者为最终用户 → 用例场景 。易错项 C。
敏感点 / 权衡点 / 风险点 / 非风险点
题干： 假设每秒中用户交易请求的数量是10个，处理请求的时间为30毫秒，则"在一秒内完成用户的交易请求"这一要求是可以实现的；在架构评估中，上述描述属于（ ）。
选项： A. 敏感点 B. 权衡点 C. 风险点 D. 非风险点
知识点： 软件架构设计 > 软件架构评估
答案：D（非风险点）
解析：
- 敏感点： 一个或多个构件（和/或构件之间关系）的、能影响系统某个质量属性的特性。
- 权衡点： 影响多个质量属性的特性，即多个质量属性的敏感点。
- 风险点： 架构设计中潜在有问题的架构决策所带来的隐患。
- 非风险点： 不会带来隐患，往往以「×××要求是可以实现（或可以接受）的」这类方式表达。
题干已论证该要求在容量与耗时约束下可实现 ，属非风险点 表述。易错项 A。
（题干「每秒中」与常见「每秒钟」同义，录自截图原文。）
基于场景的架构评估（24）（25）
题干： 在架构评估中，场景是从（24）的角度对与系统交互的描述，一般采用（25）三方面来对场景进行描述。
（24）
请作答：第 24 题
选项： A. 系统设计者 B. 系统开发者 C. 风险承担者 D. 系统测试者
知识点： 软件架构设计 > 软件架构评估 > 基于场景的架构评估
答案：C（风险承担者）
解析：
场景（scenarios）：在进行体系结构评估时，一般首先要精确地得出具体的质量目标，并以此作为判定该体系结构优劣的标准。为得出这些目标而采用的机制叫作场景。场景是从风险承担者的角度对与系统的交互的简短描述。 在体系结构评估中，一般采用刺激（stimulus）、环境（environment）和响应（response）三方面来对场景进行描述。本题（24）对应风险承担者 。易错项 A。
（25）
请作答：第 25 题
选项：
A. 刺激源、制品、响应
B. 刺激、制品、响应
C. 刺激、环境、响应
D. 参与者、制品、环境
知识点： 软件架构设计 > 软件架构评估 > 基于场景的架构评估
答案：C（刺激、环境、响应）
解析：
同上一题解析：刺激、环境、响应 三方面描述场景（与「制品」组合的选项为干扰项）。易错项 B。
ATAM 与 SAAM · 特定场景与四阶段（27）（28）
题干： 架构权衡分析法ATAM和软件架构分析方法SAAM都属于是通过分析软件架构对（27）的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。其中（28）被分为4个主要的活动领域（或阶段），分别是场景和需求收集、架构视图和场景实现、属性模型构造和分析、折中。
（27）
请作答：第 27 题
选项： A. 软件模块 B. 系统功能 C. 特定场景 D. 开发流程
知识点： 软件架构设计 > 软件架构评估
答案：C（特定场景）
解析：
基于场景 的架构评估方法由卡内基·梅隆大学软件工程研究所（SEI）等提出，应用于 ATAM、SAAM ：通过分析架构对特定场景 的支持程度，判断该场景所代表的质量需求是否被满足。易错项 B。
（28）
请作答：第 28 题
选项： A. 架构权衡分析方法 B. 软件架构分析方法 C. 成本效益分析法 D. 层次分析法
知识点： 软件架构设计 > 软件架构评估
答案：A（架构权衡分析方法 / ATAM）
解析：
ATAM 在 SAAM 基础上发展，关注性能、可用性、安全性、可修改性等质量属性，在系统开发前对它们进行评估与折中 。ATAM 划分为题干所述四个活动领域（阶段）。本题（28）问的是具备该四分法的具体方法名，故为 架构权衡分析方法 ，而非泛指的 SAAM。易错项 B。
九、架构描述语言（ADL）
双空 · ADL 三要素与「非 ADL」（33）（34）
题干： ADL架构描述语言是一种基于模型的描述语言，主要用于描述软件系统的构件、关系和行为，其三要素不包括（33），架构描述语言不包括（34）。
（33）
请作答：第 33 题
选项： A. 构件 B. 中间件 C. 连接件 D. 架构配置
知识点： 软件架构设计 > 架构描述语言（ADL）
答案：B（中间件）
解析：
ADL 三要素 ：构件 （计算或数据存储单元）、连接件 （构件间交互的构造块及规则）、架构配置 （构件与连接件连接的拓扑/连接图）。不包括中间件 。易错项易混连接件与配置，本题选 中间件。
（34）
请作答：第 34 题
选项： A. Wright B. UniCon C. ABSD D. ACME
知识点： 软件架构设计 > 架构描述语言（ADL）
答案：C（ABSD）
解析：
ABSD （基于架构的软件开发/设计）是开发方法 ，不是 架构描述语言。Wright、UniCon、ACME 等为常见 ADL 族。易错项 A。
【扩展】常见 ADL 与辨析
| 名称 | 要点（题库口径） |
|---|---|
| C2SADL | 基于组件和消息 |
| Wright | 分布、并发型 |
| ACME | 架构互换 |
| UniCon | 基于组件和连接 |
| Rapide | 基于事件 |
| 其他 | Darwin、MetaH、Aesop、Weaves、SADL、xADL 等 |
小结： ABSD 是基于架构的开发方法，勿与 ADL 混淆。
十、特定领域软件架构（DSSA）
【考生回忆版】领域分析阶段的目标
题干： 【考生回忆版】在DSSA(Domain Specific Software Architecture)中，领域分析阶段的主要目标是获得 ( )。
选项： A. 原型系统 B. 领域对象 C. 领域样本 D. 领域模型
知识点： 软件架构设计 > 特定领域软件架构
答案：D（领域模型）
解析：
DSSA 三活动：领域分析 →得到 领域模型 （描述域内共性需求，即领域需求）；领域设计 →得到 DSSA ；领域实现 →按模型与 DSSA 开发/组织可重用信息。
DSSA 参与人员角色（47）（48）
题干： 参与DSSA（特定领域软件体系结构）的人员可以划分为4种角色，其中，（47）负责控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中；（48）负责控制整个软件设计过程，根据领域模型和现有的系统开发出DSSA，对DSSA的准确性和一致性进行验证，建立领域模型和DSSA之间的联系。
（47）
请作答：第 47 题
选项： A. 领域专家 B. 领域分析人员 C. 领域设计人员 D. 领域实现人员
知识点： 软件架构设计 > 特定领域软件架构
答案：B（领域分析人员）
解析：
四角色主要任务（与题库知识点一致）：
- 领域专家：提供领域中系统的需求规约与实现方面知识；帮助组织规范的、一致的领域字典；帮助选择样本系统作为领域工程依据；复审领域模型、DSSA 等领域工程产品等。
- 领域分析人员 ：控制整个领域分析过程 ；进行知识获取；将知识组织到领域模型 中；根据现有系统、标准规范等验证领域模型的准确性和一致性 ；维护 领域模型。→ 对应题干（47）。
- 领域设计人员 ：控制整个软件设计过程 ；根据领域模型与现有系统开发 DSSA ；验证 DSSA 的准确性与一致性；建立领域模型与 DSSA 之间的联系 。→ 对应题干（48）。
- 领域实现人员：根据领域模型与 DSSA 新开发或再工程提取可重用构件；验证构件；建立 DSSA 与可重用构件间的联系。
综上： 第 47 题选 B ，第 48 题选 C。
（48）
请作答：第 48 题
选项： A. 领域专家 B. 领域分析人员 C. 领域设计人员 D. 领域实现人员
知识点： 软件架构设计 > 特定领域软件架构
答案：C（领域设计人员）
解析：
见上表第 3 条与共用题干（48）；领域设计人员 控制设计全过程、落地 DSSA 并联结语义与模型。易错项 B（易与「领域分析」混）。
答案速查表
| 题号 | 答案 |
|---|---|
| （1）批处理数据传递方式 | B 整体 |
| （2）基于规则的系统第四组件 | D 工作内存 |
| （3）复用策略 | D 机会复用 |
| （4）复用阶段 | D 使用可复用资产 |
| CORBA 屏蔽 ORB 内核、为实现者提供抽象接口 | B 对象适配器 |
| （6）适应需求增加新功能 | B 可扩展性 |
| （7）合法服务 + 阻止非授权 | B 安全性 |
| （8）SQL 注入 / XSS / 传输安全 | C 安全性 |
| （9）对应架构策略 | D 入侵检测 |
| （10）性能衡量指标 | D 事件响应时间 |
| （11）提升性能的策略 | C 增加可用资源 |
| （12）与文档化、复审构成迭代 | B 体系结构设计 |
| （13）暴露风险、早发现设计缺陷 | C 体系结构复审 |
| 单选 · EDA 正确描述 | B 独立、非耦合模块间传递事件消息 |
| 单选 · 图形编辑 / 操作意图驱动处理 | B 隐式调用 |
| （16）Web 服务注册与查找 | A UDDI |
| （17）描述 Web 服务接口与操作 | B WSDL |
| 单选 · 微服务与 SOA 管理方式 | C 微服务去中心化、SOA 集中式 |
| 单选 ·「4+1」视图典型组成 | A 逻辑/进程/开发/物理 + 场景 |
| 单选 · 关于架构的错误说法 | A "必须遵循特定架构风格"（表述过绝） |
| （21）ATAM 头脑风暴：架构发展方式 | B 增长场景 |
| （22）ATAM：利益相关者为最终用户 | A 用例场景 |
| 单选 · 一秒内完成交易需求可达成 | D 非风险点 |
| （24）场景描述视角 | C 风险承担者 |
| （25）场景三方面描述 | C 刺激、环境、响应 |
| （27）ATAM/SAAM 分析对象 | C 特定场景 |
| （28）四阶段：场景收集/视图与场景实现/属性模型/折中 | A 架构权衡分析方法（ATAM） |
| （29）ABSD 描述软件架构 | B 视角与视图 |
| （30）ABSD 描述质量需求 | C 用例与质量场景 |
| （31）体系结构：词汇表与一组 | A 约束 |
| （32）架构风格反映共有结构与 | A 语义特征 |
| （33）ADL 三要素不包括 | B 中间件 |
| （34）「架构描述语言」不包括 | C ABSD |
| （45）「4+1」映射软件到硬件 | D 物理视图 |
| （46）「4+1」系统运行特性 | A 进程视图 |
| （47）DSSA：主导领域分析 | B 领域分析人员 |
| （48）DSSA：主导设计得 DSSA | C 领域设计人员 |
| 【回忆】Hofmeister 四视图第三项 | B 执行视图 |
| 【回忆】DSSA 领域分析阶段目标 | D 领域模型 |
| 单选 · 良好软件复用实践 | B 已验证开源库/框架 |
| 单选 · REST 不正确项 | B 必须用 JSON |
| 单选 · 体系结构需求三方面 | A 质量目标、商业目标、开发人员商业目标 |
| 单选 · 横向重用（跨领域元素） | D |
| 单选 · WSDL 三基本属性 | D 做什么、如何访问、位于何处 |
| 单选 · 中间件角色 | C 连接组件/系统，通信与集成 |
| 【回忆】MVP 不正确项 | C View 直接从 Model 读 |
| 【回忆】XML 错误描述 | B "允许各种各样文档显示类型" |
| 单选 · 效用树优先级（不正确项） | A 不能认定"安全性场景必为高优先级" |