体系结构考试复习笔记

Table of Contents

考纲
#

基础部分：前四个ppt

大题

微服务部分：分析设计题（根据具体案例需求完成设计），可能包括服务拆分、通信、部署和迁移设计等，考察所学知识在实际设计任务中的灵活应用能力。
DDD部分：简答题，结合具体案例考察对于DDD原理、流程和应用的理解。
企业架构部分：简答题，考察对于企业架构原理、流程和意义的理解。

基础部分
#

1. 软件架构概述
#

1.1 什么是软件架构

SEI定义：是整个程序或计算系统的结构（Structure），包含了程序的元素（Software Elements）、外部可见的元素属性（Properties）和元素之间的关系（Relationship）。
IEEE定义：是一个系统的基本组织，包含了它的所有组件（Components）、组件之间的关系、环境以及指导该系统设计（Design）和演化（Evolution）的原则（Principle）。

元素、关系、设计、结构、属性

工业上：在所有设计阶段的重要决定组成的都称之为软件架构，按重要程度

1.2 软件架构用来做什么

将系统分解成组件、模块和子系统：定义了组件的接口，组件的交互和相互依赖关系，组件的职责；
说明了交流方式：包括数据传输机制和控制流；
架构处理非功能需求，包括技术约束、业务约束和质量属性

软件架构师（software architect）的工作：

联络（Liaison）：
1. 在客户、技术团队和商业/需求分析师之间；
2. 与管理层或营销层
软件工程（Software engineer）：软件工程最佳实践
技术知识（Technology knowledge）：对技术领域的深度理解
风险管理（Risk management）：与设计、技术选择有关的风险

1.3 架构从何而来

NFRs（非功能性需求，Non-Functional Requirements）：描述的是系统工作的有多好，包括技术约束、业务约束与质量属性
1. 性能（Performance）：系统响应时间、吞吐量、资源利用率等。
2. 可用性（Availability）：系统在一定时间内可正常工作的比例。
3. 可扩展性（Scalability）：系统应对增长需求的能力。
4. 安全性（Security）：系统防止未授权访问和数据保护的能力。
5. 可维护性（Maintainability）：系统的可修改、可调试和可扩展性。
6. 可移植性（Portability）：系统在不同环境中的运行能力。
ASRs（架构攸关需求，Architecturally Significant Requirements）：ASRs是对系统架构设计具有重要影响的需求。它们通常涵盖关键的NFRs和某些功能需求。ASRs通常是那些对系统成功至关重要的需求，如果忽视这些需求，系统可能无法满足预期的目标。
质量需求（Quality Requirements）：质量需求是对系统整体质量的期望，包括上述的NFRs。它们是ASRs的一部分，直接影响架构设计决策。例如，高性能需求可能会影响数据库选择和缓存策略，而高安全性需求可能会影响认证和授权机制的设计。
涉众（stakeholder）：涉众是指与系统有利益相关关系的所有个人或团体，包括但不限于：
1. 客户：出资和使用系统的人。
2. 开发人员：负责系统开发和维护的人。
3. 管理人员：负责项目管理和监督的人。
4. 用户：最终使用系统的人。
5. 运维人员：负责系统部署、监控和维护的人。
开发组织（organization）：开发组织是指负责系统开发的团队或公司。开发组织的能力、资源和经验对架构设计有直接影响。例如，开发团队的技术能力和经验可能会影响技术栈的选择和架构复杂性的控制。
技术环境（Technical Environments）：技术环境包括系统运行和开发所需的所有技术条件和工具，如：
1. 硬件环境：服务器、存储设备、网络设备等。
2. 软件环境：操作系统、中间件、数据库、开发工具等。
3. 开发工具和框架：编程语言、集成开发环境（IDE）、版本控制系统等。

1.4 架构视图（4+1）

场景视图（也叫用例视图）：黑盒视图。从外部视角，描述系统的参与者（用户）与系统功能用例的关系。反映的是系统的最终用户需求和交互设计。
逻辑视图（也叫结构视图）：白盒视图。从结构化视角，描述该系统对用户提供的所需功能服务所具备的组件结构和数据结构，以及一些边界约束条件，清晰的描述给用户提供的功能需求服务是如何构建的。描述该系统内部所具备了那些组织结构，以达到实现对外功能。
开发视图（也叫实现视图）：白盒视图。从结构化视角和行为视角，去描述实现系统功能的各个组件和模块是如何实现的。
处理视图（也叫过程视图、行为视图）：白盒视图。从行为视角，描述系统各个组件和模块是如何进行通信的。
物理视图（也叫部署视图）：黑盒视图。从交互视角，描述系统可以部署到哪些物理环境（如服务器、PC端、移动端等）上和软件环境（如虚拟机、容器、进程等）上。

逻辑视图：描述架构中重要的元素以及它们之间的关系。（静态的）

springcloud微服务的逻辑视图：

Java体系架构逻辑视图：

过程视图：描述架构中元素的并发性和交流。（动态的，运行时的）

物理视图：描述主要进程和组件如何映射到应用程序硬件。（软件和现实的关联）

开发视图：捕捉软件组件的内部组织。（开发时分配任务、项目管理（基于逻辑视图，关注开发顺序等））

架构用例：捕获架构的需求，不止与一个特定视图有关。

1.5 软件架构活动

为系统创建业务用例：业务用例是描述系统如何在不同情境下与用户或其他系统交互的场景。创建业务用例的目的是确保对系统功能需求有清晰的理解，并帮助识别关键的架构需求。
1. 与业务涉众讨论和确认系统功能。
2. 描述系统与用户或其他系统的交互过程。
3. 定义业务用例的触发条件、流程和预期结果。
理解需求：需求理解是架构设计的基础。需求包括功能需求和非功能需求，后者尤其重要，因为它们直接影响系统架构的决策。
1. 收集和记录需求。
2. 分析和分类需求。
3. 确定架构攸关需求（ASRs）。
构造并选择架构：构造和选择架构是软件架构活动的核心。它包括设计架构候选方案，并根据需求和约束选择最优的架构。
1. 设计多个架构候选方案。
2. 比较和评估不同方案的优缺点。
3. 选择最能满足需求的架构。
与涉众交流架构（包括开发者）：架构设计需要与各个涉众（包括开发者）进行有效的交流，以确保各方理解和支持架构决策。
1. 准备架构文档和示意图。
2. 召开架构评审会，与涉众讨论架构方案。
3. 收集反馈并做出相应调整。
分析和评估架构：
1. 整体方法；
  - 使用架构评估方法（如ATAM）。
  - 分析架构在不同场景下的表现。
2. 质量具体技术
  - 评估性能、安全性、可维护性等质量属性。
  - 使用原型或模拟测试关键质量属性。
实现架构：架构实现是将设计好的架构转化为实际的系统代码和配置。这一过程需要严格遵循架构设计，以确保系统的正确性和质量。
1. 制定详细的实施计划。
2. 分配开发任务，确保开发团队理解架构。
3. 编码、测试和集成系统组件。
确保与架构一致：确保最终的系统实现与设计的架构保持一致是软件架构活动的最后一步。这需要持续的监控和调整，以应对开发过程中可能出现的变化。
1. 定期进行架构评审和代码检查。
2. 使用自动化工具检测架构违背情况。
3. 解决架构不一致的问题，保持系统与架构一致。

1.6 架构过程

按照上面的图是需求规范→架构设计决策→逻辑设计细节→细节设计决策→物理设计细节

详细描述版本：

通过StackHolder获取到ASRs(架构攸关的需求)
通过排序、分析得到Prioritized Quality Attribute Scenarios(高优先级质量属性解决方案)和Requirements，Constraints(需求和约束)
将上述部分，结合模式和策略，综合可以得到架构的设计
根据架构的设计得到由模式决定的候选视图的示意图，之后完成文档化
选择、组合视图，将文档进行进一步的评估，这一部分需要StackHolders的参与、也需要Prioritized Quality Attribute Scenarios和文档等作为参考。

本科内容速记：从需求文档中收集ASR，通过采访涉众来收集ASR，通过了解业务目标来收集ASR，在项目树中管理ASR

ASR：除了设计文档，还要与 stakeholders 交互，通过 workshop 等形式，然后排序（根据对用户的重要程度、对开发人员来说是实现他的难易程度这俩个维度进行评价）

指定架构攸关需求（Specifying ASRs）
- 涉众（Stakeholders）：涉众包括所有与系统有利益相关的人员或团体，如客户、用户、开发团队等。
- 优先级质量属性场景（Prioritized Quality Attribute Scenarios）：从涉众收集并优先级排序的质量属性需求，如性能、安全性、可扩展性等。
- 需求和约束（Requirements and Constraints）：包括系统的功能需求和非功能需求，以及开发和技术约束。
架构设计（Architecture Design）
- 模式和策略（Patterns and Tactics）：使用设计模式和策略来指导架构设计，确保设计能够满足指定的质量属性。
- 候选视图草图（Sketches of Candidate Views）：根据设计模式和策略，创建架构候选方案的草图。
- 确定的视图（Determined by Patterns）：选择和确定最优的架构视图，以满足系统需求。
文档化（Documenting）
- 选定的组合视图及超出视图的文档（Chosen, Combined Views plus doc’n beyond views）：将选定的架构视图进行组合，并进行详细的文档化，不仅包括视图，还包括额外的架构说明和设计决策。
架构评估（Architecture Evaluation）
- 架构评估（Architecture Evaluation）：对设计好的架构进行评估，确保其能够满足所有的需求和约束。
  - 评估可能包括使用架构评估方法，如ATAM（Architecture Tradeoff Analysis Method），分析架构在不同场景下的表现。
  - 涉众参与评估，提供反馈和改进建议。
反馈循环
- 反馈和改进（Feedback and Improvement）：通过评估得到的反馈，可以用于改进架构设计。
  - 这种反馈循环确保架构在整个开发过程中不断得到验证和优化，最终确保系统的质量和性能。

tactics是什么东西：一般指的是战术模式

DDD中的战术模式包括但不限于以下几种：

实体（Entity）：具有唯一标识和生命周期的对象，其属性随时间变化。
值对象（Value Object）：描述领域概念的属性集合，通常用于描述没有独立存在意义的对象，它们是不可变的。
聚合（Aggregate）：一组相关对象的集合，它们一起作为数据修改的单元，有一个根实体（Aggregate Root）来控制外部对象对聚合内对象的访问。
领域事件（Domain Event）：领域中发生的业务事件，通常用于触发领域内其他业务逻辑。
领域服务（Domain Service）：执行领域逻辑的无状态服务，通常作为领域模型的一部分，但不归属于任何聚合。
存储库（Repository）：提供对聚合根的检索和持久化机制的接口，封装了数据访问逻辑。
工厂（Factory）：用于创建复杂对象的类或方法，隐藏对象创建的复杂性，通常与聚合根相关联。

1.7 软件架构知识领域

软件设计的基本概念：
- 软件开发的生命周期：
  1. 需求分析：收集和定义软件的功能和非功能需求。
  2. 设计：创建软件的架构和详细设计。
  3. 构造：编码和实现软件。
  4. 测试：验证和确认软件的功能和质量。
  5. 部署：将软件交付给用户。
  6. 维护：对软件进行修改和改进。
- 设计过程：
  1. 系统设计：定义系统的整体架构，包括主要组件及其交互。
  2. 详细设计：定义每个组件的内部结构和算法。
- 整体设计概念：
上下文：软件开发周期——需求、设计、构造和测试；
- 需求：定义系统必须实现的功能和特性。
- 设计：制定满足需求的系统架构和设计细节。
- 构造：将设计转化为可运行的软件代码。
- 测试：验证软件是否符合需求并且没有缺陷。
关键问题（技术）：并发性（concurrency）、事件的控制和处理、分发、异常处理、交互系统、持久性
- 并发性（Concurrency）：管理多个任务同时执行，保证系统的高效性和可靠性。
- 事件的控制和处理：处理系统中的各种事件和信号，确保系统的响应能力。
- 分发（Distribution）：在多个计算节点上分配和协调任务，确保系统的可扩展性。
- 异常处理（Exception Handling）：检测和处理系统中的错误和异常，保证系统的稳健性。
- 交互系统（Interactive Systems）：设计用户界面和用户交互流程，提高用户体验。
- 持久性（Persistence）：管理数据的长期存储和访问，确保数据的可靠性和可用性。
软件结构和架构：体系结构样式和模式（宏观体系结构，macro-architecture），设计模式（微观体系结构，micro-architecture）
- 宏观体系结构（Macro-architecture）：定义系统的整体结构，如分层架构、微服务架构等。
- 微观体系结构（Micro-architecture）：定义组件内部的设计模式，如单例模式、工厂模式等。
软件设计方法：架构方法（如ADD，属性驱动设计）、设计方法（如DDD，领域驱动设计）
- 属性驱动设计（Attribute-Driven Design, ADD）：基于系统的质量属性（如性能、安全性）进行架构设计。
  - 识别质量属性：根据系统需求和涉众期望，确定关键的质量属性。
  - 定义架构策略：针对每个质量属性，制定实现和优化的策略。
  - 创建架构视图：根据架构策略，设计系统的逻辑视图、开发视图、过程视图和物理视图。
  - 评估和改进架构：通过评估方法（如ATAM），验证架构是否满足质量属性需求，并进行必要的改进。
- 领域驱动设计（Domain-Driven Design, DDD）：以业务领域为核心进行设计，通过模型驱动开发来解决复杂的软件系统问题。
  - 领域模型：创建一个反映业务逻辑的模型，用于指导系统设计和实现。
  - 限界上下文（Bounded Context）：将系统划分为多个独立的子系统，每个子系统有明确的边界和职责。
  - 聚合（Aggregates）：定义由一组相关对象组成的聚合，用于维护数据的一致性和完整性。
  - 实体（Entities）和值对象（Value Objects）：区分具有唯一标识的实体和不变的值对象。
  - 仓储（Repositories）：提供访问和管理聚合根的接口，处理数据存储和检索。
  - 服务（Services）：定义不属于任何实体或值对象的业务逻辑操作。
- 动态系统开发方法（Dynamic Systems Development Method, DSDM）
  - 用户参与：确保最终用户在整个开发过程中持续参与，以便及时反馈和改进。
  - 频繁交付：定期发布可工作的产品增量，以便早期识别问题并进行调整。
  - 业务需求优先：将业务需求置于技术需求之上，确保开发的每个功能都能满足业务目标。
  - 合作和团队合作：促进开发团队、业务团队和用户之间的紧密合作。
  - 质量内建：将质量保证作为开发过程的一部分，而不是事后的检查。
  - 可变范围：在固定时间和资源的前提下，灵活调整需求和范围，以实现最优的业务价值。
  - 持续交付和集成：保持代码的持续交付和集成，确保系统始终处于可用状态。
软件设计质量分析和评估：质量属性、策略、质量分析和评估的方法技术和工具
- 质量属性：软件设计质量属性包括性能、可用性、安全性、可维护性等。
- 策略：通过设计策略来实现和优化质量属性，例如使用缓存来提高性能，使用冗余来提高可用性。
- 质量分析和评估的方法、技术和工具：
  - 方法：如ATAM（Architecture Tradeoff Analysis Method）。
  - 技术：如静态代码分析、性能测试。
  - 工具：如SonarQube、JMeter。
微服务架构、业务和企业架构
- 微服务架构：微服务架构是一种将应用程序设计为一组松耦合、独立部署的服务的架构模式，每个服务负责特定的业务功能。
- 业务架构：业务架构描述了组织的业务策略、业务流程和业务能力，确保业务需求与技术实现之间的对齐。
- 企业架构：企业架构是一种全面的架构方法，用于描述和设计整个组织的信息技术基础设施，确保业务和IT战略的一致性。

课堂知识点

科学和工程有什么不同？What is Difference between Science and Engineering?
1. 科学的研究是研究这个世界既有的部分
2. 工程是研究的是人类创造新的世界(是不是因为人才产生的)
软件和硬件有什么不同？What is Difference between ‘Software’ and ‘Hardware’ ?
1. 软件是不可⻅的：软件是虚拟的，而硬件是实体的。
2. 软件制作出来就是为了被修改和改变的(软件的演化是他的本质属性)
体系结构和设计有什么不同？What is Difference between Architecture and Design?
1. 所有的体系结构都是软件设计，但是不是所有的软件设计都是体系结构
2. 体系结构是设计过程的一个过程。
3. 其他观点 a. 体系结构是更高层的设计，是为了修改的 b. 体系结构是设计决策的组合
体系结构和结构有什么不同？What is Difference between Architecture and Structure?
1. 体系结构定义了组件(Component)的接口，Component之间如何交流以及如何相互依赖，Component的职责。
2. 体系结构提供了设计的更高层抽象视⻆，隐藏设计的复杂性和实现，更强调非功能性需求。
3. 【标准】架构是包括结构信息的，因为结构是一种静态的、逻辑的、是关于系统如何构成。但是架构除了包含结构，还会增加组件的相互之间的关系接口，还会定义一些动态的行为(一个组件可能和谁进行交互)
为什么要在架构中使用抽象？Why Abstraction in Architecture?
1. 更高层的视⻆，更关注本身的结构而不是本身的实现。
2. 降低架构设计时的系统复杂度，可以屏蔽和隐藏一些细节。

补充知识点

1.1 宏观体系结构

分层架构（Layered Architecture）：将系统分解为逻辑层次，例如表示层、业务逻辑层和数据访问层。
管道-过滤器架构（Pipes and Filters）：组件（过滤器）通过管道连接，数据在管道中流动，每个过滤器对数据进行处理。
事件驱动架构（Event-Driven Architecture）：系统组件通过事件进行通信，事件触发特定的处理逻辑。
微服务架构（Microservices Architecture）：将应用程序分解为一组小服务，每个服务围绕特定业务功能构建，独立部署和扩展。

1.2 属性驱动设计（Attribute-Driven Design, ADD）

这种方法侧重于识别和满足系统的关键质量属性，如性能、可靠性、可用性、可维护性和安全性。设计决策基于这些属性的需求来进行。

识别关键属性：确定系统的关键质量属性，如性能、可靠性、可扩展性和安全性。
定义场景：创建场景来模拟用户行为和系统负载，例如，高流量下的购物车操作、支付处理等。
分析和设计：根据关键属性设计系统架构，例如，使用负载均衡来提高性能，使用冗余服务器来提高可靠性。
权衡决策：在不同的质量属性之间做出权衡，例如，可能需要在快速响应时间和系统复杂性之间做出选择。
原型和评估：开发原型并对其进行评估，以验证设计是否满足所有关键属性。
迭代改进：根据评估结果迭代改进架构，直到满足所有关键属性的要求。

1.3 ATAM，即架构权衡分析方法（Architecture Tradeoff Analysis Method）

准备阶段：确定评估目标和范围。选择评估团队，包括架构师、利益相关者和领域专家。
架构描述：详细描述当前架构，包括组件、它们之间的关系以及架构决策。
场景开发：基于质量属性需求，开发一系列场景，这些场景模拟了系统在不同条件下的行为。
场景分析：对每个场景进行分析，评估架构如何支持或违反质量属性需求。
权衡优先级：确定架构中的关键权衡点，如性能与可扩展性、安全性与可用性等。
风险评估：识别架构中的风险和潜在问题，评估这些问题对项目的影响。
决策和建议：根据分析结果，提出改进建议和决策支持，帮助团队做出更明智的架构选择。
报告和记录：编写详细的评估报告，记录分析过程、发现的问题和建议。

ATAM的应用：

质量属性焦点：ATAM专注于质量属性，如性能、可靠性、可用性、安全性等，确保架构设计能够满足这些关键需求。
多角度评估：通过不同利益相关者的参与，ATAM提供了多角度的评估视角，增加了评估的全面性和客观性。
风险识别：ATAM有助于识别架构设计中可能被忽视的风险和问题，为风险管理提供支持。
持续改进：ATAM是一个迭代的过程，可以在软件开发的不同阶段重复应用，以持续改进架构设计。

软件架构为什么重要：

便于交流、协调顾客需求；
实现早期的设计决策；促进质量属性的实现；
包含潜在的change change包括（local.nonlocal.architectural）等等其他

1.8 软件产品线的体系结构与简单产品的体系结构的区别

产品线的目的是实现高重用性与高可修改性，之所以十分有效是因为可以通过重用充分利用产品的共性，从⽽实现生产的经济性。
在产品线架构中有一组明确允许发生的变化，但是对于常规架构来说，只要满足了单个系统的行为和质量目标，几乎任何实例都是可以的。

2. 质量属性
#

属性分为内部的，和外部的。用户能否感知（observable）

课上，重点学习了常⻅的质量属性。

以ability结尾。

常⻅的混淆问题：可用性和易用性 availability& usability

可用性和互用性：availability& interoperabilit

2.1 软件需求

功能性需求（Functional requirements）
- 功能需求说明系统必须做什么，并说明系统如何为涉众提供价值。
- 功能需求是指系统的行为。
- 功能是系统完成其预期工作的能力，例如，允许学生在线注册。
- 功能可以通过使用任意数量的可能结构来实现。
- 功能在很大程度上独立于结构，因为它可以作为一个单独的单片系统存在，而不需要任何内部结构。
质量需求（Quality requirements (NFRs)）
- 质量要求是整个系统的理想特性，系统应该在其功能需求之上提供质量属性。
- 质量要求是功能需求或整个产品的资格。
- 如果质量属性很重要，那么软件架构会限制将功能分配或映射到各种结构上。
约束（Constraints）
- 约束是零自由度的设计决策
- 约束是预先指定的已经做出的设计决策。
- 通过接受设计决策并将其与其他受影响的设计决策进行协调，可以满足约束。

2.2 质量属性

考题 2. How to model quality attribute scenarios? Graphically model two quality attributes in “stimulus-response” format: availability and performance.

Modeling quality attribute scenarios
- 刺激源（Source）：生成刺激的实体（人、系统或其它刺激器）
- 刺激（Stimulus）：是某事物，当其到达系统后需要对其加以考虑
- 环境（Environment）：刺激发生时的各种条件
- 制品（Artifact）：可能是整个系统，或系统的一部分
- 响应（Response）：刺激到达后采取的反应
- 响应度量（Response Measure）：能够以某种方式对响应进行度量
Availability, Interoperability, Modifiability, Performance, Security, Testability, Usability, X-ability…
- Availability：可用性。和整个程序的可靠性（Reliability）有关，是系统修复故障的能力，是大多数IT系统和应用的关键需求。Fault：错误，系统内在的缺陷，特定条件下才会触发。Failure：故障，由fault导致的结果。Error：failure和fault之间的状态。
- Interoperability：互操作性。描述多个系统在特定上下文中通过接口交换有用信息的程度，包括交换和正确推断信息。
- Modifiability：可修改性。用于评估一个更改所消耗的时间和金钱，包括所做更改对其他功能或者质量属性的影响程度。
- Performance：性能。与时间有关，用于评估软件系统满足时间需求的能力。响应时间=处理时间和等待时间。
- Security：安全性。衡量系统在向合法用户提供服务的同时，阻止非授权使用的能力。
- Testability：可测试性。描述的是通过测试揭示软件缺陷的容易程度。
- Usability：易用性。用户去完成一个特定任务的容易性程度和系统所提供的用户支持的种类。
- X-ability：可变性、可移植性、可伸缩性、可部署性、可复用性…
- Mobility：移动性，解决平台之间的移动和支持（大小、显示器类型、带宽、电池等)
- Safety：安全性，与security相比，不是有意为之，关注自身安全，防止偶然可能造成破坏的对象。
- Development Distributability：支持分布式软件开发
Tactics for quality attributes
- 每年都会考"How to model quality attribute scenarios? Graphically model two quality attributes in “stimulus-response” format: x-ability and y-ability."
- 或者让你说几个tactics和他们的用处，把每个刺激-响应的图和表看看，背几个tactics。（重点可用性，可修改性，都考过两次）

utility tree ：抓住不同解决问题的策略，每个分支都提供最小粒度的tactic

设计决策 Tactics

Tatics是一种设计决策（等同于design decision）
tactics的集合称为体系结构策略，A collectionof tactics is called an architectural strategy
Tactics可以由tactics组成，pattern一样。

Tactics等同于Quality Design Decisions：

结构是设计决策的集合，Architecture is a collection of design decisions
7个设计决策的类型：重要，后面复习大纲重点提了
1. 职责分配 Allocation of responsibilities：将大的职责进行分配
2. 协调模型 Coordination model：各部分之间的沟通、交互
3. 数据模型 Data model：数据格式、存储方式(缓存等)
4. 资源管理 Management of resources：CPU、网络、内存、时间(部分时间敏感的场景)等资源
5. 架构元素之间的映射 Mapping among architecture elements：将架构元素如何映射到软件的实现上
6. 绑定时间决策 Binding time decisions：
  1. 系统的变化可以在什么时间点前需要固定下来，也就是这个时间前，系统还是可以变化的，但是这个时间之后就不可以变化了
  2. 比如选择安装环境是需要在一个时间点前完成的，技术是否添加、编译时间、初始化时间，运行时绑定，但运行时是弹性最大的
  3. 实际上我们希望绑定时间越往后越好，但是也就要付出相应的代价
7. 技术选择 Choice of technology：前面的部分都确定后，我们可以选择技术栈相对比较局限，解空间已经被压缩了。

多个质量属性以及对应的通用场景、刺激响应图

通用场景是系统独立的场景，目的是去引导整个质量属性需求
具体场景是系统相关的场景，目的是去构建在质量属性在具体应用上的定义。这是通用场景的一种扩展。

2.3 如何识别ASR

ASR是将会对架构产生深远影响的需求，如果没有这样的需求，架构可能会有很大的不同。质量属性需求越困难、越重要，就越可能对架构产生重大影响，因此可能是ASR，ASR的实现可能会影响质量属性。
识别ASR的方式：需求文档、访谈利益相关人员（涉众）、理解业务目标、质量属性效用树（utility tree）。

补充知识点

质量属性效用树（utility tree）

质量属性效用树的组成部分：

质量属性（Quality Attributes）：树的根是系统的主要质量属性，如性能、安全性、可维护性等。
效用（Utility）：从每个质量属性分支出的节点代表该属性对用户的具体效用，即该属性如何影响用户的需求和满意度。
场景（Scenarios）：进一步细分，每个效用节点下可能挂接具体的使用场景或情境，描述在特定情况下质量属性如何影响用户体验。
需求（Requirements）：与每个场景相关联的是特定的需求，这些需求描述了系统在该场景下应如何表现以满足用户期望。
权衡（Trade-offs）：树中也可能展示不同质量属性或效用之间的潜在权衡，因为提高一个属性可能会牺牲另一个属性。
优先级（Prioritization）：通过效用树，团队可以确定哪些质量属性和效用对项目最重要，从而为需求优先级排序提供依据。

质量属性效用树的作用：

需求发现：帮助团队发现和理解用户对系统质量的期望。
沟通工具：作为与利益相关者沟通质量属性重要性的工具。
决策支持：在设计和实现阶段，支持团队做出关于资源分配和设计选择的决策。
风险管理：帮助识别可能影响质量属性的风险和潜在问题。
测试和验证：指导测试计划的制定，确保关键的质量属性得到验证。

建模步骤：

确定质量属性：识别系统的关键质量属性。
定义效用：确定每个质量属性如何影响用户和系统。
创建场景：为每个效用定义具体的使用场景。
细化需求：从场景中提取具体的需求。
评估优先级：确定哪些质量属性和效用最为关键。
分析权衡：识别和讨论不同质量属性之间的权衡。

质量属性效用树的图

mermaid代码:

graph TD
    A[软件系统] --> B[性能]
    A --> C[可靠性]
    A --> D[安全性]
    A --> E[可用性]
    B --> B1[响应时间]
    B --> B2[并发用户数]
    B --> B3[数据吞吐量]
    C --> C1[故障恢复时间]
    C --> C2[系统稳定性]
    D --> D1[数据加密]
    D --> D2[访问控制]
    E --> E1[系统正常运行时间]
    E --> E2[故障通知]

3. 架构模式（Architectural Patterns）
#

3.1 架构模式

架构模式是一组适用于反复出现的设计问题的设计决策集合，并对不同的软件开发上下文下的问题进行了参数化处理。架构模式是在不断尝试中找到的、有着可重用的一组属性，描述了一组架构的类别。

描述的是下边三者之间的关系：

上下文context：现实生活中反复出现的、导致这个问题的情况。
问题problem：给定上下文中出现的问题。
解决方案solution：元素+关系+约束。对成功的结构解决方案适当的抽象。

只能被发现而不是发明，不可能完全被发现
理解：如果只有解决方案，就蜕变成⻛格

元素（Elements）：
元素是问题域或系统的基本构成部分或组件。
在软件设计中，元素可能指代类、对象、模块、服务等。
在现实生活中，元素可以是问题涉及的个人、物体、事件等。
关系（Relationships）：
关系定义了元素之间的相互作用、连接或依赖。
在软件中，关系可以是对象之间的继承、组合、关联等。
在现实生活中，关系可以是人与人的社交联系、物体之间的物理连接等。
约束（Constraints）：
约束是限制元素和关系的条件、规则或限制。
它们可以来自于技术限制、业务规则、法律要求或设计决策。
约束指导如何在给定的边界内构建元素和关系。

DSSA：Domain-Specific Software Architecture特定领域软件构造：关注特定任务、生成领域内高效使用并且有标准的构建成功应用的拓扑，是最大化复用已有知识和进行前向发展设计的最佳实践。

Pattern和tactic的关系

都是固定的形式组合，解决反复出现的某一类问题
策略比模式更简单，策略使用单个的结构或者机制处理单个架构关注点；
模式是由多个设计决定组合成的包；
模式和策略一起构成了软件架构的基本工具
策略是对创建架构模式的设计进行块的构建；
大多数的模式包含：为一个共同的目的服务；需要保障不同的质量属性，比如layered 模式

具体的pattern

design strategies:【strategies 和 tactic的中文都是指策略，但是前者更为宏观，后者偏向具体实施】

可以分成三类：模块模式、组件-连接器模式以及分配模式。

架构模式是在实践过程中发现的，而不是被创造出来的，因此永远不会拥有一个完整的架构模式集合。

考点：每个模式的内容、好处、限制以及模式间的对比。

3.2 模块模式（Module Patterns）

Module pattern 静态的，结构化的

layered 最经典的分层的，在内部和在层和层之间进行约束

Layered pattern (micro-kernel pattern)：分层模式是将系统分解为多个层次，每个层次负责不同的职责，并通过特定的接口进行交互。常见的分层包括表示层、业务逻辑层和数据访问层等。
- 表示层（Presentation Layer）：处理用户界面和用户交互。
- 业务逻辑层（Business Logic Layer）：包含系统的业务规则和逻辑处理。
- 数据访问层（Data Access Layer）：负责与数据库或其他存储系统的交互。
微内核模式（Micro-Kernel Pattern）：微内核模式，亦称为插件架构模式，是将系统的核心功能和可扩展部分分离，核心部分只包含最基本的功能，而其他功能通过插件或扩展模块实现。核心模块负责提供插件管理、通信和基本服务。
- 插件管理：负责加载、卸载和管理插件。
- 基本服务：提供插件所需的基础服务和接口。

3.3 组件-连接器模式（Component-Connector Patterns）

Component connector patterns 不会存在孤立的connector 根据需要选择 Broker 等

Broker pattern：Broker Pattern是一种用于分布式系统的模式，其中的组件通过中介（Broker）进行通信，Broker负责管理组件之间的交互和数据传输。

Client <-> Broker <-> Server

Model-view-controller pattern：MVC模式将系统分为三部分：模型（Model）、视图（View）和控制器（Controller）。模型管理数据和业务逻辑，视图负责用户界面，控制器处理用户输入并更新模型和视图。

Pipe-and-filter pattern：Pipe-and-Filter Pattern将系统分为一系列独立的过滤器（Filter），每个过滤器执行特定的处理操作，过滤器之间通过管道（Pipe）传递数据。

Input -> Filter1 -> Filter2 -> Filter3 -> Output

Client-server pattern：Client-Server Pattern将系统分为客户端（Client）和服务器（Server），客户端发出请求，服务器处理请求并返回响应。

Client <-> Server

Peer-to-peer pattern：P2P模式中的每个节点既是客户端又是服务器，各节点之间对等通信和资源共享。

Node <-> Node <-> Node

Service-oriented pattern：SOA模式将系统功能封装为独立的服务，各服务通过标准接口进行通信和协作。

Service1 <-> Service2 <-> Service3

Publish-subscribe pattern：发布-订阅模式中，发布者（Publisher）将消息发送到特定主题，订阅者（Subscriber）订阅主题并接收相关消息。

Publisher -> Topic -> Subscriber

Share-data pattern：共享数据模式中，各组件通过共享数据存储进行通信和数据交换。

Component1 <-> Shared Data <-> Component2

3.4 分配模式（Allocation Patterns）

Allocation Patterns如何把软件元素对应到物理世界的环境

Map-reduce pattern：Map-Reduce模式是一种用于大规模数据处理的分布式计算模型。它将数据处理任务分解为两个阶段：Map阶段和Reduce阶段。
- Map阶段：将输入数据分割成若干独立的块，并行处理这些数据块，生成中间结果。
- Reduce阶段：将Map阶段生成的中间结果进行合并和处理，生成最终结果。

map-reduce Multitier pattern【可能会跨越不同层之间的交互，每一个层不一定存在，区分和 layerer pattern】

Input Data -> Map -> Shuffle and Sort -> Reduce -> Output Data

Multi-tier pattern：多层模式（Multi-Tier Pattern），也称为多层架构，是将应用程序分解为多个层次，每个层次负责特定的功能和职责。常见的层次包括表示层、业务逻辑层和数据访问层。
- 表示层（Presentation Tier）：负责处理用户界面和用户交互。
- 业务逻辑层（Business Logic Tier）：包含系统的业务规则和逻辑处理。
- 数据访问层（Data Access Tier）：负责与数据库或其他存储系统的交互。

Client -> Presentation Tier -> Business Logic Tier -> Data Access Tier -> Database

针对每个设计属性给出check list ，所作出的设计决定是否完整覆盖了那七个方面。

responsibilities：责任、和功能需求不一样，为实现质量要求而赋予的责任
coordinattion：不同元素之间的相互关系，可能是静态或动态
data：为了实现的执行加密、存储等，对数据进行操作
resources：资源的分配
elements mapping：怎么将架构映射到软件元素
time binding：确定时间，变化的可能性
technology：技术栈要掌握

ADD 有哪些步骤，然后每个步骤的输入输出 ADD2.0有八个步骤

3.5 模式与战术（Patterns vs. Tactics）

战术比架构模式简单，战术使用一种结构或机制去解决一个单独的架构问题
战术是一种设计决策，而架构模式是一组设计决策的集合
都是架构师的基础工具
战术是设计的基石，有了战术才能发现架构模式
大多架构模式包含几个不同的战术，他们可能用来实现同一个目标，也可能分别用于满足不同的质量属性。例如分层模式体现了增加内聚，降低依赖的战术
大多数架构模式也会包含其他架构模式

4. 架构设计（Designing Architecture）
#

4.1 通用设计策略

Abstraction抽象：提取系统的关键特性和功能，同时忽略不必要的细节。
Decomposition分解：
- 将质量属性需求分解并分配给元素，使其满足给定的约束条件，实现系统的质量和业务目标。
- 质量属性需求可以被分解，并且分配给分解好的元素。要考虑给定的约束并安排分解，以便可以适应这些约束。设计活动的目标是生成能够适应约束并实现系统质量和业务目标的设计。
Divide & conquer分治：根据ASR逐步设计，最后整合出完整的架构。
Generation and test生成和测试：
- 生成当前的设计，并将其看做一个假设，然后测试当前假设中的错误，在下⼀个设计假设中修正当前的错误，只保留正确的东西。
- 把一个特定的设计作为假设：这个设计版本的假设中有误的内容要在下个版本修复，正确的内容继续保持。
  - 初始假设的来源：已存在的系统；框架；模式和策略；设计检查表。
  - 测试应用：分析技术、设计检查表（清单）（重复一遍）
    1. Allocation of Responsibility
    2. Coordination Model
    3. Data Model
    4. Mapping among Architecture Elements
    5. Resource Management
    6. Binding Time
    7. Choice of Technology
其他没有具体的内容的：Iteration（迭代）Reusable Elements，Abstraction，Divide & Conquer
- Iteration迭代：不断地重复生成和测试来进行迭代。
- Reuse重用：提取设计中可以重用的元素，可以供日后使用。

4.2 设计决策类别

Responsibilities - 责任
Coordination - 协调
Data - 数据
Resources - 资源
Elements mapping - 元素映射
Binding time - 绑定时间
Technology - 技术

4.3 属性驱动设计（Attribute-Driven Design）

输入：功能需求、质量属性、约束
输出：软件元素（完成各种决策和职责、定义属性并与其他软件元素相关以组成系统架构的计算或开发工件）、角色（一组相关职责的集合）、职责、属性、元素之间的关系
8个步骤：
1. 确认有效的需求信息
2. 选择一个系统元素进行分解
3. 识别这个元素的ASR：为每个需求列出一个H、M和L构成的二维数组（H、H），前者表示这个需求对涉众的重要性，后者表示对系统架构的影响。
4. 选择一个满足ASR的设计
  1. 确认设计关注点，
  2. 为次要关注点列出不同的模式的策略，
  3. 选择合适的模式和策略，
  4. 确定ASR和模式策略之间的关系，
  5. 得到架构视图，
  6. 评估并解决不一致问题
5. 实例化元素并分配职责
6. 为实例后的元素定义接口
7. 验证和细化需求、为元素构造约束
8. 重复步骤2-7，直到满足所有ASR。

5. 领域驱动设计（Domain-Driven Design）——简答题
#

不会考DDD的流程！

重点1：DDD设计过程中，三个空间

极限押题：

重点2：6个模式概念和解决的问题
注意实体和值对象的名词的差别，原话：这俩个非常重要
搞清楚为什么要有这些标红的模式？可能让大家分析一下这些模式提出来的原因和原理是什么。

ps：第一次上课记录：

在战略设计里面梳理限界上下文

标红的尤其关注：是什么、领域驱动分析、设计和实现模式解决了什么
实体和值对象的俩大区别
面向对象的基础之上的聚合的模式
理解每个模式解决的问题以及为什么要设计

领域驱动设计（DDD）

域和域模型（Domain & Domain model）
服务分解（Service decomposition）
战略模式：边界上下文、共享内核、合作伙伴关系、上/下游流、客户/供应商（Strategic patterns: Bounded Context, Shared Kernel, Partnership, Up/Down Stream, Customer/Supplier）
策略模式：实体、值对象、域事件、聚合、域服务、存储库、工厂（Tactic patterns: Entity, Value Object, Domain Event, Aggregate, Domain Service, Repository, Factory）

原理、流程和应用（结合具体案例）

6. 企业与业务架构——简答题
#

经典方法没有必要掌握

EA 企业架构：

课堂

领域一些已有的经典方法，结合一些具体的案例（比较老）
理解基本的背景、以全局化、结构化的思维（说了无数次）

原理、流程和意义

7. 微服务架构（MSA）——分析设计题
#

用了五个课时讲的针对微服务的问题、有哪些可复用的方案

原话记录：不会考大家微服务的定义、而是考特性

6个特性：
- 拆分服务–组件化（通过进程间通信的方式变成独立单元）；
- 微服务中，团队围绕业务组织；
- 服务与服务之间遵循面向对象的高内聚低耦合；
- 拆分后的分布式系统，服务数量变多，可能带来一致性等问题，具有去中心化的特性；
- 自动化的管理，依赖基础设施服务（主要是运维层面）；
- 设计过程中针对质量属性的策略，核心是故障，保障服务等设计；SOA和微服务不同的三个点了解一下（不重要

主要特性、优势、问题和挑战 -> 微服务架构设计模式

基础知识：可能会考：主要特性—（6大特性）巴拉巴拉讲了6个特性），⻅上面原话记录
核心架构设计模式模式解决的问题、和需求、模式之间的关系

也就是说要看每个模式有哪些问题和context、然后具体的解决模式对应（背不下来啊

拆分模式：包括在上面主要特性的时候，针对不同问题、上下文谈谈理解、约束部署的时候不同模式的差分
业务能力：具有层次结构的，包含子结构
通信模式：重点复杂建议看原版ppt和review ppt 如何选择；针对故障的问题；服务实例如何交互
数据模式：context ，数据可能来自多个服务，读和写–API组合查询模式；saga 数据一致性；
部署模式：重要，对着reiview ppt 的图，部署服务的约束：服务之间是异构的；实例之间的隔离性（从故障出发）；成本考虑; 有6个模式，要理清之间的关系，哪些互为替代，不断发展演化【大家要重点掌握
运维模式：原话简单过以下就好了，那就不记了；但是讲了很久，可以看下模式，从ppt找到所支持的基础设施

复习课讲了很多个重点X

包括但不限于：拆分和定义，数据模式，通信模式、数据模式、部署模式

基础知识:原话是只要了解基础知识，考试只看标红的（微服务全是标红的）

极限押题：一道大题=拆分+通信模式、部署模式

微服务架构是把应用程序功能性分解为一组服务的架构风格，每一个服务都是由一组专注、内聚的功能职责组成。服务之间采用轻量级通信机制进行交互，可以进行分布式管理，从而支持不同的编程语言进行开发和不同的数据存储技术进行存储。是分布式架构，SOA的一种拓展。

电商应用微服务架构

FTGO（订餐平台）微服务架构

主要特性

服务组件化：将服务拆分设计成一个一个组件，组件之间通过轻量级通信机制进行交互。
围绕业务能力组织：
1. 围绕业务能力进行划分，而非技术。团队跨职能、全方位开发。
2. 采用产品开发模式，团队开发完就解散。
内聚和解耦：
1. 单一职责，每个微服务有各自的领域逻辑。
2. 微服务间尽量减少直接依赖，独立自治，实现解耦。
去中心化：
1. 去中心化治理，微服务可以有自己的技术栈选择，服务之间只需约定接口，无需关注内部实现。
2. 去中心化数据存储，每个微服务管理自己的数据库。
3. 去中心化数据管理。
基础设施自动化：
1. 依赖自动化的基础设施，降低开发和运维微服务的操作复杂度。
2. 持续部署和交付。
3. 测试：单元测试、集成测试、组件化测试、契约测试和端到端测试等。
服务设计与演进：
1. 高可用设计，可以快速发现不良突发行为并尽早修复。
2. 演进式设计，合理设计实现频繁、快速且控制良好的增量变更和演化，合适的服务解耦，只需重新部署修改的服务。
优点：高可伸缩、每个服务相对较小并独立维护、技术栈不受限、服务可以独立扩展、大型复杂程度可以持续部署和交付。
缺点：设计复杂性、网络延迟、联调、故障定位和修复。

微服务和SOA服务（面向服务架构）

相同点：微服务和SOA都是分布式架构，微服务是SOA的一种扩展，都包含了服务契约、服务封装、服务重用、服务组合、服务自治和服务无状态等基本特点。
不同点：
1. 服务间通信：SOA采用智能管道（如ESB，企业服务总线），依靠重量级协议；MSA采用哑管道（如消息代理），依靠轻量级协议。
2. 数据管理：SOA采用全局数据模型并共享数据库，MSA 每个服务有自己的数据模型和数据库MSA。
3. 典型服务规模：SOA适用于较大的单体应用，MSA适用于较小的服务。

设计过程

服务拆分
- 定义系统操作：将需求提炼为系统必须处理的关键请求（系统操作）
- 分析用户故事中频繁出现的名词，创建（抽象的）领域模型
- 分析用户故事和场景中的动词，确定系统操作。命令型或查询型（增删改查）、系统操作规范（命令对应的参数、返回值）

FTGO重要系统操作命令

CreateOrder() 系统操作规范

定义微服务：根据业务能力/子域/动静态调用关系进行服务拆分

根据业务能力：业务能力相对稳定，但实现方式可能不稳定。能力可分解为子能力。

根据子域：子域是领域驱动设计（DDD）方法论的核心，从业务出发，以面向对象和领域模型为核心。领域描述的是问题域，指一种特定的范围（电商、外卖保险）。子域是领域的细分（如电商可拆分为订单、商品、物流）。方法：为每一个子域单独构建领域模型，识别限界上下文（对应着微服务的一个或一组服务），确定领域边界

FTGO子域映射到服务

定义服务API和协作方式：将系统操作分配给服务，独立或与其他服务协作实现操作，确定支持协作的API。

映射不清晰的服务时，将操作分配给需要它提供信息的服务，比如noteUpdatedLocation()操作与送餐员和配送服务都有关系，但配送服务需要该操作提供位置信息。其他情况将操作分配给具有处理它所需信息的服务。

某些操作可以由单个服务处理。某些操作会跨越过多个服务（数据分散），这类操作需要验证前置条件并使后置条件成立，如 createOrder()调用多个服务，需要验证前置条件并使后置条件成立，再比如acceptOrder()需要调用配送服务安排送餐员并交付订单。

进程间的协作依赖于通信技术，有两种方式：

基于同步请求和响应；
异步消息。

通信

进程间通信机制复杂性高于方法调用、局部故障。

基于 RPI 的客户端如何在网络上发现服务实例的位置？应用层服务发现模式

模式：应用层服务发现模式。

自注册：服务实例调用服务注册表的注册API来注册其网络位置（服务注册表定期调用心跳API）。
客户端发现：客户端查询服务注册表以获取服务实例的列表（缓存+负载均衡，提高性能）。

结果：处理多平台部署的问题；需要为使用的每种编程语言提供服务发现库；开发者负责设置和管理服务注册表，分散精力。

相关模式：前序模式——同步远程过程调用；替代模式：平台层服务发现模式。

基于 RPI 的客户端如何在网络上发现服务实例的位置？平台层服务发现模式

模式：平台层服务发现模式。

第三方注册：由第三方负责（注册服务器，通常是部署平台的一部分）处理注册，而不是服务本身向服务注册表注册自己。
服务端发现：客户端无需查询服务注册表，而是向DNS名称发出请求，对该DNS名称的请求被解析到路由器，路由器查询服务注册表并对请求进行负载均衡。

结果：完全交给部署平台，服务端、客户端代码减负；多语言支持度较高；存在平台约束。

相关模式：前序模式——同步远程过程调用；替代模式——应用层服务发现模式。

如何处理外部客户端与服务之间的通讯？API网关

模式：API Gateway，实现一个服务，外部API 客户端进入基于微服务应用的入口点，针对不同客户端提供不同的API。

结果：封装应用程序内部结构，减少交互（请求往返）次数；确保客户端不受服务实例位置影响。

问题：性能和可扩展性、局部故障等。

相关模式：替代模式——后端前置模式；后续模式——断路器模式、服务发现模式。

同步通信中如何避免由于服务故障或网络中断所引起的故障蔓延到其他服务？断路器

模式：断路器（Circuit Breaker）。

闭合状态：对程序的请求能够直接引起方法的调用。
断开状态：对程序的请求会立即返回错误响应。
半断开状态：允许对程序的一定数量的请求可以调用服务，如调用成功，可认为之前导致调用失败的错误已经修正，熔断器切换到闭合状态；如调用失败，则认为问题仍存在，熔断器切回到断开状态。

结果：防止不断地尝试执行可能会失败的操作；使程序能够诊断错误是否已经修正，进而再次尝试调用操作。

相关模式：前序模式——同步远程过程调用模式。

部署

微服务架构包含一组服务，每个服务都部署为一组服务实例，以实现吞吐量和可用性。问题：如何大规模部署微服务？

需求：

服务使用各种语言、框架和框架版本编写；
需要快速构建、独立部署和扩展服务；
服务实例需要相互隔离；需要监控每个服务实例的行为、部署可靠；
需要限制服务消耗的资源（CPU 和内存）；
尽可能经济高效地部署应用程序。

部署模式：

单主机部署多个服务实例
单主机部署单个服务实例
将服务部署到虚拟机
将服务部署到容器
服务部署平台
无服务器部署

往年试卷
#

15年试卷
#

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

软件架构从哪来？列举五个可能的来源。

功能性需求
⾮功能性需求
架构重要需求
质量需求
涉众
开发组织
技术环境
商业因素
What distinguishes an architecture for a software product line from an architecture for a simple product?

软件产品线的体系结构与简单产品的体系结构有什么区别？

产品线的⽬的是实现⾼重⽤性、⾼可修改性；之所以如此有效，是因为可以通过重⽤，充分利⽤产品的共性，从⽽产⽣⽣产的经济性
在产品线架构中有⼀组明确允许发⽣的变化，但是对于常规架构来说，只要满⾜了单个系统的⾏为和质量⽬标，⼏乎任何实例都是可以的
How to model quality attribute scenarios? Graphically model two quality attributes in “stimulus-response” format: availability and performance.

如何对质量属性场景建模？以“刺激-响应”的形式，给这两个质量属性图形化建模：可⽤性、性能

刺激源
刺激
环境
制品
响应
响应度量
Describe relationships between architecture patterns and tactics. List four tactics names and describe their usage.

描述架构模式和战术之间的关系，列举四个战术名称并描述他们的⽤途

战术⽐模式简单，它们使⽤单⼀的结构或机制来处理单⼀的架构要求
模式把多个设计决定组合在⼀起
都是架构师的主要⼯具
战术是模式设计和创造的基⽯
⼤多数模式由⼏个不同的战术组成
Briefly describe the general activities involved in a software architecture process.

简要描述在软件架构过程中涉及的⼀般活动

创造系统的商业案例
理解需求
创造和选择架构
与包括开发者在内的涉众沟通架构
分析或评估架构
1. 总的⽅法
2. 质量特定技术
实现架构
确保架构符合要求
Mapping, and list 4 views for each style. (sa07, p.9)

连线，并为每种样式列出 4 个视图

它如何被构造成⼀组样式单元？模块样式
- 分解视图、使⽤视图、概括视图、分层视图、⽅⾯视图、数据模型视图、逻辑视图
它如何被构造成⼀组有运⾏时⾏为和交互的元素？组件-连接器样式
- 管道-过滤器视图、客户机-服务端视图、点对点视图、⾯向服务架构视图、发布-订阅视图、共享数据视图、多层视图
它如何与它环境中的⾮软件结构关联？分配样式
- 部署视图、安装视图、⼯作安排视图、开发视图、物理视图
Explain the context, benefits and limitations of Broker Architecture Pattern.

解释代理⼈架构模式的上下⽂、优点和限制

定义了⼀个叫做代理⼈的运⾏时组件，它在多个客户机和服务器之间进⾏通。包括客户机、服务器、代理⼈元素，可能还有客户机端代理和服务器端代理。连接关系将客户机（与可选的客户机端代理）和服务器（与可选的服务器端代理）与代理⼈相关联，只允许客户机连接到代理⼈、服务器连接到代理⼈（或分别通过客户机端代理和服务器端代理）
降低客户机和服务器间的耦合；提⾼服务的位置透明性；提⾼组件的可变性、扩展性、伸缩性和可重⽤性
代理⼈在客户机和服务器之间增加了⼀层间接寻址，导致延迟，可能是性能瓶颈；代理⼈可能是⼀个单⼀的失败点；代理⼈增加了前期的复杂度；代理⼈可能是安全攻击的⽬标；代理⼈可能难于测试
Why should a software architecture be documented using different views? Give the name and purposes of 4 example views.

为什么软件架构要⽤不同的视图来⽂档化？举例 4 个视图并给出名称和⽬的

视图是⼀组系统元素及其关系的表示，这些元素不⼀定是全部系统元素，⽽是特定类型的元素。视图让我们将系统实体划分成感兴趣和易于管理的系统表示。不同的视图⽀持不同的⽬标和⽤户，并凸显出不同系统元素和关系。不同视图在不同程度上展现不同的质量属性
视图
1. 逻辑视图：描述架构中重要的元素及其之间的关系
2. 进程视图：描述架构的并发和通信元素
3. 物理视图：描述主要过程和元素是如何被映射到应⽤程序硬件
4. 开发视图：捕获软件组件的内部组织
5. 架构⽤例：捕获架构的需求，与多个特定视图关联
Briefly describe the fundamental principles of SOA and discuss the impact of SOA on quality attributes like interoperability, scalability and security.

简要描述SOA 的基本原则，讨论 SOA 对质量属性的影响，⽐如互操作性、可伸缩性和安全性

原则
1. 服务解耦：服务之间的关系最⼩化，只是相互知道接⼝
2. 服务契约：服务按照描述⽂档所定义的服务契约⾏事
3. 服务封装：除了服务契约所描述内容，服务将对外部隐藏实现逻辑
4. 服务重⽤：将逻辑分布在不同的服务中，以提⾼服务的重⽤性
5. 服务组合：⼀组服务可以协调⼯作，组合起来形成定制组合业务需求
6. 服务⾃治：服务对所封装的逻辑具有控制权
7. 服务⽆状态：服务将⼀个活动所需保存的资讯最⼩化
对质量属性
1. 良好的互操作性，符合开放标准
2. 服务动态识别、注册、调⽤，可伸缩性⾼
3. 模组化，可重⽤性⾼
4. 服务⾃身⾼内聚、服务间松耦合，最⼩化开发维护中的相互影响，可修改性⾼
5. 单个服务的规模变⼩，可维护性⾼
6. 使⽤消息机制及异步机制，可靠性⾼
7. 分布式系统，可扩展性、可⽤性⾼
8. 各独⽴服务演化不可控，安全性不⾼
9. 难以测试验证，可测试性不⾼
Describe outputs generated from each phase of ATAM process.

描述 ATAM 过程每个阶段产⽣的输出

合作与准备：评估团队领导和主要项⽬决策者
1. 谁：涉众的初步名单
2. 逻辑：何时？何地？如何？
3. 评估报告何时交付给何⼈
4. 评估报告包含何种信息
评估 1：评估团队和项⽬决策者
1. 架构的简短展示
2. 业务⽬标的表达（驱动因素）
3. 作为场景实现的特定质量属性需求的优先级列表
4. 效⽤树
5. ⻛险和⾮⻛险
6. 敏感点和权衡点
评估 2：评估团队、项⽬决策者和架构涉众
1. 涉众社区的优先级场景列表
2. ⻛险主题和受到威胁的业务驱动因素
后续⾏动：评估团队和主要涉众
1. 最终评估报告
Why SPL and MDA have high reusability? Compare and discuss their commonality and differences.

为什么软件产品线和模型驱动架构有⾼可重⽤性？⽐较并讨论他们的共同点和不同点

分布式缓存更新

17年考题
#

Briefly describe the general activities in a software architecture process, and the major inputs and outputs at each activity.
What distinguishes an architecture for a software product line from an architecture for a single product?
What are generic design strategies applied in designing software? Give a concise working example with software architecture for each strategy.
How to model quality attribute scenarios? Graphically model two quality attributes in “stimulus-response” format: availability and modifiability.
Describe outputs generated from each phase of ATAM process.
Map, and list four views of each category of style.
What are ASR? List four sources and methods for extracting and identifying ASRs.
Please name at least three Object-Oriented principles, and explain how they are applied in Strategy pattern?
What should be included in a typical software architecture documentation package? Briefly describe each component and its purpose.
Describe 4+1 view
软件设计的的三个变化维度，每个维度的变化点。differing binding time如何影响可修改性和可测试性。

18 年考题（梁神回忆）
#

软件架构的关注点有哪些？利益相关方有哪些？
Software requirements, quality attributes, ASRs 的区别和联系
What is the nature of component-connector style? 以 MVC pattern 举例
如何对质量属性场景建模？画出 availability 和 modifiability 的刺激-响应图
risks, sensitivity points, trade-off points 是什么？各举一个例子
连线，并对每种 style 列出四种视图
Layered pattern 和 Multi-tier pattern 的区别
描述 ADD 过程

为什么软件架构需要用不同的视图描述？举出四种视图的例子（列出名称和目的）
软件产品线架构如何实现可变性？描述可变性机制的工作方式
设计一个飞行模拟软件，要求能模拟多种飞机的特性。为了在将来支持更多飞机种类，要求使用策略模式。画出架构图和类图
太复杂，忘了

19 年最终考题（law回忆）
#

如何对质量属性场景建模？画出 Interoperability 和 modifiability 的刺激-响应图
What are ASR? List four sources and methods for extracting and identifying ASRs.
4+1 视图介绍（还要画图，我的图画的的有点问题，去wiki百科上可以看）
What are generic design strategies applied in designing software? Give a concise working example with software architecture for each strategy. (和17年一样的)
Map, and list four views of each category of style.（每年必考题）
What should be included in a typical software architecture documentation package? Briefly describe each component and its purpose. （和17年基本一样）
描述在 ATAM 的每一个过程中有哪些 stake holder 和他们的职责
软件产品线架构如何实现可变性？描述可变性机制的工作方式，和变化点。（和去年一样）
Explain the context, benefits and limitations of Broker Architecture Pattern.
微服务和 SOA 的区别，相同点
一个买票系统的设计题，不同的角色有不同的打折方案，用策略模式设计，最后画图，还要说明策略模式的使用场景。
设计题，和 15 年的设计题一模一样

考纲 #

基础部分 #

1. 软件架构概述 #

2. 质量属性 #

3. 架构模式（Architectural Patterns） #

4. 架构设计（Designing Architecture） #

5. 领域驱动设计（Domain-Driven Design）——简答题 #

6. 企业与业务架构——简答题 #

7. 微服务架构（MSA）——分析设计题 #

往年试卷 #

15年试卷 #

17年考题 #

18 年考题（梁神回忆） #

19 年最终考题 （law回忆） #