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

来源：exams/2015、2017、2018、2019押题、2019.pdf 第 1.5 节「19 年最终考题（个人回忆）」注：本考卷为个人回忆版，题目表述可能与真实考卷有差异。

1. 如何对质量属性场景建模？画出 Interoperability 和 modifiability 的刺激-响应图¶

质量属性场景建模方法¶

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

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

Interoperability（互操作性）刺激-响应图¶

刺激源: 车辆信息系统 → 刺激: 发送当前位置和其他车辆信息 → 工件: 路况监控系统 → 环境: 系统在运行前已知 → 响应: 信息合并，覆盖 Google 地图上 → 度量: 99.99% 的时间是正确的，并进行广播

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

刺激源: 开发者 → 刺激: 希望修改 UI 界面 → 工件: 代码 → 环境: 设计时 → 响应: 进行修改和单元测试 → 度量: 在 3 小时内完成

参考课件：slides/2026SUG_SysArch2_quality attributes.pdf

2. 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，slides/Lecture 01 - Attributes Driven Design.pdf

3. 4+1 视图介绍（还要画图）¶

Philippe Kruchten 的 "4+1" 视图模型 包含五种视图：

视图	说明	受众
逻辑视图（Logical View）	描述对架构重要的元素及其关系（功能需求）	最终用户
过程视图（Process View）	描述元素间的并发和交互（进程、线程、同步）	系统集成者
开发视图（Development View）	描述软件模块的内部组织联系	程序员/开发团队
物理视图（Physical View）	描述主要过程和组件如何映射到硬件上	系统工程师
+1: 场景/用例视图（Scenarios）	通过用例/场景验证和说明架构设计	所有利益相关者

图解¶

                ┌─────────────────┐
                │    Scenarios    │
                │   （场景/用例）   │
                │   +1 视图       │
                └────────┬────────┘
                         │
        ┌────────────────┼────────────────┐
        │                │                │
        ▼                ▼                ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│  Logical     │ │  Process     │ │ Development  │
│ （逻辑视图）  │ │ （过程视图）   │ │ （开发视图）  │
│              │ │              │ │              │
│ 功能需求      │ │ 并发与交互    │ │ 软件模块组织  │
└──────────────┘ └──────────────┘ └──────────────┘
                         │
                         ▼
                ┌──────────────┐
                │  Physical    │
                │ （物理视图）   │
                │              │
                │ 部署与拓扑    │
                └──────────────┘

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

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

六种通用设计策略：

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

参考课件：slides/Lecture 01 - Attributes Driven Design.pdf，slides/2026SUG_SysArch1_introduction.pdf

5. 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）

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

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

Beyond 部分¶

组件	目的
文档路线图（Document Roadmap）	包含范围和总结、简单摘要，帮助读者导航
视图的文档组织方式	描述本文档中视图是如何组织的
系统概述（System Overview）	从整体上描述架构的简要说明、业务目标（驱动因素）等
视图之间的映射关系	描述不同视图之间的关联映射
系统原理（Rationale）	描述架构设计原理和设计决策的理由
目录/索引/词汇表/首字母缩略词表	帮助快速查找定位

View 部分¶

组件	目的
体系结构风格和视图（Styles and Views）	使用标准化风格描述系统结构
结构视图（Structural Views）	具体描述系统的各个结构维度

参考课件：slides/2026SUG_SysArch1_introduction.pdf（架构文档化）

7. 描述在 ATAM 的每一个过程中有哪些 Stakeholder 和他们的职责¶

ATAM 阶段	Stakeholder（参与者）	职责
阶段 -0：准备和建立团队（Partnership & Preparation）	评估团队领导、关键项目决策者	评估团队领导根据架构设计文档生成评估计划（包括谁参加评估、如何何时何地开展评估、评估报告呈递给谁）
阶段 -1：评估-1（Evaluation-1）	评估团队、项目决策者、首席架构师、项目经理或客户	第一步：评估负责人介绍 ATAM 方法；第二步：项目经理/客户介绍业务驱动因素；第三步：首席架构师介绍体系结构；第四步：评估团队确定架构方法；第五步：生成质量属性效用树（Utility Tree）；第六步：评估团队分析架构方法，识别风险/非风险点、敏感点/权衡点
阶段 -2：评估-2（Evaluation-2）	评估团队、项目决策者、项目涉众	第一步：评估负责人介绍 ATAM 方法和已有成果；第七步：涉众头脑风暴并确定场景优先级（生成涉众优先级场景列表）；第八步：评估团队分析架构方法（类似第六步）；第九步：评估团队展示评估结果并呈递给涉众（风险主题和受威胁的业务驱动因素）
阶段 -3：后续（Follow-up）	评估团队、主要涉众	评估团队制作最终评估报告，发给主要涉众审核通过后，将报告呈递给委托评估的人

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

8. 软件产品线架构如何实现可变性？描述可变性机制的工作方式，和变化点。¶

SPL 可变性实现¶

在 SPL（软件产品线）中： 1. 核心资产（Core Assets） 通过提供变体点（Variation Points） 来支持可变功能 2. SPL 具有 PLA（Product Line Architecture，产品线架构），为变化提供架构基础 3. PLA 使用特定的架构变体机制来实现可变功能

变体点与绑定时间（变化点）¶

软件实体变化发生在不同的绑定时间：

绑定阶段	工作方式
创建编码工作区时	从核心资产库中选择适合特定产品的代码
构建目标代码时	通过编译选项、条件编译选择不同实现
创建应用程序时	通过配置文件、装配脚本组合不同模块
应用程序启动时	读取配置文件动态加载不同插件或服务
应用程序运行时	通过依赖注入、策略模式等动态切换行为

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

9. Explain the context, benefits and limitations of Broker Architecture Pattern.¶

上下文（Context）¶

多个同步或异步交互的远程对象组成的系统。Broker 模式定义运行时组件 broker，协调多个客户机和服务器之间的通讯。

优点（Benefits）¶

提高了 Client 和 Server 之间的交互性
提高可伸缩性和可扩展性
解决了单体应用的性能瓶颈
大规模集群的性能提高

局限性（Limitations）¶

代理增加了前期复杂度
可能成为通信的屏障（瓶颈）
可能成为攻击的目标（单点故障）
难以测试
单点性能下降

注：SOA 延续了 Broker 的思想。Broker 模式中查找服务和使用服务都要通过 Broker，而 SOA 只在查找时通过 Registry，分散了 Broker 的职责，降低了单点风险。

参考课件：slides/软件架构模式_update_2.pdf（Broker 模式）

10. 微服务和 SOA 的区别、相同点¶

相同点¶

微服务和 SOA 都是分布式架构
微服务是 SOA 的一种扩展
都包含了服务契约、服务封装、服务重用、服务组合、服务自治和服务无状态等基本特点

区别¶

维度	SOA	MSA（微服务架构）
服务间通信	智能管道（如 ESB），重量级协议（如 SOAP/WS-*）	哑管道（如消息代理），轻量级协议（如 REST/gRPC），或点对点通信
数据管理	全局数据模型并共享数据库	每个服务有自己的数据模型和独立数据库
典型服务规模	较大的单体应用	较小的服务
中间件	使用 ESB（企业服务总线）	去掉了 ESB，采用轻量级通信机制（HTTP、REST）
DevOps	传统部署方式	结合 DevOps 实现自动化部署和监控预警
额外组件	—	引入 API 网关（屏蔽访问各项服务的复杂性）、熔断器（避免级联故障）

参考课件：slides/Microservices Patterns.pdf，slides/软件架构模式_update_2.pdf（SOA）

11. 一个买票系统的设计题，不同的角色有不同的打折方案，用策略模式设计，最后画图，还要说明策略模式的使用场景。¶

设计说明¶

使用策略模式，将打折方案（DiscountStrategy） 作为策略进行封装，不同角色的用户使用不同的打折策略。

策略模式的使用场景¶

许多相关的类仅仅是行为有异时
需要使用一个算法的不同变体时
算法使用客户端不应该知道的数据时（避免暴露复杂的、与算法相关的数据结构）
一个类定义了多种行为，并且这些行为以多个条件语句的形式出现时（替代 if-else/switch）

类图¶

┌───────────────────┐
│  <<interface>>     │
│  DiscountStrategy  │
├───────────────────┤
│ + discount(price:  │
│   double): double  │
└─────────┬──────────┘
          │
    ┌─────┼──────────────┐
    │     │              │
    ▼     ▼              ▼
┌────────┐ ┌────────┐ ┌────────┐
│NoDiscount││Student │ │VIP     │
│(无折扣)│ │Discount│ │Discount│
├────────┤ │(学生折扣)│ │(VIP折扣)│
│0% off  │ │50% off │ │30% off │
└────────┘ └────────┘ └────────┘

    ┌────────────────────────┐
    │    TicketContext        │
    │    （售票上下文）         │
    ├────────────────────────┤
    │ - strategy:             │
    │   DiscountStrategy      │
    │ - ticketPrice: double   │
    ├────────────────────────┤
    │ + getFinalPrice():      │
    │   double                │
    │ + setStrategy(s): void  │
    └───────────┬────────────┘
                │
    ┌───────────┼────────────┐
    │           │            │
    ▼           ▼            ▼
┌────────┐ ┌────────┐ ┌────────┐
│Normal  │ │Student │ │VIP     │
│User    │ │User    │ │User    │
│(普通用户)│ │(学生)  │ │(VIP)   │
└────────┘ └────────┘ └────────┘

代码示例¶

// 策略接口
interface DiscountStrategy {
    double discount(double price);
}

// 具体策略
class NoDiscount implements DiscountStrategy {
    public double discount(double price) { return price; }
}

class StudentDiscount implements DiscountStrategy {
    public double discount(double price) { return price * 0.5; }
}

class VIPDiscount implements DiscountStrategy {
    public double discount(double price) { return price * 0.7; }
}

// 上下文
class TicketContext {
    private DiscountStrategy strategy;
    private double ticketPrice;

    public TicketContext(double price) {
        this.ticketPrice = price;
    }

    public double getFinalPrice() {
        return strategy.discount(ticketPrice);
    }

    public void setStrategy(DiscountStrategy s) {
        this.strategy = s;
    }
}

参考课件：slides/02策略模式.pdf（策略模式）

12. 设计题，和 15 年的设计题一模一样¶

注：回忆者未说明具体是 15 年哪道设计题。2015 年考卷中无独立设计题，可能指代 2015 年考卷中与设计模式相关的题目（如策略模式相关）。参考 2015 年考卷解答。

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