2017 年软件系统设计考题解答¶

来源：exams/2015、2017、2018、2019押题、2019.pdf 第 1.2 节「17年考题」

1. Briefly describe the general activities in a software architecture process, and the major inputs and outputs at each activity.¶

软件架构过程的一般活动及其输入输出：

活动	主要输入	主要输出
1. 识别架构攸关需求（Identify ASRs）	需求文档、业务目标、涉众需求	ASR 列表、优先级排序的需求
2. 架构设计（Architecture Design）	ASR 列表、约束条件、技术环境	架构设计方案、设计决策记录
3. 架构文档化（Documentation）	设计决策	架构文档包（多视图文档）
4. 架构评估（Architecture Evaluation）	架构文档、ASR	评估报告（风险、敏感点、权衡点）
5. 架构实现与维护（Implementation & Maintenance）	最终架构设计	可运行系统、维护记录

核心方法包括 ADD（Attribute-Driven Design，属性驱动设计），通过迭代-增量方式逐步精化架构设计，每次迭代针对一组 ASR 进行设计决策。

参考课件：slides/Lecture 01 - Attributes Driven Design.pdf（ADD 方法），slides/Lecture 02 - Attributes Driven Design - Case Study.pdf

2. What distinguishes an architecture for a software product line from an architecture for a single product?¶

产品线的目的：实现高可重用性、高可修改性。
经济性：产品线之所以有效是因为通过重用可以充分利用产品的共性，从而产生经济性（规模效应）。
可变性管理：在产品线架构中有一组明确允许发生的变化（variation points），识别允许的变化是架构责任的一部分，同时还需要提供内建机制来实现它们。而常规的单一产品架构只要满足单个系统的行为和质量目标即可，几乎任何实例都是可以的。
产品线架构围绕核心资产（core assets） 组织，通过变体点（variation points）支持一族产品。

参考课件：slides/2026SUG_SysArch1_introduction.pdf（SPL 介绍）

3. What are generic design strategies applied in designing software? Give a concise working example with software architecture for each strategy.¶

六种通用设计策略：

策略	说明	示例
1. 分解（Decomposition）	针对某一个系统关注点分解后处理	将整个系统分解为前端、后端、数据库等模块；或将某个模块分解为子模块
2. 抽象（Abstraction）	使用抽象让设计师关注本身结构而不关心实现	将系统抽象为组件和连接件，或将系统抽象为模块
3. 逐步求精/分而治之（Stepwise Refinement）	将每个模块分别处理，逐步细化	先定义高层接口，再逐步实现每个模块的具体逻辑
4. 生成与测试（Generate and Test）	将一个特定的设计看作是一个假设，根据测试路径生成测试用例	设计评审后，针对设计中的关键路径生成测试方案来验证
5. 迭代-增量细化（Iterative Refinement）	使用迭代的方法，每次迭代完善一部分	ADD 方法多次迭代直到满足所有 ASR
6. 复用元素（Reuse of Elements）	重用设计过程中出现的可复用元素	重用现有架构（如 MVC、分层架构等成熟的架构模式）

参考课件：slides/Lecture 01 - Attributes Driven Design.pdf（通用设计策略），slides/2026SUG_SysArch1_introduction.pdf

4. How to model quality attribute scenarios? Graphically model two quality attributes in "stimulus-response" format: availability and modifiability.¶

质量属性场景建模方法¶

质量属性场景由六个部分组成：

部分	说明
刺激源（Source of Stimulus）	产生刺激的实体（人、系统或任何其他触发）
刺激（Stimulus）	到达系统时需要考虑的条件
环境（Environment）	发生刺激时系统的状况
工件（Artifact）	完成需求的整个系统或系统的一部分
响应（Response）	刺激到来后工件开展的行为
响应度量（Response Measure）	对响应的可量化测量

Availability（可用性）刺激-响应图¶

┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│ Source of    │    │              │    │              │    │              │    │              │    │ Response     │
│ Stimulus     │───▶│  Stimulus    │───▶│  Artifact    │───▶│  Environment │───▶│  Response    │───▶│  Measure     │
├──────────────┤    ├──────────────┤    ├──────────────┤    ├──────────────┤    ├──────────────┤    ├──────────────┤
│ 监视器        │    │ 服务器无响应  │    │ 监视器进程    │    │ 正常操作      │    │ 通知操作者    │    │ 没有停机时间  │
│ (Monitor)    │    │              │    │              │    │              │    │ 继续操作      │    │              │
└──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘

Modifiability（可修改性）刺激-响应图¶

┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│ Source of    │    │              │    │              │    │              │    │              │    │ Response     │
│ Stimulus     │───▶│  Stimulus    │───▶│  Artifact    │───▶│  Environment │───▶│  Response    │───▶│  Measure     │
├──────────────┤    ├──────────────┤    ├──────────────┤    ├──────────────┤    ├──────────────┤    ├──────────────┤
│ 开发者        │    │ 希望修改     │    │ 代码/UI 组件 │    │ 设计时        │    │ 进行修改      │    │ 在 3 小时内   │
│              │    │ UI 界面      │    │              │    │              │    │ 和单元测试    │    │ 完成          │
└──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘

参考课件：slides/2026SUG_SysArch2_quality attributes.pdf（质量属性建模）

5. Describe outputs generated from each phase of ATAM process.¶

ATAM（Architecture Tradeoff Analysis Method）各阶段输出：

阶段	输出	参与者
阶段 -0：准备和建立团队	评估计划（人员、时间、地点）	评估团队领导、项目决策者
阶段 -1：评估（Evaluation）	架构方法描述、质量属性效用树（Utility Tree）、初步风险/非风险列表、敏感点、权衡点	评估团队、项目决策者、架构师
阶段 -2：评估（Evaluation）	对架构方法更详细的分析结果、优先级排序的场景、更详细的风险/非风险列表	评估团队、利益相关者
阶段 -3：后续（Follow-up）	最终评估报告、改进建议、行动计划	评估团队、项目团队

参考课件：slides/Lecture 01 - Attributes Driven Design.pdf（ATAM），slides/Lecture 02 - Attributes Driven Design - Case Study.pdf

6. Map, and list four views of each category of style.¶

将每个架构风格类别映射到视图类型：

架构风格类别	适合的视图类型	四种具体样式/视图
Module Style（模块风格）	模块视图	分解（Decomposition）、使用（Uses）、分层（Layered）、类/泛化（Generalization）
Component-Connector Style（组件-连接器风格）	C&C 视图	客户端-服务器（Client-Server）、管道-过滤器（Pipe-Filter）、发布-订阅（Publish-Subscribe）、对等（Peer-to-Peer）
Allocation Style（分配风格）	分配视图	部署（Deployment）、安装（Install）、工作分配（Work Assignment）、实现（Implementation）

参考课件：slides/2026SUG_SysArch1_introduction.pdf（架构风格与视图分类，sa07 p.9）

7. What are ASR? List four sources and methods for extracting and identifying ASRs.¶

ASR 定义¶

ASR（Architecturally Significant Requirements，架构攸关需求） 是对软件体系结构产生深远影响的需求。如果需求影响关键架构设计决策的制定，那么根据定义，它就是 ASR。

四种提取和识别 ASR 的来源和方法¶

来源	方法
1. 从需求文档中收集	使用 MoSCoW 方法（Must/Should/Could/Won't）和用户故事（User Stories），识别对架构有重大影响的需求
2. 通过采访涉众来收集	组织质量属性工作坊（QAW，Quality Attribute Workshop），让利益相关者表达对质量属性的关注
3. 通过了解业务目标来收集	与业务分析人员和管理层沟通，提取影响架构的业务驱动因素和高层目标
4. 通过质量属性效用树（Utility Tree）来管理 ASR	通过场景量化描述需求后，逐渐对质量属性进行分解细化，直到包含可量化的指标（叶节点）为止

参考课件：slides/2026SUG_SysArch2_quality attributes.pdf（ASR），slides/Lecture 01 - Attributes Driven Design.pdf（Utility Tree）

8. Please name at least three Object-Oriented principles, and explain how they are applied in Strategy pattern?¶

至少三个面向对象原则¶

单一职责原则（Single Responsibility Principle, SRP）
开闭原则（Open-Closed Principle, OCP）
里氏代换原则（Liskov Substitution Principle, LSP）
合成复用原则（Composite Reuse Principle, CRP）

在策略模式中的应用¶

1. 单一职责原则（SRP）¶

原则：一个类应该只包含单一的职责，仅有一个引起它变化的原因
在策略模式中的体现：每个具体策略类（ConcreteStrategy）只负责封装一种算法或行为，职责单一。例如在 Duck 示例中，FlyWithWings 类只负责"用翅膀飞行"的行为，FlyNoWay 类只负责"不会飞"的行为

2. 开闭原则（OCP）¶

原则：软件实体应当对扩展开放，对修改关闭
在策略模式中的体现：可以通过添加新的具体策略类来扩展系统行为，无需修改 Context（上下文）类和已有的策略类。例如可以新增 FlyRocketPowered 类来支持火箭动力飞行，而无需修改 Duck 类或其他飞行类

3. 里氏代换原则（LSP）¶

原则：所有引用基类的地方必须能透明地使用其子类的对象
在策略模式中的体现：Context（上下文）通过 Strategy（策略接口）来引用具体策略，所有具体策略类都实现了 Strategy 接口，可以互相替换。例如 Duck 类持有 FlyBehavior 接口类型的引用，运行时可以替换为任何 FlyBehavior 的子类

4. 合成复用原则（CRP）¶

原则：尽量使用对象组合（composition），而不是继承来达到复用的目的
在策略模式中的体现：策略模式的核心就是"优先使用组合而非继承"。Duck 类通过组合方式持有 FlyBehavior 和 QuackBehavior 对象（HAS-A 关系），而不是通过继承来获取飞行和叫唤行为

参考课件：slides/01面向对象设计原则.pdf（OO 设计原则），slides/02策略模式.pdf（策略模式）

9. What should be included in a typical software architecture documentation package? Briefly describe each component and its purpose.¶

一个典型的软件架构文档包应包含 View（视图） 和 Beyond View（视图之外） 两部分。

Beyond 部分（视图之外的文档）¶

组件	目的
1. 文档路线图（Document Roadmap）	包含范围和总结、简单摘要，帮助读者了解文档结构和导航方式
2. 视图的文档组织方式（How Views Are Documented）	描述本文档中视图是如何组织的，使用什么模板或格式
3. 系统概述（System Overview）	从整体上描述当前架构的简要说明、业务目标（驱动因素）、关键约束等
4. 视图之间的映射关系（Mapping Between Views）	描述不同视图之间的关联，例如逻辑视图中的模块如何在物理视图中部署
5. 系统原理（Rationale）	从整体上描述当前架构的设计原理，解释为什么做出特定的设计决策
6. 目录/索引/词汇表/首字母缩略词表	帮助读者快速查找和定位信息

View 部分（视图）¶

组件	目的
体系结构风格和视图（Styles and Views）	使用标准化风格（如模块风格、C&C 风格、分配风格）描述系统的结构，每种风格下包含多个视图
结构视图（Structural Views）	具体描述系统的各个结构维度，如逻辑视图、过程视图、开发视图、物理视图等

参考课件：slides/2026SUG_SysArch1_introduction.pdf（架构文档化），slides/Lecture 01 - Attributes Driven Design.pdf

10. Describe 4+1 view¶

Philippe Kruchten 的 "4+1" 视图模型将软件架构从五个视角（五种视图）来描述：

视图	说明	关注点
1. 逻辑视图（Logical View）	描述对架构而言重要的元素及其关系，主要关注功能需求	最终用户；系统功能和抽象
2. 过程视图（Process View）	描述元素之间的并发和交互，包括进程、线程、同步机制	系统集成者；性能、可伸缩性、吞吐量
3. 开发视图（Development View）	描述软件模块的内部组织联系（如配置管理中的目录结构、包组织）	程序员和开发团队；软件组织和管理
4. 物理视图（Physical View）	描述主要过程和组件如何映射到硬件上，展示物理拓扑	系统工程师；部署、通信
+1. 场景/用例视图（Scenarios）	捕获架构需求，通过一组用例或场景来验证和说明架构设计	所有利益相关者；系统的可用性和一致性

图示¶

                     ┌──────────────┐
                     │  Scenarios   │
                     │  （场景/用例） │
                     └──────┬───────┘
                            │
        ┌───────────────────┼───────────────────┐
        │                   │                   │
        ▼                   ▼                   ▼
┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│   Logical    │    │   Process    │    │ Development  │
│  （逻辑视图）  │    │  （过程视图）  │    │ （开发视图）   │
└──────────────┘    └──────────────┘    └──────────────┘
                            │
                            ▼
                   ┌──────────────┐
                   │   Physical   │
                   │  （物理视图）  │
                   └──────────────┘

参考课件：slides/2026SUG_SysArch1_introduction.pdf（4+1 视图）

11. 软件设计的三个变化维度，每个维度的变化点。不同的绑定时间（Differing Binding Time）如何影响可修改性和可测试性。¶

三个变化维度¶

软件设计的三个变化维度（Variation：forms of variation × software entity varied × binding time）：

变化维度	变化点
1. 面向对象（OOP）	强调重用性、灵活性和扩展性。通过继承、多态等机制实现变化
2. 面向切面（AOP）	满足横切关注点的扩展需求，可以在程序中自由地扩展功能而不修改核心业务代码
3. 面向服务（SOA）	系统发布功能的一种方式，基于这种方式下不同的系统之间可以有效沟通、协作

Binding Time（绑定时间）对可修改性和可测试性的影响¶

不同的绑定时间是指在软件生命周期的哪个阶段确定变化：

绑定时间	可修改性	可测试性
设计时（Design Time）	高 — 在设计阶段可以自由修改	高 — 可以独立测试设计
开发时（Development Time）	较高 — 编码阶段仍可灵活调整	高 — 可以编写单元测试
测试时（Test Time）	中等 — 发现缺陷后进行修改	在测试中 — 正在验证
发布时（Deployment Time）	较低 — 发布配置决定了行为	较低 — 已部署，难以单独测试
运行时（Runtime）	最低 — 系统在运行中，修改受限	最低 — 难以进行完整的测试覆盖

总体趋势：从设计时→开发时→测试时→发布时→运行时，可修改性逐渐降低，可测试性也逐渐降低。

越早绑定（设计时/开发时），灵活性越高，但也可能引入更多的不确定性；越晚绑定（运行时），系统越固定，但稳定性和可预测性更高。

参考课件：slides/2026SUG_SysArch1_introduction.pdf（变化维度），slides/Lecture 01 - Attributes Driven Design.pdf

综合参考：exams/软件系统设计-复习-EagleBear.pdf（综合复习资料）