24软件系统设计

孙顾燚 - v3.0

总体来说考试的简答题还是考察的基础知识，部分题目需要结合知识思考

详细设计部分的设计题不会非常难，但是今年的架构设计题直接gg了

由于博客的markdown不支持渲染[!important]，所以博客上看这篇文章怪怪的

24考试回忆

代码违背了什么设计原则，如何修改
设计原则之间的联系
ASR是什么？ASR来源
checklist 7个categories
SOA基本原则，对质量属性的影响
微服务部署模式的上下文，需求，模式，优缺点
Risks，Senstivity Points，Trade-Off Points分别是什么？各举一个例子。
一个在线购物平台，用了策略模式但是有问题，分析问题出在哪里，如何修改
装饰器能否作为组合模式的变种？（忘了位置了，也可能反过来
架构设计大题，需要画不同的views

架构部分 - zh部分

[!IMPORTANT]

【2019】Architecture，structure和Design的区别？

Design 包含 Architecture，Architecture 包含 Structure

结构是静态的、逻辑的，是关于系统如何构成的

Architecture除包含structure ，还会包含组件之间的相关的关系结构，并定义一些动态的行为。

体系结构是关于软件设计的，所有体系结构都是设计，但是不是所有的设计都是体系结构，体系结构是软件设计的一个部分

Intro

架构定义

定义1：程序或计算系统的软件体系结构是系统的一个或多个结构，其中包括软件组件，这些组件的外部可见属性以及它们之间的关系。[软件工程学院(SEI)]
定义2：系统的基本组织，体现在其组件，它们之间的相互关系以及环境以及支配其设计和演进的原则。[IEEE 1471-2000有关软件密集型系统的体系结构描述的推荐做法]

软件架构师在做什么 What Does a Software Architect Do?

联络人 Liaison
1. 在客户、技术团队和商业/需求分析师之间 Among clients, technical team and business/requirements analysts
2. 包含管理和市场分析 With management or marketing
软件工程：软件工程的最佳实践 Software Engineering:Software engineering best practices
技术知识：深入理解技术领域 Technology Knowledge:Deep understanding of technology domain
风险管理：Risk Management
1. 与设计、技术决策相关的风险 Risks associated with the design, technology choices
2. 更多？More?

架构来源

NSRs, ASRs, 质量需求, stakeholder, Organisations, Technical Environments

[!IMPORTANT]

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

NFRs

ASRs

质量需求

涉众，组织

技术环境

业务目标

商业与技术决策组合

视图 4+1 views

逻辑，过程，物理，开发 + 用例场景

[!IMPORTANT]

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

原因

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

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

【2017】【2019】描述 4+1 视图 Describe 4+1 view(掌握绘图)：答案如上

逻辑视图：描述了体系结构中在体系结构上明显重要的元素以及他们之间的关系 Logical view: describes architecturally significant elements of the architecture and the relationships between them
过程视图：描述了体系结构中的并发和交流元素 Process view: describes the concurrency and communications elements of an architecture.
物理视图：描述了主要过程和部件是如何映射到应用硬件上的 Physical view: depicts how the major processes and components are mapped on to the applications hardware.
开发视图：描述了软件部件是如何在软件内部组织的，比如配置管理工具 Development view: captures the internal organization of the software components as held in e.g., a configuration management tool.
体系结构用例：描述了体系结构的需求，关系到了超过一个常规的视图。是四个视图在某一个场景下进行描述Architecture use cases: capture the requirements for the architecture; related to more than one particular view

体系结构活动 & 软件体系结构过程 Software Architecture Process

[!IMPORTANT]

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

长答案

创建商业案例输入：问题域，输出：商业案例

了解用户需求输入：用户的模糊需求输出：架构攸关的需求

创建或选择体系结构输入：策略、模式和备选场景输出：被选中的策略、模式和场景

沟通体系结构输入：架构设计文档输出：

分析和评估体系结构输入：架构设计文档输出：

实现体系结构输入：架构设计文档输出：架构设计的具体实现

保证体系结构的一致性输入：架构设计的具体实现输出：保持一致的架构设计具体实现

短答案

识别ASRs

输入：无

输出：优化的质量属性场景

架构设计

输入：优化的质量属性场景、需求和约束、模式和决策

输出：一组候选视图的草图（模式决定）

架构文档化

输入：一组模式决定的草图（由模式决定）

输出：View & Beyond

架构评估

输入：View & Beyond、优化的质量属性场景

输出：View & Beyond

其他

通过StackHolder获取到ASRs（架构攸关需求）

通过分析得到Prioritized Quality Attribute Scenarios(高优先级质量属性解决方案)和Requirements，Constraints(需求和约束)

将上述部分，结合模式和策略，综合可以得到架构的设计

根据架构的设计得到由模式决定的候选视图的示意图，之后完成文档化

选择、组合视图，将文档进行进一步的评估，这一部分需要StackHolder的参与、也需要Prioritized Quality Attribute Scenarios和文档等作为参考。

活动

创建系统的商业案例 Creating the business casenfor the System
理解需求 Understanding the requirements
创建和选择体系结构 Creating and selecting architecture
沟通体系结构(涉众，包括开发商) Communicating the architecture (stakeholders including developers)
分析或评估体系结构 Analysing or evaluating the architecture
1. 整体的方法论 Overall methodologies
2. 具体技术的质量 Quality specific techniques
实现体系结构Implementing the architecture
保证和体系结构的一致性Ensuring contormance to an architecture

过程

软件体系结构和体系结构知识领域 Software Design & Architecture Knowledge Areas

软件设计基本原理 Software Design Basic Concepts
1. 整体设计原理 General design concepts
2. 上下文：软件发展生命周期-需求、设计、编码和测试 Context: software development life cycle - requirements, design, construction and testing
3. 设计过程：决策、活动、可运行产品 Design process(role, activity, work product)
4. 软件设计的使能技术 Enabling techniques for software design
核心问题(技术)：一致性、事件控制和处理、分发、异常处理、交互系统、持久化 Key Issues (technical): concurrency, control and handling of events, distribution, exception handling, interactive systems, persistence
软件结构和体系结构 Software Structure and Architecture
1. 体系结构结构和视点 Architecture Structures and viewpoints
2. 体系结构风格和模式(宏观体系结构) Architectural styles and patterns (macro-architecture)
3. 设计模式(微观体系结构) Design patterns (micro-architecture)
软件设计方法Software Design Methods
1. 体系结构方法，比如属性驱动的设计 Architecture Methods (e .g., Attribute- Driven Design)
2. 设计方法，比如动态系统发展方法 Design Methods (e.g., Dynamic System Development Method)
软件设计的质量分析和评估 Software Design Quality Analysis and Evaluation
1. 质量属性 Quality attributes
2. 质量分析和评估方法、技术和工具 Quality analysis and evaluation methods, techniques and tools
  1. 设计回顾：比如SEI的体系结构权衡分析方法 Design reviews (e.g. SEI’s Architecture Trade-off Analysis Method)
  2. 静态分析和动态分析 Static analysis and dynamic analysis
  3. 模拟和原型 Simulation and prototyping
3. 度量 Measures:
  1. 矩阵：体系结构级别 Metrics: Architecture level
  2. 技术特有度量指标 Technique specific measures
设计建模和展示 Design Modeling and Representation
1. 体系结构和设计符号(体系结构描述语言，Architecture Description Languages，ADL)Architecture and Design Notations (Architecture Description Languages(ADL))
2. UML Unified Modelling Language (UML)
3. 设计文档(意见或其他) Design Documentation (Views & Beyond)
4. 其他：在活动、关注点和领域上的不同，比如ACME，Rapide。 Others: differ in ability, focus and domain (e.g. ACME, Rapide)

质量属性

软件需求

Functional requirements，Quality requirements（NFRs），Constraints

[!IMPORTANT]

【2018】Software requirements, Quality attributes, ASRs 的区别和联系

软件需求包括功能性需求和非功能性需求（又称质量需求）

质量属性是由软件的业务目标所决定，在功能性需求的基础上提供的整个系统的合乎需求的特性，是非功能需求的一种反应。

ASRs架构攸关需求是对于体系结构有着深远影响的需求，肯定是软件需求的一部分。

功能性需求 Functional Requirements

功能性需求定义了系统必须做什么并且强调了系统如何提供价值给涉众 Functional requirements state what the system must do and address how the system provides value to the stakeholders.
功能性需求意味着系统的行为 Functional requirements means the behaviour of the system.
功能是系统完成其预期工作的能力，例如，使学生能够在线注册。Functionality is the ability of the system to do the work for which it was intended, e.g., enable students to enrol online.
通过使用许多可能的结构可以实现功能。Functionality may be achieved through the use of any
number of possible structures.
功能在很大程度上与结构无关，因为它可以作为单个整体系统存在而没有任何内部结构。Functionality is largely independent of structure, because it could exist as a single monolithic system without any internal structure.

质量需求 Quality Requirements

质量需求是系统应在其功能要求之上提供的整个系统的合乎需要的特性(又称质量属性) Quality requirements are desirable characteristics of the overall system (aka. quality attrilbutes) that system should provide on the top of its functional requirements.
质量要求是功能要求或整个产品的资格。软件体系结构限制了分配 Quality requirements are qualifications of the functional requirements or of the overall product.
如果质量属性很重要，则将功能(映射)到各种结构上。Software architecture constrains the allocatio (mapping) of the functionality onto various structures if quality attributes are important.

非功能性需求 Non-functional Requirements

非功能要求或体系结构要求是用于质量属性的替代术语 Non-functional requirements or architectural requirements are alternative terms used for quality attributes.
无法正确使用功能，然后尝试适应非功能性要求(不具备翻新质量)。It is not possible to get the functionality right and then try to accommodate non-functional requirements (NO retro-fitting quality).
在任何设计决策中都必须考虑非功能性要求。Non-functional requirements must be taken into account during any design decision.
非功能性需求分为两大类：There are two broad categories ot non-functional requirements:
1. 在执行过程中==可观察(外部)==：系统满足其行为要求的程度如何？例如性能，安全性，可用性，可用性等。Observable (External) during execution: How well a system satisties its behavioural requirements? e.g., performance, security, availability, usability etc.
2. 执行期间==不可观察(内部)==：系统的维护，集成或测试有多容易？例如，可修改性，可移植性，可重用性，可测试性等。Not observable (Internal) during execution: How easily a system can be maintained, integrated, or tested? e.g., modifiability, portability, reusability, testability etc.
约束了限定的边界，之后的架构是在这个边界内找到最优的解。

约束 Constraints

约束是具有零自由度的设计决策。A constraint is a design decision with ZERO degrees of freedom.
约束是已经做出的预先指定的设计决策。Constraints are pre-specified design decisions that have been already made.
通过接受设计决策并将其与其他受影响的设计决策进行协调，可以满足约束条件。Constraints are satisfied by accepting the design decision and reconciling it with other affected design decisions.

质量属性

内部 vs. 外部

质量属性方案建模 Modeling Quality Attribute Scenarios 重要

质量属性：Availability，Interoperability，…

Tactics 策略(原子级别的最小的决定)

Checklist for architectures design desicion - 设计覆盖的7个方面

质量属性方案建模 Modeling Quality Attribute Scenarios

[!IMPORTANT]

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

【2015】availiability and Performance

【2017】【2018】availiability and modifiability

【2019】interoperability and modifiability

刺激(Stimulus)：到达系统时需要考虑的条件 Stimulus: A condition that needs to be considered when it arrives at a system.
刺激源(Source of Stimulus)：产生刺激的实体(人，系统或任何促动器) Source of Stimulus: An entity (human, system, or any actuator) that generates the stimulus.可能是输入、消息等等，对当前的状态有一个变化。
应对(Response)：刺激措施到来之后开展的活动 Response: The activity undertaken after the arrival of the stimulus.
响应度量(Response Measure)：对刺激的响应应以某种方式进行测量，以便可以测试需求。Response Measure: The response to the stimulus should be measurable in some fashion so that the requirement can be testable.多长时间系统有反馈
环境(Environment)：发生刺激时系统的状况，例如过载，运行等 Environment: A system’s condition when a stimulus occurs, e.g. overloaded, running etc.
工件(Artifact)：需求适用的整个系统或系统的一部分。Artifact: The whole system or the portion of the system to which the requirement applies.可能是一个软件制品
只有定义好这6个元素，就能锁定架构的一个场景，之后可以用来进行架构的设计
刺激和响应发生在一个环境中：系统正常运行、系统过载、系统受到攻击、系统网络等出现了故障。

质量属性

[!IMPORTANT]

7. 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?请给出质量属性中的“可用性的概念。MTBF 和 MTTR 分别代表什么？如何计算系统的可用性（例如 SLA）作为概率？

可用性是大多数 IT 应用程序的关键要求 Key requirement for most IT applications

度量方式：以所需的可用时间比例来衡量，例如 Measured by the proportion of the required time it is useable, e.g.

可将可用性计算为在指定的时间间隔内它将在要求的范围内提供指定服务的概率。Availability can be calculated as the probability that it will provide the specified services within required bounds over a specitied time interval.

MTBF（平均无故障时间） MTBF (mean time between failures)

MTTR（平均维修时间） MTTR (mean time to repair)

$$
\frac{MTBF}{MTBF+MTTR}
$$

课上讲过的参考spricoder的博客

Adaptability
Extensibility
Availability
Modularity
Configurability
Portability
Flexibility
Reusability
Interoperability
Testability
Performance
Auditability
Reliability
Maintainability
Responsiveness
Manageability
Recoverability
Sustainability
Scalability
Supportability
Stability
Usability
Security

Tactics 策略(原子级别的最小的决定)

风格或样式运用策略来提供预期的收益 Style or pattern applies tactics to provide the promised benefit.
策略是影响质量属性响应控制的设计决策，例如冗余。A tactic is a design decision, .e.g. redundancy, that influences the control of a quality attribute response.
策略的集合称为体系结构策略。A collection of tactics is called an architectural strategy.
系统设计包括一组设计决策，其中一些决策可帮助控制质量属性响应；其他确保系统功能的实现 A system design consists of a collection of design decisions: some of these decisions help control the quality attribute response; others ensure achievement of system functionality.
像模式一样，策略也可以由其他策略组成，例如，冗余可以由数据的冗余，计算的冗余组成。设计人员根据需求选择一个或另一个 Like patterns, tactics may also be composed of other tactics, e.g., redundancy may be composed of redundancy of data, redundancy of computation-Designer chooses one or other depending upon requirements.
策略可以用作策略等级 Tactics can be used as hierarchy of tactics.

Checklist for Design and Analysis

Responsibilities, Coordination, Data, Resources, Elements mapping, Binding time, Technology

以Usbility为例

需要覆盖7个方面

架构攸关的需求 Architecturally Significant Requirements

How to gather and identify ASRs：需求、Workshop、Business goals、Utility tree

[!IMPORTANT]

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

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

四种来源和方法：

从需求文档中收集ASR：MoScoW方法和用户故事

通过采访涉众来收集ASR：质量属性工作坊(QAW)

通过了解业务目标来收集ASR：

通过质量属性实体树(Utility Tree)来管理ASR：通过方案量化描述需求后，逐渐对质量属性进行分解细化，直到包含量化指标为止。

从需求文档中收集ASR Gathering ASRs from Requirements Documents

无论是使用"MoSCoW"样式指定需求还是作为"用户故事"的集合来指定需求，这些都不能帮助您确定质量属性。Whether requirements are specifed using the “MoSCoW” style or as a collection of “user stories”, neither of these is much help in nailing down quality attributes.
MoSCoW样式：MoSCoW的样式说明：使用四个级别来定义一个需求的优先级程度
需求文档通常会以两种方式使架构师失败：Requirements documents often fail an architect in two ways:
1. 需求规范中的大多数内容都不会影响体系结构。Most of what is in a requirements specification does not affect the achitecture.
  1. 系统应模块化 The system shall be modular
  2. 系统应显示出高可用性 The system shall exhibit high usability
  3. 系统应满足用户的性能期望 The system shall meet users’ performance expectations
2. 对架构师有用的大部分内容甚至都没有出现在最佳需求文档中 Much of what is useful to an architect is not in even the best requirements document.
  1. 在收购环境中，需求文档代表的是收购方的利益，而不是开发商的利益。In an acquisition context, the requirements document represents the interests of the acquirer, not that of the developer.
如果某项要求影响了关键体系结构设计决策的制定，那么根据定义，它就是ASR。If a requirement affects the making of a critical architectural design decision, it is by definition an ASR.

通过和涉众面谈来收集ASR Gathering ASRs by Interviewing Stakeholders

质量属性工作坊(QAW) Quality Attribute Workshop (QAW)
1. QAW演示和介绍 QAW presentation and introductions
2. 业务任务介绍 Business mission presentation
3. 架构计划介绍 Architectual plan presentation
4. 架构驱动程序的识别：就精简的架构驱动程序列表达成共识，其中包括总体需求，业务驱动程序，约束和质量属性。Identification of architectural drivers: to reach a consensus on a ditilled list of architectural drivers that includes overall requirements, business drivers, constraints, and quality attributes.
5. 场景集思广益：每个利益相关者都表达一个场景，表示他/她对系统的关注。Scenario brainstorming: each stakeholder expresses a scenario representing his/ her concerns with respect to the system.
6. 方案合并(合并类似方案) Scenario consolidation (merging similar scenarios)
7. 方案优先级(通过投票) Scenario prioritization(by voting)
8. 方案细化：对最重要的方案进行细化和阐述。Scenario refinement: the top scenarios are refined and elaborated.
QAW的结果包括架构驱动程序列表和利益相关者(作为一个小组优先考虑)的一组(2A方案)。The results of QAW include a list of architectural drivers and a set of QA scenarios that the stakeholders (as a group prioritized).

通过Utility树来获取ASR Capturing ASRs in a Utility Tree

将scenario使用量化的方式来描述，之后才可以使用测试等方式来确定是否实现了要求。
逐渐对质量需求进行分解，分解到含有量化指标为止。
然后将分解的结果进行细化

架构模式

Architectural Pattern

架构模式是一组架构设计决策，适用于重复出现的设计问题，并进行了参数化处理以解决出现该问题的不同软件开发环境。An architectural pattern is a set of architectural design decisions that are applicable to a recurring design problem, and parameterized to account for different software development contexts in which that problem appears

架构模式建立了以下之间的关系：Architecture pattern establishes a relationship between:

背景：世界上经常发生的常见情况，会引起问题 A context: A recurring, common situation in the world that gives rise to a problem.
一个问题：在给定的上下文中出现的问题，经过适当概括 A problem: The problem, appropriately generalized, that arises in the given context.
解决方案：针对问题的成功架构解决方案，并进行了适当抽象 A solution: A successful architecture resolution to the problem, appropriately abstracted.
- 元素
- 关系
- 约束

Module Patterns

Layered pattern（micro-kernel pattern）

[!IMPORTANT]

Explain the context, benefits and limitations of Layered Architecture Style.

分层模式定义了层（提供一组内聚服务的模块分组）和层之间的单向允许使用关系。该模式通常通过将表示层的框堆叠在一起来以图显示。优点：可以将复杂的问题分成几个部分；

具有很高的可扩展性和可重用性；

组件之间的连接可以通过相邻性来显示，并且“上”和“下”很重要。缺点：添加层会增加系统的前期成本和复杂性；

层会导致性能下降；

如果分层设计不正确，它实际上可能会妨碍系统，因为它不提供较低级别的抽象；

如果出现许多层桥接实例，系统可能无法满足严格分层有助于实现的可移植性和可修改性目标；

分层模式 Layered Pattern

对应4+1视图中的逻辑视图

Component-Connector Patterns

Broker pattern, Model-view-controller pattern, Pipe-and-filter pattern, Client-server pattern, Peer-to-peer pattern, Service-oriented pattern, Publish-subscribe pattern, Share-data pattern

[!IMPORTANT]

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

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

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

局限性：代理增加了前期复杂度、可能成为通信的屏障、可能成为攻击的目标、难以测试。

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

[!IMPORTANT]

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

Layered Pattern是Module Style，而Multi-tier Pattern 是Allocation Style

Layered Pattern是将任务拆解成一个个处于特定抽象级别的子层次，每层为下一层提供更高层次的服务，核心是关注点分离。

Multi-tier Patten中的层是逻辑的组合，没有层次模式的强依赖关系，在不同部署环境中分层不同但是软件完成的内容一致。

[!IMPORTANT]

What is the nature of component connector style?以MVC pattern举例

MVC模式将系统功能分为三个组件：模型、视图和在模型和视图之间进⾏中介的控制器

模型是应⽤程序数据或状态的表⽰，它包含（或提供）应⽤程序逻辑。

视图是⽣成表⽰的⽤⼾界⾯组件或者允许某种形式的⽤⼾输⼊

控制器管理模型和视图之间的交互。

代理模式 Broker Pattern

Broker可以理解为中间人，撮合双方达成交易。

优点
1. Interoperability：根本目的，提高Server-Client之间的交互性
2. Scaliability：可伸缩和扩展
3. Modifiabiliy：
4. 两面性：
  1. Security：代理对象屏蔽了系统内部的具体实现
  2. Reliability：服务降级和实例重启
  3. Availability：
缺点
1. Security：成为被攻击的对象
2. Reliabiliy：可靠性会降低
两面性：
1. Performance：整体大集群的性能可能会提高(QPS等提高)，但是局部单点性能会下降，多次网络请求、多次匹配，有可能会抵消。

模型-视图-控制器模式 Model-View-Controller Pattern(MVC)

使用运行时、动态、相互之间的关系来审视，集成到了开发框架中，也是分层架构的变种(会强调各模块之间的约束关系，model不可以直接返回到controller)
1. model 业务逻辑
2. view 处理用户展示，接收用户操作
3. controller 对用户操作进行处理，将信息通知给model
model -> controller 不会产生通信

Pipe-and-Filter Pattern 管道和过滤模式

filter：相当于component，起到数据处理、计算作用，每个filter有input和多个output，数据处理后传递给后续的部分。
pipe：连接filter，相当于connector，将output导入到其他的filter的input中去，不会孤立存在。
管道和过滤模式不会孤立存在，应用在顺序处理结构，有一系列的数据结构filter，体现依赖关系。
场景应用在科学计算的场景中，需要避免出现环形的filter，不适用于有很多交互产生的场景。

Client-Server Pattern 客户端-服务端模式

包含两类不同的component
请求发起client、server接收请求，这里没有broker，不能动态改变client和server的关系，相对更固定，但是一个client可以连接多个server
一个component在一个关系中可以是client，也可能是server，非绝对，但是成对的关系相对固定。
会受到负载的限制。
Server可能有性能瓶颈，但是可以通过事先规划避免。
Server可能单点失效，但是broker可以控制

Peer-to-Peer Pattern 点对点模式

这一刻是提供者，下一刻就是消费者，是对等的。
不单单提供服务，还能提供物流(对于整个网络)
对每一个peer可能会给他一个规定对的连接数

Service-Oriented Pattern 面向服务的模式

broker架构的延续。
component包含服务提供者、服务消费者。
除了这些component还有ESB、企业服务组件、连接处理，包括发现、注册。
Registry of Services
Orchestration Server 不同的Service按照一定的顺序进行编排，提供更高级的(申请贷款流程)
Connectors：
1. SOAP：
2. REST：
3. Asynchronous messaging connector

[!IMPORTANT]

【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的基本原则

服务契约:服务按照描述文档所定义的服务契约行事

服务封装:除了服务契约所描述内容，服务将对外部隐藏实现逻辑

服务重用:将逻辑分布在不同的服务中，以提高服务的重用性

服务组合:一组服务可以协调工作，组合起来形成定制组合业务需求

服务自治:服务对所封装的逻辑具有控制权

服务无状态:服务将一个活动所需保存的资讯最小化

SOA对互操作性的影响

SOA具有更高的互操作性：符合开放标准，可以更好的重用服务

支持服务的自动识别、发现、注册和调用等等

SOA对可伸缩性的影响

SOA具有更高的可伸缩性：服务自身高内聚、服务间松耦合，最小化维护的影响

但是SOA也会带来系统复杂度较高的问题

SOA对安全性的影响

中间件可能会成为性能的瓶颈

ESB等中间件都可以成为被攻击的目标

多服务导致攻击的跟踪、溯源和防御成为困难。

[!IMPORTANT]

【2019】微服务和SOA的区别，相同点

相同点：微服务和SOA都是分布式架构，微服务是SOA的一种扩展，都包含了服务契约、服务封装、服务重用、服务组合、服务自治和服务无状态等基本特点。

微服务去掉了SOA架构中的ESB，采用轻量级通信机制(HTTP、REST)进行服务之间的通信。

微服务的管理和部署结合DevOps实现自动化，可以对服务进行自动化部署和监控预警。

微服务引入了API网关、对客户端屏蔽访问各项服务的问题。

微服务引入了熔断器：避免出现服务失效或网络问题等导致的级联故障。

subscribe注册对于publiser进行注册
某一个publiser发布自己的消息可能订阅其他消息（朋友圈微博）

Shared-Data Pattern 共享数据模式3

中间安全数据会被很多人共享登录访问

Allocation Patterns

Map-reduce pattern，Multi-tier pattern

Map-Reduce Pattern

软件和外部环境的关系部署
map对数据进行抽取所需要的信息信息转换
可以有多个map 处理数据工作内容不一样
相互独立可以运行
reduce进行合并产出想要的答案

Multi-Tier Pattern 多层模式

部署的环境划分
layer是真实存在的
这里是逻辑的组合没有和层的强依赖关系
不同的部署环境里面分层不同但是软件完成内容一样

Patterns VS Tactics

[!IMPORTANT]

【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

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

决策比模式更简单，仅有单一的结构或机制来应对单一的架构驱动

决策是构成架构模式的重要组成部分

架构模式通常将许多个决策组合在一起。

大多数架构模式都包含不同的决策，这些决策可能有共同的目的或者常被用于实现不同的质量属性。

决策和架构模式共同构成了软件设计时的工具。

四种决策的名称

ping/echo

heartbeat

软件升级

增加内聚

降低耦合

重写配置

⾃检（⾃我测试）

异常检测

延迟绑定

识别攻击者

控制输入

限制复杂度

减少单点失效

策略比模式简单。他们使用单一的结构或机制来应对单一的架构力量 Tactics are simpler than patterns; they use a single structure or mechanism to address a single architectural force.
模式通常将多个设计决策组合到一个包中 Patterns typically combine multiple design decisions into a package.
模式和策略共同构成了软件设计师的主要工具 Patterns and tactics together constitute the software architect’ s primary tools.
战术是设计的“构建块”，可从中创建建筑模式 Tactics are “building blocks” of design from which architectural patterns are created.
大多数模式包含几种不同的策略，这些策略可能 Most patterns consist of several different tactics that may:
1. 都有共同的目的 all serve a common purpose,
2. 经常被选择来承诺不同的质量属性 be often chosen to promise different quality attributes
示例：分层图案 Example: layered pattern
1. 提高语义连贯性 Increase semantic coherence
2. 限制依赖 Restrict dependencies
tactic是设计最小粒度tactic进行组合一个tactic是为了某一个质量属性也会影响其他属性（正面、负面）
针对某一个质量属性Modifiablity 相关的tactic 和pattern之间的关系是否涉及到

设计架构

[!IMPORTANT]

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

三个变化维度：

面向对象 OOP，强调重用性、灵活性和扩展性。

面向切面 AOP，满足扩展的需求，可以在程序中自由的扩展功能

面向服务 SOA，是系统发布功能的一种方式，且基于这种方式下不同的系统之间可以有效的沟通、协作。

设计时，开发时，测试时，发布时，运行时：可修改性降低，可测试性升高

[!IMPORTANT]

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

软件架构的关注点

利益相关者 Stakeholders addressed

解决的问题 Concerns addressed

语言，建模技巧 Language, modeling techniques

决策，模式 Tactics, Pattern

利益相关方有哪些？

顾客 Customer

用户 User

建筑师 Architect

需求工程师 Requirements engineer

设计师 Designer

实施者 Implementer

测试师，集成师 Tester, integrator

维护者 Maintainer

产品经理 Product manager

质量保证人 Quality assurance people

General Design Strategy

[!IMPORTANT]

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

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

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

分而治之：将每个模块分别处理

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

迭代与细化：使用迭代的方法，ADD方法多次迭代直到满足所有ASR

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

Abstraction，Decomposition，Divide VS. conquer，Generation and test，Reuse

Abstraction
Generate & Test
Decomposition
Reusable Elements
Iteration & Refinement
Divide & Conquer

Categories of design desicions

Responsibilities, Coordination, Data, Resources, Elements mapping, Binding time, Technology

Attribute-Driven Design 2.0

Inputs to and outputs of ADD

8-step process:

confirm requirements, 2. choose an element to decompose, 3. identify ASRs, 4. choose a design satisfying ASRs, 5. instantiate elements & allocate responsibilities, 6. define interface, 7. verify & refine requirements, 8. repeat step 2-7 until all ASRs satisfied

Step4:

4.1 identify concerns, 4.2 list alternatives, 4.3 select patterns/tactics, 4.4 determine relations, 4.5 capture views, 4.6 resolve inconsistencies

[!IMPORTANT]

【2018】描述ADD过程

确定有足够的需求信息

选择要分解的系统要素

确定所选的元素的ASR

选择符合ASR的设计

找出设计问题

列出子关注点替代模式/决策

从清单中选择模式/决策

确定模式/决策与ASR之间的关系

记录初步的架构视图

评估并解决不一致的问题

实例化架构元素并分配职责

实例化元素定义接口

验证和完善需求

重复进行2-7步直到满足所有的ASR

ADD的步骤概述

步骤1：确认有足够的需求信息

系统的涉众已根据业务和任务目标确定了需求的优先级。The system’s stakeholders have prioritized the requirements according to business and mission goals.
您可以确定设计期间要重点关注的系统元素。You determine which system elements to focus on during the design.
您确定是否有关于系统质量属性要求的足够信息：“刺激反应”形式（图）。You determine if there is sufficient information about the quality attribute requirements of the system: stimulus-response form.

步骤2：选择要分解的系统元素

如果是第一次作为“未开发”开发的一部分，则将所有需求分配给系统。If the first time as part of a greenfield development, all requirements are assigned to the system.
完善部分设计的系统时，系统已划分为多个元素，并为其分配了要求。从这些元素中选择一个作为聚焦点。When refining a partially designed system, the system has been partitioned into elements with requirements assigned to them. Choose one of these elements as the focus.
Ploughed field：耕种过的地

步骤3：确定所选元素的ASR

根据对每个需求的高影响，中影响或低影响，根据对架构的相对影响第二次对这些相同需求进行排名。Rank these same requirements a second time based on their relative impact on the architecture as assigning high impact," medium impact," or" low impact" to each requirement.

(H，H) (H，M) (H，L) (M，H) (M，M) (M，L) (L，H) (L，M) (L，L)

第一个字母表示要求对涉众的重要性 The first letter indicates the importance of requirements to stakeholders
第二个字母表示需求对体系结构的潜在影响 The second letter indicates the potential impact of requirements on the architecture

步骤4：选择符合ASR的设计

Step 4.1: Identify design concerns - 找出设计问题
1. 如何解决设计中的 ASR？How to address ASRs in your design?
2. 如何将问题划分成几个子问题。
Step 4.2: List alternative patterns/tactics for subordinate concerns - 列出子关注点替代模式/决策

对于列表中的每个模式，您应该 For each pattern on your list, you should
1. 识别每个模式的区分参数，以帮助您在模式和战术中进行选择 identify each pattern s discriminating parameters to help you choose among the patterns and tactics
2. 估计区分参数的值 estimate the values of the discriminating parameters
Step 4.3: Select patterns/tactics from the list - 从清单中选择模式/决策
1. 使用每种模式时需要进行哪些权衡？ What tradeoffs are expected when using each pattern?
2. 模式之间的结合程度如何？ How well do the patterns combine with each other?
3. 是否有任何模式互斥？ Are any patterns mutually exclusive?
Step 4.4: Determine relationship between patterns/ tactics and ASRs - 确定模式/决策与ASR之间的关系
1. 考虑到目前为止确定的模式/策略，我决定它们之间的关系。Consider the patterns/ tactics identified so far and decide how they relate to each other. The combination of the selected patterns may result in a new pattern.
2. 所选图案的组合可以产生新的图案。
Step 4.5: Capture preliminary architectural view - 记录初步的架构视图
1. 通过开始捕获不同的架构视图来描述您选择的模式。Describe the patterns you have selected by starting to capture different architectural views.
2. 在此阶段，您无需创建完整记录的架构视图（You don’t need to create fully documented architectural views at this stage)
Step 4.6: Evaluate and resolve inconsistencies - 评估并解决不一致的问题
1. 根据体系结构驱动程序评估设计。Evaluate the design against the architectural drivers.
2. 确定是否有未考虑的体系结构驱动程序。Determine if there are any architectural drivers that were not considered.
3. 评估替代模式或应用其他策略。Evaluate alternative patterns or apply additional tactics.
4. 将当前元素的设计与体系结构中其他元素的设计进行评估，并解决所有不一致之处。Evaluate the design of the current element against the design of other elements in the architecture and resolve any inconsistencies.

步骤5：实例化架构元素并分配职责

实例化您选择的每种元素的一个实例。Instantiate one instance of every type of element you chose.
根据子元素的类型分配职责。Assign responsibilities to child elements according to their type.
在其子级之间分配与父级元素相关联的责任。Allocate responsibilities associated with the parent element among its children.
分析并记录您所做的设计决策。Analyze and document the design decisions you have made.

步骤6：为实例化元素定义接口

接口描述了 PROVIDES 和 REQUIRES 假设，即软件元素之间相互联系。Interfaces describe the PROVIDES and REQUIRES assumptions that software elements make about one another.
1. 练习涉及您实例化的元素的功能要求。Exercise the functional requirements that involve the elements you instantiated.
2. 观察由一个元素产生并由另一元素消耗的任何信息。Observe any information that is produced by one element and consumed by another.

步骤7：验证和完善需求，并使其成为实例化元素的约束

验证分配给父元素的所有需求是否已分配给一个或多个子元素。Verify that all requirements assigned to the : parent element have been allocated to one or more child elements.
将分配给子元素的所有职责转换为各个元素的功能需求。Translate any responsibilities assigned to child elements into functional requirements for the individual elements.

步骤8：重复进行，直到满足所有ASR

Inputs & Outputs to ADD

Input ：: Requirements?

文档提供的信息是不充分的。
Output
1. 软件元素：履行各种角色和职责，具有预定属性并与其他软件元素相关以组成系统架构的计算或开发工件 software element: a computational or developmental artifact that fulills various roles and responsibilities, has defined properties, and re elates to other software elements to compose the architecture of a system
2. 角色：一组相关职责 role: a set of related responsibilities
3. 责任：软件元素提供的功能，数据或信息 responsibility: the functionality, data, or information that a software element provides
4. 属性：有关软件元素的附加信息 property: additional information about a software element
5. 关系：两个软件元素如何相互关联或交互的定义 relationship: a definition of how two software elements are associated with or interact with one another

Document Architecture

Views：

Styles (viewpoints), patterns and views

Structural views: module views, component-and -connector views, allocation views

Quality views

Documenting views: 1. build stakeholder/ view table, 2. combine views, 3. prioritise & stage

Info. beyond views: documentation info & architecture info (mapping between views)

Documentation package: views + beyond

[!IMPORTANT]

软件架构风格

module Styles：认为体系结构是由模块组成。模块是实现单元的集合，它提供了一组一致的职责。

C & C Styles 认为体系结构是由组件(主要的处理单元和数据存储)、连接件(组件之间的交互路径)组成的。

Allocation Styles 认为体系结构是由软件元素(软件元素具有环境所需的属性)和环境元素(环境元素有提供给软件的属性)组成的，展示了软件如何与环境关联

[!IMPORTANT]

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

包含View和Beyond

Beyond部分：

文档路线图：包含了范围和总结、简单摘要等。

视图的文档组织方式：描述了本文档中视图是如何组织的。

系统概述：从整体上描述了当前架构的简要说明、业务目标(驱动因素)等等。

视图之间的映射关系：描述了不同视图之间的映射关系。

系统原理：从整体上描述了当前架构的设计原理。

目录-索引、词汇表、首字母缩略词表。

View部分

styles and views(体系结构风格和视图)

Structural views

module views

C & C views

Allocation views

Quality Views

每一个View的内容

主要介绍：显示视图的元素和关系，以及图例

元素介绍，详细介绍第一部分中描述的元素、元素属性、关系属性和元素接口和行为。

上下文图：描述系统如何与环境相关

可变性指南：告知视图中可能出现的变化

基本原理：解释设计如何映射在视图中，以及其合理性。

[!IMPORTANT]

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

Module Styles：分解视图、使用视图、泛化视图、分层视图、领域视图、数据模型视图

Component-Connector Styles：管道-过滤器视图、客户端-服务器视图、点对点视图、面向服务视图、发布-订阅视图

Allocation Styles：部署视图、安装视图、工作分配视图、其他分配视图。

Views

Styles (viewpoints), patterns and views

Three Categories of Styles

Views	描述	示例
Module Views	它是如何构建为一组实现单元的？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 style	它与环境中的非软件结构有何关系？How it relates to non-software structures in its environment?	部署视图、安装视图、工作分配视图、其他分配视图

Styles vs. Patterns

架构风格是元素和关系类型的特殊化，以及关于如何使用它们的一组约束 An architecture style is a"specialization of element and relation types, together with a set of constraints on how they can be used" (Bass, Clements, and Kazman 2003)
架构模式表达了软件系统的基本结构组织模式 An architecture pattern"expresses a fundamental structural organization schema for software systems"(Buschmann et al. 1996)
架构模式的一个重要部分是关注问题和上下文，以及如何在该上下文中解决问题。An essential part of an architecture pattern is its focus on the problem and context as well as how to solve the problem in that context.
架构风格侧重于架构方法，对特定风格何时有用或无用提供更轻量级的指导。An architecture style focuses on the architecture approach, with more lightweight guidance on when a particular style may or may not be useful.
架构模式：{问题，上下文} --> 架构方法 Architecture pattern: {problem, context} --> architecture approach
架构风格：架构方式 Architecture style: architecture approach
风格描述通常不包括详细的问题/上下文信息；架构模式可以。A style description does not generally include detailed problem/context information; architecture patterns do.
微服务知识定义了 element，和 element 通过什么方式进行交互。

Architectural Views

视图是一组系统元素和它们之间关系的表示——不是所有的系统元素，而是特定类型的那些元素 A view is a representation of a set of system elements and relations among them - not all system elements, but those of a particular type.
视图让我们将系统的实体划分为有趣且易于管理的系统表示 Views let us divide the system’s entity into interesting and manageable representations of the system.
不同的视图支持不同的目标和用户，突出不同的系统元素和关系 Different views support different goals and users, and highlight different system elements and relations
不同的视图在不同程度上暴露了不同的质量属性。 Different views expose different quality attributes to different degrees.

Structural view

Module Views

模块是提供一组连贯职责的实现单元 A module is an implementation unit that provides a coherent set of responsibility.

没有至少一个模块视图，任何软件架构的文档都不可能是完整的 It is unlikely that the documentation of any software architecture can be complete without at least one module view.
- 视图示例
1. 分解视图 Decomposition view
2. 使用视图 Uses view
3. 泛化视图 Generalization view
4. 分层视图 Layered view
5. 领域视图 Aspects View
6. 数据模型视图 Data model view
Component-Connector Views

组件和连接器视图显示具有某些运行时存在的元素，例如进程、对象、客户端、服务器和数据存储（称为“组件”）。 Component-and-connector views show elements that have some runtime presence, e.g, processes, objects, clients, servers, and data stores (being termed 'components).

附件指示哪些连接器连接到哪些组件 Attachments indicate which connectors are attached to which components.

通过将连接器的端点连接到组件的端口来显示附件。 Attachment is shown by connecting the endpoints of the connector to the ports of components.
- 视图示例
1. 管道和过滤器视图 Pipe-and-filter view
2. 客户端-服务器视图 Client-server view
3. 点对点视图 Peer-to-peer view
4. 面向服务的架构 (SOA) 视图 Service-oriented architecture (SOA) view
5. 发布订阅视图 Publish-subscribe view
6. 共享数据视图 Shared-data view
7. 多层视图 Multi-tier view
Allocation Views
1. 分配视图描述了软件单元到软件开发或执行环境元素的映射 Allocation views describe the mapping of software units to elements of an environment in which the software is developed or in which it executes.
2. 分配视图的通常目标是将软件元素所需的属性与环境元素提供的属性进行比较，以确定分配是否成功 The usual goal of an allocation view is to compare the properties required by the software element with the properties provided by the environmental elements to determine whether the allocation will be successful or not.
3. 分配视图可以描绘静态或动态视图 Allocation views can depict static or dynamic views
- 视图实例
1. 部署视图 Deployment view
2. 安装视图 Install view
3. 工作分配视图 Work assignment view
4. 其他分配视图 Other allocation views

Quality views

安全视图 Security view
性能视图 Performance view
可靠性视图 Reliability view
通信视图 Communication View
异常（错误处理）视图 Exception(error-handling) view

Documenting views

步骤 1：构建涉众/视图表 Step-1: Build a stakeholder/view table
步骤 2：合并视图 Step-2: Combine views
1. 2.1 识别上表中的边缘视图 2.1 Identify marginal views in the above table
2. 2.2 通过关联一个视图中的元素和另一个视图中的元素，将每个边缘视图与另一个具有更强选区的视图相结合 2.2 Combine each marginal views with another view with stronger constituency by associating between elements in one view and elements in the other
步骤 3：确定优先级和阶段 Step-3: Prioritize and stage
1. 分解视图 decomposition view
2. 80/20 原则 80/20 principle
3. 按顺序完成所有视图？complete all views in sequence?

Beyond (Information Beyond Views)

Documentation info

第 1 部分：文档路线图说明文档中的信息以及在哪里可以找到它 Section-1: Documentation Roadmap tells what in formation is in the documentation and where to find it
1. 范围和总结 Scope and summary
2. 文档的组织方式 How the documentation is organized
  1. 简短的概要 short synopsis
  2. 带注释的目录 annotated table of contents
3. 查看概览 View overview
4. 利益相关者如何使用文档 How stakeholders can use the documentation
Architecture info (mapping between views)

Documentation package: views + beyond

架构评估

架构分析 & 评估方法

ATAM：Architecture Tradeoff Analysis Method

Stakeholders involved in ATAM

Inputs to and Outputs of ATAM: Risks (Non-risks, Risk themes), Sensitivity points, Trade-off points

Phase 0: Partnership & preparation; Phase 3: Follow-up

Phase 1: Evaluation - 1

1.present ATAM, 2. present business drivers, 3. present architecture, 4. identify architectural approaches, 5. generate utility tree, 6. analyse architectural approaches

Phase 2: Evaluation - 2

1.present ATAM & results, 7. brainstorm & prioritize, 8. analyse architectural approaches, 9. present results

架构分析 & 评估方法

一种有助于提出正确问题来评估架构的系统方法 A systematic approach to evaluate architecture needs a method that helps ask right questions
1. 来发现风险 to discover risks
2. 来识别错误的架构决定 to identify wrong architectural choices
3. 确保质量问题得到解决 to ensure quality issues have been addressed
这里有很多用来评估软件架构的方法 There are a number of methods to evaluate software architecture:
1. Software Architecture Analysis Method (SAAM)
2. Architecture Level Modifiability Analysis (ALMA)
3. Performance Assessment of Software Architecture (PASA)
4. Architecture Trade-off Analysis Method (ATAM)
所有这些方法都是基于场景的方法，因为质量属性是使用场景定义的 All these methods are scenario-based approaches as quality attributes are defined using scenarios
场景被映射到架构组件上，以评估架构能力，以满足所需的质量属性 Scenarios are mapped on architectural components to evaluate architectural capability to fulfill desired quality attributes

[!IMPORTANT]

【2018】【2019】Risks，Senstivity Points，Trade-Off Points分别是什么？各举一个例子。

识别风险：发现可能对所需质量属性产生负面影响的架构决策，例如使用分层模式可能带来性能损耗。

发现权衡：影响多个质量属性的架构决策，例如使用分层模式可能会带来性能损耗，但是也会解耦增加系统的可修改性。

发现敏感点：特定质量属性对其敏感的架构决策，比如在对性能敏感的系统中，决定使用缓存中间件。

[!IMPORTANT]

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

阶段-0：准备和建立团队(输入是架构设计文档)

评估计划

阶段-1：评估-1

架构的简明介绍

业务目标（驱动因素）的阐释

作为场景实现的特定质量属性要求的优先级列表

Utility Tree 效用树

风险和无风险点

敏感和权衡点

阶段-2：评估-2

涉众们的优先级场景列表

风险主题和业务驱动因素各自受到的威胁

阶段-3：后续

最终的评估报告

ATAM的整体输出

架构的简明介绍

业务目标（驱动因素）的阐释

表现为质量属性场景的优先质量属性要求

质量属性效用树(Utility Tree)

风险和非风险组

风险主题组(共同的潜在问题或系统性缺陷将风险分组为风险主题)

将架构映射到质量属性

敏感点和权衡点

最终的评估报告

[!IMPORTANT]

【2019】描述在ATAM的每一个过程中有哪些Stack holder和他们的职责

阶段-0：准备和建立团队

参与者：评估团队领导和关键项目决策者

职责：根据架构设计文档生成评估计划，包括谁参加评估、如何何时何地开展评估、最后评估报告会被呈递给谁。

阶段-1：评估-1

参与者：评估团队和项目决策者

职责：

第一步，评估负责人介绍ATAM方法

第二步，项目经理或客户从业务角度介绍业务驱动因素

第三步，首席架构师介绍体系结构

第四步，评估团队确定架构方法

第五步，评估团队和项目决策者生成质量属性效用树(Utiltiy Tree)

第六步，评估团队分析架构方法

阶段-2：评估-2

参与者：评估团队、项目决策者和项目涉众

职责：

第一步，评估负责人介绍ATAM方法和之前已经取得的成果

第七步，涉众头脑风暴并确定场景优先级

第八步，评估团队分析架构方法，类似第六步

第九步，评估团队展示评估结果，并呈递给涉众

阶段-3：后续

参与者：评估团队、主要涉众

职责：评估团队制作最终评估报告，发给主要涉众审核通过后，将报告呈递给委托评估的人。

ATAM：Architecture Tradeoff Analysis Method

ATAM 方法分为 4 个阶段完成

Inputs to and Outputs of ATAM

Summary of ATAM Outputs

架构的简明展示 A concise presentation of the architecture
业务目标的阐述 Articulation of the business goals
表示为质量属性场景的优先质量属性要求 Prioritized quality attribute requirements expressed as quality attribute scenarios
引用树 A utility tree
一组风险和非风险 A set of risks and nonrisks
一组风险主题 A set of riskthemes
将架构决策映射到质量要求 Mapping of architectural decisions to quality requirements
一组确定的敏感度和权衡点 A set of identified sensitivity and tradeoff points
最终的评估报告 Final evaluation report

Phase 0 - Partnership & Preparation

参与者：评估团队领导和关键项目决策者 Participants: evaluation team leadership and key project decision makers
输入：架构设计文档 Inputs: the architecture documentation
输出：评估计划 Outputs: the evaluation plan
1. **谁？**涉众的初步名单 Who? a preliminary list of stakeholders
2. 逻辑：什么时候？什么地点和如何？ Logistics: When? Where? and How?
3. 什么时候评估报告被送给谁？When the evaluation report is to be delivered to whom?
4. 评估报告中应该包含什么信息？What information to be included in the evaluation report?

Phase 1 - Evaluation (1)

参与者：评估团队和项目决策者 Participants: evaluation team and project decision makers
步骤 1-6 Step 1-6
输出 Outputs:
1. 架构的简明介绍 a concise presentation of the architecture
2. 业务目标（驱动因素）的阐述 articulation of the business goals (drivers)
3. 作为场景实现的特定质量属性要求的优先列表 a prioritized list of specific quality attribute requlrements realized as scenarios
4. 效用树 utility tree
5. 风险和无风险 risks and nonrisks
6. 敏感点和权衡点 sensitivity points and tradeoff points

Step1 - Present the ATAM

评估负责人向集合的项目代表（“决策者”）简要介绍 ATAM，让他们了解评估的过程和输出 The evaluation leader presents the ATAM in brief to assembled project representatives (‘decision makers’) for their understanding of the process and outputs of the evaluation

Step2 - Present the Business Drivers

项目经理或系统的客户从业务角度呈现系统概览，描述 Project manager or system’s customer presents a system overview from a business perspective, describing 1. 它最重要的功能需求 its most important functional requirements 2. 其技术、管理、经济或政治限制 its technical, managerial, economic, or political constraints 3. 其商业目标和上下文 its business goals and context 4. 其主要涉众 its major stakeholders 5. 架构驱动因素（塑造架构的主要质量属性目标）the architectural drivers (major quality attribute goals that shape the architecture)

Step3 - Present the architecture

首席架构师在适当的细节级别上进行了描述架构的演示： The lead architect makes a presentation describing the architecture at an appropriate level of detail:
1. 技术限制，例如规定使用的操作系统、硬件或中间件 technical constraints such as an OS, hardware, or middleware prescribed for use
2. 系统必须与之交互的其他系统 other systems with which the system must interact
3. 用于满足质量属性要求的架构方法 architectural approaches used to meet quality attribute requirements
架构演示（大约 20 张幻灯片；60 分钟）Architecture Presentation (Approximately 20 slides; 60 Minutes)
1. 推动架构要求、与这些要求相关联的可测量数量，以及满足这些要求的任何现有标准/模型/方法（2-3 张幻灯片） Driving architectural requirements, the measurable quantities you associate with these requirements, and any existing standards/ models/ approaches for meeting these (2-3 slides)
  1. 重要的架构信息（4-8 张幻灯片）：Important architectural information (4-8 slides):
    1. 语境图 - 系统在其存在的语境中。系统将与之交互的人类或其他系统。 Context diagram-the system within the context in which it will exist. Humans or other systems with which the system will interact.
    2. 模块或层视图 - 描述系统功能分解的模块（可以是子系统或层），以及填充这些的对象、过程、函数以及它们之间的关系（例如，过程调用、方法调用、回调，遏制）。Module or layer view- the modules (which may be subsystems or layers) that describe the system s decomposition of functionality, along with the objects, procedures, functions that populate these, and the relations among them (e.g, procedure call, method invocation, callback, containment).
    3. 组件和连接器视图进程、线程以及连接它们的同步、数据流和事件。Component-and-connector view-processes, threads along with the synchronization, data flow, and events that connect them.
    4. 部署视图 - CPU、存储、外部设备/传感器以及连接它们的网络和通信设备。还显示了在各种处理器上执行的进程。Deployment view- CPUs, storage, external devices/ sensors along with the networks and communication devices that connect them. Also shown are the processes that execute on the various processors.
  2. 采用的架构方法、模式或策略，包括它们解决的质量属性以及这些方法如何解决这些属性的描述（3-6 张幻灯片）：Architectural approaches, patterns, or tactics employed, including what quality attributes they address and a description of how the approaches address those attributes (3-6 slides):
    1. 商业现货（COTS）产品的使用以及它们的选择/集成方式（1-2 张幻灯片）。Use of commercial off-the-shelf (COTS) products and how they are chosen/integrated (1-2 slides).
    2. 跟踪 1 到 3 个最重要的用例场景。如果可能，包括每个场景消耗的运行时资源（1-3 张幻灯片）。Trace of 1 to 3 of the most important use case scenarios. If possible, include the runtime resources consumed for each scenario (1-3 slides).
    3. 跟踪 1 到 3 个最重要的变化场景。如果可能，根据更改的模块或界面（1-3 张幻灯片）描述更改影响（更改的估计大小/难度） Trace of1 to 3 of the most important change scenarios. If possible, describe the change impact (estimated size/ difficulty of the change) in terms of the changed modules or interfaces (1-3 slides).
    4. 与满足驱动架构要求相关的架构问题/风险（2-3 张幻灯片）。Architectural issues/risks with respect to meeting the driving architectural requirements (2-3 slides).
    5. 词汇表（1 张 PPT）Glossary (1 slide).

Step4 - Identify Architectural Approaches

ATAM 专注于通过理解架构方法来分析架构。ATAM focuses on analyzing an architecture by understanding its architectural approaches.
在这一步，评估团队：By this step, the evaluation team
1. 研究了架构文档 have studied the architecture documentation
2. 听取了架构师的展示 have heard the architect’s presentation
3. 向架构师询问了设计系统时使用的模式和策略 have asked the architect about patterns and tactics used in designing the system
评估团队对已确定的架构方法（风格、模式和策略）进行编目。The evaluation team catalogs the architectural approaches (styles, patterns and tactics) that have been identified.

Step5 - Generate Quality Attribute Utility Tree

这是指导其余分析的关键步骤。 This is a crucial step that guides the remainder of the analysis.
评估团队与项目决策者合作，确定、确定和优化系统最重要的质量属性目标。The evaluation team works with the project decision makers to identify, prioritize and refine the system’s most important quality attribute goals.
质量属性目标通过质量属性效用树详细阐述，该树通过精确定义相关质量属性需求使需求具体化。The quality attribute goals are articulated in detail via quality attribute utility tree that makes the requirements concrete by defining precisely the relevant quality attribute requirements.

Step6 - Analyze Architectural Approaches

目标是让评估团队确信该方法的实例化适合满足特定于属性的要求。The goal is for the evaluation team to be convinced that the instantiation of the approach is appropriate for meeting the attribute-specific requirements.
评估团队通过要求架构师解释架构如何相互支持，一次检查排名最高的场景（来自实用程序树）。The evaluation team examines that the highest-ranked scenarios(from the utility tree) one at a time by asking the architect to explain how the architecture supports each other.
评估团队记录相关的架构决策，并通过讨论识别和分类其风险、非风险、敏感点和权衡。The evaluation team documents the relevant architectural decisions and identifies and catalogs their risks, nonrisks, sensitivity points, and tradeoffs through a discussion.
分析是为了引出足够的架构信息，以在已经做出的架构决策和需要满足的质量属性之间建立某种联系。The analysis is to elicit sufficient architectural information to establish some link between the architectural decisions that have been made and quality attributes that need to be satisfied.
在这一步结束时，评估团队应该清楚地了解整个架构的最重要方面、关键设计决策的基本原理以及风险、非风险、敏感点和权衡点的列表。At the end of this step, the evaluation team should have a clear picture of the most important aspects of the entire architecture, the rationale for key design decisions, and a list of risks, nonrisks, sensitivity points, and tradeoff points.

Phase 2 - Evaluation (2)

参与者：评估团队，项目决策者和架构涉众 Participants: evaluation team, project decision makers, and architecture stakeholders
步骤(1) 7-9 Step (1) 7~9
输出：Outputs:
1. 涉众社区的优先场景列表 a list of prioritized scenarios from the stakeholder community
2. 风险主题和业务驱动因素受到每一个威胁 risk themes and business drivers threatened by each one

Step-1: Present the ATAM & Previous Results

重复步骤 1，以便利益相关者了解方法和他们将扮演的角色。 Step 1 is repeated so that the stakeholders understand the method and the roles they are to play.
评估负责人总结第 2 步到第 6 步的结果，并分享输出（效用树除外）。The evaluation leader recaps the results of steps 2 through 6, and shares the outputs (except the utility tree).

Step-7: Brainstorm & Prioritize Scenarios

此步骤的目的是把握更大的利益相关者社区的脉搏，以了解系统成功对他们意味着什么。The purpose of this step is to take the pulse of the larger stakeholder community to understand what system success means to them.
评估团队要求利益相关者集思广益，就其个人角色而言，在操作上有意义的场景。The evaluation team asks the stakeholders to brainstorm scenarios that are operationally meaningful with respect to their individual roles.
一旦收集了场景，就会要求利益相关者对他们认为代表行为或质量问题的场景进行优先级排序和合并。Once the scenarios have been collected, stakeholders are asked to prioritize and merge scenarios they feel represent the behavior or quality concern.
将优先场景列表与实用程序树中的场景进行比较。The list of prioritized scenarios is compared with those from the utility tree.
如果差异很大，则额外的情景可能被识别为风险。If the discrepancy is significant, the additional scenario may be identified as a risk.

Step-8: Analyze Architectual Approaches

在此步骤中，评估团队执行与步骤 6 中相同的活动，使用排名最高的（例如前 5 到 10）但新生成的场景。In this step, the evaluation team performs the same activities as in Step 6, using the highest ranked (e.g. top 5 to 10), but newly generated scenarios.
架构师解释了相关的架构决策如何有助于实现每个决策。 The architect explains how relevant architectural decisions contribute to realizing each one.

Step-9: Present Results

评估团队根据共同的潜在问题或系统性缺陷将风险分组为风险主题。The evaluation team groups the risks into risk themes, based on common underlying concern or systemic deficiency.
然后，确定的风险主题与步骤 2 中列出的特定业务驱动因素相关。The identified risk themes are then related to specific business drivers listed in Step 2.
从评估中收集的信息被总结并呈现给所有利益相关者：The collected information from evaluation is summarized and presented to all stakeholders:
1. 记录的架构方法 The architectural approaches documented
2. 集思广益的场景集及其优先级 The set of scenarios and their prioritization from brainstorming
3. 实用树 The utility tree
4. 发现的风险和记录的非风险 The risks discovered and nonrisks documented
5. 发现的敏感因素和权衡因素 The sensitivity points and tradeoff points found
6. 风险主题和受威胁的业务驱动因素 Risk themes and the business drivers threatened by each one

Phase 3 - Follow-up

参与者：评估团队和主要涉众（评估客户） Participants: evaluation team and key stakeholders (evaluation clients)
输出：最终评估报告 Outputs: the final evaluation report
评估团队制作一份书面最终报告，分发给主要涉众以供审核。The evaluation team produces a written final report that is circulated to key stakeholders for revlew.
审查结束后，将报告提交给委托评估的人。After the review, the report is delivered to whom commissioned the evaluation.

微服务部分

[!IMPORTANT]

微服务部署模式

上下文

微服务架构包含一组服务

每个服务都部署为一组服务实例，以实现吞吐量和可用性

问题

如何大规模部署微服务？

需求

服务使用各种语言、框架和框架版本编写

需要快速构建、独立部署和扩展服务

服务实例需要相互隔离

需要监控每个服务实例的行为、部署可靠

需要限制服务消耗的资源（CPU 和内存）

尽可能经济高效地部署应用程序

[!IMPORTANT]

微服务部署模式

单主机部署多个服务实例

单主机部署单个服务实例

将服务部署到虚拟机

将服务部署到容器

服务部署平台

无服务器部署

微服务可观测性模式

上下文

多台机器上、多个服务和服务实例

请求跨越多服务实例，每个服务通过执行一个或多个操作来处理请求

以标准化格式将操作信息写入日志文件，跟踪用户行为和代码异常

服务实例可能无法处理请求但仍在运行

问题：

如何理解用户和应用程序的行为并解决问题？

如何检测正在运行的服务实例无法处理请求？

模式列表：

日志聚合

审计日志

应用程序指标

分布式跟踪

异常跟踪

健康检查API

[!IMPORTANT]

微服务的6个特性

1、拆分服务–组件化（通过进程间通信的⽅式变成独⽴单元）；

2、微服务中，团队围绕业务组织；

3、服务与服务之间遵循⾯向对象的⾼内聚低耦合；

4、拆分后的分布式系统，服务数量变多，可能带来⼀致性等问题，具有去中⼼化的特性；

5、⾃动化的管理，依赖基础设施服务（主要是运维层⾯）；

6、设计过程中针对质量属性的策略，核⼼是故障，保障服务等设计；

[!IMPORTANT]

如何将应用拆分为微服务？

需求：

高内聚：实现一组密切相关的功能

松耦合：封装内部细节，API交互

单一职责原则（SRP）

共同封闭原则（CCP）

双披萨团队开发

团队自治

拆分模式列表：

根据业务能力进行服务拆分

根据子域进行服务拆分

领域驱动设计方法论的核心

根据动静态调用关系拆分

[!IMPORTANT]

微服务架构通信模式

问题：

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

客户端如何在网络上发现服务实例的位置？

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

模式列表：

断路器（Circuit Breaker）模式

应用层服务发现模式

平台层服务发现模式

API Gateway模式

[!IMPORTANT]

领域驱动设计⾥⾯的战略设计和战术设计的区别、各据俩个例⼦

**战略设计：**通过 DDD 的理论，对业务进行领域划分构建领域模型，梳理出相应的限界上下文，通过统一的领域语言从战略层面进行领域划分以及构建领域模型。在构建领域模型的过程中需要梳理出对应的聚合、实体、以及值对象。

**战术设计：**以领域模型为战术设计的输入，以限界上下文作为微服务划分的边界进行微服务拆分，在每个微服务中进行领域分层，实现领域模型对于代码的映射，从而实现 DDD 的真正落地实施。

[!IMPORTANT]

企业架构设计的⼀般设计过程

业务架构设计

战略设计：确定战略⽬标和主要措施，分解识别业务⽬标，拆分能⼒需求，形成战略能⼒聚类，形成组织设计（谁来⼲）

业务设计与分析：通过流程模型、产品模型、数据模型组成并扩展为业务模型，定义了以提⾼⽣成效率和避免操作性错误为核⼼的⽤户体验模型，并对业务组件进⾏业务需求分析形成业务架构

应⽤架构设计：设计应⽤构件和应⽤，进⾏应⽤分析，服务拆分等⽅法，识别并定义⽤例

技术架构设计：包括物理构建设计和技术平台设计

安全架构设计：满⾜安全要求的设计。选择安全⼯具

微服务定义

微服务架构是把应用程序功能性分解为一组服务的架构风格，每一个服务都是由一组专注、内聚的功能职责组成。

主要特性

上面有👆

SOA 🆚 MSA

~~怎么感觉DevOps见过这图~~

关键步骤

定义系统操作
- 将需求提炼为系统必须处理的关键请求（系统操作）
  - 定义架构的第一步
  - 描述服务之间协作方式的架构场景
  - 如更新/检索数据等
- 由抽象的领域模型定义
  - 领域模型从需求派生
- 输入：需求，用户故事/相关用户场景/源代码恢复等
- 步骤一：创建领域模型
- 步骤二：确定系统操作
定义微服务（围绕业务概念而非技术）
- 根据业务能力进行服务拆分
- 根据子域进行服务拆分
- 根据动静态调用关系进行服务拆分
定义服务API和协作方式
- 将标识的系统操作分配给服务
- 独立或与其他服务协作（涉及通信方式）实现操作

重构策略

策略1. 将新功能实现为微服务：

API Gateway：新功能的请求路由到新服务，遗留系统请求路由到单体
集成胶水（Integration Glue）代码：将服务与单体结合，访问单体所有数据，并能调用单体实现的功能

策略2. 提取业务能力到服务中：

详细设计部分 - pmx部分

简答题+设计题

设计题

要给出设计方案，类图、代码…

问题描述 -> 前提条件 -> 解法 -> 「效果/优缺点/已知应用，关联解法，其他相关模式」

简答题

设计原则之间的关系

设计模式体现了什么原则

模式和模式的变体，模式与模式之间的异同点

设计原则

设计模式

模式名称
问题
解决方案
- 角色&角色的关系
效果
- 作为题目中约束条件的一部分

设计模式分类

按范围、按目的分
关注模式之间的组合

防御式编程

防御式编程：可以预见到（或至少预先推测到）问题所在，断定代码中每个阶段可能出现的错误，并作出相应的防范措施，来防止类似意外的发生。
断言：在开发期间使用的、让程序在运行时进行自检的代码，是对开发人员的警告，通常是一个子程序或宏。断言不可以有副作用。
异常：是将代码中的错误或异常事件传递给调用方代码的一种特殊手段，谨慎使用可以降低复杂度。
错误处理：根据软件类别平衡正确性和健壮性（哪个优先级更高）
隔离程序：隔离程序是以防御式编程为目的而进行隔离的一种方法，将某些接口选定为“安全”区域的边界，对穿越安全区域边界的数据进行合法性检验（集中工作在特定的模块中降成本）
辅助调试代码：辅助进行代码调试的代码，帮助快速检查错误，应该尽早地引入辅助调试代码。
攻击式编程：主动暴露出可能出现的错误，在开发阶段将其暴露显现出来，而在产品代码运行时让他能够自我恢复。

表驱动

表驱动法：一种编程模式

目的：表驱动法适用于复杂逻辑，将复杂逻辑从代码中独立出来方便单独维护
原理：从表里面查找信息而不使用逻辑语句 (if 和 else)
具体实现
1. 直接访问表：直接通过索引值可以从表中找到对应的条目
2. 索引访问表：首先从索引表中找到数据表的地址，然后再从数据表中找到对应的条目 ( 节省空间、管理廉价、容易维护 )
3. 阶梯访问表：根据每项命中的阶梯层次来确定其归属

24软件系统设计

24考试回忆

架构部分 - zh部分

Intro

架构定义

软件架构师在做什么 What Does a Software Architect Do?

架构来源

视图 4+1 views

体系结构活动 & 软件体系结构过程 Software Architecture Process

软件体系结构和体系结构知识领域 Software Design & Architecture Knowledge Areas

质量属性

软件需求

功能性需求 Functional Requirements

质量需求 Quality Requirements

非功能性需求 Non-functional Requirements

约束 Constraints

质量属性

质量属性方案建模 Modeling Quality Attribute Scenarios

质量属性

Tactics 策略(原子级别的最小的决定)

Checklist for Design and Analysis

架构攸关的需求 Architecturally Significant Requirements

从需求文档中收集ASR Gathering ASRs from Requirements Documents

通过和涉众面谈来收集ASR Gathering ASRs by Interviewing Stakeholders

通过Utility树来获取ASR Capturing ASRs in a Utility Tree

架构模式

Architectural Pattern

Module Patterns

分层模式 Layered Pattern

Component-Connector Patterns

代理模式 Broker Pattern

模型-视图-控制器模式 Model-View-Controller Pattern(MVC)

Pipe-and-Filter Pattern 管道和过滤模式

Client-Server Pattern 客户端-服务端模式

Peer-to-Peer Pattern 点对点模式

Service-Oriented Pattern 面向服务的模式

Publish-Subscribe Pattern 发布-订阅模式

Shared-Data Pattern 共享数据模式3

Allocation Patterns

Map-Reduce Pattern

Multi-Tier Pattern 多层模式

Patterns VS Tactics

设计架构

General Design Strategy

Categories of design desicions

Attribute-Driven Design 2.0

ADD的步骤概述

步骤1：确认有足够的需求信息

步骤2：选择要分解的系统元素

步骤3：确定所选元素的ASR

步骤4：选择符合ASR的设计

步骤5：实例化架构元素并分配职责

步骤6：为实例化元素定义接口

步骤7：验证和完善需求，并使其成为实例化元素的约束

步骤8：重复进行，直到满足所有ASR

Inputs & Outputs to ADD

Document Architecture

Views

Styles (viewpoints), patterns and views

Three Categories of Styles

Styles vs. Patterns

Architectural Views

Structural view

Quality views

Documenting views

Beyond (Information Beyond Views)

Documentation package: views + beyond

架构评估

架构分析 & 评估方法

ATAM：Architecture Tradeoff Analysis Method

Inputs to and Outputs of ATAM

Phase 0 - Partnership & Preparation

Phase 1 - Evaluation (1)

Step1 - Present the ATAM

Step2 - Present the Business Drivers

Step3 - Present the architecture

Step4 - Identify Architectural Approaches

Step5 - Generate Quality Attribute Utility Tree

Step6 - Analyze Architectural Approaches

Phase 2 - Evaluation (2)