质量属性及战术

一、六大质量属性
1、可用性分析
　  可用性是指系统正常运行时间的比例，是通过两次故障之间的时间长度或在系统崩溃情况下能够恢复正常运行的速度来衡量的。
　 
　  可用性分析所关注的方面包括：如何检测系统故障，系统故障发生的频度，出现故障时会发生什么情况，允许系统有多长时间非正常运行，什么时候可以安全地出现故障，如何防止故障的发生以及发生故障时要求进行哪种通知。

2、可修改性分析
　  可修改性是有关变更的成本问题。可以修改什么（制品）和何时进行变更以及由谁进行变更（环境）。

3、性能分析

　  性能是指系统的响应能力。性能与时间有关。事件（中断、消息、用户请求或时间已到）发生时，系统必须做出响应。事件到达和相应有很多特性，但性能基本上与事件发生时，将要耗费系统多长时间做出响应有关。

4、安全性分析
　  安全性是衡量系统在向合法用户提供服务的同时，阻止非授权使用的能力。试图突破安全防线的行为被称为攻击，它可以是未经授权试图访问数据或服务，或试图修改数据，也可能是试图使系统拒绝向合法用户提供服务。

安全性系统被刻画为提供如下属性的系统。
认可：交易不能被交易的任何一方拒绝。
保证：交易的各方是所声称的人的属性。如当客户发送一个信用卡的卡号到商家时，该商家就是用户所认可的商家。
审核：系统的内部跟踪属性。如客户转账时，系统会把转账过程记录下来。
机密性：未经授权不能访问。
可用性：系统用于合法用途的属性。

5、可测试性分析
      软件可测试性是指通过测试揭示软件缺陷的容易程度。

特别地，假设软件中至少有一个错误，软件在下次测试运行时不能正常工作的可能性。
可测试性的响应度量处理的是测试在发现缺陷方面的效率以及想要达到某个期望的覆盖范围，需要用多长时间进行测试。

 

6、易用性分析
　  易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类。

 

7.构架的质量属性
　　1.概念完整性
　　　　在各个层次上统一系统设计。构架应该以类似的方式做类似的事情。
　　2.正确性和完整性
　　　　构架能够满足系统的各种需求及运行时的资源要求。
　　3.可构建性
　　　　构建系统的难易程度。保证能够由指定的开发小组在规定的时间里完成系统开发。

8.功能、架构和质量属性

　　1.功能和构架之间的关系
　　　　功能是构架设计的必要条件而非充分条件，因为具有相同功能的不同构架，它们的差别在于质量。
　　　　随着软件开发水平的提高，如何满足功能已不是软件开发的主要矛盾，也不是构架层次上主要考虑的问题，构架设计主要考虑如何满足质量上的要求，但软件构架会限制各模块的功能划分，功能对构架设计有间接的影响。
　　2.构架和质量属性的关系
　　　　构架是获取许多质量属性的基础（上梁不正下梁歪）。
　　　　在构架设计过程中就应考虑到这些质量属性，并在构架层次上进行评估。
　　　　质量属性既和构架有关，也和具体实现有关。
　　　　例如，系统设计时一般都会考虑设置密码来提供安全性，可是如果实现时SQL语句没写好，则可能被注入攻击。
　　3.质量属性之间的关系
　　　　一个质量属性的获取对其他质量属性可能产生正面或负面的影响。
　　　　几乎每个质量属性都会对系统性能产生消极影响。
　　　　例如：最开始银行没有为网上银行的客户提供从客户端到网站之间的加密手段，银行获得了性能和成本上的好处，但牺牲了客户的安全性，导致假网站频出，很多人不敢使用网银业务。后来，银行给客户提供了各种加密手段，如支付宝、UKey等，花费了一定的成本和牺牲了部分性能，但客户获得了安全。现在网银用户和网上交易额逐年递增。

 二、质量属性战术

1.可用性战术分类：
　　1.错误检测
　　　　命令/响应----一个组件发出信号，收到回复（主动询问）
　　　　心跳（dead man计时器）----组件定期发出一个心跳信息。还可用于传递数据。
　　　　异常----异常处理程序通常将错误在语义上转换为可以被处理的形式，异常通常与引入异常的程序通常在一个进程。
　　2.错误恢复（不是万能的，都是致命的）
　　　　表决----多数规则或首选组件（类同MapReduce）
　　　　主动冗余（热重启）----所有的冗余组件都以并行的方式对事件作出响应，他们的状态都相同，但每次只能使用一个组件的响应而丢弃其余组件的响应
　　　　被动冗余（暖重启/双冗余/三冗余）----主组件对事件做出相应并通知其他备用组件必须进行的状态更新。主组件负责状态同步。
　　　　备件
　　　　shadow操作
　　　　状态再同步
　　　　检查点/回滚
　　3.错误预防
　　　　从服务中删除
　　　　事务
　　　　进程监视器
2.可修改性战术分类：
　　可修改性：牵一发而动全身，模块之间存在调用关系，模块内部的修改不能影响模块间的调用
　　1.局部化修改
　　　　维持语义的一致性----抽象通用服务
　　　　预期期望的变更----变更的影响最小化
　　　　泛化该模块
　　　　限制可能的选择
　　2.防止连锁反应----修改某个模块并不影响其他模块
　　　　隐藏信息
　　　　维持现有的接口
　　　　限制通信路径
　　　　使用仲裁者
　　3.推迟绑定时间