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

来源：exams/2015、2017、2018、2019押题、2019.pdf 第 1.3 节「18 年考题（梁神回忆）」注：本考卷为学长回忆版，题目表述可能与真实考卷有差异。

1. 软件架构的关注点有哪些？利益相关方有哪些？¶

软件架构的关注点（Concerns）¶

利益相关者（Stakeholders addressed）：架构需要满足哪些利益相关者的关注
解决的问题（Concerns addressed）：架构需要解决哪些核心问题
语言与建模技巧（Language, modeling techniques）：使用什么语言和建模技术来描述架构
决策与模式（Tactics, Patterns）：架构设计中使用哪些战术和模式

利益相关方（Stakeholders）¶

利益相关方	角色
顾客（Customer）	系统的购买者或委托方
用户（User）	系统的实际使用者
架构师（Architect）	负责架构设计
需求工程师（Requirements Engineer）	负责需求分析
设计师（Designer）	负责详细设计
实施者（Implementer）	负责编码实现
测试师/集成师（Tester/Integrator）	负责测试和集成
维护者（Maintainer）	负责系统维护
产品经理（Product Manager）	负责产品方向和商业价值
质量保证人员（Quality Assurance People）	负责质量把关

参考课件：slides/2026SUG_SysArch1_introduction.pdf（软件架构介绍）

2. Software requirements, quality attributes, ASRs 的区别和联系¶

定义与关系¶

软件需求（Software Requirements）
├── 功能性需求（Functional Requirements）
│   └── 系统必须做什么，说明系统如何为利益相关者提供价值
└── 非功能性需求（Non-Functional Requirements / Quality Requirements）
    ├── 技术限制（Technical Constraints）
    ├── 商业限制（Business Constraints）
    └── 质量属性（Quality Attributes）
        └── 由业务目标决定，在功能需求基础上整个系统的合乎需求的特性
            └── ASR（Architecturally Significant Requirements）
                └── 对架构产生深远影响的质量属性需求

区别与联系¶

概念	定义	关系
软件需求（Software Requirements）	系统的全部需求，包括功能性需求和非功能性需求	最广泛的概念
质量属性（Quality Attributes, QA）	高于系统功能的系统理想特征（如性能、可用性、安全性）	是非功能性需求的一种反应；非功能性需求/体系结构需求是质量属性的替代术语
ASR（架构攸关需求）	将对架构产生深远影响的需求	QA 要求越困难、越重要，就越有可能成为 ASR。如果需求影响关键架构设计决策的制定，根据定义它就是一个 ASR

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

3. What is the nature of component-connector style? 以 MVC pattern 举例¶

组件-连接器（C&C）风格的本质¶

C&C 风格关注的是运行时行为，描述系统在运行时如何由组件（Components） 和连接器（Connectors） 构成：

组件（Component）：主要的处理单元和数据存储单元，是计算的主体
连接器（Connector）：组件之间交互的路径和机制，如方法调用、消息传递、管道等
C&C 风格描述运行时结构，是动态的、行为的视图

MVC 模式作为 C&C 风格的实例¶

MVC（Model-View-Controller）是一个典型的 C&C 风格模式：

┌────────────┐     用户操作       ┌────────────┐
│   View     │──────────────────▶│ Controller │
│  （视图）   │◀──────────────────│ （控制器）  │
│            │    更新显示        │            │
└────────────┘                   └─────┬──────┘
       │                               │
       │ 查询状态                       │ 修改状态
       │                               │
       ▼                               ▼
┌────────────┐                   ┌────────────┐
│   Model    │◀──────────────────│   Model    │
│  （模型）   │                   │  （模型）   │
└────────────┘                   └────────────┘

C&C 特性分析： - 组件：Model、View、Controller 是三个运行时组件 - 连接器：View→Controller 的方法调用（用户事件传递），Controller→Model 的状态修改，Model→View 的更新通知（观察者模式） - 分工明确：每个组件承担特定的运行时职责

参考课件：slides/2026SUG_SysArch1_introduction.pdf（C&C 风格），slides/软件架构模式_update_2.pdf（MVC 模式）

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

建模方法¶

质量属性场景由六个部分构成：刺激源、刺激、工件、环境、响应、响应度量。

Availability（可用性）¶

刺激源: 监视器(Monitor) → 刺激: 服务器无响应 → 工件: 监视器进程 → 环境: 正常操作 → 响应: 通知操作者继续操作 → 度量: 没有停机时间

Modifiability（可修改性）¶

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

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

5. Risks, Sensitivity Points, Trade-off Points 是什么？各举一个例子¶

这三个概念来自 ATAM（架构权衡分析方法），用于架构评估：

概念	定义	示例
风险（Risks）	可能对所需质量属性产生负面影响的架构决策	使用分层模式可能带来性能损耗，因为每一层调用都会增加额外的开销
敏感点（Sensitivity Points）	特定质量属性对其敏感的架构决策点——该点的微小变化会导致质量属性的显著变化	在对性能敏感的系统中，决定在某处使用缓存中间件——缓存命中率的微小变化会显著影响系统响应时间
权衡点（Trade-off Points）	影响多个质量属性的架构决策，改善一个属性可能损害另一个	使用分层模式可能会带来性能损耗（性能↓），但是也会解耦增加系统的可修改性（可修改性↑）——需要在性能和可修改性之间权衡

三者关系¶

架构决策 ──▶ 可能造成 ──▶ 风险（Risk）
    │
    ├── 对某个QA敏感 ──▶ 敏感点（Sensitivity Point）
    │
    └── 影响多个QA ──▶ 权衡点（Trade-off Point）

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

6. 连线，并对每种 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. Layered pattern 和 Multi-tier pattern 的区别¶

维度	Layered Pattern（分层模式）	Multi-tier Pattern（多层模式）
所属风格类别	Module Style（模块风格）	Allocation Style（分配风格）
关注层面	关注代码/模块的组织	关注物理部署的组织
层次关系	将任务拆解成一个个处于特定抽象级别的子层次，每层为下一层提供更高层次的服务	层是逻辑的组合，没有强依赖关系
核心思想	关注点分离（Separation of Concerns），严格的分层使用关系	逻辑分层，不同的部署环境中分层不同但软件完成的内容一致
典型应用	OSI 网络模型、Java EE 分层架构	典型 Web 应用的三层部署：表示层（Web Server）、业务层（App Server）、数据层（DB Server）

关键区别：Layered Pattern 是模块视图下的代码组织（逻辑分层），Multi-tier Pattern 是分配视图下的部署架构（物理分层）。

参考课件：slides/软件架构模式_update_2.pdf（分层模式），slides/2026SUG_SysArch1_introduction.pdf

8. 描述 ADD 过程¶

ADD（Attribute-Driven Design，属性驱动设计） 是一种迭代的软件架构设计方法，通过以下步骤进行：

步骤	描述
Step 1: 确认输入	确定有足够的需求信息（ASR、约束等）可以开始设计
Step 2: 选择分解元素	选择要分解的系统要素（从整个系统开始，逐级细化）
Step 3: 确定 ASR	确定所选元素的架构攸关需求
Step 4: 选择设计决策	① 找出设计问题 → ② 列出子关注点和替代模式/决策 → ③ 从清单中选择模式/决策 → ④ 确定模式/决策与 ASR 之间的关系 → ⑤ 记录初步的架构视图 → ⑥ 评估并解决不一致的问题
Step 5: 实例化与分配	实例化架构元素并分配职责
Step 6: 定义接口	为实例化的元素定义接口
Step 7: 验证与细化	验证和细化需求，使它们成为实例化元素的约束
Step 8: 迭代	重复步骤 2-7，直到满足所有的 ASR

ADD 的核心思想：通过迭代-增量方式逐步精化架构设计，每次迭代针对一组 ASR 进行设计决策，每次迭代完成后评估当前设计是否满足需求。

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

9. 为什么软件架构需要用不同的视图描述？举出四种视图的例子¶

为什么需要不同视图¶

不同视图支持不同的目标和用户，突出不同的系统元素和关系
不同视图将不同质量属性暴露出不同的程度
单一视图无法描述软件架构的全部内容
分离关注点，管理架构复杂性

四种视图及其目的¶

视图	目的	受众
逻辑视图（Logical View）	描述对架构重要的元素及其关系（功能需求）	最终用户，业务分析师
过程视图（Process View）	描述元素的并发和交互，包括进程、同步等	系统集成者
开发视图（Development View）	描述软件模块的内部组织联系	开发团队
物理视图（Physical View）	描述主要过程和组件如何映射到硬件上	系统工程师

参考课件：slides/2026SUG_SysArch1_introduction.pdf（架构视图）

10. 软件产品线架构如何实现可变性？描述可变性机制的工作方式¶

SPL 可变性实现方式¶

在 SPL（Software Product Line，软件产品线） 中：

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

可变性机制的工作方式¶

软件实体的变化可以在以下时机发生（Binding Time，绑定时间）：

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

变体点 + 绑定时间 = SPL 的可变性管理核心机制。

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

11. 设计一个飞行模拟软件，要求能模拟多种飞机的特性。为了在将来支持更多飞机种类，要求使用策略模式。画出架构图和类图¶

设计说明¶

使用策略模式，将飞机的飞行行为（FlyBehavior） 作为策略进行封装，使得不同飞机的飞行特性可以独立变化，并且可以在运行时动态修改。

类图¶

┌─────────────────┐          ┌──────────────────┐
│   <<interface>>  │          │  <<interface>>    │
│   FlyBehavior    │          │  DisplayBehavior   │
├─────────────────┤          ├──────────────────┤
│ + fly(): void    │          │ + display(): void  │
└────────┬────────┘          └────────┬─────────┘
         │                            │
    ┌────┴────────────────┐    ┌──────┴──────────────┐
    │                     │    │                      │
    ▼                     ▼    ▼                      ▼
┌────────────┐   ┌────────────┐  ┌────────────┐  ┌────────────┐
│ JetFly     │   │ PropellerFly│  │ FighterUI  │  │ CivilianUI │
│（喷气飞行）│   │（螺旋桨飞行）│  │（战斗机显示）│  │（民航显示）│
├────────────┤   ├────────────┤  ├────────────┤  ├────────────┤
│+ fly():void│   │+ fly():void│  │+display(): │  │+display(): │
│ 超音速      │   │ 亚音速      │  │  void      │  │  void      │
│ 大仰角爬升  │   │ 水平飞行     │  └────────────┘  └────────────┘
└────────────┘   └────────────┘

         ┌──────────────────────────────┐
         │        Aircraft               │
         │       （飞机 - 上下文）         │
         ├──────────────────────────────┤
         │ - flyBehavior: FlyBehavior   │
         │ - displayBehavior: Display   │
         │   Behavior                   │
         ├──────────────────────────────┤
         │ + performFly(): void         │
         │ + performDisplay(): void     │
         │ + setFlyBehavior(fb): void   │
         │ + setDisplayBehavior(db):    │
         │   void                       │
         └──────────────┬───────────────┘
                        │
        ┌───────────────┼───────────────┐
        │               │               │
        ▼               ▼               ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ FighterJet   │ │ CivilianPlane│ │ Helicopter   │
│ （战斗机）    │ │ （民航飞机）   │ │ （直升机）    │
├──────────────┤ ├──────────────┤ ├──────────────┤
│ 初始化时设置   │ │ 初始化时设置   │ │ 初始化时设置   │
│ JetFly +     │ │ PropellerFly │ │ PropellerFly │
│ FighterUI    │ │ + CivilianUI │ │ + SpecialUI  │
└──────────────┘ └──────────────┘ └──────────────┘

架构图（组件-连接器视图）¶

┌──────────────┐     委托飞行      ┌──────────────┐
│   Aircraft   │─────────────────▶│  FlyBehavior │
│  （上下文）   │                   │  （策略接口）  │
│              │◀─────────────────│              │
│  performFly()│   策略模式委托     │              │
└──────────────┘                   └──────────────┘
        │                                  △
        │ 继承                             │ 实现
        ▼                                  │
┌──────────────┐              ┌────────────┼────────────┐
│  FighterJet  │              │            │            │
│  CivilianPl  │              ▼            ▼            ▼
│  Helicopter  │        ┌──────────┐ ┌──────────┐ ┌──────────┐
└──────────────┘        │ JetFly   │ │Propeller │ │HoverFly  │
                        │          │ │Fly       │ │          │
                        └──────────┘ └──────────┘ └──────────┘

代码示例¶

// 策略接口
interface FlyBehavior {
    void fly();
}

// 具体策略
class JetFly implements FlyBehavior {
    public void fly() {
        System.out.println("超音速飞行，大仰角爬升");
    }
}

class PropellerFly implements FlyBehavior {
    public void fly() {
        System.out.println("螺旋桨推进，亚音速巡航");
    }
}

// 上下文
abstract class Aircraft {
    protected FlyBehavior flyBehavior;

    public void performFly() {
        flyBehavior.fly();
    }

    public void setFlyBehavior(FlyBehavior fb) {
        this.flyBehavior = fb;
    }
}

// 具体飞机
class FighterJet extends Aircraft {
    public FighterJet() {
        flyBehavior = new JetFly();
    }
}

class CivilianPlane extends Aircraft {
    public CivilianPlane() {
        flyBehavior = new PropellerFly();
    }
}

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

12. 太复杂，忘了¶

（该题回忆缺失，无法提供解答）

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