软件系统设计复习往年题 | wbl-z’s Blog

架构定义

什么是软件架构

• 所有架构都属于设计
• 结构、元素、关系、设计

定义

1. 软件架构是程序或计算系统的结构，由软件元素、这些元素外部可⻅的属性、这些元素的关系组成
2. 一个系统的基本组织形式，包含于它的组件、组件之间和软件与环境之间的关系、⽀配它的设计和演进的原则

所有架构都是软件设计，但不是所有设计都是架构

架构与设计

• 架构是设计过程的⼀个部分
• 是⾼层次的设计
• 是⼀系列的设计决定
• 因地制宜的
• 系统的结构/组织
• 元素：组件和连接件
• 关系：静态/动态关系
• 属性：元素、元素的组、总体的系统

架构与架构

• 系统分解为组件、模块、子系统

架构定义了

• 组件接口：组件能做什么
• 组件交互和依赖：组件怎么交互
• 组件责任：组件怎么按要求做

架构定义了交互

• 数据传输机制
• 控制流

体系结构强调非功能性需求

非功能性需求 NFRs include

• 技术约束 Technical constraints
• 商业约束 Business constraints
• 质量属性 Quality attrilbutes

体系结构视图

体系结构视图主要是为了应对软件不可见的问题，屏蔽其他没有影响的部分，将关注点进行分离

软件体系结构代表了一个复杂的设计制品

如何开发设计

1. 分解 Decomposition
2. 抽象 Abstraction
3. 逐步的：分而治之 Stepwise: Divide and Conquer
4. 生成和测试 Generate and Test
5. 迭代：渐进式细化 Iteration: Incremental Refinement
6. 重用元素 Reusable elements

架构做什么

• 联络

• 在客户、技术团队和业务需求分析师之间

• 与主管或销售

• 软件工程

• 软件工程最佳实践

• 技术知识

• 技术领域的深⼊理解

• ⻛险管控

• 与设计、技术选择相关联的⻛险

哪来的

• ASRs
• stakeholders开发维护，考虑他们的利益

架构（4+1）视图

https://juejin.cn/post/7271283075171205156

• 逻辑、过程、物理、开发视图

• 逻辑：

• 元素间的逻辑关系、静态的，除非架构变化，否则不变

• 描述了体系结构中在体系结构上明显重要的元素以及他们之间的关系

• 过程：

• 动态

• 描述了体系结构中的并发和交流元素 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.

• 开发：

• 描述了体系结构的需求，关系到了超过一个常规的视图。是四个视图在某一个场景下进行描述Architecture use cases: capture the requirements for the architecture; related to more than one particular view

• 用例场景（Use Case）：捕获架构需求，与一个或多个特定视图相关。

【UML】软件工程中常用图：类图、部署图、时序图、状态图_软件工程 uml-CSDN博客

• 逻辑视景（Logical view）：逻辑视景和提供给最终用户的机能有关。会用统一建模语言（UML）来表现逻辑视景，包括有类别图、状态图等[2]。
• 过程视景（Process view）：过程视景处理系统的动态层面，说明系统的过程以及通信的方式，着重在系统运行时的时间特性。过程视景描述并发性、分散、集成者、性能以及可扩缩性（scalability）等。表示过程视景的UML有时序图、通信图、活动图[3][2]。
• 开发视景（Development view）：开发视景描述从程序员的观点所看到的系统，着重软件的管理。此视景也称为实现视景（implementation view），会用到UML中的组件图来说明系统组件。包图也可以用来说明开发视景[2]
• 实体视景（Physical view）：实体视景以系统工程师的观点来说明系统，这和软件组件在物理层上的拓扑有关，也和各组件之间的实体连接有关。此视景也称为是布署视景（deployment view）UML图中的部署图可以说明实体视景[2]。
• 情景（scenarios）：这种说明架构的方式是透过小型的用例或情景来进行，这是第五个观点。情景会叙述各对象、各过程之间交互的结果。也可以用来识别架构元素，也可叙述并且确认架构设计。这也是架构原形测试的起点。此视景也称为是用例视景（use case view）。

架构活动

• 架构实践、确认、维护、演化

架构设计的活动

• 识别ASRs，指导架构设计的依据
• 考虑已有的框架、风格、模式、tactic
• 形成文档
• 架构的分析和评估 stakeholder参与，是否满足ASR要求

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

质量属性

• 功能 需求：说明系统的行为

• 质量需求：系统完成工作的好坏程度 NFRs

• constraints：约束，设计时预设好的，满足现有系统架构或者法律法规要求

• 质量属性：对质量属性的高度抽象聚合

• 内部：系统作为白盒，开发人员知道系统是如何实现的，系统之内出发，可修改性、可测试性、可靠性

• 外部：系统之外的，外部用户看系统是个黑盒，与系统交互能够体验到的，可用性、易用性、安全性

• 刺激-响应，基于情境来建模

• 谁发出

• 刺激是什么

• 作用在那一部分

• 发生刺激是在什么环境中

• 产生什么样的响应

• 度量

• 什么策略来解决问题，在每一个策略下有很多tactics

• checklist是在架构设计时需要覆盖的七个方面，结合质量属性

• 如何从用户获取ASR，哪些需求是架构时要考虑的

• 需求中获取ASR最简单，但是信息缺少

• workshop（interviews）、最终商业目标（作为最终裁决标准）、使用项目树组织排序（utility tree）

需求

功能性需求

• 系统必须要做的、系统如何为涉众提供价值，意为系统的⾏为
• 功能的实现可能⽤了很多的结构，但功能是与结构⽆关的

质量需求

• 是整个系统的期望特征，是在功能需求之上的
• 如果质量属性很重要，软件架构将约束功能的分配到不同的结构

约束

• 是 0 自由度的设计决定
• 是预定义的设计决定
• 接受设计决定、协调其他受影响的设计决定，如此来满足约束

非功能需求 NFRs

非功能需求是质量需求

质量需求包括质量属性 约束

1. 在执行过程中可观察（外部）：系统满足其行为要求的程度如何？例如性能，安全性，可用性，易用性等。Observable (External) during execution: How well a system satisfies 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.

• ⾮功能需求和架构需求是质量属性的两个相互替代的形式
• 不太可能先把功能做好再考虑⾮功能需求
• ⾮功能需求必须在设计的时候就考虑

质量属性

• 替代用语：非功能要求或体系结构要求
• 质量不能在开发结束后才被加到系统上
• 需要在开发的所有阶段考虑质量
• 业务⽬标决定了系统需要有的质量
• 质量属性高于系统功能，是系统功能、服务和行为的基本陈述 Quality attributes are over and above of system’s functionality, which is the basic statement of the system’s capabilities, services, and behaviours.
• 功能通常是开发计划的第⼀步，但是系统常因缺乏预期的质量水平而被重新设计
• 软件体系结构限制了各种质量属性的实现，例如性能，安全性，可用性等 Software architecture constrains the achievement of various quality attributes, e.g., performance, security, usability etc.
• 这就是为什么软件架构被认为是落实质量要求的最恰当的层次
• 没有质量属性完全依赖于设计，也没有完全依赖于实现或者部署

质量属性场景建模

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

只要定义好这 6 个元素，就能锁定架构的一个场景，之后可以用来进行架构的设计。

刺激和响应发生在一个环境中：系统正常运行、系统过载、系统受到攻击、系统网络等出现了故障。

战术（tactic）

（原子级别的最小的决定）

• 战术是影响质量属性响应控制的设计决策，例如冗余。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.

质量设计决策

架构是设计决策的集合。Architecture is a collection of design decisions.

七类设计决策（可能重叠） Seven categories of design decisions (may overlap):

1. 职责分配 Allocation of responsibilities：将大的职责进行分配

2. 协调模型 Coordination model：各部分之间的沟通、交互

3. 数据模型 Data model：数据格式、存储方式（缓存等）

4. 资源管理 Management of resources：CPU、网络、内存、时间（部分时间敏感的场景）等资源

5. 架构元素之间的映射 Mapping among architecture elements：将架构元素如何映射到软件的实现上

6. 绑定时间决策 Binding time decisions：

7. 系统的变化可以在什么时间点前需要固定下来，也就是这个时间前，系统还是可以变化的，但是这个时间之后就不可以变化了

8. 比如选择安装环境是需要在一个时间点前完成的，技术是否添加、编译时间、初始化时间，运行时绑定，但运行时是弹性最大的

9. 实际上我们希望绑定时间越往后越好，但是也就要付出相应的代价。

10. 技术选择 Choice of technology：前面的部分都确定后，我们可以选择技术栈相对比较局限，解空间已经被压缩了。

质量属性举例

• Adaptability 适应性
• Extensibility 可扩展性
• Availability 可⽤性
• Modularity 模块化性
• Configurability 可配置性
• Portability 便携性
• Flexibility 灵活性
• Reusability 可重⽤性
• Interoperability 互操作性
• Testability 可测试性
• Performance 性能
• Auditability 可审计性
• Reliability 可靠性
• Maintainability 可维护性
• Responsiveness 响应性
• Manageability 可管理性
• Recoverability 可恢复性
• Sustainabilit 持续性
• Scalability 可伸缩性
• Supportability 保障性
• Stability 稳定性
• Usability 易⽤性
• Security 安全性

可用性 Availability

1. 可用性是应用程序的关键要求 Key requirement for most IT applications

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

3. 营业时间内100％可用 100% available during business hours

4. **每周计划的停机时间不超过2个小时-24x7x52(100％可用性)**No more than 2 hours scheduled downtime per week - 24x7x52 (100% availability)

5. 相关性：与应用程序的可靠性有关 Related to an application’s reliability

6. 不可靠的应用程序的可用性较差 Unreliable applications suffer poor availability

7. 可用性、可靠性不同：

8. 可用性是指可以使用，但是不保证正确

9. 可靠性是指可以稳定正确的使用。

10. 可用性损失的时间由以下因素决定：Period of loss of availability determined by:

11. 发现故障的时间 Time to detect failure

12. 纠正故障的时间 Time to correct failure

13. 重启应用的时间 Time to restart application

14. 例子(时间序)：发生故障-检测到故障-纠正故障-重启应用，这三个代表的是not available的时间(N/A)

15. 提高可用性的方案

16. 尽可能降低N/A的时间

17. 机器尽可能缩短failure到detect时间

18. 机器尽可能缩短correct到restart的时间

19. 尽可能提高Available的时间

20. 高可用性策略 Strategies for high availability

21. 消除单点故障 Eliminate single points of failure

22. 复制和故障转移 Replication and failover

23. 自动检测并重启 Automatic detection and restart

24. 可恢复性(例如数据库)Recoverability (e.g… a database)

25. 在应用程序或系统出现故障后，可以重新建立性能级别并恢复受影响的数据的功能。The capability to re-establish performance levels and recover affected data after an application or system failure.

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

27. MTBF(平均无故障时间)MTBF (mean time between failures)

28. MTTR(平均维修时间)MTTR (mean time to repair)

29. 计算可用性时，可能不考虑计划内的停机时间。Scheduled downtimes may not be considered when calculating availability

Outage, Failure, Fault, Error

1. 可用性是指通过减少故障来最大程度地减少服务中断时间。Availablity is about minimizing the service outage time by mitigating faults.

2. Failure的原因称为Fault。A failure’s cause is called a fault.

3. 当系统无法交付该系统期望的服务时，将发生Failure。A failure occurs when a system cannot deliver a service that is expected of that system.

4. Failure是系统状态的可观察特征。A failure is an observable characteristics of a system’s state.

5. 系统任何部分中的Fault都有可能导致Failure。系统可以从Failure中修复或恢复。A fault in any part of a system has a potential to cause a tailure; a system can be repaired or recovered from a failure.

6. Fault发生与Failure之间的中间状态称为Error。Intermediate states between the occurrence of a fault and a ftailure are called errors.

7. 名词辨别

8. Outage是系统不可用的情况，scheduled downTime就是一种Outage。

9. Failure：系统不可用失效

10. Fault：是系统导致Failure的原因，Fault不会立即导致Failure

11. Error：在Fault发生与Failure的中间状态。

服务水平协议 Service-Level Agreement

1. Amazon EC2的SLA Amazon EC2’s SLA
2. AWS将通过商业上合理的努力来使Amazon EC2在服务年度内的年度正常运行率至少达到99.95％。如果Amazon EC2不符合年度正常运行时间百分比承诺，您将有资格获得服务信用。AWS will use commercially reasonable efforts to make Amazon EC2 available with an Annual Uptime Percentage of at least 99.95% during the Service Year. In the event Amazon EC2 does not meet the Annual Uptime Percentage commitment, you will be eligible to receive a Service Credit.
3. 99.95%的是99.9%的一半

对于Failure的计划 Planning for Failure

1. 危害分析 Hazard analysis: 对Failure进行分类

2. 灾难性的/危险 Catastrophic/ Hazardous

3. 重大的/轻微的 Major/ Minor

4. 没有效果 No effect

5. 故障树分析：Fault tree analysis:

• 分级处理Failure

1. 故障模式，影响和严重性分析(Failure Mode, Effects, and Criticality Analysis：FMECA) Failure Mode, Effects, and Criticality Analysis (FMECA)

2. FMECA依靠过去类似系统的故障历史。FMECA relies on the history of failure of similar systems in the past.

3. 5∗10−5=1∗10−3∗5%5∗10−5=1∗10−3∗5%5∗10−5=1∗10−3∗5%

可用性通用方案 Availability General Scenario

1. source：可能是内部的，也可能是外部的，可能是人、设施、硬件等等，无论是哪一类都会引起可用性的问题，都能发出一个刺激
2. Stiumulus：Failure，不正确的时间、不正确回复(超过边界)
3. 工件：在进程中、交流通道中等等
4. 环境：各种不同的系统环境，正常的错误的等等
5. 反应：错误发生后一些的可能反应，recover是correct的时间

防止错误变成失败

1. 检测故障：

2. 记录故障

3. 通知有关实体(人员或系统)

4. 从错误中恢复：

5. 禁用导致故障的事件源

6. 在进行修理时暂时不可用

7. 修复或掩盖错误/故障或包含它所造成的损害

8. 在进行修复时，以降级模式操作。

9. 反应度量：时间上、可用性的描述(多长时间，可以用多少)

10. 系统必须可用的时间或时间间隔可用性百分比(例如，99.999%)

11. 检测故障的时间

12. 修复故障的时间

13. 系统处于退化模式的时间或时间间隔

14. 某一特定值的比例(例如99%)或比率(例如，每秒100%)

15. 系统防止或处理的错误的类别，而不会失败。

可用性具体方案 Availability Sample Scenario

1. Source没有收到Heartbeat认为出现了一个Failure
2. 将Stimulus发送给正在处理的进程
3. 进程会通知Operation(人和服务器，来检查是否可以运行)
4. 最后会发送一个回复
5. 整体发生在一个正常运转的环境中

可用性策略 Availability Tactics

1. 这个树说明了对于可用性可以采用哪些手段来解决可用性：很重要

2. 每一个树的分支代表了我们考虑的时间点：尽可能的延长可用时间

3. 不同的检测服务可用的手段

4. 主动发送心跳：Heart Beat

5. 资源的损耗有一次通讯

6. 可以同时承担更多的业务(定期更新状态)

7. 自动化检测，更为定时的服务

8. 单向更为安全

9. 被动接受检测：Ping/Echo 或 Minotor

10. 资源损耗有两次通讯

11. 更加灵活自助，根据自己的情况进行检测

12. 双向确认

13. TimeStamp

14. 收到一系列的消息应该在时间上有先后顺序

15. 进行常识的信息的检查，如果和常识不符合那么可能是出现了问题

16. 自检：检查一下自己是否有问题

Fault

Fault 探测 Fault Detection

1. Ping/Echo

2. 一个组件发出ping命令，并期望在预定时间内在另一个组件上产生回波。One component issues a ping and expects, an echo from another component within a pre-detined time.

3. Ping/Echo可以在负责一项任务的一组组件中使用。Ping/Echo can be used within a group of components responsible for one task.

4. 心跳(死人时间) Heartbeat(dead man time)

5. 一个组件定期发出心跳消息(也可以携带数据)，而另一个组件侦听该消息。One component emits a heartbeat message (can also carry data) periodically and another component listens for it.

6. 如果心跳失败，则假定始发组件已失败，并通知故障纠正组件。If the heartbeat fails, the originating component is assumed to have failed and a fault correction component is notified.

7. 异常 Exception

8. 识别故障的一种方法是遇到异常。One method for recognising faults is to encounter an exception.

9. 异常处理程序通常在引入异常的同一过程中执行。The exception handler typically executes in the same process that introduces the exception.

10. ping和心跳策略在不同的进程中运行，异常策略在单个进程中运行。The ping and heartbeat tactics operate among distinct processes, and the exception tactic operates within a single process.

Fault 恢复 Fault Recovery

1. 表决 Voting

2. 在冗余处理器上运行的进程每个都接受等效输入并计算一个简单值，该值将发送给投票者。Processes running on redundant processors each take equivalent input and compute a simple value that is sent to a voter.

3. 如果投票者从单个过程中检测到异常行为，则它会使失败。If the voter detects deviant behaviour from a single process, it fails it.

4. 主动冗余 Active redundancy

5. 所有冗余组件均以并行方式响应事件-所有组件均处于相同状态。All redundant components respond to events in parallel - there are all in the same state.

6. 仅使用了一个组件的响应，其余组件则被丢弃。The response from only one component is used, and the rest are discarded.

7. 发生故障时，通常不存在停机时间，因为备份是最新的，唯一的切换时间是恢复时间。When a failure occurs, the downtime is usually non-existent as backup is current and the only switching time is the recovery time.

8. 被动冗余 Passive redundancy

9. 一个组件(主要)响应事件，并通知其他组件(辅助)它们必须进行的状态更新。One component (primary) responds to events and informs the other components (secondary) of state updates they must make.

10. 发生故障时，系统必须首先确保备份状态足够新，然后才能恢复服务。When a failure occurs, the system must first ensure that the backup state is sufficiently recent before resuming services.

11. 备件 Spare

12. 备用备用计算平台配置为替换许多不同的故障组件。A standby spare computing platform is configured to replace many different failed components.

13. 影子操作 Shadow operation

14. 先前发生故障的组件可能会在“影子模式”下运行一小段时间，以确保它可以模仿工作组件的行为，然后再将其恢复正常工作。A previously failed component may be run in “shadow mode” for a short time to make sure that it mimics the behaviour of the working components before restoring it to service.

15. 状态重新同步 State re-synchronisation

16. 被动和主动冗余策略要求要恢复的组件在恢复服务之前对其状态进行升级。The passive and active redundancy tactics require the component being restored to have its state upgraded before its return to service.

17. 检查点/回滚 Checkpoint/ Rollback

18. 检查点记录的是定期或响应特定事件创建的一致状态。A checkpoint is recording of a consistent state created either periodically or in response to specific events.

19. 从服务中删除 Removal from service

20. 该策略将系统的某个组件从运行中移除，以进行一些活动以防止预期的故障。This tactic removes a component of the system from operation to undergo some activities to prevent anticipated failure.

21. 交易 Transaction

22. 事务是几个连续步骤的捆绑，这样就可以一次撤消整个捆绑。A transaction is the bundling of several sequential steps such that the entire bundle can be undone at once.

23. 过程监控器 Process monitor

24. 一旦检测到流程中的故障，监视流程就可以检测到不良流程并为其创建新实例，并按照备用策略将其初始化为适当的状态。Once a fault in a process has been detected, a monitoring process can detect the non- pertorming process and create a new instance ot it, initialised to some appropriate state as in the spare tactic.

可用性设计和分析的检查列表

互操作性 Interoperability

1. 互操作性是指两个或多个系统可以在特定上下文中通过接口完全改变有意义的信息的程度 Interoperability is about the degree to which two or more systems can usefully exchange meaningful information via interfaces in a particular context.

2. 交换数据的能力(语法互操作性)Ability to exchange data (syntactic interoperability)

3. 能够正确解释数据(语义互操作性)Ability to correctly interpret the data (semantic interoperability)

4. 互操作性需要确定与谁，什么以及在什么情况下(上下文)。Interoperability needs to identify with whom, with what, and under what circumstances (the context).

5. 互动 Interface

6. 夏琳说金告诉她特雷弗听说希瑟想参加你的聚会。Charlene said that Kim told her that Trevor heard that Heather wants to come to your party.

7. 互操作性的两个重要方面：Two important aspects of interoperability:

8. 发现：服务的使用者必须发现服务的位置，身份和接口。Discovery: the consumer of a service must discover the location, identity, and the interface of the service.

9. 处理回应

：Handling of the response:

1. 向请求者报告并做出响应。reports back to the requester with response.
2. 将其响应发送到另一个系统。sends its response on to another system.
3. 向任何感兴趣的各方广播其回复。broadcasts its response to any interested parties.

互操作性的通用方案 Interoperability General Scenario

互操作性的样本方案 Interoperability Sample Scenario

. 互操作性的策略 Interoperability Tactics

1. 定位 Locate

2. 发现

服务：通过搜索已知目录服务来找到服务Discovery service: locate a service through searching a known directory service.

1. 多级间接 multiple levels of indirection

2. 管理界面 Manage interfaces

3. 编排：使用控制机制来协调，管理和排序特定服务的调用。Orchestrate: uses a control mechanism to coordinate and manage and sequence the invocation of particular services.

4. 定制界面：添加或删除界面功能 Tailor interface: adds or removes capabilities to an interface.

5. Orchestrate：请求，一个请求会涉及到多个Service，我们需要按照一定顺序进行处理请求

互操作性的检查列表 Checklist for Interoperability Design & Analysis

可修改性 Modifiability

1. 可修改性涉及更改以及进行更改所花费的时间或金钱，包括这种可更改性影响其他功能或质量属性的程度。Modifiability deal with change and the cost in time or money of making a change, including the extent to which this modifiability affects other functions or quality attributes.

2. 为变更做准备是有代价的，而进行变更则要付出代价。There is a cost of prepraring for change as well as a cost of making a change.

3. 计划可修改性的四个问题 Four questions to plan for modifiability

4. 有什么可以改变的？What can change?

5. 变化的可能性是多少？What is the likelihood of the change?

6. 何时进行更改，谁进行更改？When is the change made and who makes it?

7. 变更的费用是多少？What is the cost of the change?

8. 如果更改少于预期，则可能不需要昂贵的修改机制。If fewer changes than expected come in, then an expensive modification mechanism may not be warranted.

9. 计算公式：N * 不使用机械装置进行更改的成本 ≤≤≤ 安装机械装置的成本 +(N *使用机械装置进行更改的成本)

10. 降低的成本可以用于提高可修改性

可修改性的通用方案 Modifiability General Scenario

可修改性的样本方案 Modifiability Sample Scenario

可修改性的策略 Modifiability Tactics

1. Reduce Size of a Module：拆分模块：如果要修改的模块包含大量功能，则修改成本可能会很高(尽可能的控制包的大小)。Split module: If the module being modified includes a great deal of capabilities, the modification costs will likely be high.

2. Increase Cohesion：增加语义一致性：如果模块中的职责A和B不能达到相同的目的，则应通过创建新模块或将职责移至现有模块将它们放置在不同的模块中。Increase semantic coherence: If the responsibilities A and B in a module do not serve the same purpose, they should be placed in different modules by creating a new module or moving a responsibility to an existing module.

3. Reduce Coupling：

4. 封装为模块引入了显式接口，并减少了对一个模块的更改传播到其他模块的可能性。Encapsulation introduces an explicit interface to a module, and reduces the probability that a change to one module propagates to other modules.

5. 使用中介打破依赖：所有的组件都要通过中间的组件进行通信，使用反模式等方法解决。Use an intermediary breaks a dependency.

6. 当两个模块受到相同更改的影响时，请进行重构：不同于代码重构 Refactor when two modules are affected by the same change.

7. Defer Binding：延迟绑定：在生命周期中与初始定义阶段不同的阶段绑定某些参数的值。Defer binding: Binds the value of some parameters at a different phase in the life cycle than the one in which they are initially defined.

Checklist for Modifiability Design and Analsis

性能 Performance

1. 性能与时间有关，软件与系统满足时序要求的能力有关。(单位时间内能做多少事情) Performance is about time and the software system’s ability to meet timing requiements.

2. 所有系统都有性能要求，即使未明确表示也是如此。All systems have pertormance requirements, even it they are not explicitly expressed.

3. 响应时间的两个基本因素 Two basic contributors to the response time

4. 处理时间(系统正在响应时) processing time (when the system is working to response)

5. 阻塞时间(系统无法响应时) blocked time (when the system is una able to response)

性能的通用方案 Performance General Scenario

性能的样本方案 Performance Sample Scenario

性能的策略 Tactics for Performance

1. 在需求方面 On the demand side

2. 管理采样率(降低采样频率) Manage sampling rate (reducing sampling frequency)

3. 限制事件响应：当离散事件到达系统的速度太快而无法处理时，必须将事件排队，直到可以处理它们为止。Limit event response: When discrete events arrive at the system too rapidly to be processed, the events must be queued until they can be processed.

4. 如果不是所有事件都同样重要，则对事件进行优先级排序。Prioritize events if not all events are equally important.

5. 通过使用中介来增加处理事件流的资源，从而减少开销 Reduce overhead by using intermediaries to increase the resources in processing an event stream

6. 在资源方面 On the resource side

7. 增加资源(更快的处理器，更多的内存，更快的网络…)Increase resources(faster processor, additional memory, faster network…)

8. 如果可以并行处理请求，请引入并发性。Introduce concurrency if requests can be processed in parallel.

9. 维护多个计算副本：使用负载平衡器将新工作分配给可用的重复服务器之一。Maintain multiple copies of computations: Use load balancer to assign new work to one of the available duplicate servers.

10. 维护数据的多个副本：Maintain multiple copies of data:

11. 快取 caching

12. 资料复制 data replication

Checklist for Performance Design and Analysis

安全性 Security

1. 安全性衡量系统保护数据和信息免遭未授权访问的能力，同时仍提供对授权人员和系统的访问权限。Security measures system’s ability to protect data and information from unauthorized access while still providing access to people and systems that are authorized.

2. 安全性的三个特征：(CIA) Three characteristics of security: (CIA)

3. 机密性，Confidentiality：防止未经授权访问数据和服务。Confidentiality: Data and services are pretected from unauthorized access.

4. 完整性，Integrity：数据和服务不会受到未经授权的操纵。Integrity: Data and services are not subject to unauthorized manipulation.

5. 可用性，Availability：系统将可供合法使用。Availability: The system will be available for legitimate use.

安全性的通用方案 Security General Scenario

安全性的样本方案 Security Sample Scenario

安全性的策略 Security Tactics

1. 通过将系统内的网络流量或服务请求模式与一组签名或已知模式进行比较来检测入侵 Detect intrusion by comparing network traffic or service request patterns within a system to a set of signatures or known patterns.
2. 检测服务拒绝 Detect service denial
3. 使用校验和或哈希值验证消息的完整性。Verify message integrity using checksums or hash values.
4. 确定参与者-系统的任何外部输入的来源。ldentify actors - source of any external input to the system.
5. 验证演员或他们所要扮演的角色。Authenticate actors who or what they purport to be.
6. 授权有权访问和修改数据或服务的行为者。Authorize actors who have the rights to access and modify either data or services.
7. 限制对计算资源的访问。Limit access to computing resouces.
8. 通过最小化系统的攻击面来限制暴露。Limit exposure by minimizing the attack surface of a system.
9. 加密数据。Encrypt data.
10. 正在进行攻击时，撤消对敏感资源的访问。Revoke access to sensitive resources when an attack is underway.
11. Authenticate：认证，Authorize：授权。

安全性的检查列表 Checklist for Security Design and Analysis

可测试性 Testability

1. 可测试性是指可以使软件通过(通常基于执行)测试来证明其故障的难易程度。Testability refers to ease with which software can be made to demonstrate its faults through (typically execution-based) testing.
2. 为了使系统能够正确测试，必须有可能控制每个分量S的输入，然后观察其输出。For a system to be properly testable, it must be possible to control each component s inputs and then to observe its outputs.

可测试性的通用方案 Testability General Scenario

可测试性的样本方案 Testability Sample Scenario

可测试性的策略 Testability Tactcs

1. 控制和观察系统状态：维护某种状态信息，允许测试人员为该状态信息分配一个值，和/或使测试人员可以按需访问该信息。Control and observe system state: Maintain some sort of state information, allow testers to assign a value to that state information, and/or make that information accessible to testers on demand.

2. 专用界面使您可以控制或捕获组件的值 Specialized interfaces allow you to control or capture values for a component.

3. 记录/回放导致故障的状态，然后重新创建故障。 Record/playback the state that caused a fault and re-create the fault.

4. 沙盒将系统的实例与现实世界隔离开来，可以进行实验以消除其后果。Sandboxing isolates an instance of the system from the real world to enable experimentation to undo its consequences.

5. 限制复杂度**：复杂的软件更难测试，因为它的操作状态空间很大**，并且在大状态空间中重新创建精确状态更加困难。Limit complexity: Complex software is harder to test, because its operating state space is very large and more difficult to re-create an exact state in a large state space.

6. 限制结构的复杂性，避免、减少或解决组件之间的依赖关系；隔离和封装对外部环境的依赖关系。Limit structural complexity avoiding, reducing or resoling dependencies between components; isolating and encapsulating dependencies on external environment.

7. 限制派生一个类的类的数量。Limit the number of classes from which a class is derived.

8. 限制继承树的深度和类的子级数。Limit the depth of the inheritance tree and the number of children of a class.

9. ==限制多态和动态调用==。Limit polymorphism and dynamic calls.

10. 限制不确定性-限制行为复杂性 Limit nondeterminism - limiting behavioral complexity.

11. 非确定性系统更难测试。Nondeterminism systems are harder to test.

可测试性的检查列表 Checklist for Testability Design and Analysis

易用性 Usability

1. 易用性与用户完成所需任务的难易程度以及系统提供的用户支持的类型有关。Usability is concerned with h how easy it is for the user to accomplish a desired task and the kind of user support the system provides.

2. 可用性包括以下几个方面：Usability comprises the following aspects:

3. 学习系统功能 Learning system features

4. 有效使用系统 Using a system efficiently

5. 最小化错误的影响 Minimizing the impact of errors

6. 使系统适应用户需求 Adapting the system to user’s needs

7. 增强信心和满意度 Increasing confidence and satistaction

易用性的通用方案 Usability General Scenario

易用性的样本方案 Usbility Sample Scenario

易用性的策略 Usability Tactics

1. 支持用户主动权：支持用户纠正错误或提高效率。Support user initiative: support the user in either correcting errors or being more efficient.

2. 取消 Cancel

3. 撤消：系统必须维持足够数量的系统状态，以便可以恢复更早的状态。Undo: System must maintain a sufficient amount of system state so that an earlier state may be restored.

4. 用户启动长时间操作运行时暂停/恢复 Pause/resume when a user has initiated a long-running operation

5. 将较低级别的对象聚合到一个组中，以便可以将操作应用于该组。Aggregate the lower-level objects into a single group, so that the operation may be applied to the group.

6. 初步支持

系统：确定系统用来预测其自身行为或用户意图的模型。Support system initiaive: Identify the models the system uses to predict either its own behavior or the user’s intention.

1. 维护任务模型：确定上下文，以便系统可以了解用户的尝试并提供帮助，对任务进行建模。Maintain task model: Determine context so the system can have some idea of what the user is attemping and provide assistance.
2. 维护用户模型：代表用户的关于系统的知识，根据用户行为训练出用户的模型 Maintain user model: Represent the user’s knowledge of system.
3. 维护系统模型：确定预期的系统行为，以便可以向用户提供适当的反馈。Maintain system model: Determine expected system behavior so that appropriate feedback can be given to the user.

Checklist for Usbility Design and Analysis

架构模式

架构模式里除了分层、Map-Reduce、Mutil-tier都是CC

定义

context problem solution

能够复用的解决方案

元素+关系+constraints = solution

1. 是在实践中反复发现的一套设计决策 is a package of design decisions that is found repeatedly in practice,

2. 具有允许重复使用的已知属性，并且描述了一类架构 has known properties that permit reuse, and describes a class of architectures.

3. 背景：世界上经常发生的常见问题，会引起问题 A context: A recurring, common situation in the world that gives rise to a problem.

4. 一个问题：在给定的上下文中出现的问题，经过适当概括 A problem: The problem, appropriately generalized, that arises in the given context.

5. 解决方案：针对问题的成功架构解决方案，并进行了适当抽象 A solution: A successful architecture resolution to the problem, appropriately abstracted.

module pattern

layered pattern

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

分层模式变体

1. 上面的 A、B、C：不是一种分层模式：

2. 分层的核心是为了实现关注点分离

3. 不是分层模式：

4. 形成了环状依赖

5. 没有实现关注点分离，一个的修改可能有多个原因

6. 是一种软件的坏味道

7. 下面的 A、B、C、D：是一种分层模式：

8. 也可以是一种分层模式，D 不期待 A 的结果且 D 不期待 B 的结果

9. 而严格意义和其他场景中，不认为是一种分层模式

分层模式对质量属性的影响

可修改性

可模块化

可维护性

可复用性

micro-service

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

1. 相同点：微服务和 SOA 都是分布式架构，微服务架构可以看作是SOA的一种实现方式，适用于更小规模和更灵活的应用系统。都包含了服务契约、服务封装、服务重用、服务组合、服务自治和服务无状态等基本特点。
2. 微服务去掉了 SOA 架构中的 ESB(Enterprise Service Bus) 企业服务总线，采用轻量级通信机制 (HTTP、REST) 进行服务之间的通信。
3. 微服务引入了熔断器：避免出现服务失效或网络问题等导致的级联故障。
4. 部署和扩展：在SOA中，整个应用程序通常作为一个单元进行部署和扩展。而在微服务架构中，每个微服务可以独立部署和扩展，使得系统具有更好的弹性和可伸缩性。
5. 服务粒度：在SOA中，服务的粒度可以比较大，一个服务可能涵盖多个相关的业务功能。而在微服务架构中，服务的粒度更小，每个服务通常专注于一个特定的业务功能。
6. 组织和治理：SOA通常需要涉及企业范围内的中央治理和管理，不能控制独立服务的演变。而微服务架构强调团队的自治性，每个微服务可以由一个独立的团队进行开发和管理，更加注重服务的自治性和快速迭代。

是分布式架构，SOA的一种扩展

1. 微服务架构风格是一种将一个单一应用开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制，这些服务围绕业务能力构建并可以通过自动部署机制独立部署。

2. 微服务特点

3. 服务颗粒化:服务粒度由业务功能决定，服务间尽可能解耦

4. 责任单一化:单一职责原则，服务内尽可能内聚

5. 运行隔离化:服务运行在各自进程中，互不影响

6. 管理自动化:对服务提供自动化部署与监控预警能力，高效管理

7. 微服务核心模式：针对采用微服务系统在特定问题所使用的程序的架构解决方案的集合

8. 服务注册与发现

9. API网关

10. 熔断器

11. 微服务的挑战

12. 运维要求高:微服务数量多，部署与监控要求高

13. 发布复杂度:部署环境多样化，网络性能系统容错、分布式事务等挑战

14. 部署依赖强:服务间相互调用关系复杂，存在部署顺序依赖

15. 通信成本高:跨进程调用比进程内调用消耗更多的资源

微服务架构特点

• 通过服务组件化

• 组件是⼀个可独立替换或升级的软件单元，微服务架构实现组件化的⽅式是分解成服务

• 服务是⼀种进程外的组件，它通过 Web 服务请求或远程过程调⽤（RPC）机制通信

• 使⽤服务作为组件的主要原因是服务是可独立部署

• 使⽤服务作为组件产⽣更加明确的组件发布接⼝

• 围绕业务能⼒组织

• 传统软件系统开发管理通常聚焦在技术层⾯，导致⽤户界⾯团队、服务逻辑团队、数据库团队
  等的划分，将始终伴随跨团队的沟通、交接和预算审批等

• 微服务采⽤围绕业务能⼒的划分⽅法来组织服务，实现在服务的业务领域内的宽栈实现，其团
  队都是跨职能的，包括全⽅位开发技能，如⽤户体验、数据库、项⽬管理

• 微服务采⽤产品开发模式，⽽⾮项⽬模式，开发团队负责软件的整个⽣命周期，持续关注软件
  如何帮助⽤户提升业务能⼒，实现价值交付

• 内聚与解耦

• 基于微服务构建的系统⽬标是尽可能的解耦和尽可能的内聚，他们拥有各⾃的领域逻辑

• 当系统被划分成分离的服务时，可利⽤领域驱动设计（Domain-Driven Design）的理念，把⼀
  个复杂域划分成多个限界上下⽂（Bounded Context），并且映射出它们之间的关系

• 服务和上下⽂边界的确定有助于澄清和强化分离，实现解耦

• 去中⼼化

• 去中⼼化治理，在构建微服务时各服务可以⾃⼰选择技术栈

• 服务之间只需要约定接⼝，⽽⽆需关注彼此的内部实现

• 运维只需要知道服务的部署规范

• 去中⼼化数据存储，微服务更倾向于让每个服务管理⾃⼰的数据库，或者同⼀数据库技术的不
  同实例，或完全不同的数据库系统

• 去中⼼化数据管理，对跨微服务的数据来说，去中⼼化责任对管理升级带来困难，微服务架构
  强调服务间的⽆事务协作，需要权衡更⼤⼀致性的业务损失与修复错误的代价

• 基础设施⾃动化

• 随着基础设施的⾃动化，特别是云和 Web Services 等技术的发展，已经降低了构建、部署和
  运维微服务的操作复杂度

• 服务设计

• ⾼可⽤性

• 任何服务调⽤都可能因为服务提供者不可⽤⽽失败，客户端必须尽可能有效地应对这种失效

• 为每个单独的服务设置完善的监控和⽇志记录，有助于快速发现不良突发⾏为⽽尽早修复

• 变更与演化

• 把组件放在服务中，只需重新部署修改的服务，可以在更细粒度上实现频繁、快速的发布

• 服务的划分上，系统中很少变更的部分应该和正在经历频繁改动的部分放在不同的服务⾥
  （如果不断地⼀起改变两个服务，它们应该被合并）

组件-连接器模式

为了解决一个问题，使用一个模式，可能会对别的质量属性产生正面或者负面的影响

需要做权衡和补充设计，最大化收益、忽略能够容忍的负面影响

broker：代理解决互操作问题

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

对质量属性的影响

1. 优点

2. Interoperability：根本目的，提高 Server-Client 之间的交互性

3. Scaliability：可伸缩和扩展

4. Modifiabiliy：

5. 两面性：

6. Security：代理对象屏蔽了系统内部的具体实现

7. Reliability：服务降级和实例重启

8. Availability：

9. 缺点：

10. Security：成为被攻击的对象

11. Reliabiliy：可靠性会降低

12. 两面性：

13. Performance：整体大集群的性能可能会提高（QPS 等提高），但是局部单点性能会下降，多次网络请求、多次匹配，有可能会抵消。

MVC

使用运行时、动态、相互之间的关系来审视，集成到了开发框架中，也是分层架构的变种（会强调各模块之间的约束关系，model 不可以直接返回到 controller）

• model 业务逻辑
• view 处理用户展示，接收用户操作
• controller 对用户操作进行处理，将信息通知给 model
• model -> controller 不会产生通信

Pipe-and-Filter Pattern

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

每一组件表示 filter，连接两个组件的部分是 pipe（类似于 queue 交易任务的排队等待处理）

任何一个 filter 都依赖于前一个 filter 的输出，中间没有机会接收外部的交互来改变严格定义好的流程。

不适用于一些可以引入变形的场景（相互独立、不依赖前面的产出，会带来损耗）

Client-Server Pattern

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

1. ATM 验证身份，某一个 server 会给很多设备提供服务。

2. ATM 操作安全监控、盗刷之类，通过 monitoring 发现问题找到记录

3. 对银行工作人员而言，需要新的业务，policy 发生变化，银行工作人员定义 ATM 上的操作

4. 银行负责安全金融的根据 ATM、对照用户操作行为是否有安全隐患，多对多。

5. 问题：broker 也存在 client 和 server 之间的关系，对质量属性的影响，做一下比较，broker 是之前，c/s 是 90 年代流行广泛应用

6. 互操作性：可能导致变弱？没有 broker，需要人为连接

7. 安全性：Client、Server 不采用 broker 可能被拦截

8. 伸缩性

9. 性能

10. 可修改性

11. 小型局域网、互联网还没有普及，规模有限，直接联系，性能上安全性可能带来更大收益

12. broker 的一些负面影响就不必承担了，c/s 会比 broker 投入更少，收益可能更大

peer-to-peer 点对点模式

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

1. 可能安全性不受保障，因为节点既是 Client 又是 Server，被攻击可能性提高了，attack、surface 受攻击面变大
2. 数据分布在不同的节点上，相同数据多处拷贝，如果要的话，可能会导致数据不一致（数据一致性难度更大），不能保证数据一定可用，数据可用性不能百分之百保证。
3. 可用性 availability，同一个数据多个副本，所以个别数据出问题不影响整体。
4. 但又不能保证 availability，不会以后任何一个节点有权限。
5. Performance：多个节点同时提供服务，性能快（多个渠道获取数据，并行能力提高）

service-oriented 面向服务

1. 具备 broker 的优势，这里又不想继承 broker，所以 broker 消失了
2. 出现类似集基础设施的组件，代替单一节点 broker，单点失效的问题消失了
3. 商业模式的变化、看技术可用性
4. 基础条件——互联网普及范围参与者人数规模比以往大这样一个背景下打破 broker c-s
5. 追求更高互操作性更高伸缩性
6. 技术条件下提供的服务越来越多现在可以分得更细更大差异化更细粒度的组合可以实现出来社会分工越来越细（不同航空公司不同酒店细粒度体现如果固定就很难实现差异化）微服务也是这样的体现服务粒度越来越小是有很多技术条件支持的（单体系统内部复杂度外化外面复杂度可以进行动态绑定可以提供多样化服务）

publish-subscribe 发布订阅

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

1. 传统操作系统也是通过事件驱动方式来管理的
2. IDE 环境注册后就行结构发布的事件
3. 数据发生变化会反映到环境中去
4. 性能上的延迟（可限制 subscriber 数量订阅越多性能下降）
5. scalability publisher 数量不会变多
6. 发布者不关心每个订阅者都收到不是 guarantee

share-data 共享数据模式

allocation pattern

每个pattern之间并不是互斥，而是描述一个系统在不同视角下的

map-reduce 映射-规约

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

1. map reduce 部署在不同的地方
2. 词频分析案例大量数据
3. Map-Reduce Based System
4. 每一个 partition 对应一个 map 每一个 map 任务一样不同实例
5. 所有词汇使用频率标注出来
6. 通过 reduce 进行合并
7. 最后进行排序

multi-tier 多层模式

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

pattern和tactic

pattern包括要解决的问题和发生问题的场景context

1. 策略比模式简单。他们使用单一的结构或机制来应对单一的架构力量 Tactics are simpler than patterns; they use a single structure or mechanism to address a single architectural force.WW

2. 模式通常将多个设计决策组合到一个包中 Patterns typically combine multiple design decisions into a package.

3. 模式和策略共同构成了软件设计师的主要工具 Patterns and tactics together constitute the software architect’ s primary tools.

4. 战术是设计的“构建块”，可从中创建架构模式 Tactics are “building blocks” of design from which architectural patterns are created.

5. 大多数模式包含几种不同的策略，这些策略可能 Most patterns consist of several different tactics that may:

6. 都有共同的目的 all serve a common purpose,

7. 经常被选择来承诺不同的质量属性 be often chosen to promise different quality attributes

8. 示例：分层模式 Example: layered pattern

9. 提高语义一致性 Increase semantic coherence

10. 限制依赖 Restrict dependencies

11. tactic 是设计最小粒度

12. tactic 进行组合

13. 一个 tactic 是为了某一个质量属性也会影响其他属性（正面、负面）

14. 针对某一个质量属性 Modifiability 相关的 tactic 和 pattern 之间的关系是否涉及到

设计架构

通用设计策略

abstraction：从下往上进行抽象，忽略、隐藏细节，关注高抽象层次的关系

分解decomposition：分解成一个个问题？

divide & conquer：分而治之

generation and test：看组合能不能满足ASR要求，

iteration：迭代、修正

reuse：复用以往的成功设计，快速 有保障的方式

在设计软件时应用了哪些通用设计策略？为每个策略提供一个带有软件架构的简明工作示例。

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

设计应该覆盖的内容

1. responsibility：职责
2. coordination：系统中元素如何协调通讯
3. data 处理数据，输入输出，管理存储协议格式，不同介质上的分配
4. resource 资源分配，计算资源、网络、cache、软件资源、时间
5. elements mapping元素的对应关系 从架构元素到软件元素
6. binding time 元素与元素之间的关系什么时候确认，五个时间点绑定，绑定时间越靠后越灵活，但是增加不确定和测试负担
7. technology 实现技术和技术栈的选择

ADD 属性驱动设计

输入

Architecturally significant requirements

ASR，最重要的功能需求和constraints

输出

• 软件元素
• 角色
• 职责
• 属性
• 关系

八步过程

1. 确保有充足的需求信息

2. 系统的涉众已经根据业务和任务⽬标，对需求定优先级

3. 你可以决定在设计过程中关注哪些系统元素

4. 你可以决定是否有充⾜的关于系统的质量属性需求的信息

5. “刺激-响应”形式

6. 选择元素作为设计焦点：哪一个元素承担了最多最重要的ASR

7. 如果是第⼀次作为绿地开发的⼀部分，所有需求都被分配给系统

8. 当细化⼀个部分设计的系统时，系统被划分为多个元素，并分配了相应的需求，选择其中⼀个
   元素作为焦点

9. 识别哪些相关ASR

10. 根据这些需求对架构的相对影响，对这些相同的需求进⾏第⼆次排序，为每个需求分配“⾼影
    响”“中影响”“低影响”

11. (H,H)(H,M)(H,L)(M,H)(M,M)(M,L)(L,H)(L,M)(L,L)

12. 第⼀个字符表示需求对涉众的重要性

13. 第⼆个字符表示需求对架构的潜在影响

14. 选择设计满足ASR

4.1. 识别设计关注点

• 如何在设计中落实你的 ASR ？

4.2. 为从属关注点列出可选的模式、战术

• 对于列表中的每个模式，应该
• 确定每个模式的估计参数，以帮助你在模式和战术中选择
• 判别参数的估计值

4.3. 从列表中选择模式、战术

• 在使⽤每种模式时，需要进⾏哪些权衡？
• 模式如何良好地组合？
• 有没有相互排斥的？

4.4. 决定模式、战术与 ASR 之间的关系

• 考虑到⽬前为⽌确定的模式、战术，并决定它们之间的关系。所选模式的组合可产⽣新模式

4.5. 捕捉初步架构视图

• 通过开始捕捉不同的架构视图，来描述你选择的模式
• 在此阶段，你不需要创建完全⽂档化的架构视图

4.6. 评估和解决不⼀致

• 根据架构驱动因素对设计进⾏评估
• 决定是否存在未考虑的架构驱动因素
• 评估可选的模式或者应⽤附加的战术
• 对照架构中其他元素的设计，评估当前元素的设计，并解决不⼀致的问题

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

2. 为你选择的每类元素实例化⼀个实例

3. 根据类型，分配职责给每个⼦元素

4. 在⼦元素上分配与⽗元素相关联的职责

5. 分析并⽂档化你所做的设计决定

6. 为实例化的元素定义接⼝

7. 接⼝描述了元素之间的“提供”和“需要”的假设

8. 运⽤涉及实例化元素的功能性需求

9. 观察由⼀个元素产⽣并由另⼀个元素消费的任何信息

10. 验证和细化需求，并使它们成为实例化元素的约束

11. 验证所有被分配到⽗元素的需求都被分配到了⼀个或多个⼦元素

12. 将分配给⼦元素的任何职责转化为给单个元素的功能性需求

13. 重复直到所有 ASR 都被满⾜

views and beyond

合并视图减少视图数量

排序来减少不重要的视图，得到精简的视图

对视图进行说明，提供作出决定的依据、视图之间的关系

视图之外的补充信息（跨越视图、系统之间的）

评估：在不同阶段对系统掌握的信息不同，使用不同的手段，使用不同的方法

为什么软件系统架构需要使用不同视图来文档化？给出4种示例视图的名称和目的。

1. 原因

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

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

4. 4种视图(了解)：

5. 模块视图 Module View：提供一组连贯职责的实现单元

6. 组件和连接器视图 C & C View：显示具有某些运行时存在的元素

7. 分配视图 Allocation View：描述了软件单元到软件开发或执行环境元素的映射

8. 质量视图 Quality Views，安全视图、性能视图、可靠性视图、沟通视图、异常（错误处理）视图

9. 组合视图：将上述视图进行组合

模块视图

• 模块是提供⼀套连贯的职责的实现单元
• 没有⾄少⼀个模块视图，任何软件架构⽂档都不可能完整

包含

• 分解视图 Decomposition view
• 使⽤视图 Uses view
• 概括视图 Generalization view
• 分层视图 Layered view
• ⽅⾯视图 Aspects view
• 数据模型视图 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

• 分配视图描述了软件单元到软件开发或执⾏环境元素的映射
• 分配视图的通常⽬标是⽐较软件元素所需的属性和环境元素所提供的属性，以确定分配是否成功
• 分配视图可以描述静态或动态视图

包含

• 部署视图 Deployment view
• 安装视图 Install view
• ⼯作安排视图 Work assignment view
• 其他分配视图 Other allocation view

总结

• 元素

• 软件元素。软件元素具有环境所需的属性

• 环境元素。环境元素具有提供给软件的属性

• 关系：被分配。软件元素被映射（分配）到环境元素，属性取决于特定视图

• 约束：视不同视图⽽定

• ⽤途

• ⽤于对性能、可⽤性、安全性 security 和安全性 safety 进⾏解释

• ⽤于解释分布式开发和将⼯作分配给团队

• ⽤于解释软件版本的并⾏访问

• ⽤于解释系统安装的形式和机制

质量视图

包含

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

文档化视图

选择视图三步走

1. 构建涉众-视图表

2. 组合视图

3. 确定上表中的边缘视图

4. 通过将⼀个视图的元素与另⼀个视图中的元素相关联，将每个边缘视图与另⼀个更具⽀持性
   的视图相结合

5. 确定优先级和阶段

6. 分解视图

7. ⼋⼆开原则

8. 按顺序完成所有视图？

涉众与视图

将视图组合

1. 各种 C&C 视图 Various C&C view
2. 带有 SOA 或通信进程视图的部署视图 Deployment view with either SOA or communicating- process Views
3. 分解视图和任何工作分配、实施、使用或分层视图 Decomposition view and any of work assignment, implementation, uses, or layered views

• 使用一张视图说明整个系统的部署信息

视图模板

1. 第 1 部分：主要介绍 Section-1: The Primary Presentation

2. 显示视图的元素和关系 shows the elements and relations of the view

3. 通常带有一个键的图形 often graphical with a key

4. 第 2 部分：元素目录 Section-2: The Element Catalog

5. 详细介绍了第 1 节中描述的元素。details the elements depicted in Sect.1

6. 元素及其属性 Elements and their properties

7. 关系及其属性 Relations and their properties

8. 元素接口和行为 Element interfaces and behavior

9. 第 3 部分：上下文图 Section-3: Context Diagram

10. 系统或其部分如何与其环境相关 how the system or its portion relates to its envlronment

11. 第 4 部分：可变性指南 Section-4: Variability Guide

12. 如何在此视图中练习架构的任何变化点 how to exercise any variation points of the architecture in this view

13. 第 5 节：基本原理 Section-5: Rationale

14. 为什么设计反映在视图中 why the design reflected in the view

15. 提供了一个令人信服的论据，证明它是合理的。 provides a convincing argument that it is sound .

超越视图

超越视图的⽂档

1. 范围和总结 Scope and summary

2. 文档的组织方式 How the documentation is organized

3. 简短的概要 short synopsis

4. 带注释的目录 annotated table of contents

5. 查看概览 View overview

6. 利益相关者如何使用文档 How stakeholders can use the documentation

文档控制信息

文档间映射

文档包

评估架构

评估方法 ATAM

参与者

输入输出

ASR与项目树中体现出来的重要场景

风险（非风险）：组织形成风险主题，对某一类的ASR，怎样影响商业目标达成

敏感点

权衡点：影响多个ASR

第一个阶段：介绍评估过程、项目经理介绍目标、架构师介绍重要决定和视图、平菇小组如何做设计、一起决定重要场景和形成项目树、对重要场景和使用的设计决定产生对应（是否解决）

第二个阶段：展示第一阶段结果、不能向stakeholder透露项目树（不受之前的设计者和评估者的影响）、头脑风暴收集对stakeholder重要的场景、排序投票、得到列表、与项目树对比、发现不一致、调整列表、形成评估的文档

ATAM 体系结构权衡分析方法

: Architecture Tradeoff Analysis Method

ATAM一种进行构架评估的综合方法，ATAM是评估软件构架的一个健壮的方法。在该方法中，项目决策者和涉众要清晰地阐述一个准确的质量属性需求列表（以场景的方式），并说明与实现每个高优先场景相关的构架决策。然后，把这些决策确定为有风险决策或无风险决策，以找到构架中任何存在问题的地方。

ATAM不是需求评估。

ATAM不是代码评估。

ATAM不包括实际的系统测试。

ATAM不是一个准确的手段，但它识别了构架中可能存在风险的区域。这些风险包含在敏感点和权衡中。

选择ATAM的原因

通用的架构评估方法（很多其他方法只关心某一个质量属性）

四个阶段

阶段 0 ：合作和准备

• 参与者：评估团队领导和主要项⽬决策者

• 输⼊：架构⽂档

• 输出：评价计划

• 谁：涉众的初步名单

• 逻辑：何时？何地？如何？

• 评估报告何时交付给何⼈

• 评估报告包含何种信息

阶段 1 ：评估 1

• 参与者：评估团队和项⽬决策者
• 步骤

1. 展示 ATAM ：评估负责⼈向项⽬代表（决策者）简要介绍 ATAM ，以让他们了解评估过程和
   结果

2. 展示业务驱动因素：项⽬经理或者系统客户从业务⻆度介绍系统概述，描述

3. 它最重要的功能需求

4. 它的技术、管理、经济或政治约束

5. 它的业务⽬标和环境

6. 它的主要涉众

7. 架构驱动因素（塑造架构的主要的质量属性⽬标）

8. 展示架构

9. ⾸席架构师以适当的细节级别进⾏描述

10. 技术限制，如规定使⽤的操作系统、硬件或中间件

11. 系统必须与之交互的其他系统

12. ⽤于满⾜质量属性需求的架构⽅法

13. 确定架构⽅法

14. ATAM 专注于通过理解架构⽅法来分析架构

15. 在这⼀步前，评估团队

16. 研究过架构⽂档

17. 听过架构师的展示

18. 问了架构师关于在设计系统中使⽤的模式、战术的问题

19. 评估团队对已经确定的架构⽅法（样式、模式、战术）进⾏编⽬

20. ⽣成质量属性效⽤树

21. 这是指导分析其余部分的关键步骤

22. 评估团队与项⽬决策者合作，识别、确定优先级并细化系统最重要的质量属性⽬标

23. 质量属性⽬标通过质量属性效⽤树进⾏详细阐述，通过精确定义相关的质量属性需求，使
    需求具体化

24. 分析架构⽅法

25. ⽬标是让评估团队确信该⽅法的实例化适合于满⾜特定属性的需求

26. 评估团队通过要求架构师解释架构如何相互⽀持，⼀次⼀个地检查最⾼排名的场景（来⾃
    效⽤树）

27. 评估团队记录了相关的架构信息，以便在已经做出的架构决定和需要满⾜的质量属性之间
    建⽴某种联系

28. 在这⼀步结束时，评估团队应该清楚地了解整个架构最重要的⽅⾯、关键设计决定的原
    理，以及⻛险、⾮⻛险、敏感点和权衡点的列表

• 输出：

• 架构的简短展示

• 业务⽬标的表达（驱动因素）

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

• 效⽤树

• ⻛险和⾮⻛险

• 敏感点和权衡点

阶段 2 ：评估 2

• 参与者：评估团队、项⽬决策者和架构涉众

• 步骤

• 重复“步骤 1 ”，展示 ATAM 和之前的结果

• 让涉众理解⽅法和他们扮演的⻆⾊

• 评估负责⼈重述步骤 2 到 6 的结果，并分享输出（效⽤树除外）

1. 头脑⻛暴、定场景优先级

• 这⼀步的⽬的是把握更⼤的涉众群体的脉搏，了解系统成功对他们意味着什么
• 评估团队要求涉众集思⼴益，讨论对其个⼈角色有操作性意义的场景
• ⼀旦收集到场景，涉众被要求对他们认为表示行为或者质量关注点的场景进⾏定优先级和
  合并
• 将优先方案列表与效⽤树中的⽅案列表进⾏⽐较
• 如果差异明显，则可将附加场景确定为⻛险

1. 分析架构⽅法

• 在这⼀步中，评估团队执⾏与步骤 6 相同的活动，使⽤排名最高的但是新生成的场景
• 架构师解释相关的架构决定如何有助于实现每个场景

1. 展示结果

• 评估⼩组根据共同的潜在关注点或系统缺陷，将⻛险划分成⻛险主题

• 确定的⻛险主题随后被关联到步骤 2 中列出的特定业务驱动因素

• 从评估中收集的信息被总结并提交给所有涉众

• 记录的架构⽅法

• 从头脑⻛暴中获取的⼀组场景及其优先级

• 效⽤树

• 发现的⻛险和记录的⾮⻛险

• 找到的敏感点和权衡点

• ⻛险主题和每个主题所威胁的业务驱动因素

• 输出：

• 涉众社区的优先级场景列表

• ⻛险主题和受到威胁的业务驱动因素

阶段 3 ：后续⾏动

• 参与者：评估团队和主要涉众（评估客户）
• 输出：最终评估报告
• 评估团队编写⼀份书⾯的最终报告，分发给关键涉众进⾏评估
• 审查结束后，报告将交给委托进⾏评估的⼈

总结 ATAM 输出

• 架构的简短展示
• 业务⽬标的表达
• 由质量属性场景表达的定优先级的质量属性需求
• 效⽤树
• ⼀组⻛险和⾮⻛险
• ⼀组⻛险主题
• 从架构决定到质量需求的映射
• ⼀组确定的敏感点和权衡点
• 最终评估报告