EagleBear2002 的博客

这里必须根绝一切犹豫，这里任何怯懦都无济于事

软件系统设计-复习

发表于 更新于 分类于 ，
本文字数： 22k 阅读时长 ≈ 20 分钟

本文主要内容来自 SpriCoder 的博客，修改了一些翻译错误和笔误，修改了一些表格的样式，添加了 2022 年考题、2025Spring《软件体系结构》考题和解答。

软件架构简答题

软件架构介绍

【2025】【2015B】【2016A】【2019】Architecture，structure 和 Design 的区别？What is difference between architecture and design? What is difference between architecture and structure?

所有架构都是软件设计，但并非所有设计都是软件架构；架构是设计过程的一部分。架构提供了设计的抽象视图。架构是高层设计和一组设计决策；程序或计算系统的软件架构是系统的一个或多个结构，它包括软件元素、这些元素的外部可见属性以及它们之间的关系。架构是高层结构。架构定义结构。结构的属性是由体系结构的设计引起的。

  1. Design 包含 Architecture，Architecture 包含 Structure；
  2. 体系结构是关于软件设计的，所有体系结构都是设计，但是不是所有的设计都是体系结构，体系结构是软件设计的一个部分；
  3. 结构是静态的、逻辑的，是关于系统如何构成的；
  4. 架构除包含结构，还会包含组件之间的相关的关系结构，并定义一些动态的行为。

【2015A】【2016B】【2019】软件架构来自哪里？列举五种可能的软件架构的来源 Where do software architecture come from? List five possible sources of software architecture.

三种需求：NFRs(Non-Functional Requirements)、ASRs(Architecturally Significant Requirements)、质量需求

业务面：涉众和组织、业务目标

技术面：技术环境、商业与技术决策组合

【2025】【2017】【2019】【2022】【2024】在设计软件时应用了哪些通用设计策略？为每个策略提供一个带有软件架构的简明工作示例。What are generic design strategies applied in designing software? Give a concise working example with software architecture for each strategy.

  1. 分解：针对某一个系统关注点分解后处理，比如将整个系统分解或将某个模块分解。
  2. 抽象：使用抽象让设计师关注本身结构而不关心实现，比如将系统抽象为组件和连接件或抽象为模块。
  3. 逐步求精-分而治之：将每个模块分别处理
  4. 生成与测试：将一个特定的设计看作是一个假设；根据测试路径生成测试用例。
  5. 迭代-增量细化：使用迭代的方法，ADD 方法多次迭代直到满足所有 ASR
  6. 复用元素：重用在设计过程中出现了可以复用的元素，重用现有架构

【2015A】【2016A】【2017】简要描述软件架构过程中的一般活动，以及每个活动的主要输入和输出。Briefly describe the general activities involved in a software architecture process, and the major inputs and outputs at each activity.

【2025】【2024】【2015B】【2016B】【2017】【2019】描述 4+1 视图 Describe Philippe Krutchen’s “4+1” views.（考察绘图）

五种视图：

  1. 逻辑视图（Logical View）：描述了对架构而言重要的元素和他们之间的关系（功能需求）
  2. 过程视图（Process View）：描述了元素之间的并发和交互
  3. 开发视图（Development View）：描述了软件组件的内部组织联系（比如使用配置管理工具存储）
  4. 物理视图（Physical View）：描述了主要过程和组件是如何被映射到硬件上的
  5. 架构用例（Architecture Use Cases）：捕获架构需求，与一个或多个特定视图相关。

【2024】software architect 是什么？写出其五种职责。

架构师 archtect：

  • 监督施工并确保符合计划：
    • 在设计变更、危机和模糊性的风暴中引导愿景
    • 软件架构师对软件构造专业人员进行监督
    • 程序员、工程师、设计师
  • 著名的软件架构师：
    • 比尔·盖茨：微软的首席软件架构师
    • 蒂姆·伯纳斯 - 李：万维网的发明者和首席架构师
    • 罗伊·菲尔丁：表述性状态转移（REST）

职责包括：

  • 联络
    • 客户、技术团队与业务/需求分析师之间的联络
    • 与管理或营销部门的沟通
  • 软件工程：软件工程最佳实践
  • 技术知识：对技术领域的深入理解
  • 风险管理：与设计、技术选择相关的风险

质量属性建模

【2016A】哪些主要需求类型被认为会影响架构设计决策，以及这些需求通常如何指定？What are the main kinds of requirements that are considered to influence architecture design decisions and how these requirements are usually specified?

功能需求、质量需求、约束条件。

  • 功能需求说明系统必须做什么，并说明系统如何为利益相关者提供价值。
  • 质量要求是系统应该提供的整个系统的理想特征。
  • 约束是已经做出的预先指定的设计决策。通过接受设计决策并将其与其他受影响的设计决策协调来满足约束。也包括行业规则、法律法规等。

【必考】如何进行质量属性方案建模？请使用“刺激-响应”图的格式进行建模 How to model quality attribute scenarios? Graphically model one quality attributes in "stimulus-response" format:

如何进行质量属性方案建模：

  1. 刺激（Stimulus）：到达系统时需要考虑的条件。
  2. 刺激源（Source of Stimulus）：产生刺激的实体（人，系统或任何其他触发），可能是输入、信息等，对当前的状态的一个变化。
  3. 响应（Response）：刺激到来后工件开展的行为。
  4. 响应度量（Response Measure）：对刺激的响应以某种方法进行测量，以便可以测试需求（比如多长时间系统有反馈）
  5. 环境（Environment）：发生刺激时系统的状况，例如系统正常运行、系统过载、系统受到攻击、系统网络出现故障等。
  6. 工件（Artifact）：完成需求的整个系统或者系统的一部分（软件制品）。
QA Source of Stimulus Stimulus Artifact Environment Response Response Measure
Availability【2015A】【2017】【2018】 Heartbeat 监视器 服务器无响应 进程 正常操作 通知操作者继续操作 没有停机时间
Interoperability【2019】【2024】 车辆信息系统 发送当前位置 路况监控系统 系统在运行前已知 路况监控把当前位置和其他信息合并，覆盖 Google 地图上的，并进行广播 我们的信息在 99.99% 的时间是正确的
Modifiability【2017】【2018】【2019】 开发者 希望修改 UI 界面 代码 设计时 进行修改和单元测试 在 3 小时内
Performance【2015A】【2024】 用户 发起事务 系统 正常操作 事务被处理 平均延迟不超过 2 秒
Security 远程的心怀不满的员工 尝试修改支付率 系统内数据 正常操作 系统维护审计追踪 正确数据在一天内被恢复，并且篡改源被识别
Testability 单元测试者 单元测试完成 单元测试代码 开发时 捕捉结果 3 小时内到达 85% 的路径覆盖
Usability 用户 下载新应用 系统 运行时 用户高效使用应用 在 2 分钟内完成实验

【2025】【2022】请将“可用性”定义为质量属性。MTBF 和 MTTR 代表什么？如何计算一个系统的可用性（例如，SLA）作为概率？Please define 'Availability' as a quality attribute. What do MTBF and MTTR stand for? How to calculate the availability of a system (e.g., SLA) as the probability? (6 points)

可将可用性计算为在指定的时间间隔内它将在要求的范围内提供指定服务的概率。

  1. MTBF（平均无故障时间，mean time between failures）
  2. MTTR（平均维修时间，mean time to repair）
MTBFMTBF+MTTR

架构模式

【2015A】【2016B】【2017】【2018】什么区分了软件产品线架构和单个软件产品架构？What distinguishes an architecture for a software product line from an architecture for a single product?

  1. 产品线的目的：实现高可重用性、高可修改性。
  2. 产品线之所以有效是因为通过重用可以充分利用产品的共性，从而产生经济性。
  3. 在产品线架构中有一组明确允许发生的变化，然而对于常规架构来说，只要满足了单个系统的行为和质量目标，几乎任何实例都是可以的。因此，识别允许的变化是架构责任的一部分，同时还需要提供内建的机制来实现它们。

分层模式

【2015B】【2016A】解释分层架构风格的背景、优点和局限性。Explain the context, benefits and limitations of Layered Architecture Style.

分层模式定义层（提供一组内聚服务的模块分组）和层之间的单向允许使用关系。该模式通常通过将表示层的框堆叠在彼此之上来以图形方式显示。

好处：它可以将一个复杂的问题分成几个部分；具有很高的可扩展性和复用性；组件之间的连接可以通过邻接关系显示，“上方”和“下方”很重要。

弱点：添加层会增加系统的前期成本和复杂性；层会降低性能；如果分层设计不正确，它实际上可能会阻碍，因为它没有提供较低级别的抽象；如果发生许多层桥接实例，系统可能无法满足严格分层有助于实现的可移植性和可修改性目标。

代理模式

【2015A】【2016B】【2019】解释代理（Broker）架构模式的上下文、好处和局限性。Explain the context, benefits and limitations of Broker Architecture Pattern.

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

好处：

  1. 提高了 Client 和 Server 之间的交互性
  2. 提高可伸缩性和可扩展性
  3. 解决了单体应用的性能瓶颈
  4. 大规模集群的性能提高，但是单点性能会下降。

局限性：

  1. 代理增加了前期复杂度
  2. 可能成为通信的屏障
  3. 可能成为攻击的目标
  4. 难以测试
  5. 单点性能下降

SOA 延续了 broker 的思想，查找服务和使用服务都要通过 broker，而 SOA 只在查找时通过 register，分散了 broker 的职责，降低了单点风险。

MVC 模式

【2015B】【2016B】What is the nature of component-connector style (patterns)? Describe the model-view-controller pattern as an example.

MVC 模式将功能分解为三个组件：模型、视图和介于模型和视图之间的控制器。模型是应用程序数据或状态的表示。视图是一个用户界面组件，控制器管理模型和视图之间的交互，将用户操作转化为对模型的更改或对视图的更改。通知关系连接模型、视图和控制器的实例。

SOA 模式

【2015A】【2016A】简要描述面向服务架构（SOA）的基本原则，并讨论 SOA 对互操作性、可伸缩性和安全性等质量属性的影响 Briefly describe the fundamental principles of Service Oriented Architecture(SOA) and discuss the impact of SOA on quality attributes like interoperability, scalability and security

SOA 的基本原则：

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

SOA 对互操作性的影响：

  1. SOA 具有更高的互操作性：符合开放标准，可以更好的重用服务
  2. 支持服务的自动识别、发现、注册和调用等等

SOA 对可伸缩性的影响：

  1. SOA 具有更高的可伸缩性：服务自身高内聚、服务间松耦合，最小化维护的影响
  2. 但是 SOA 也会带来系统复杂度较高的问题

SOA 对安全性的影响：

  1. 中间件可能会成为性能的瓶颈
  2. ESB 等中间件都可以成为被攻击的目标
  3. 多服务导致攻击的跟踪、溯源和防御成为困难。

Multi-tier 模式

【2024】【2018】Layered pattern 和 Multi-tier pattern 的区别

  1. Layered Pattern 是 Module Style，而 Multi-tier Pattern 是 Allocation Style
  2. Layered Pattern 是将任务拆解成一个个处于特定抽象级别的子层次，每层为下一层提供更高层次的服务，核心是关注点分离。
  3. Multi-tier Patten 中的层是逻辑的组合，没有层次模式的强依赖关系，在不同部署环境中分层不同但是软件完成的内容一致。

Peer-to-Peer 模式

【2025】

Pipe-Filter 模式

【2025】

模式 vs 策略

【2024】【2015A】【2016A】描述架构设计中架构模式和决策之间的关系。给出可以在架构设计过程中使用的任何四种决策的名称，并描述每种决策的目的。Describe the relationships between architectural patterns and tactics in architecture design. Give name of any four tactics that can be used during architecture design and describe the purpose of each of them.

架构模式与决策之间的关系：

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

以可用性为例，列举可用策略如下。更多策略可参考 Quality Attributes & Tactics。

【2017】【2023Spring 没讲】【2025Spring 没讲】软件设计的三个变化维度，每个维度的变化点。不同的绑定时间如何影响可修改性和可测试性。

三个变化维度：

  1. 面向对象 OOP，强调重用性、灵活性和扩展性。
  2. 面向切面 AOP，满足扩展的需求，可以在程序中自由的扩展功能。
  3. 面向服务 SOA，是系统发布功能的一种方式，且基于这种方式下不同的系统之间可以有效的沟通、协作。

设计时，开发时，测试时，发布时，运行时：这些绑定方式一次可修改性降低，可测试性升高

架构设计

【2017】【2019】什么是 ASR？列出提取和识别 ASR 的四种来源和方法。What are ASR? List four sources and methods for extracting and identifying ASRs.

ASR 架构攸关需求是对体系结构产生深远影响的需求。

四种来源和方法：

  1. 从需求文档中收集 ASR：MoSCoW 方法和用户故事
  2. 通过采访涉众来收集 ASR：质量属性工作坊（QAW）
  3. 通过了解业务目标来收集 ASR：
  4. 通过质量属性实体树（Utility Tree）来管理 ASR：通过方案量化描述需求后，逐渐对质量属性进行分解细化，直到包含量化指标为止。

【2015B】【2016B】【2018】【2022】软件需求、质量属性、ASRs 的区别和联系 Describe the difference and relationship between software requirements, quality attributes, and architecturally significant requirements.

非功能性需求或体系结构需求是用于质量属性的替代术语。质量属性高于系统的功能。架构上重要的需求是将对架构产生深远影响的需求。QA 要求越困难、越重要，它就越有可能对架构产生重大影响，因此成为 ASR。如果需求影响关键架构设计决策的制定，那么根据定义，它就是 ASR。

  1. 软件需求包括：功能性需求和非功能性需求（又称质量需求）
  2. 非功能性需求包括：技术限制、商业限制和质量属性
  3. 质量属性是由软件的业务目标所决定，在功能性需求的基础上提供的整个系统的合乎需求的特性，是非功能需求的一种反应。
  4. ASRs 架构攸关需求是对于体系结构有着深远影响的需求，肯定是软件需求的一部分。

【2024】【2015B】【2016B】【2018】描述 ADD 过程 Briefly describe the Attribute-Driven Design (ADD) process.

  1. 确定有足够的需求信息
  2. 选择要分解的系统要素
  3. 确定所选的元素的 ASR
  4. 选择符合 ASR 的设计
    1. 找出设计问题
    2. 列出子关注点替代模式/决策
    3. 从清单中选择模式/决策
    4. 确定模式/决策与 ASR 之间的关系
    5. 记录初步的架构视图
    6. 评估并解决不一致的问题
  5. 实例化架构元素并分配职责
  6. 为实例化的元素定义接口
  7. 验证和细化需求并使它们成为实例化元素的约束
  8. 重复进行 2-7 步直到满足所有的 ASR

【2025】通用设计策略在 ADD 中如何体现？

TODO

软件架构视图和文档化【2025Spring 没讲】

【2015A】【2016A】【2017】【2019】【2022】为什么软件系统架构需要使用不同视图来文档化？给出 4 种示例视图的名称和目的。Why should a software architecture be documented using different different views? Give the name and purposes of 4 example views.

原因：

  1. 不同视图支持不同的目标和用户，突出不同的系统元素和关系
  2. 不同视图将不同质量属性暴露出不同的程度

4 种视图（了解）：

  1. 结构视图：
Views Styles 描述 示例
Module Styles 它是如何构建为一组实现单元的？How it is structured as a set of implementation units? 分解视图、使用视图、泛化视图、分层视图、领域视图、数据模型视图
Component-connector(C&C) Styles 它是如何构建为一组具有运行时行为和交互的元素的？How it is structured as a set of elements that have runtime behavior and interactions? 管道-过滤器视图、客户端-服务器视图、点对点视图、面向服务视图、发布-订阅视图
Allocation Styles 它与环境中的非软件结构有何关系？How it relates to non-software structures in its environment? 部署视图、安装视图、工作分配视图、其他分配视图
  1. 质量视图 Quality Views，安全视图、性能视图、可靠性视图、通信视图、异常（错误处理）视图
  2. 组合视图：将上述视图进行组合

【2015A】【2017】将以下每个问题（左侧）与解决该问题的架构风格/视图（右侧）对应起来。列出每个样式类别的四个视图。Map each of the following questions (on the left) with the architectural style/view (on the right) that addresses the question. List four views of each category of style.

见 2

【2015B】【2016B】【2017】【2019】典型的软件架构文档包中应该包含哪些内容？简要描述每个组件及其目的。What should be included in a typical software architecture documentation package? Briefly describe each component and its purposes.

视图之外的架构视图和文档。

视图是一组系统元素和它们之间关系的表示——不是所有系统元素，而是特定类型的元素。视图让我们将系统的实体划分为有趣且易于管理的系统表示。

视图之外的文档包含体系结构文档信息和体系结构信息，该组件显示文档路线图、如何记录视图、系统概述、视图之间的映射、基本原理和目录。

文档应包含 View 和 Beyond 两部分内容。

  1. Beyond 部分：
    1. 文档路线图：包含了范围和总结、简单摘要等。
    2. 视图的文档组织方式：描述了本文档中视图是如何组织的。
    3. 系统概述：从整体上描述了当前架构的简要说明、业务目标（驱动因素）等等。
    4. 视图之间的映射关系：描述了不同视图之间的映射关系。
    5. 系统原理：从整体上描述了当前架构的设计原理。
    6. 目录-索引、词汇表、首字母缩略词表。
  2. View 部分：
    1. styles and views（体系结构风格和视图）
    2. Structural views
      1. module views
      2. C & C views
      3. Allocation views
    3. Quality Views
  3. 每一个 View 的内容：
    1. 主表示图：显示视图的元素和关系，以及图例
    2. 元素介绍：详细介绍第一部分中描述的元素、元素属性、关系属性和元素接口和行为。
    3. 上下文图：描述系统如何与环境相关
    4. 可变性指南：告知视图中可能出现的变化
    5. 基本原理：解释设计如何映射在视图中，以及其合理性。

【2016A】Map each of the following questions (on the left) with the architectural style/view (on the right) that addresses the question. List four views of each category of style.

架构评估【2025Spring 没讲】

【2015A】【2016B】【2017】描述架构权衡分析方法（ATAM）过程的每个阶段生成的输出。Describe the outputs generated from each phase of Architecture Tradeoff Analysis Method(ATAM) process.

阶段 输出 参与者 职责
阶段-0：准备和建立团队 输入：架构设计文档
输出：评估计划		 评估团队领导和关键项目决策者 根据架构设计文档生成评估计划，包括谁参加评估、如何何时何地开展评估、最后评估报告会被呈递给谁。
阶段-1：评估-1 1. 架构的简明介绍
2. 业务目标（驱动因素）的阐释
3. 质量属性要求的优先级列表
4. Utility Tree 效用树
5. 风险和无风险点
6. 敏感和权衡点		 评估团队和项目决策者 第一步，评估负责人介绍 ATAM 方法
第二步，项目经理或客户从业务角度介绍业务驱动因素
第三步，首席架构师介绍体系结构
第四步，评估团队确定架构方法
第五步，评估团队和项目决策者生成质量属性效用树（Utiltiy Tree）
第六步，评估团队分析架构方法
阶段-2：评估-2 1. 涉众们的优先级场景列表
2. 风险主题和每一个受到威胁的业务驱动因素		 评估团队、项目决策者和项目涉众 第一步，评估负责人介绍 ATAM 方法和之前已经取得的成果
第七步，涉众头脑风暴并确定场景优先级
第八步，评估团队分析架构方法，类似第六步
第九步，评估团队展示评估结果，并呈递给涉众
阶段-3：后续 最终的评估报告 评估团队、主要涉众 评估团队制作最终评估报告，发给主要涉众审核通过后，将报告呈递给委托评估的人。

【2015B】【2016A】【2019】描述在 ATAM 的每一个过程中 有哪些 Stakeholder 和他们的职责 Briefly describe the stakeholders involved in ATAM process and discuss their roles in each phase and step.

见上表

【2018】软件架构的关注点有哪些？利益相关方有哪些？

软件架构的关注点：

  1. 利益相关者 Stakeholders addressed
  2. 解决的问题 Concerns addressed
  3. 语言，建模技巧 Language, modeling techniques
  4. 决策，模式 Tactics, Pattern

利益相关方：

  1. 顾客 Customer
  2. 用户 User
  3. 架构师 Architect
  4. 需求工程师 Requirements engineer
  5. 设计师 Designer
  6. 实施者 Implementer
  7. 测试师，集成师 Tester, integrator
  8. 维护者 Maintainer
  9. 产品经理 Product manager
  10. 质量保证人 Quality assurance people

【2018】【2019】【2022】Risks，Senstivity Points，Trade-Off Points 分别是什么？各举一个例子。What are the risks, sensitivity points, and trade-off points associated with software architecture? Give an example for each of them.

  1. 识别风险：发现可能对所需质量属性产生负面影响的架构决策，例如使用分层模式可能带来性能损耗。
  2. 发现权衡：影响多个质量属性的架构决策，例如使用分层模式可能会带来性能损耗，但是也会解耦增加系统的可修改性。
  3. 发现敏感点：特定质量属性对其敏感的架构决策，比如在对性能敏感的系统中，决定使用缓存中间件。

【2015A】【2015B】How do software product lines and model driven architecture archive a high reusability? Compare and discuss the commonalities and differences between these two architectural approaches from various perspectives. What are your considerations when you choose from them?

SPL makes code variable to maximize reuse, and variation is key to large scale software reuse. MDA encourages reuse models, best practices in models and model transformation mapping, create families of applications, PIM is intended for reuse by mapping to different PSMs and MDA platform designed for reuse as a target for multiple applications.

SPL and MDA both agree that variation or mass-customization mechanisms are necessary.

MDA and SPL usually are represented in a platform-independent way in the form of interrelated UML models.

MDA can be used to effectively manage software product lines, an entire SPL can be expressed and created from a single configurable model. Models can explicitly show both the common and varying parts of the SPL design.

【2015B】【2016A】【2016B】How does software product line architecture implement variability? How do variation mechanisms work in software product line? Describe when(how) software entity variation may take place?

In an SPL, core assets support variable functionality by providing variation points. A SPL typically has a PLA that gives an architectural basis for variation. A PLA uses specific architectural variation mechanisms to implement variable functionality.

在 SPL 中，核心资产通过提供变体点来支持可变功能。SPL 通常具有为变化提供架构基础的 PLA。PLA 使用特定的架构变体机制来实现可变功能。

当我们创建编码工作区时、构建目标代码时、创建应用程序时、应用程序启动时以及应用程序运行时。

微服务架构

【2024】微服务部署的容器模式，使用上下文、需求、优势和限制。

下表汇总了所有部署模式的优缺点：

模式 优点 缺点
无服务器 消除管理操作系统和运行时状态的必要性；
自动弹性配置；
基于请求的定价		 长尾延迟；
使用基于事件/请求的编程模型
容器 必须管理操作系统和运行时；
需要管理 Docker 编排框架及其底层运行的虚拟机		 轻量级，比 Serverless 部署更灵活；
延迟可预测
虚拟机 Amazon EC2 等现代云；
部署小型简单应用程序可能比设置 Docker 编排框架更容易		 重量级且部署速度较慢；
使用更多的资源
服务部署平台 多种后续模式支持；
功能强大		 额外的技术学习和资源成本
主机（单/多）

【2025】【2019】微服务架构（MSA）和 SOA 的区别，相同点。【2024】分层、SOA 和微服务架构之间的差异，从设计策略、优势、限制等 多个角度完整解释。

  1. 相同点：微服务和 SOA 都是分布式架构，微服务是 SOA 的一种扩展，都包含了服务契约、服务封装、服务重用、服务组合、服务自治和服务无状态等基本特点。
  2. 微服务去掉了 SOA 架构中的 ESB，采用轻量级通信机制（HTTP、REST）进行服务之间的通信。
  3. 微服务的管理和部署结合 DevOps 实现自动化，可以对服务进行自动化部署和监控预警。
  4. 微服务引入了 API 网关、对客户端屏蔽访问各项服务的问题。
  5. 微服务引入了熔断器：避免出现服务失效或网络问题等导致的级联故障。
  6. SOA 使用全局数据模型并共享数据库；MSA 每个服务有自己的数据模型和数据库
  7. SOA 服务是较大的单体应用；MSA 提供较小的服务
SOA MSA
服务间通信 1. 智能管道，如(ESB)
2. 重量级协议，如 SOAP 或 WS * 标准		 1. 哑管道，如消息代理，或服务之间点对点通信
2. 轻量级协议，如 REST 或 gRPC
数据管理 全局数据模型并共享数据库 每个服务有自己的数据模型和数据库
典型服务规模 较大的单体应用 较小的服务

【2025】微服务架构的六大特性：

  1. 通过服务组件化
  2. 围绕业务能力组织，而不是聚焦在技术层面
  3. 服务内部高内聚，服务间低耦合
  4. 去中心化
  5. 基础设施自动化
  6. 服务高可用性设计、演进式设计

其他特性：

  1. 每个服务相对较小并容易维护
  2. 服务可以独立扩展
  3. 技术栈不受限
  4. 大型复杂程序可以持续部署和交付
  5. 高可伸缩

【2015B】【2016B】描述 SOA、Web 服务和企业服务总线（ESB）的用途，并讨论它们之间的区别和联系。Describe the purposes of SOA, Web Service, and Enterprise Service Bus. Discuss the difference and relations between them.

SOA 是让应用程序调用其他应用程序提供的功能，从现有服务创建业务流程，并使应用程序适应不断变化的技术。Web 服务是一组集成技术标准，旨在满足面向服务的体系结构和系统的需求，并为使用中介的系统体系结构提供良好的支持。企业服务总线 (ESB) 是一种中间件基础架构，它通过事件驱动和基于标准的消息传递引擎为更复杂的体系结构提供基础服务。

SOA 是一种设计原则，Web 服务是一种实现技术。可以在不使用 Web 服务的情况下构建面向服务的应用程序。Web 服务带来了独立于平台的标准。Web 服务允许异构技术之间更好的互操作性。Web 服务是 SOA 模式的一个实例。ESB 不实现 SOA，但提供可以实现的功能。大多数 ESB 供应商现在构建 ESB 以纳入 SOA 原则并增加其销售额。ESB 利用网络服务提供服务。通过 Internet 的 SOAP/HTTP 和 WSDL 不提供 ESB。

AI 原生应用

Domain-Driven Design

【2024】DDD 的一般过程

原理：

  • 业务驱动（而非数据驱动）：DDD 认为业务模型是软件开发的核心，开发者应该深入理解业务领域，构建准确的业务模型。
  • 领域划分：将业务领域划分为不同的子域，每个子域有其特定的业务逻辑和模型。
  • 统一语言：开发者和业务专家使用统一的语言来沟通，减少误解，确保模型的准确性。
  • 限界上下文：定义模型的边界，明确不同模型之间的交互规则。

流程：

企业架构

【2024】企业架构的 basic function

简答题，考察对于企业架构原理、流程和意义的理解。

【2025，6 分】企业架构的核心是什么？它们在企业数字化转型中发挥什么作用？

TODO

软件详细设计简答题

【2017】请至少说出三个面向对象的原则，并解释它们如何应用于策略模式？ Please name at least three Object-Oriented principles, and explain how they are applied in Strategy pattern?

  1. 单一职责原则
  2. 开闭原则
  3. 里氏代换原则
  4. 合成复用原则

【2019】设计模式是什么？举例说明类模式和对象模式的区别？

  1. 什么是设计模式：
    1. 设计模式是对被用来在特定场景下解决一般设计问题的类和互相通信的对象的描述，包括模式名称、问题、解决方案和效果四部分。
    2. 设计模式（Design Pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。
  2. 设计模式分类
    1. 根据其目的（模式是用来做什么的）可分为创建型（Creational），结构型（Structural）和行为型（Behavioral）三种：
      1. 创建型模式主要用于创建对象。
      2. 结构型模式主要用于处理类或对象的组合。
      3. 行为型模式主要用于描述对类或对象怎样交互和怎样分配职责。
    2. 根据范围，即模式主要是用于处理类之间关系还是处理对象之间的关系，可分为类模式和对象模式两种：
      1. 类模式处理类和子类之间的关系，这些关系通过继承建立，在编译时刻就被确定下来，是属于静态的。
      2. 对象模式处理对象间的关系，这些关系在运行时刻变化，更具动态性。

【2019】防御式编程是什么？断言和错误处理的区别？

  1. 可以预见到（至少预先推测到）问题所在，断定代码中每个阶段可能出现的错误，并作出相应的防范措施，来防止类似的意外的发生。
  2. 断言和错误处理的区别
    1. 断言是在开发期间使用的、让程序在运行时进行自检的代码，是对开发人员的警告，通常是一个子程序或宏。断言不可以有副作用。
    2. 错误处理是对预先已经考虑到的错误（如用户错误、程序错误、意外情况等等）按照流程进行处理。

【2019】设计模式对 MVC 的影响？

  1. MVC 模式使用了运行时、动态和相互之间的关系集成到开发框架中，是分层模式的变种。
    1. 分为 model（业务逻辑）、view（处理用户展示，接收用户操作）、controller（对用户操作进行处理，将信息通知给 model）（强调模块间约束关系，model 不可以直接返回到 controller）
    2. 优点：耦合性低，重用性高，生命周期成本低，部署快，可维护性高，方便管理
    3. 缺点：没有明确定义，不适于中小型应用程序，增加实现复杂度，视图和控制器过于紧密，视图对模型访问低效。
  2. 四人书中，MVC 模式是观察者模式、策略模式和组合模式的演化，可能涉及到工厂模式和装饰器模式
    1. 基于推送-订阅模式
    2. 观察者：model 发生变化通知 controller，然后更新 view
    3. 策略模式：controllers 帮助 views 对不同用户的输入做不同的响应。
    4. 组合模式：一组 views

【2019】策略模式和状态模式的区别？

  1. 在状态模式中，具体状态类的方法参数中包含上下文对象，需要在状态处理完成后完成状态切换。
  2. 在策略模式中，直接对上下文类调用 set 方法设置策略即可，不涉及到策略的切换。

【2019】最小知识原则在设计模式中的应用？

  1. 中介者模式
  2. 外观模式

【2022】Please explain the Liskov Substitution Principle and how it contributes to the Open- Closed Principle. (6 points)

【2022】Please explain how the Factory Method Pattern and Abstract Factory Pattern adhere to the Open-Closed Principle. (6 points)

【2022】What is the benefit of decoupling the Receiver from the Invoker in the Command Pattern? (6 points) 4.There are two methods for propagating data to observers with the Observer design pattern: the push model and the pull model. Why would one model be preferable over the other? What are the trade-offs of each model? (6 points)

【2022】What is the difference between the categories of Creational Patterns and Structural Patterns? What categories do Prototype and Flyweight fall into,respectively? Explain why.(6 points)

软件架构设计题

【2025】材料题：给出一个电商平台 Java 代码。

  1. （8 分）请指出两处该设计违反 DDD 原则之处？
  2. （12 分）请改进设计以符合 DDD 原则。

【2024】材料题：一个在线课程平台是分层架构的，把它迁移到微服务架构，材料里给了一些需求和要满足的质量属性以及迁移可能面临的挑战

  1. 用什么模式实现微服务架构
  2. single-host，muti-host 和容器三种部署方式的差异。你推荐实验哪种部署模式
  3. 设计迁移方案，例如如何分解、部署、数据如何迁移，写出关键里程碑和最终的交付物

TODO

【2015A】【2016A】【2019】Distributed Cache Updates. Figure 1-1 below shows a distributed application with caches to improve its runtime performance. An online customer service system provides its clients access to their Bill Statement Information (BSI). The database stores BSI for clients. During a session, a client may require the BSI several times. In order to improve the performance, the BSI information for a particular client is cached. If the cache is loaded, then the BSI can be directly returned back to the client without access to the database. There are N servers clustered to serve the requests from clients. The server is load-balanced, and each time one server is scheduled for one client request. All the caches on N servers need to synchronize their states. If the client request changes the states of one cache, there are two requirements:

  1. The changes are committed to the database;
  2. All other cache states must be invalidated and they should reload the states from the database.

The current design in Figure 1 cannot meet the second requirement. Some important components are missing. Consider to apply architectural pattern(s) and tactic(s) to the design that can meet the second requirement, and complete the following questions:

  1. (5 分) Identify extra component(s) that is (are) necessary for this design to meet second requirement. List each component name and it major functionalities.
  2. (5 分) Draw sequence diagram to illustrate the communication between your devised components and original components in Figure 1.
  3. (10 分) Assume that the servers are heterogeneous, and the protocols to access caches on different servers vary. For example, Server 1 supports Java RMI invocations to cache 1, Server 2 supports http JSP requests to cache 2, and server 3 supports SOAP requests to cache 3. It is further assumed that the cache interfaces are not consistent to each other due to the evolution of system development and legacy problems. Explain how the concept of connectors or web services can be applied to provide a generic invocation to caches? You can choose either connector or web services for discussion.

【2015B】Design a simplified architecture for a flight (or train service) booking system in the three-tier style. Explain what responsibilities each component in the architecture has. Document your design using the “Views and Beyond” approach.

以下是一个简化的三层风格的航班（或火车）订票系统的架构设计，并解释了每个组件在架构中的责任。我们将使用“Views and Beyond”方法对设计进行文档化。

  • 用户界面层（Presentation Layer）：
    • 负责处理用户与系统的交互，接收用户的输入并展示相应的信息。
    • 提供用户界面，包括网页、移动应用等，以便用户能够搜索航班信息、选择座位和购买机票。
    • 处理用户的身份验证和授权，确保只有经过认证的用户才能进行预订操作。
  • 业务逻辑层（Business Logic Layer）：
    • 负责处理系统的业务逻辑和流程，包括航班查询、座位选择、价格计算、订单管理等。
    • 处理用户提交的预订请求，根据航班信息和座位可用性进行验证和处理。
    • 协调不同的数据访问操作，包括与数据库的交互、调用第三方服务获取航班信息等。
  • 数据访问层（Data Access Layer）：
    • 负责与数据库进行交互，执行数据的读取、写入和更新操作。
    • 提供持久化机制，将预订信息、航班数据等存储在数据库中。
    • 封装数据库操作的细节，提供简化的接口供业务逻辑层进行数据访问。

这个架构设计遵循了三层架构的原则，将系统的不同功能和责任分离到不同的层级中。用户界面层负责与用户的交互和界面展示，业务逻辑层负责处理业务规则和流程，数据访问层负责处理数据的持久化和访问。这样的设计使得系统更加模块化、可维护和可扩展，不同层级的组件可以独立变化而不会影响到其他部分的功能。

【2016A】【2016B】Design a simple architecture for an automated teller machine (ATM) application in the three-tier style. Explain what responsibilities each component in the architecture has. Document your design using the “Views and Beyond” approach.

以下是一个简单的三层风格的自动取款机（ATM）应用的架构设计，并解释了架构中每个组件的责任。我们将使用“Views and Beyond”方法对设计进行文档化。

  • 用户界面层（Presentation Layer）：
    • 负责与用户进行交互，提供友好的界面和操作方式。
    • 接收用户的输入，包括账号、密码和取款金额等信息。
    • 显示用户的操作结果，例如显示账户余额、取款金额等信息。
  • 业务逻辑层（Business Logic Layer）：
    • 负责处理系统的业务逻辑和流程，包括账户验证、金额计算、交易记录等。
    • 处理用户提交的取款请求，验证账号和密码的正确性，并检查账户余额是否足够。
    • 更新账户余额，生成交易记录，并与数据访问层进行交互。
  • 数据访问层（Data Access Layer）：
    • 负责与数据库进行交互，执行账户信息的读取、写入和更新操作。
    • 存储用户的账户信息，包括账号、密码、余额和交易记录等。
    • 提供访问数据库的接口，供业务逻辑层进行账户信息的读取和更新操作。

这个架构设计遵循了三层架构的原则，将系统的不同功能和责任分离到不同的层级中。用户界面层负责与用户的交互和界面展示，业务逻辑层负责处理业务规则和流程，数据访问层负责处理数据的持久化和访问。这样的设计使得系统更加模块化、可维护和可扩展，不同层级的组件可以独立变化而不会影响到其他部分的功能。

软件详细设计题

【2019】一个游戏，有几种人类角色：骑士、骑兵、步兵，持有不同的武器（矛、剑、斧），拥有 fight 方法；有一个非人类角色巨魔，可以持有武器，但攻击方法不同（beat）。现在希望让巨魔和其他人类角色一起进行游戏，并且要求有角色死亡时其他活着的角色要收到通知。运用设计模式进行设计，并画出类图。

【2019】表驱动，参考 PPT 即可。

【2019】架构设计，没太看懂……大概是分析程序结构生成报告？

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

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

其他知识点

  1. 什么是软件系统架构：是结构和系统结构，包含了软件元素，这些组件的外部可视化属性和他们之间的关系（包含组件的行为）
  2. 几个概念
    1. 功能性需求：定义系统必须做什么，并且强调系统如何提供价值给涉众。
    2. 质量需求：系统应在功能性需求之上提供的整个系统的合乎需求的特性。
    3. 策略：是影响质量属性相应控制的设计决策，比如冗余。
  3. 架构模式
    1. 背景、上下文（Context）：世界上经常发生问题的场景。
    2. 问题（Problem）：在给定上下文中出现经过适当概括的问题。
    3. 解决方案（Element + Relations + Constraints）：针对问题的成功的经过适当抽象的解决方案。
  4. ADD 的输出
    1. 软件元素：完成各种决策和职责、定义属性并与其他软件元素相关以组成系统架构的计算或开发工件。
    2. 角色：一组相关的职责。
    3. 职责：软件提供的功能、数据或信息。
    4. 属性：有关软件元素的附加信息。
    5. 关系：两个软件元素之间如何相互关联和交互的定义。
  5. 如何选择视图
    1. 构建涉众/视图表
    2. 合并视图
    3. 确定优先级和完成阶段
  6. 什么是微服务：是分布式架构，SOA 的一种扩展
    1. 微服务架构风格是一种将一个单一应用开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制，这些服务围绕业务能力构建并可以通过自动部署机制独立部署。
    2. 微服务特点
      1. 服务颗粒化:服务粒度由业务功能决定，服务间尽可能解耦
      2. 责任单一化:单一职责原则，服务内尽可能内聚
      3. 运行隔离化:服务运行在各自进程中，互不影响
      4. 管理自动化:对服务提供自动化部署与监控预警能力，高效管理
    3. 微服务核心模式：针对采用微服务系统在特定问题所使用的程序的架构解决方案的集合
      1. 服务注册与发现
      2. API 网关
      3. 熔断器
    4. 微服务的挑战
      1. 运维要求高:微服务数量多，部署与监控要求高
      2. 发布复杂度:部署环境多样化，网络性能系统容错、分布式事务等挑战
      3. 部署依赖强:服务间相互调用关系复杂，存在部署顺序依赖
      4. 通信成本高:跨进程调用比进程内调用消耗更多的资源
  7. 面向对象设计原则

  1. 设计原则
    1. 目标：开闭原则
    2. 指导：最小知识原则
    3. 基础：单一职责原则、可变性封装原则
    4. 实现：依赖倒转原则、合成复用原则、里氏代换原则、接口隔离原则
  2. 模式一般都有的缺点
    1. 增加设计的复杂性和增加类的个数（增加辅助类）
    2. 增加隔阂、方法调用，降低软件运行的效率，但是已经不是目前主要的问题
  3. 引入设计模式的作用 1. 设计模式提供了与其他开发人员共享的词汇表。2. 通过在模式级别（而不是实质性对象级别）进行思考，提高对体系结构的思考（但不要迷失在细节中）

  1. 防御式编程
    1. 防御式编程：可以预见到（或至少预先推测到）问题所在，断定代码中每个阶段可能出现的错误，并作出相应的防范措施，来防止类似意外的发生。
    2. 断言：在开发期间使用的、让程序在运行时进行自检的代码，是对开发人员的警告，通常是一个子程序或宏。断言不可以有副作用。
    3. 异常：是将代码中的错误或异常事件传递给调用方代码的一种特殊手段，谨慎使用可以降低复杂度。
    4. 错误处理：根据软件类别平衡正确性和健壮性（哪个优先级更高）
    5. 隔离程序：隔离程序是以防御式编程为目的而进行隔离的一种方法，将某些接口选定为“安全”区域的边界，对穿越安全区域边界的数据进行合法性检验（集中工作在特定的模块中降成本）
    6. 辅助调试代码：辅助进行代码调试的代码，帮助快速检查错误，应该尽早地引入辅助调试代码。
    7. 攻击式编程：主动暴露出可能出现的错误，在开发阶段将其暴露显现出来，而在产品代码运行时让他能够自我恢复。
  2. 表驱动法：一种编程模式
    1. 目的：表驱动法适用于复杂逻辑，将复杂逻辑从代码中独立出来方便单独维护
    2. 原理：从表里面查找信息而不使用逻辑语句（if 和 else）
    3. 具体实现
      1. 直接访问表：直接通过索引值可以从表中找到对应的条目
      2. 索引访问表：首先从索引表中找到数据表的地址，然后再从数据表中找到对应的条目（节省空间、管理廉价、容易维护）
      3. 阶梯访问表：根据每项命中的阶梯层次来确定其归属
  3. 装饰者的两个缺点：很多小类、难以排查错误
  4. 增加新的鸭叫统计次数（不允许修改原本代码）：装饰器模式

选择模式

  1. 一个温度系统有 3 个恒温器，一个恒温器可以调整和显示温度，2 个恒温器只能手动调节，1 个恒温器可以手动、计时器调节：中介者、策略
    1. 模板方法：先调整、再显示（用户直接复用模板方法，而本例中复用的是实现）
  2. 一个队伍有 1 个管理者和 25 个队员，每一个队员可以有一个位置，有的特别强的队员可以有多个位置：策略、原型
    1. 策略独立于 Player，所以 Player 是一样的
    2. 模板方法模式是解决步骤的问题
  3. 积分会员制，积分比较高则为高级会员，积分比较低则为低级会员

What is a Pattern? Match each pattern with its description:

A:Adapter B:State C:Iterator D: Facade E: Strategy F: Observer G: Factory Method H: Decorator I:Command J: Template Method K: Composite L: Singleton

描述 模式
Wraps an object and provides a different interface to it. 适配器模式
Subclasses decide how to implement steps in an algorithm. 模板方法模式
Subclasses decide which concrete classes to create. 工厂方法模式
Ensures one and only one objectis created. 单例模式
Encapsulates interchangeable behaviors and use delegation to decide which one to use. 策略模式
Clients treat collections of objects and individual objects uniformly. 组合模式
Encapsulates state-based behaviors and use delegation to switch between behaviors. 状态模式
Provides a way to traverse a collection of objects without exposing its implementation. 迭代器模式？
Simplifies the interface of a set of classes. 外观模式
Wraps an object to provide new behavior. 装饰模式
Allows objects to be notified when state changes. 观察者模式
Encapsulate a request as an object. 命令模式