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

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

1. Where do software architecture come from? List five possible sources of software architecture.¶

软件架构的来源可分为三大类：

三种需求： 1. NFRs（Non-Functional Requirements，非功能需求）：一般包括约束和质量属性 2. ASRs（Architecturally Significant Requirements，架构攸关需求）：对架构有重大影响的需求 3. 质量需求（Quality Requirements）：在功能需求的基础上需要满足的特征

业务面： 4. 涉众和组织（Stakeholders & Organisations）：系统的利益相关者和开发组织 5. 业务目标（Business Goals）：组织的商业目标

技术面： 6. 技术环境（Technical Environments）：可用的技术栈和环境 7. 商业与技术决策组合：不局限于需求，可能是商业和技术决定的集合

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

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

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

参考课件：slides/2026SUG_SysArch1_introduction.pdf（软件产品线）

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

质量属性场景建模方法¶

质量属性场景（Quality Attribute Scenario）由六部分组成：

部分	说明
刺激源（Source of Stimulus）	产生刺激的实体（人、系统或任何其他触发）
刺激（Stimulus）	到达系统时需要考虑的条件
环境（Environment）	发生刺激时系统的状况（正常运行、过载、攻击中、网络故障等）
工件（Artifact）	完成需求的整个系统或系统的一部分
响应（Response）	刺激到来后工件开展的行为
响应度量（Response Measure）	对响应的可量化测量，以便测试需求

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

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

Performance（性能）刺激-响应图¶

┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│ Source of    │    │              │    │              │    │              │    │              │    │ Response     │
│ Stimulus     │───▶│  Stimulus    │───▶│  Artifact    │───▶│  Environment │───▶│  Response    │───▶│  Measure     │
├──────────────┤    ├──────────────┤    ├──────────────┤    ├──────────────┤    ├──────────────┤    ├──────────────┤
│ 用户         │    │ 发起事务      │    │ 系统         │    │ 正常操作      │    │ 事务被处理    │    │ 平均延迟      │
│              │    │              │    │              │    │              │    │              │    │ 不超过 2 秒   │
└──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘

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

4. Describe relationships between architecture patterns and tactics. List four tactics names and describe their usage.¶

架构模式与战术（决策）的关系¶

战术（决策）比模式更简单，仅有单一的结构或机制来应对单一的架构驱动。
战术是构成架构模式的重要组成部分。
架构模式通常将许多个战术组合在一起。
战术和架构模式共同构成了软件设计时的工具。
大多数架构模式都包含不同的战术，这些战术可能有共同的目的或者常被用于实现不同的质量属性。

四种战术及其用途¶

战术名称	用途
心跳（Heartbeat）	可用性战术：通过定期发送心跳信号检测组件故障，实现故障检测
冗余（Redundancy）	可用性战术：部署多个相同的组件实例，当一个实例故障时其他实例接管
负载均衡（Load Balancing）	性能战术：将请求分发到多个处理节点，提高系统吞吐量
加密（Encryption）	安全性战术：对数据进行加密处理，保护数据的机密性和完整性

参考课件：slides/2026SUG_SysArch2_quality attributes.pdf（架构战术），slides/Lecture 01 - Attributes Driven Design.pdf（ADD 方法）

5. Briefly describe the general activities involved in a software architecture process.¶

软件架构过程的一般活动包括：

识别架构攸关需求（Identify ASRs）：从需求中提取对架构有重大影响的需求
架构设计（Architecture Design）：基于 ASRs 进行架构决策和设计
架构文档化（Architecture Documentation）：使用多视图记录架构设计决策
架构评估（Architecture Evaluation）：验证架构是否满足 ASRs
架构实现与维护（Architecture Implementation & Maintenance）：确保实现遵循架构设计

主要输入：需求文档、业务目标、约束条件、技术环境 主要输出：架构设计文档、架构视图、评估报告

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

6. Mapping, and list 4 views for each style (sa07, p.9)¶

将每个架构风格映射到其适合的视图类型，并为每种风格列出四种视图：

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

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

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

上下文（Context）¶

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

优点（Benefits）¶

提高了 Client 和 Server 之间的交互性：客户端无需知道服务器的具体位置
提高可伸缩性和可扩展性：可以动态添加新的服务器
解决了单体应用的性能瓶颈：通过分布式架构分散负载
大规模集群的性能提高：但单点性能会下降

局限性（Limitations）¶

增加了前期复杂度：需要额外的 Broker 组件设计
可能成为通信的屏障：所有通信经过 Broker 可能成为瓶颈
可能成为攻击的目标：Broker 是系统的单点故障和攻击面
难以测试：分布式系统的测试复杂度更高
单点性能下降：Broker 自身可能成为性能瓶颈

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

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

8. Why should a software architecture be documented using different views? Give the name and purposes of 4 example views.¶

为什么需要使用不同的视图¶

软件架构是复杂的，每个视图关注架构的不同方面。不同利益相关者（stakeholders）关注架构的不同维度。使用多视图可以： - 分离关注点（Separation of Concerns） - 针对不同受众提供合适的信息 - 管理架构的复杂性

四种视图及其目的¶

视图名称	目的
逻辑视图（Logical View）	描述对架构而言重要的元素及其关系（功能需求）。向最终用户展示系统功能。
过程视图（Process View）	描述元素之间的并发和交互，包括进程、线程、同步等。向系统集成者展示运行时行为。
开发视图（Development View）	描述软件模块的内部组织联系（如配置管理存储结构）。向程序员和开发团队展示代码组织。
物理视图（Physical View）	描述主要过程和组件如何映射到硬件上。向系统工程师展示部署拓扑。

参考课件：slides/2026SUG_SysArch1_introduction.pdf（4+1 视图），slides/Lecture 01 - Attributes Driven Design.pdf

9. Briefly describe the fundamental principles of SOA and discuss the impact of SOA on quality attributes like interoperability, scalability and security.¶

SOA 的基本原则¶

服务契约（Service Contract）：服务按照描述文档所定义的服务契约行事
服务封装（Service Encapsulation）：除了服务契约所描述内容，服务将对外部隐藏实现逻辑
服务重用（Service Reuse）：将逻辑分布在不同的服务中，以提高服务的重用性
服务组合（Service Composition）：一组服务可以协调工作，组合起来形成定制组合业务需求
服务自治（Service Autonomy）：服务对所封装的逻辑具有控制权
服务无状态（Service Statelessness）：服务将一个活动所需保存的资讯最小化

SOA 对质量属性的影响¶

质量属性	影响
互操作性（Interoperability）	正向影响：符合开放标准，可以更好的重用服务；支持服务的自动识别、发现、注册和调用
可伸缩性（Scalability）	正向影响：服务自身高内聚、服务间松耦合，最小化维护的影响。但也会带来系统复杂度较高的问题
安全性（Security）	负面影响：中间件（如 ESB）可能成为性能瓶颈和被攻击的目标

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

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

ATAM（Architecture Tradeoff Analysis Method，架构权衡分析方法）各阶段的输出：

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

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

11. Why SPL and MDA have high reusability? Compare and discuss their commonality and differences.¶

为什么 SPL 和 MDA 具有高重用性¶

SPL（Software Product Line，软件产品线）：通过使代码可变来最大化重用，变体（variation）是大规模软件重用的关键。核心资产支持可变功能，通过变体点提供可配置性。
MDA（Model Driven Architecture，模型驱动架构）：鼓励重用模型、模型中的最佳实践和模型转换映射。创建应用程序家族（families of applications），PIM（Platform Independent Model）可通过映射到不同的 PSM（Platform Specific Model）来实现重用。

共同点¶

SPL 和 MDA 都认为变体/大规模定制机制（variation or mass-customization mechanisms）是必要的
通常都以平台无关的方式（UML 模型）表示
都旨在通过系统化的方式实现大规模复用

区别¶

维度	SPL	MDA
核心机制	通过变体点（variation points）和核心资产实现代码可变性	通过模型转换（model transformation）和映射实现重用
关注层面	关注代码层面的可变性和复用	关注模型层面的抽象和转换
实现方式	通过架构中的变体机制支持不同产品	通过 PIM→PSM 映射生成不同平台的实现
关系	MDA 可用于有效管理 SPL——整个 SPL 可以从单一可配置模型表达和创建，模型可以显式显示 SPL 设计的共同和变化部分

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

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