架构师备考-背诵精华（系统质量属性）

系统质量属性

        根据GB/T 16260.1 定义，从管理角度对软件系统质量进行度量，可将影响软件质量的主要因素划分为6种维度特性包括：功能性、可靠性、易用性、效率、维护性、可移植性

• 功能性
  • 适合性、准确性、互操作性、依从性、安全性

• 可靠性
  • 容错性、易恢复性、成熟性

• 易用性
  • 易学性、易理解性、易操作性

• 效率
  • 资源特性、时间特性

• 维护性
  • 可测试性、可修改性、稳定性、易分析性

• 可移植性
  • 适应性、易安装性、一致性和可替换性

开发期质量属性

        开发期质量属性包括：易理解性、可拓展性、可重用性、可测试性、可移植性

运行期质量属性

        运行期质量属性包括：性能、安全性、可伸缩性、互操作性、可靠性、鲁棒性

质量属性场景描述

        质量属性场景是一种面向特定质量属性的需求，由6部分组成：刺激源、刺激、环境、制品、响应、响应度量

• 刺激源：这是某个个生成刺激的实体。
• 刺激：该刺激是当刺激到达系统时需要考虑的条件
• 环境：该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况。
• 制品：某个制品被激励。这可能是整个系统，也可能是系统的一部分。
• 响应：该响应是在激励到达后所采取的行动。
• 响应度量：当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。

面向架构评估的质量属性

性能

        是指系统的响应能力，及要经过多长时间才能对某个事件做出响应，或者在某段事件内系统所能处理的事件的个数。经常用单位时间内处理事务的数量或系统完成某个事物处理所需的时间来对性能进行定量标识。性能测试经常要使用基准测试程序。

性能质量属性场景

1. 刺激源：用户请求、其他系统触发等
2. 刺激：事件（定期、随机、偶然事件）
3. 制品：系统
4. 环境：正常模式、超载模式
5. 响应：处理刺激、改变系统状态
6. 响应度量指标：处理时间所花时间、单位时间内处理事件的数目、处理的错误率/丢失率

提升性能的策略

        提升性能的策略包含以下方式：资源需求、资源管理、资源仲裁

• 资源的需求：减少处理事件时对资源的占用、减少处理事件的数量、控制资源的使用
  • 减少处理事件时对资源的占用：改进算法、减少计算开销
  • 减少处理事件的数量：控制事件到来的速率、控制采样频率
  • 控制资源的使用：限制执行时间、限制队列大小
• 资源管理：并发机制、增加资源
  • 并发机制：多核、多线程
  • 增加资源：计算资源、存储资源、带宽资源
• 资源仲裁：先来先服务、固定优先级、动态优先级、静态调度
  • 动态优先级：时限时间最早优先、轮转调度

可靠性

        可靠性是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。可靠性是最重要的软件特征，通常用来衡量在规定的条件和时间内，软件完成规定功能的能力。通常用平均失效等待时间MTTF 和平均失效间隔时间 MTBF 来衡量。在失效率为常数和修复时间很短的情况下，MTTF 和 MTBF 几乎相等。可靠性分为两个方面：

• 容错
  • 容错的目的是错误发生时确保系统正确的行为，并进行内部“修复”。例如在一个分布式软件系统中失去了一个与远程构件的连接，接下来恢复了连接。在修复这样的错误之后，软件系统可以重新或重复执行进程间的操作，直到错误再次发生。
• 健壮性
  • 这里说的是保护应用程序不受错误使用和错误输入的影响，在发生意外错误事件时确保应用系统处于预先定义好的状态。值得注意的是，和容错相比，健壮性并不是说在错误发生时软件可以继续运行，它只能保证软件按照某种已经定义好的方式终止执行。软件架构对软件系统的可靠性有巨大的影响。例如，软件架构设计上通过在应用程序内部采用冗余机制，或集成监控构件和异常处理，以提升系统可靠性。

软件/硬件可靠性对比

• 复杂性：软件失效可能性大于硬件
• 物理退化：硬件有物理退化，软件没有
• 唯一性：软件唯一,硬件不可能相同
• 版本更新快：软件更新比硬件快

软件可靠性定量描述

1. 规定时间：人们使用执行时间来度量软件的可靠性最为准确，效果也最好
2. 失效概率
3. 可靠度：软件规定的条件下、规定的时间内不发生失效的概率
4. 失效强度：单位时间软件系统出现失效的概率；

• 使用失效强度来表示软件缺陷对软件运行的影响程度
• 失效严重程度类就是对用户具有相同程度影响的失效集合

1. 平均失效前时间（MTTF）：Mean Time To Faliure：从t=0 时到故障发生时系统的持续运行时间的期望值，不包括老化失效。
2. 平均恢复前时间 （MTTR）Mean Time To Restoration：从出现故障到修复成功的一段时间
3. 平均故障间隔时间（MTBF）Mean Time Between Failures：失效或维护中所需的平均时间，包括故障时间以及检测和维护设备的时间；MTBF = MTTF+ MTTR

影响软件可靠性的因素

• 运行环境
• 软件规模
• 软件的内部结构
• 软件的开发方法和开发环境
• 软件的可靠性投入

软件可靠性建模

        可靠性建模的步骤包括：模型假设、性能度量、参数估计方法、数据要求

1. 模型假设。模型是实际情况的简化或规范化，总要包含若干假设，例如测试的选取代表实际运行剖面，不同软件失效独立发生等。
2. 性能度量。软件可靠性模型的输出量就是性能度量，如失效强度、残留缺陷数等。在软件可靠性模型中性能度量通常以数学表达式给出。
3. 参数估计方法。某些可靠性度量的实际值无法直接获得，例如残留缺陷数，这时需要通过一定的方法估计参数的值，从而间接确定可靠性度量的值。估计是通过收集到的失效数据进行统计分析，利用一定的推导过程归纳出模型的参数；预测则是使用软件产品自身的属性和开发过程来确定模型的参数，这种方法可以在开始执行程序前完成。
4. 数据要求：一个软件可靠性模型要求一定的输入数据，即软件可靠性数据。不同类型的软件可靠性模型可能要求不同类型的软件可靠性数据。

• 模型的3个共同假设包括：代表性假设、独立性假设、相同性假设
  • 代表性假设。此假设认为软件测试用例的选取代表软件实际的运行剖面，甚至认为测试用例是独立随机地选取。此假设实际上是指可以用测试产生的软件可靠性数据预测运行阶段的软件可靠性行为。
  • 独立性假设。此假设认为软件失效是独立发生于不同时刻，一个软件失效的发生不影响另一个软件失效的发生。
  • 相同性假设。此假设认为所有软件失效的后果相同，即建模过程只考虑软件失效的具体发生时刻，不区分软件的失效严重等级

• 好的可靠性建模满足：
  • 基于可靠的假设
  • 简单
  • 计算一些有用的量
  • 给出未来失效行为的好的映射
  • 可广泛应用

软件的可靠性模型分类

类型	描述
种子法模型	预先在程序中播种错误“种子”，根据测试找出错误以及估计残留错误数量。
失效率类模型	用来研究程序的失效率
曲线拟合类模型	用回归分析的方法研究软件复杂性、程序中的缺陷数、失效率、失效间隔时间，包括参数方法和非参数方法两种。
可靠性增长模型	预测软件在检测过程中的可靠性改进，用增长函数来描述软件的改进过程
程序结构分析模型	根据程序、子程序及其相互间的调用关系，形成一个可靠性分析网络
输入域分类模型	选取软件输入域中的某些样本“点”运行程序，根据这些样本点在“实际”使用环境的使用概率的测试运行时的成功/失效率，推断软件的使用可靠性。
执行路径分析方法模型	先计算程序各逻辑路径的执行概率和程序中错误路径的执行概率，再综合出该软件的使用可靠性
非齐次泊松过程模型	以软件测试过程中单位时间的失效次数为独立泊松随机变量，来预测在今后软件的某使用时间点的累计失效数
马尔可夫过程模型	用于预测未来的数学模型
贝叶斯模型	利用失效率的试验前分布和当前的测试失效信息，来评估软件的可靠性

软件可靠性管理

        软件可靠性管理分为六个阶段：需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、实施阶段

需求分析阶段	确定软件的可靠性目标 分析可能影响可靠性的因素 确定可靠性的验收标准 制订可靠性管理框架 制定可靠性文档编写规范 制订可靠性活动初步计划 确定可靠性数据收集规范
概要设计阶段	确定可靠性度量 制定详细的可靠性验收方案 可靠性设计 收集可靠性数据 调整可靠性活动计划 明确后续阶段的可靠性活动的详细计划。编制可靠性文档
详细设计阶段	可靠性设计 可靠性预测 调整可靠性活动计划 收集可靠性数据 明确后续阶段的可靠性活动的详细计划 编写可靠性文档
编码阶段	可靠性测试 排错 调整可靠性活动计划 收集可靠性数据 明确后续阶段的可靠性活动的详细计划 编制可靠性文档
测试阶段	可靠性测试 排错 可靠性建模 可靠性评价 调整可靠性活动计划 收集可靠性数据 明确后续阶段的可靠性活动的详细计划 编制可靠性文档
实施阶段	可靠性测试 排错 收集可靠性数据 调整可靠性模型 可靠性评价 编制可靠性文档

软件可靠性设计

• 容错设计
  • 恢复快设计：恢复快方法是一种动态的故障屏蔽技术，采用向后恢复策略。
  • N版本程序设计:N版本程序设计是一种静态的故障屏蔽技术，采用向前恢复的策略。（订单、对账、清算工作）
  • 防卫式程序设计：通过在程序中包含错误检查代码和错误恢复代码，使得一旦发生错误，程序就能撤销错误状态，恢复到一个已知的正确状态中去
  • 冗余设计：改善软件可靠性的一个重要技术是冗余设计。在硬件系统中，在主程序运行的系统之外备用额外的元件或系统，如果出现一个元件故障或系统故障，则立即更换冗余的元件或切换到冗余的系统，则该硬件仍可以继续维持运行。在软件系统中，冗余技术的运用有所区别。如果采用相同两套软件系统互为备份，其意义不大，因为在相同的环境中，一套软件出现故障的地方，另外一套也一定会出现故障。软件冗余设计技术实现的原理是在一套完整的软件系统之外，设计一种不同路径、不同算法或不同实现方法的模块或系统作为备份，在出现故障时可以使用冗余的部分进行替换，从而维持软件系统的正常运行。

• 检错技术
  • 采用检错技术要着重考虑几个要素：检测对象、检测延迟、实现方式和处理方式
  • 检测对象：包含两个层次的含义，即检测点和检测内容。在设计时应考虑把检测点放在容易出错的地方和出错对软件系统影响较大的地方；检测内容选取那些有代表性的、易于判断的指标。
  • 检测延时：从软件发生故障到被自检出来是有一定延时的，这段延时的长短对故障的处理是非常重要的。因此，在软件检错设计时要充分考虑到检测延时。如果延时长到影响故障的及时报警，则需要更换检测对象或检测方式
  • 实现方式：最直接的一种实现方式是判断返回结果，如果返回结果超出正常范围，则进行异常处理。计算运行时间也是一种常用的技术，如果某个模块或函数运行超过预期的时间可以判断出现故障。另外，还有置状态标志位等多种方法，自检的实现方式要根据实际情况来选用。
  • 处理方式：大多数检错采用：查出故障-停止软件系统运行-报警的处理方式，但也有采用不停止或部分停止软件系统运行的情况，这一般由故障是否需要实时处理来决定。

• 降低复杂度设计
  • 软件复杂性常分为模块复杂性和结构复杂性
    • 模块复杂性主要包含模块内部数据流向和程序长度两个方面
    • 结构复杂性用不同模块之间的关联程度来表示
  • 降低复杂度的思想就是在保证实现软件功能的基础上，简化软件结构、缩短程序代码长度，优化软件数据流向，降低软件复杂度，从而提高软件可靠性。
• 系统配置技术
  • 系统配置技术主要包括双机热备、双机互备、双机双工、服务集群技术
  • 双机热备：双机热备即是目前通常所说的active/standby方式，服务器数据包括数据库数据同时往两台或多台服务器写，或者使用一个共享的存储设备。当 active服务器出现故障的时候，通过软件诊测(一般是通过心跳诊断)将standby机器激活，保证应用在短时间内完全恢复正常使用。
  • 双机互备：在双机热备的基础上，两个相对独立的应用在两台机器同时运行，但彼此均设为备机，当某一台服务器出现故障时，另一台服务器可以在短时间内将故障服务器的应用接管过来，从而保证了应用的持续性。这种方式实际上是双机热备的一种应用。它避免了两个应用使用四台服务器分别实现双机热备。
  • 双机双工：两台或多台服务器均为活动，同时运行相同的应用，保证整体的性能，也实现了负载均衡和互为备份。需要利用磁盘柜存储技术(最好采用san)。对于数据库服务而言，它同时需要数据库软件的支持，是比较复杂的。而WEB服务器或应用服务器就比较简单了。
  • 服务器集群技术：集群技术是指一组相互独立的服务器在网络中组合成为单一的系统工作，并以单一系统的模式加以管理。此单一系统为客户工作站提供高可靠性的服务。大多数情况下，集群中所有的计算机拥有一个共同的名称，集群内任一系统上运行的服务可被所有的网络客户所使用。

可靠性测试

• 分为广义的可靠性测试与狭义的可靠性测试
  • 广义的软件可靠性测试是指为了最终评价软件系统的可靠性而运用建模、统计、试验、分析和评价等一系列手段对软件系统实施的一种测试。
  • 狭义的软件可靠性测试是指为了获取可靠性数据，按预先确定的测试用例，在软件的预期使用环境中，对软件实施的一种测试
• 目的
  • 发现软件系统在需求、设计、编码、测试和实施等方面的各种缺陷
  • 为软件的使用和维护提供可靠性数据
  • 确认软件是否达到可靠性的定量要求
• 步骤
  • 可靠性目标的确定
  • 定义软件运行剖面
  • 测试用例的设计
  • 测试实施
  • 测试结果分析

• 内容
  • 软件产品标识
  • 测试环境配置（软件和硬件）
  • 测试依据
  • 测试结果
  • 测试问题
  • 测试时间

可靠性评价过程

        可靠性的评价过程包括：选择可靠性模型、收集可靠性数据、可靠性评估和预测

• 选择可靠性模型
  • 模型假设的适用性
  • 预测的能力与质量
  • 模型输出值是否满足可靠性评价需求
  • 模型使用的简便性

• 收集可靠性数据
  • 尽早确定可靠性模型，并确定需要收集的可靠性数据
  • 制定数据收集计划
  • 重视测试产生的数据
  • 利用数据库分析

• 可靠性评估和预测
  • 评估和预测依赖于可靠性模型
  • 使用支持软件可靠性估计的软件工具；失效数据的图形分析法、试探性数据分析技术

可用性

        可用性是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。

可用性质量属性

1. 刺激源：故障（来自系统内部或外部）
2. 刺激：系统出错，系统崩溃（反复出错），给出结果不及时，给出错误结果
3. 制品：计算或存储或网络
4. 环境：正常状态，降级模式
5. 响应：错误报告，回传厂家；通知管理员或其它系统；关闭系统，系统在维修期间不可用
6. 响应度量指标：故障时间百分比，平均故障修复时间，平均无故障时间

提升可用性的策略

提升可用性的策略包括：错误检测、错误恢复、错误避免

• 错误检测 ： 心跳，ping/Echo，异常
  • 心跳：被监控组件定期向监控的组件发出心跳消息。若连续未收到的心跳信号到了一定的数目，则认为相应的系统已经出现故障。
  • ping/Echo: 监控组件不定期向被监控的组件发出ping 消息，并根据收到的echo 消息做出响应
  • 异常：需要编程语言的支持。如抛出+ 捕获+ 处理
• 错误恢复：表决、主动冗余、被动冗余、重新同步、内测、检查点/回滚
  • 表决： 多个冗余的组件，用同一或不同的算法来完成一个任务，如果计算结果不同，则由表决器按照算法（少数服从多数的原则）确定
  • 主动冗余：服务器A 和B并行完成同样的运算，它们的状态时刻保持一致，平时只取A算出的结果。当A 出现故障时，系统可以迅速切换到B
  • 被动冗余：服务器A完成运算后，在一定时间内通知服务器B 进行更新
  • 重新同步：主动冗余和被动冗余都需要在重新上线前，做状态的重新同步
  • 检查点/回滚：定期保存，便于恢复
• 错误避免：服务下线、事务、进程监控器

安全性

        是指系统在合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性可根据系统可能受到的安全威胁类型来分类。安全性又可分为机密性、完整性、不可否认性及可控性等特性。其中，机密性保证信息不泄露给未授权的用户、实体或过程。完整性保证信息的完整和准确，防止信息被非法修改；不可否认性是指信息交换的双方不能否认其在交换过程中发送信息或接收信息的行为；可控性保证对信息的传播及内容具有控制的能力，防止为非法者所用。

安全性质量属性场景

• 刺激源：正确识别、非正确识别；授权、未授权
• 刺激：试图显示数据，改变/删除数据，访问系统服务
• 环境：在线或离线、联网或断网
• 制品：系统服务、系统中的数据
• 响应：对用户身份进行认证；隐藏用户的身份；阻止或允许访问数据或服务；
• 响应度量：用成功的概率表示；检测到攻击的可能性；确定攻击或访问、修改数据或服务的个人的可能性

提升安全性的策略

        提升安全性的策略包括：抵抗攻击、检测攻击、从攻击中恢复

• 抵抗攻击
  • 用户身份验证：动态密码、一次性密码、生物识别
  • 用户授权：对用户访问进行控制管理
  • 维护数据机密性与完整性：给数据和传输过程加密，维护数据完整性、MD5码校验
  • 限制暴露：关闭无用端口、自启动的服务、无线路由SSID 等
  • 限制访问：设置黑名单、白名单
• 检测攻击
  • 入侵检测系统
• 从攻击中恢复
  • 恢复状态：恢复检查点
  • 识别攻击者：用于预防或惩罚性目的

可修改性

        可修改性是指能够快速地以较高的性价比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价来衡量可修改性。可修改性分为4个方面

• 可维护性：这主要体现在问题的修复上，在错误发生后“修复”软件系统。可维护性好的软件架构往往能做局部性的修改并能使对其他构件的负面影响最小化。
• 可拓展性：这一点关注的是使用新特性来拓展软件系统，以及使用改进版本方式替换构件并删除不需要或不必要的特性和构件。为了实现可拓展性，软件系统需要松散耦合的构件。其目标是实现一种架构，能使开发人员在不影响构件客户的情况下替换构件。支持把新构件集成到现有的架构中也是必要的。
• 结构重组：这一点处理的是重新组织软件系统的构件及构件间的关系，例如通过将构建移动到一个不同的子系统而改变它的位置。为了支持结构重组，软件系统需要精心设计构件间的关系。理想情况下，它们允许开发人员在不影响实现的主体部分的情况下灵活地配置构件。
• 可移植性：可移植性使软件系统适用于多种硬件平台、用户界面、操作系统、编程语言或编译器。为了实现可移植性，需要按照硬件、软件无关的方式组织软件系统。可移植性是系统能够在不同计算环境下运行的能力，这些环境可能是硬件、软件，也可能是两者的结合。如果移植到新的系统需要做适当更改，则该可移植性就是一种特殊的可修改性。

可修改性质量属性场景

• 刺激源：最终用户、开发人员、系统管理员
• 刺激：希望增加、删除、修改、改变功能、质量属性、容量等
• 环境：系统设计时、编译时、构建时、运行时
• 制品：系统用户界面、平台、环境或与目标系统交互的系统
• 响应：查找架构中需要修改的位置，进行修改且不会影响其他功能，对所做的修改进行测试，部署所做的修改
• 响应度量：根据所影响元素的数量度量的成本、努力、资金；该修改对其他功能或质量属性所造成影响的程度

提升可修改性的策略

提升可修改性的策略有：局部化修改、防止连锁反应、延迟绑定时间

• 局部化修改：
  • 高内聚、低耦合
    • 对程序的修改控制在一个模块内
  • 预测变更
  • 使模块通用
• 防止连锁反应
  • 信息隐藏
    • 利用面向对象中的可访问性（Public、Protected、Private）
  • 维持现有接口
    • 接口不变的情况下，双方都能独立地变化
    • 定义一个稳定的接口，使得接口的实现方和依赖方能够解耦，双方能够独立变化的，分别适应各自的需求变化，不会在一方维护时牵连另一方的情况
  • 限制通信路径

• 使用中介
  • 数据中介：仓库（数据共享风格）
  • 服务中介：桥接模式、工厂方法模式、代理模式
• 延迟绑定时间
  • 运行时注册
    • 即插即用
  • 多态
    • 动态绑定
  • 配置文件
    • 配置文件来避免修改代码

功能性

        是系统完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。

可变性

        是指架构经扩充或变更而成为新架构的能力。这种新架构应该符合预先定义的规则，在某些方面不同于原有的架构。当要将某个架构作为一系列相关产品的基础时，可变性是很重要的。

互操作性

        作为系统组成部分的软件不是独立存在的，通常与其他系统或自身环境相互作用。为了支持互操作性，软件架构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和其他编程语言编写的软件系统的交互作用就是互操作性的问题，这种互操作性也影响应用的软件架构。