软件需求

功能性需求

定义系统必须做什么，即如何给用户提供价值
功能是系统完成预期工作的能力，很大程度上与结构无关

质量需求（非功能性需求）

质量需求应在功能性需求之上提供整个系统合乎需求的特性
质量需求是对功能需求或整个产品的约束
质量属性如果很重要，软件架构会约束功能到各种结构上的分配（映射）
不能先完成功能，再对质量需求进行适配，因为质量不能被添加到软件密集系统中
任何设计决策中都必须考虑质量需求
软件体系结构限制了质量属性的实现，比如性能、安全性、可用性等
分为两大类：
- 执行期间可观测：系统满足其行为需求的程度如何？比如性能、安全性、可用性等
- 执行期间不可观测：系统维护、测试容易吗？比如可修改性、可移植性、可重用性等

约束

约束是具有零自由度的设计决策
是已经做出的预先指定的设计决策
需要通过接受设计决策并与其他受影响的设计决策进行协调才能满足约束

质量属性

确定质量属性

质量属性的精确定义对于进行评估是必要的
使用质量属性方案来定义所需的质量属性

质量属性列表

质量属性方案

质量属性方案用于定义所需的质量属性，主要分为通用方案与具体方案。

通用方案

与系统无关的方案，用于指导质量属性要求的规范
提供了一个框架，用于生成通用的、独立于系统的、质量属性特定的方案
因为是通用方案，所以不一定都和当前系统相关，需要转化为特定系统的术语

具体方案

系统特定方案，指导特定系统满足质量属性要求

刺激相应图（重要）

刺激：到达系统时需要考虑的条件
刺激源：产生刺激的实体（人、系统等）
响应：刺激到来后工件开展的行为
响应度量：对响应以某种方法测量，比如系统多长时间有反应
环境：刺激发生时系统的状态，比如正常运行、过载等
工件 Artifact：完成需求的系统或系统一部分

决策

设计或模式用决策来提供预期收益
决策会影响质量属性的响应控制
决策的集合即体系结构策略
决策也可以由其他决策组成，比如冗余可以划分为数据冗余和计算冗余
系统设计包含一组设计决策，有的保证质量属性，有的确保功能实现

质量设计决策

体系结构是设计决策的集合

有七种设计决策（可能有重叠）：

职责分配
协调模型
数据模型
资源管理
架构元素映射
绑定事件决策
技术选型

质量属性和相应策略详细介绍

可用性 Availability

可用性是应用程序的关键要求，用“所需的可用时间”来度量。示例：业务运行期间100%可用

Outage、Failure、Fault和Error：

Outage：系统不可用的情况
Fault：Failure的原因
Error：Fault发生与Failure出现之间的中间状态
Failure：系统状态的可观察特征，系统无法交付该系统期望的服务

影响因素

发现故障的时间、修复故障的时间、重启应用的时间

MTBF (Mean Time Between Failure)

MTTR (Mean Time To Repair)

可用性 = MTBF / (MTBF + MTTR)

服务等级协议

可用性 (Availability)	停机时间/90天 (Downtime/90 Days)	停机时间/年 (Downtime/Year)
99.0%	21 小时, 36 分钟	3 天, 15.6 小时
99.9%	2 小时, 10 分钟	8 小时, 0 分钟, 46 秒
99.99%	12 分钟, 58 秒	52 分钟, 34 秒
99.999%	1 分钟, 18 秒	5 分钟, 15 秒
99.9999%	8 秒	32 秒

为故障做规划

危害分析，从高到低依次为：

灾难性
主要/次要
无影响

故障树分析：

这个图的意思是，D失败了是因为A失败了且B或C其中之一失败了，B或C其中之一失败了是因为B失败了或C失败了

可用性通用场景

场景组成部分	具体内容
源 (Source)	内部/外部：人员、硬件、软件、物理基础设施、物理环境
激励 (Stimulus)	故障：遗漏、崩溃、不正确的时机、不正确的响应
交互实体 (Artifact)	处理器、通信信道、持久化存储、进程
环境 (Environment)	正常操作、启动、关机、修复模式、降级操作、过载操作
响应 (Response)	阻止故障演变成失效检测故障：记录故障，通知相关实体（人员或系统）从故障中恢复：禁用导致故障的事件源，在进行修复时暂时不可用
响应度量 (Response Measure)	系统必须可用的时间或时间间隔，可用性百分比（例如，99.999%）检测故障的时间，修复故障的时间等

示例：

可用性策略

（这图真让人南蚌

输入：Fault

高可用性策略：消除单点故障、复制和故障转移、自动检测并重启

输出：Fault被屏蔽或完全恢复

故障检测

Ping/Echo

一个组件发出ping命令，并期望在预定义的时间内收到另一个组件的echo回复
可用于负责同一任务的一组组件内部

Heatbeat（又叫死信时间）

一个组件周期性地发出心跳信息（可以携带数据），另一个组件监听该消息
如果心跳失败（即没有收到心跳信息，判定为死信），通知该组件发生故障，通知故障并尝试纠正组件

异常

识别故障的方法是捕获一个异常
异常处理程序通常在引发异常的同一个进程中进行

表决

在冗余处理器上运行的进程接收等效的输入，计算一个简单的值发送给表决器（voter）
如果表决器发现异常，使进程失效

进程监视器

一旦进程中检测到故障，监控进程就检测这个无响应的进程，并创建一个它的新实例，初始化到适当状态

从上面可以看出，Ping/Echo和Heatbeat机制往往运行在不同进程中，异常检测运行在同一进程中（检测同一进程中发生的异常）

故障恢复

主动冗余

所有冗余组件并行地响应事件
只使用其中一个组件的响应，丢弃其他的（冗余）
故障发生时，不会停机，通过冗余继续运行，恢复时间即切换时间

被动冗余

一个主组件响应事件，然后通知其他冗余组件更新状态
故障发生时，系统先更新备份状态（用于同步），再恢复服务

备份

字面意思

影子操作

之前故障过的组件会先在影子模式下运行一段时间，以确保它在恢复服务之前能正常工作

状态重新同步

被动和主动冗余都需要被恢复的组件先更新状态再返回服务

检查点回滚

检查点记录着过去的某个一致性状态

阻止故障

从服务中移除

字面意思

事务

和数据库里的事务一样

互操作性 Interoperability

互操作性指多个系统在特定上下文中交换有意义信息的程度，包括语法可操作性（交换数据的能力）和语义可操作性（正确解释数据的能力）。

影响因素

有两个：发现和处理

发现：发现服务位置、身份和接口
处理：返回、转发、广播等

互操作性通用场景

场景组成部分	具体内容
源 (Source)	一个系统发起与另一个系统进行互操作的请求。
激励 (Stimulus)	在一个或多个系统之间交换信息的请求。
交互实体 (Artifact)	希望进行互操作的系统。
环境 (Environment)	希望进行互操作的系统在运行时被发现，或在运行前已知。
响应 (Response)	以下一项或多项：请求被拒绝，并通知相关实体（人或系统）请求被接受，并且信息交换成功一个或多个相关系统记录了该请求。
响应度量 (Response Measure)	以下一项或多项：信息交换被正确处理的百分比信息交换被正确拒绝的百分比

示例：

互操作性策略

输入：信息交换请求

定位：发现服务，通过已知目录服务来找到服务

管理界面：编排、定制界面

输出：请求被正确处理

定位

发现服务，通过已知目录服务来找到服务

管理界面

编排、定制界面

可修改性 Modifiability

可修改性涉及到变更以及变更的成本，包括这种变更影响到其他功能或质量属性的程度

影响因素

什么会变？
什么更可能变
什么时候谁变？
变更成本？

可修改性场景示例

直接上刺激相应图了

可修改性策略

输入：出现变更

拆分模块：将包含大量功能的模块拆分

增加语义一致性：将用途不同的功能拆分

减少耦合：封装

延迟绑定：尽可能将绑定时间延迟（不要在编码时写死一个值）

输出：在预期内实现变更

性能 Performance

性能与时间有关，和系统单位时间能做多少事情有关

影响因素

处理时间：正在响应
阻塞时间：此时无法响应

性能场景示例

性能策略

输入：事件到达

控制资源需求：管理采样频率、限制事件响应（排队）、事件优先级排序等

管理资源：增加资源、引入并发、备份等

输出：在一定时间内限制响应生成

安全性

安全性衡量系统保护数据和信息免受未授权应用访问或攻击的能力，但仍然能够被授权用户访问

影响因素（CIA）

C：保密性——防止未授权访问
I：完整性——防止未授权写
A：可用性——授权允许

安全性场景示例

安全性策略

输入：攻击

检查攻击：发现入侵（通过流量或签名信息）、检测服务拒绝、消息完整性（哈希）

防御攻击：验证、授权并认证请求者，限制资源访问与资源暴露等

响应攻击：撤销资源访问、锁定电脑、警告

恢复：快照存储

输出：系统监测、防御、响应和恢复

可测试性

可测试性是指可以使软件通过**（执行）测试来证明其是否故障的难易程度**。

一个系统如果想被测试，它必须能控制每个部件的输入并可观测输出

可测试性场景示例

可测试性策略

输入：执行测试

控制和观察系统状态：专用界面、记录或回放故障、本地化状态存储

限制复杂度：限制结构复杂性与行为不确定性

输出：直到检测到Fault

易用性 Usability

易用性与用户完成所需任务的难易程度以及系统提供的用户支持类型相关

影响因素

学习系统功能、有效使用系统、最小化错误影响、系统适应用户需求、增强信息和满意度

易用性场景示例

易用性策略

输入：用户请求

支持用户操作：取消、撤销、暂停恢复等

支持系统操作：维护任务模型（确定上下文后对人物建模）、维护用户模型（预期知识）、维护系统模型（预期的系统行为）

输出：用户获得正确反馈和帮助

质量属性场景示例总结

质量属性	刺激源	刺激	工作	环境	响应	响应度量
Availability	Heartbeat 监视器	服务器无响应	处理器	正常操作	通知操作者继续操作	没有停机时间
Interoperability	车辆信息系统	发送当前位置	路况监控系统	系统运行前已知	路况监控结合当前位置和 Google 地图上的其他信息，并且进行广播	我们的信息在 99.9%的时间是正确的
Modifiability	开发者	希望修改 UI 界面	代码	设计时	进行修改和单元测试	在 3 个小时内完成
Performance	用户	发起事务	系统	正常操作	事务被处理	平均延迟不超过 2 秒
Security	来自偏远地区心怀不满的员工	尝试修改支付率	系统内数据	正常操作	系统存储修改追踪	正确数据在 1 天内被存储并且进行篡改身份识别
Testability	单元测试者	单元测试完成	单元测试代码	开发时	记录结果	3 小时内达到 85%的路径覆盖
Usability	用户	下载新应用	系统	运行时	用户高效地使用应用	在 2 分钟以内的实验

每日一弘文