本文参考总结自 SpriCoder的博客、EagleBear2022 的博客

软件架构简答题

1.1 软件架构介绍

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

  1. NFRs（Non-functional requirements 非功能性需求）

  2. ASRs（Architecture Significant Requirements 架构攸关的需求）

  3. 质量需求

  4. 涉众，组织

  5. 技术环境

  6. 业务目标

  7. 商业与技术决策组合

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

  1. 分解：针对某一个系统关注点分解后处理，比如将整个系统分解或将某个模块分解。

    • 质量属性可以分解，并分配给分解后的元素。
    • 如何对非 ASR 进行设计：ASR 仅意味着需求的优先级，仍然可以满足非 ASR需求来满足其他人，除非您即将满足需求、需要重新确定需求优先级并重新设计和您不能满足需求。
    • 一次设计所有的 ASR 还是一个 ASR？经验问题。通过经验和教育，我们会有直观的设计方法，并使用模式/策略来设计多个 ASR。

  2. 抽象：使用抽象让设计师关注本身结构而不关心实现，比如将系统抽象为组件和连接件或抽象为模块。

  3. 逐步求精 - 分而治之：对于一个大规模系统，每次聚焦一部分。将每个模块分别处理。

  4. 生成与测试：将一个特定的设计看作是一个假设；根据测试路径生成测试用例。

    • 将特定设计作为假设，当前假设的错误在下一次设计的假设中得到解决，而正确的谁设计得到保留。
    • 最初的假设来自于：现有系统、框架、模式与策略、设计清单（提供指导）
    • 下一个假设的生成：当前的假设、系统实现的具体情况和质量属性之间的差距、结合新选用的 Tactics。
    • 有哪些测试？根据分析技术、根据检查清单（职责分配、协作模型、数据模型、架构元素映射、资源管理、绑定时间、技术选择）
    • 什么时候完成？具有满足 ASR 的设计、或者您将使用完预算进行设计时、实施出你做出的最佳假设时。

  5. 迭代 - 增量细化：使用迭代的方法，ADD (Attribute-Driven Design) 方法多次迭代直到满足所有 ASR

  6. 复用元素：重用在设计过程中出现了可以复用的元素，重用现有架构

  1. 【2019】Architecture，structure 和 Design 的区别？
  1. Design 包含 Architecture，Architecture 包含 Structure
  2. 体系结构是关于软件设计的，所有体系结构都是设计，但是不是所有的设计都是体系结构，体系结构是软件设计的一个部分
  3. 结构是静态的、逻辑的，是关于系统如何构成的
  4. 体系结构除包含结构，还会包含组件之间的相关的关系结构，并定义一些动态的行为。
  1. 【2015】【2017】简要描述软件架构过程中的一般活动，以及每个活动的主要输入和输出。Briefly describe the general activities in a software architecture process, and the major inputs and outputs at each activity.
  1. 通过 StackHolder 获取到 ASRs（架构攸关的需求）
  2. 通过分析得到 Prioritized Quality Attribute Scenarios(高优先级质量属性场景) 和 Requirements，Constraints(需求和约束)
  3. 将上述部分，结合模式和决策，综合可以得到架构的设计
  4. 根据架构的设计得到由模式决定的候选视图的示意图，之后完成文档化
  5. 选择、组合视图，将文档进行进一步的评估，这一部分需要 StackHolder 的参与、也需要 Prioritized Quality Attribute Scenarios 和文档等作为参考。
  1. 【2017】【2019】描述 4+1 视图 Describe 4+1 view（考察绘图）

  1. 逻辑视图：描述了对架构而言重要的元素和他们之间的关系（功能需求）

    • 一般用类图或ER图来描述

  2. 过程视图：描述了元素之间的并发和交互

    • 进程视图主要从性能，可用性等一些非功能性需求的角度去描述系统

  3. 物理视图：描述了主要过程和组件是如何被映射到硬件上的

    • 部署视图：主要考虑一些非功能性的需求，比如可用性，可靠性（容错性），性能（吞吐量）以及横向扩展性

  4. 开发视图：描述了软件组件的内部组织联系（比如使用配置管理工具存储）

    • 软件由一系列的程序库或者子系统打包而成，子系统又会根据实现需要被分成多个层次，每一层会提供一个定义完善而又简洁的接口给上层调用。

  5. 用例场景(Scenarios use case)：捕获架构需求，与一个或多个特定视图相关。

image-5

  • 软件体系结构概念
    • Module，模块：是还没有实现出来的软件部分。
    • Component，组件：是已经实现出来的软件部分。
    • Connector，连接件：连接组件的部分
    • Element，元素：包含 Component 和 Connector
  • 体系结构在做什么？
    • 将系统分解成组件、模块和子系统
    • 定义了通信的方式
    • 处理非功能需求
  • 什么是体系结构视图？为什么使用体系结构视图？
  • 一组特定类型的系统元素和它们之间的关系表示。
  • 体系结构视图主要是为了应对软件不可见的问题，屏蔽其他没有影响的部分，将关注点分离。
  • 为什么软件系统架构需要用不同的视图来文档化？
    • 不同的视图支持不同的目标和用途，突出不同的系统元素和关系，在不同程度上暴露了不同的质量属性。

1.2 质量属性建模

  • 质量属性图
    alt text
  1. 【必考】如何进行质量属性方案建模？请使用“刺激-响应”图的格式进行建模 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）：完成需求的整个系统或者系统的一部分（软件制品）。

alt text

QASource of StimulusStimulusArtifactEnvironmentResponseResponse Measure
Availability【2015】【2017】【2018】Heartbeat 监视器服务器无响应进程正常操作通知操作者继续操作没有停机时间
Interoperability【2019】车辆信息系统发送当前位置路况监控系统系统在运行前已知路况监控把当前位置和其他信息合并，覆盖 Google 地图上的，并进行广播我们的信息在 99.99% 的时间是正确的
Modifiability【2017】【2018】【2019】开发者希望修改 UI 界面代码设计时进行修改和单元测试在 3 小时内
Performance【2015】用户发起事务系统正常操作事务被处理平均延迟不超过 2 秒
Security远程的心怀不满的员工尝试修改支付率系统内数据正常操作系统维护审计追踪正确数据在一天内被恢复，并且篡改源被识别
Testability单元测试者单元测试完成单元测试代码开发时捕捉结果3 小时内到达 85% 的路径覆盖
Usability用户下载新应用系统运行时用户高效使用应用在 2 分钟内完成实验
  1. 【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）

MTBF / (MTBF + MTTR)

1.3 架构模式

  1. 【2015】【2017】【2018】什么区分了软件产品线架构和单个软件产品架构？What distinguishes an architecture for a software product line from an architecture for a single product?
  1. 产品线是产品的集合
  2. 单一产品体系结构只有一个产品，软件产品线体系结构有多个产品
  3. 产品线的目的：实现高可重用性、高修改性。
  4. 产品线之所以有效是因为通过重用可以充分利用产品的共性，从而产生经济性。
  5. 识别允许的变化是架构责任的一部分，同时还需要提供内建的机制来实现它们。单一产品架构对架构的变化没有说明和限制；必须在软件产品线架构中对允许进行的变化进行显式的说明和限定。
  6. .面向独立软件系统的软件体系结构设计方法并不完全适用于软件产品线体系结构的设计，因为它们一般没有考虑产品线中不同产品之间的共性和个性问题。
  7. .产品线架构可以使软件开发组织将总成本均摊到产品线的多个产品的设计开发中，从而充分地降低整体成本、有效地提高软件生产率。
  1. 【2015】【2019】解释代理架构模式的上下文、好处和局限性。Explain the context, benefits and limitations of Broker Architecture Pattern.

  • 上下文：

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

  • 好处：

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

  • 局限性

    • 代理增加了前期复杂度

    • 可能成为通信的屏障

    • 可能成为攻击的目标

    • 难以测试

    • 单点性能下降

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

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

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

  2. 【2015】描述架构设计中架构模式和决策之间的关系。给出可以在架构设计过程中使用的任何四种决策的名称，并描述每种决策的目的。Describe the relationships between architectual 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. 决策和架构模式共同构成了软件设计时的工具。

  • 四种决策的名称：

    1. 职责分配：将大的职责进行拆分。
    2. 协调模型：各部分之间的沟通与交互。
    3. 数据模型：数据格式、存储方式（缓存等）。
    4. 资源管理：CPU、网络、内存、时间等资源。
    5. 架构元素映射：架构元素如何映射到具体的软件实现。
    6. 绑定时间决策：设置时间点（这个时间点前系统还是可以变化的，但之后不可以）
    7. 技术选择：之前的部分已经确定后，我们可以选择的技术栈比较局限。
  1. 【2015】简要描述面向服务架构（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 具有更高的互操作性：SOA是Broker模式的延伸，具备 Broker 的优势。符合开放标准，可以更好的重用服务
    2. 支持服务的自动识别、发现、注册和调用等等

  • SOA 对可伸缩性的影响：

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

  • SOA 对安全性的影响：

    1. 中间件、服务可能会成为性能的瓶颈
    2. ESB 等中间件都可以成为被攻击的目标
    3. 多服务导致攻击的跟踪、溯源和防御成为困难。
  1. 【2017】【不在授课范围】软件设计的三个变化维度，每个维度的变化点。不同的绑定时间如何影响可修改性和可测试性。
  • 三个变化维度：
  • 面向对象 OOP，强调重用性、灵活性和扩展性。
  • 面向切面 AOP，满足扩展的需求，可以在程序中自由的扩展功能
  • 面向服务 SOA，是系统发布功能的一种方式，且基于这种方式下不同的系统之间可以有效的沟通、协作。
  • 设计时，开发时，测试时，发布时，运行时：这些绑定方式一次可修改性降低，可测试性升高

  • 架构模式 Architectural Patterns

    • 架构模式是在实践中反复发现的一套设计决策，具有允许重复使用的已知属性，并且描述了一类架构。

    • 关联了如下三种角色：

      • 背景、上下文（Context）：世界上经常发生问题的场景。

      • 问题（Problem）：在给定上下文中出现经过适当概括的问题。

      • 解决方案（Element + Relations + Constraints）：针对问题的成功的经过适当

        抽象的解决方案。

  • 架构模式——分层模式 Layered Pattern 模块模式

    • 分层模式用来构造可以分解为子任务组的程序，每个子任务组都处于一个特定的抽象级别，每层都为下一个提供更高层次的服务。分层模式的关键点在于确定依赖，核心是关注点分离（必须逐层访问）
    • 上下文：
      • 一般桌面应用
      • Web（OSI 的七层网络模型）
    • 优点：高内聚、松耦合、易于维护
    • 缺点：降低系统的性能，导致级联修改增加开发成本。

  • 架构模式——代理模式 Broker Pattern 组件-连接器模式

    • 代理体系结构模式可以用于构建分布式软件系统，其中具有通过 RMI 交互的分离组件，代理组件负责协调通信，如转发请求，以及传输结果和异常。

    • 上下文：

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

    • 好处：

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

    • 局限性

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

    • 解决方案：通过提供隔离通讯相关的代理，将系统通信功能与主应用程序分开

  • 架构模式——模型-视图-控制器模式 MVC Pattern 组件-连接器模式

    • 使用运行时、动态、相互之间的关系来审视，集成到了开发框架中，也是分层架构的变种（强调模块间约束关系，model 不可以直接返回到 controller），分为 model（业务逻辑）、view（处理用户展示，接收用户操作）、controller（对用户操作进行处理，将信息通知给 model）
    • 优点：耦合性低，重用性高，生命周期成本低，部署快，可维护性高，方便管理
    • 缺点：没有明确定义，不适于中小型应用程序，增加实现复杂度，视图和控制器过于紧密，视图对模型访问低效。

  • 架构模式——管道和过滤模式 Pipe-and-Filter Pattern 组件-连接器模式

    • 管道和过滤器模式应用在顺序处理结构中，有一系列 filter 体现依赖关系。
    • Filter：相当于 Component，起数据处理、计算作用，每个 Filter 有 input 和多个output，将数据处理后传递给后续部分。
    • Pipe：相当于 Connector，连接 filter，将 output 导入到其他的 filter 的 input 中去，不会独立存在。
    • 缺点：不适用于互动式系统，过多的过滤器导致大量的计算开销。

  • 架构模式——客户端服务器模式 Client-Server Pattern 组件-连接器模式

    • 客户端-服务器模型是一种分布式应用程序结构，它在资源或服务（称为服务器）和服务请求者（称为客户端）的提供者之间划分任务或工作负载。客户端和服务器通常通过计算机网络在单独的硬件上进行通信，但客户端和服务器可能位于同一系统中。服务器主机 运行一个或多个与客户共享资源的服务器程序。客户端不共享其任何资源，但请求服务器的内容或服务功能。因此，客户端启动与等待传入请求的服务器的通信会话。使用客户端-服务器模型的计算机应用程序的示例是电子邮件，网络打印和万维网。
    • 包含了两类不同的 Component，没有 broker 可以动态改变 Client 和 Server 的关系，成对的关系相对固定。
    • 上下文：
      • Windows 的客户端应用（桌面应用）。
    • 缺点：
      • 服务器成为性能瓶颈
      • 可能单点失效
      • 决定在哪里实现功能的决定也是复杂的（并且难以修正。）

    与 Broker Pattern 进行质量属性的影响方面的比较

    Broker 也存在 Client 和 Server 之间的关系，但 CS 架构导致互操作性有所降低（没有 broker，需要人为制定固定连接），而 CS 不采用 broker 可能导致被拦截。

    而在小型局域网（互联网还没有普及）时，规模有限，直接联系，性能与安全性平衡可能带来更大的收益。

  • 架构模式——点对点模式 Peer-to-Peer Pattern 组件-连接器模式

    • 点对点模式中的组件，可能这一时刻为提供者，下一时刻是消费者（对等的）。同时点对点模式不仅仅提供服务，还能提供物流，每个 peer 可能有一个规定对的连接数。
    • 对等（P2P）计算或网络是分布式应用程序体系结构，用于在对等体之间划分任务或工作负载。同行在申请中享有同样的特权，等同参与者。据说它们形成了节点的点对点网络。
    • 上下文：分布式应用程序体系结构，应用于对等体之间划分任务或工作负载。
    • 缺点：安全性管理、数据持久化、数据/服务可用性（availability）、备份、修复更复杂、小型点对点系统不能持续实现质量目标，类似性能（performance）和可用性（availability）。

  • 架构模式——面向服务的模式 Service-Oriented Pattern，SOA 组件-连接器模式

    • 面向服务的体系结构（SOA）是一种软件设计风格，其服务通过应用程序组件，通过网络上的通信协议提供给其他组件。
    • 面向服务的体系结构的基本原则独立于供应商，产品和技术。服务是一个独立的功能单元，可以远程访问并独立操作和更新，例如在线检索信用卡对帐单。
    • 面向服务的模式是 Broker Pattern 的延伸，Component 包含服务提供者、服务消费者、ESB（企业服务总线）、企业服务组件、连接处理（注册、发现），Connector 包含SOAP、REST、Asynchronous messaging connector。
    • 缺点：
      • 构建复杂
      • 无法管理独立服务的演化
      • 服务可能成为性能瓶颈（无法提供性能保障）
      • 使用中间件导致的性能开销（Overhead）

  • 架构模式——多层模式 Multi-Tier Pattern 分配模式

    • Layer 是真实存在的，这里的层是逻辑的组合，没有层次模式的强依赖关系，在不同的部署环境中分层不同，但是软件完成内容一致。
    • 许多系统的执行结构被组织成一组逻辑组件。每个分组被称为一个层。将组件分组到层中可能基于各种标准，例如组件的类型、共享相同的执行环境或具有相同的运行时目的。
    • 上下文：旅行社。
    • 缺点：大量的前期成本和复杂性。
    • 三大类：Modular 类、Runtime Process 动态类、软件和非软件环境关系（部署关系）

还有好多，放弃了…

想了解的仔细去看PPT吧

1.4 架构设计

  1. 【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：通过方案量化描述需求后，逐渐对质量属性进行分解细化，直到包含量化指标为止。
  1. 【2018】【2022】Software requirements, Quality attributes, ASRs 的区别和联系
  1. 软件需求包括：功能性需求和非功能性需求（又称质量需求）
  2. 非功能性需求包括：技术约束、商业约束和质量属性
  3. 质量属性是由软件的业务目标所决定，在功能性需求的基础上提供的整个系统的合乎需求的特性，是非功能需求的一种反应。
  4. ASRs ：架构攸关需求是对于体系结构有着深远影响的需求，肯定是软件需求的一部分。
  1. 【2018】描述 ADD 过程
  1. 确定有足够的需求信息
  2. 选择要分解的系统要素
  3. 确定所选的元素的 ASR
  4. 选择符合 ASR 的设计
    1. 找出设计问题
    2. 列出子关注点替代模式/决策
    3. 从清单中选择模式/决策
    4. 确定模式/决策与 ASR 之间的关系
    5. 记录初步的架构视图
    6. 评估并解决不一致的问题
  5. 实例化架构元素并分配职责
  6. 为实例化的元素定义接口
  7. 验证和细化需求并使它们成为实例化元素的约束
  8. 重复进行 2-7 步直到满足所有的 ASR

1.5 软件架构视图和文档化

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

  • 原因：

  • 不同视图支持不同的目标和用户，突出不同的系统元素和关系

  • 不同视图将不同质量属性暴露出不同的程度

  • 4种视图

  • 结构视图：如下

    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?
    分配视图描述了软件单元到软件开发或执行环境元素的映射
    分配视图目标是将软件元素所需的属性与环境元素提供的属性比较，以确定分配是否成功。
    分配视图可以描述静态或动态视图。    		部署视图、安装视图、工作分配视图、其他分配视图

  • 质量视图 Quality Views：安全视图、性能视图、可靠性视图、通信视图、异常（错误处理）视图

  • 组合视图 Combining Views：

    • 包括各种 C&C 视图、带有 SOA 或通信进程视图的部署视图、分解视图和任何工作分配、实施、使用或分层视图。
  1. 【2015】【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.

见上图

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

文档应包含 视图 View 和 视图之外 Beyond 两部分内容。

  • View部分
    • styles and views（架构风格和视图）
      • 它是如何构建为一组实现单元的？Module Styles
      • 它是如何构建为一组运行时行为和交互的元素的？Component-Connector Styles
      • 它与环境中的非软件结构有何关系？Allocation Style
    • Structural views
      1. module views
      2. C & C views
      3. Allocation views
    • Quality Views
    • Combining Views
  • Beyond部分
    • 文档路线图：包含了范围和总结、简单摘要等。
    • 视图的文档组织方式：描述了本文档中视图是如何组织的。
    • 系统概述：从整体上描述了当前架构的简要说明、业务目标（驱动因素）等等。
    • 视图之间的映射关系：描述了不同视图之间的映射关系。
    • 系统原理：从整体上描述了当前架构的设计原理。
    • 目录-索引、词汇表、首字母缩略词表。

1.6 架构评估

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

见上表

  1. 【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
  1. 【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. 发现敏感点：特定质量属性对其敏感的架构决策，比如在对性能敏感的系统中，决定使用缓存中间件。

1.7 微服务架构

  1. 【2019】微服务架构（MSA）和 SOA 的区别，相同点：
  1. 相同点：微服务和 SOA 都是分布式架构，微服务是 SOA 的一种扩展，都包含了服务契约、服务封装、服务重用、服务组合、服务自治和服务无状态等基本特点。
  2. 微服务去掉了 SOA 架构中的 ESB，采用轻量级通信机制（HTTP、REST）进行服务之间的通信。
  3. 微服务的管理和部署结合 DevOps 实现自动化，可以对服务进行自动化部署和监控预警。
  4. 微服务引入了 API 网关、对客户端屏蔽访问各项服务的问题。
  5. 微服务引入了熔断器：避免出现服务失效或网络问题等导致的级联故障。
  6. SOA 使用全局数据模型并共享数据库；MSA 每个服务有自己的数据模型和数据库
  7. SOA 服务是较大的单体应用；MSA 提供较小的服务
  1. 【2023 预测】微服务架构的主要特性：
  1. 通过服务组件化
    • 服务作为进程外组件，通过Web服务请求或 RPC机制通信
  2. 服务内部高内聚，服务间低耦合
  3. 围绕业务能力组织，而不是聚焦在技术层面。传统软件系统开发管理通常聚焦在技术层面
  4. 去中心化
    • 去中心化治理：构建微服务时可以有服务自己的技术栈选择
    • 去中心化数据存储：让每个微服务管理自己的数据库
    • 去中心化数据管理：强调服务间的无事务协作，最终一致性和补偿策略
  5. 基础设施自动化：依赖自动化的基础设施，降低开发和运维微服务的操作复杂度
  6. 服务高可用性设计、演进式设计
    • 高可用设计：完善的监控和日志记录
    • 演进式设计：合理设计实现频繁、快速且控制良好的增量变更和演化
  7. 每个服务相对较小并容易维护
  8. 服务可以独立扩展
  9. 技术栈不受限
  10. 大型复杂程序可以持续部署和交付
  11. 高可伸缩
  • 部署复杂性：
    • 应选择支持服务要求的最轻量级部署模式：Serverless < 容器 < 虚拟机……
      alt text
    • 部署模式列表
      • 单主机部署多个服务实例 ：资源相冲突的风险； 依赖版本冲突的风险
      • 单主机部署单个服务实例 ：资源利用率低
      • 将服务部署到虚拟机 ：资源利用率较低（整台虚拟机）；部署速度相对较慢（分钟级）；系统管理的额外开销（操作系统、运行补丁）
      • 将服务部署到容器 ：大量的容器镜像管理工作；基础设施不如虚拟机的丰富
      • 服务部署平台：额外技术学习和资源成本
      • 无服务器部署：长尾延迟；基于有限事件与请求的编程模型，不用于长时间运行的服务

软件详细设计

  1. 【2017】请至少说出三个面向对象的原则，并解释它们如何应用于策略模式？ Please name at least three Object-Oriented principles, and explain how they are applied in Strategy pattern?
  • 单一职责原则：在策略模式中，每个具体的策略类都实现了一个特定的算法或策略。每个策略类都有单一的责任，即实现其定义的算法逻辑。这确保了每个类在变化时只需修改自己的算法，不会影响其他策略或上下文对象。
  • 开闭原则：在策略模式中，这意味着可以通过定义新的具体策略类来扩展系统的行为，而不需要修改已有代码。上下文类通过接口与策略类进行交互，从而实现了对变化的封闭（通过接口定义的方式），对扩展的开放（可以添加新的策略类）。
  • 依赖倒置原则：在策略模式中，上下文类依赖于一个抽象的策略接口，而不是具体的策略实现类。这样，上下文类与具体的策略实现解耦，这种松耦合的设计有助于系统的灵活性和可维护性。
  • 里氏代换原则：上下文类与所有的具体策略类都是通过一个共同的接口或抽象类进行交互，上下文类不关心使用哪个具体策略，只要它们实现了策略接口即可。这种设计确保了不同的策略可以被无缝地替换，而上下文类无需修改。
  • 合成复用原则
  1. 【2019】设计模式是什么？举例说明类模式和对象模式的区别？
  • 设计模式定义：设计模式（Design Pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。
  • 区别：根据范围，可分为类模式和对象模式两种
    • 类模式处理类和子类之间的关系，这些关系通过继承建立，在编译时刻就被确定下来，是属于静态的。
    • 对象模式处理对象间的关系，这些关系在运行时刻变化，更具动态性。
  1. 【2019】防御式编程是什么？断言和错误处理的区别？【不考】
  1. 可以预见到（至少预先推测到）问题所在，断定代码中每个阶段可能出现的错误，并作出相应的防范措施，来防止类似的意外的发生。
  2. 断言和错误处理的区别
  3. 断言是在开发期间使用的、让程序在运行时进行自检的代码，是对开发人员的警告，通常是一个子程序或宏。断言不可以有副作用。
  4. 错误处理是对预先已经考虑到的错误（如用户错误、程序错误、意外情况等等）按照流程进行处理。
  1. 【2019】设计模式对 MVC 的影响？
  • MVC 模式使用了运行时、动态和相互之间的关系集成到开发框架中，是分层模式的变种。
    • 分为 model（业务逻辑）、view（处理用户展示，接收用户操作）、controller（对用户操作进行处理，将信息通知给 model）（强调模块间约束关系，model 不可以直接返回到 controller）
    • 优点：耦合性低，重用性高，生命周期成本低，部署快，可维护性高，方便管理
    • 缺点：没有明确定义，不适于中小型应用程序，增加实现复杂度，视图和控制器过于紧密，视图对模型访问低效。
  • MVC 模式是观察者模式、策略模式和组合模式的演化，可能涉及到工厂模式和装饰器模式
    • 基于推送-订阅模式
    • 观察者模式：model 发生变化通知 controller，然后更新 view
    • 策略模式：controllers 帮助 views 对不同用户的输入做不同的响应。
    • 组合模式：一组 views
  1. 【2019】策略模式和状态模式的区别？
  1. 在状态模式中，具体状态类的方法参数中包含上下文对象，需要在状态处理完成后完成状态切换。
  2. 在策略模式中，直接对上下文类调用 set 方法设置策略即可，不涉及到策略的切换。
  1. 【2019】最小知识原则在设计模式中的应用？
  1. 中介者模式【对象行为型模式】
  2. 外观模式【对象结构型模式】
  1. 【2022】Please explain the Liskov Substitution Principle and how it contributes to the Open- Closed Principle. (6 points)
  2. 【2022】Please explain how the Factory Method Pattern and Abstract Factory Pattern adhere to the Open-Closed Principle. (6 points)
  3. 【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)
  4. 【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)

设计题

  1. 【2019】一个游戏，有几种人类角色：骑士、骑兵、步兵，持有不同的武器（矛、剑、斧），拥有 fight 方法；有一个非人类角色巨魔，可以持有武器，但攻击方法不同（beat）。现在希望让巨魔和其他人类角色一起进行游戏，并且要求有角色死亡时其他活着的角色要收到通知。运用设计模式进行设计，并画出类图。
  2. 【2018】设计一个飞行模拟软件，要求能模拟多种飞机的特性。为了在将来支持更多飞机种类，要求使用策略模式。画出架构图和类图
  3. 【2019】一个买票系统的设计题，不同的角色有不同的打折方案，用策略模式设计， 最后画图，还要说明策略模式的使用场景。
  4. 【2015】【2019】

其他架构设计总结

by Zhy

系统架构