第8章 系统质量属性与架构评估
赞
踩
8.1软件系统质量属性
8.1软件系统质量属性
8.1.1质量属性概念
8.1.2面向架构评估的质量属性
评估架构，所关心的质量属性：
1.性能：响应能力，性能测试经常要使用集中测试程序
2.可靠性：软件系统在系统错误、意外或错误使用的情况下维持软件系统的功能特性的基本能力。它是最重要的软件特性。
平均失效等等时间Mean Tme To Failure MTTF：从运行直到失效的时间间隔。
平均失效间隔时间(平均故障时间)Mean Time Between Failure MTBF：两次失效间隔时间(含修复时间)。
平均维修时间Mean Time To Repair MTTR：发生故障后修复失效并正常运行的时间间隔。
可修复系统中，修复时间不可忽略的：
MTBF = MTTR + MTTF。
可靠性分2方面：
1).容错：目的是发生错误时确保系统的正确行为，并进行内部修复。
2).健壮性：保护应用程序不受错误使用和错误输入的影响，发生意外错误的时候，确保系统处于预先设定的状态。健壮性不是说错误发生时可继续运行，而是保证软件按照某种定义好的方式终止执行。
3.可用性：系统正常运行的时间比例。常用两次故障间隔时间MTBF和出现故障恢复正常的速度来表示。
4.安全性：向合法用户提供服务的同时阻止非授权用户的企图或拒绝服务的能力。
安全性根据根据安全威胁类型划分：机密性、完整性、不可否认性及可控性等。
- 机密性：信息不泄露给未授权用户、实体、进程。
- 完整性：信息的完整和准确，防止被非法修改。
- 不可否认性：不能否认自己发送和接收的信息的行为。
- 可控性：对信息的传播及内容具有控制的能力，防止非法者所用。
5.可修改性：能够快速地较高性价比对系统进行变更的能力。
一般以具体的变更为基准，可修改性4个方面：
- 可维护性(Maintainability)：主要在问题修复上，发生错误后，修复软件系统对其他构件的负面影响尽量小。
- 可扩展性(Extendibility)：使用新特性扩展系统以及改进版本替换构件或删除构件，集成新构件
- 结构重组(Rassemble)：重新组织软件系统的构件及构件间关系。如将构件移动到另一个子系统，改变了位置，原系统减少了构件，调用它的以及它调用的做成改变，系统解雇发生了变化，同样的增加了构件的系统也发生了变化。原则是不影响主体实现的情况下可灵活配置构件，
- 可移植性(Portability)：移植多种平台、环境的能力
6.功能性：完成期望的工作的能力。
7.可变性：架构经扩充或变更成为新架构的能力。这种类型的架构应该符合预先定义的规则，在某些具体方面不同于原有的架构。当这种类型的架构作为一系列相关产品(如软件产品线)的基础时，可变性很重要。
8.互操作性：与其他系统互操作的能力
8.1.3质量属性场景描述
它是一种手段，为了描述质量属性的。
它是一个具体的质量属性需求，是利息相关者与系统的交互的简短陈述。
六部分组成：
- 1.刺激源(Source):生成的实体(人、计算机或其他)
- 2.刺激(Stimulus):刺激到达系统时需要考虑的条件
- 3.环境(Environment):该刺激在某些条件内发生，当激励发生时，系统可能处于过载、运行或其他情况。
- 4.制品(Artifact):某个制品被激励。
- 5.响应(Response):激励到达后采取的行动。
- 6.响应度量(Measurement):当响应发生时，应当能够以某种方式对其独立，以对需求进行测试。
质量属性场景主要关注的质量属性：可用性、可修改、性能、可测属性、易用性、安全性6类。
1.可用性质量属性场景
2.可修改性质量属性场景
主要关注改变功能和质量属性时候付出的成本和难度。它会发生在设计、编译、构建、运行等等多种情况下。
3.性能质量属性场景
关注响应的速度、时间，吞吐量，负载来评价好坏。
4.可测属性质量属性场景
关注系统测试过程中的效率，发现缺陷或故障的难易程度等
5.易用性质量属性场景
用户使用系统的难以程度，系统的学校曲线、完成操作的效率，对系统使用过程的满意度等。
6.安全性质量属性场景
安全性方面的要素，向合法用户提供服务，阻止非授权用户使用的能力。
8.2系统架构评估
系统架构评估 是在对架构分析、评估的基础上，对架构策略的选取进行决策。
基于调查问卷或检查表
基于场景的评估方法
架构权衡分析法ATAM、软件架构分析法SAAM
基于度量的评估方法
建立在软件架构度量的基础上的，设计三个活动：
8.2.1系统架构评估中的重要概念
·敏感点：是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。
·权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。
·风险点与非风险点不是以标准专业术语形式出现的，只是一个常规概念，即可能引起风险的因素，可称为风险点。某个做法如果有隐患，有可能导致一些问题，则为风险点；而如果某件事是可行的可接受的，则为非风险点。
·软件架构评估在架构设计之后，系统设计之前，因此与设计、实现、测试都没有关系。评估的目的是为了评估所采用的架构是否能解决软件系统需求，但不是单纯的确定是否满足需求。
8.2.2系统架构评估方法
1.SAAM方法 Snarios-based Architecture Analysis Method
1).特定目标
SAAM的目标是文档(描述应用程序属性的)，验证基本的架构假设和原则。
SAAM直到对架构的检查，使其主要关注签字啊的问题点，如需求冲突。
SAAM有利于评估架构的固有风险，还能评估架构对于特定系统需求的使用能力，也能被用来比较不同的架构。
2).评估技术
场景技术。景代表了描述架构属性的基础，描述了各种系统必须支持的活动和可能存在的状态变化。
3).质量属性
基本点是把质量属性都具体化为场景，主要是可修改性。
4).风险承担者
5).架构描述
SAAM用于架构的最后版本，但早于详细设计。
6).方法活动
主要输入是问题描述、需求声明和架构描述。
评估的5个过程：场景开发、架构描述、单个场景评估、场景交互和总体评估。
具体方式：
7).已有知识库的可重用性：不考虑这个问题
8).方法验证
2.ATAM方法 Architecture Tradeoff Analysis Method
1).特定目标
2).质量属性
3).风险承担者
4).架构描述
5).评估技术
6).方法的活动
7).领域知识库的可重用性
8).方法验证
3.CBAM方法
在ATAM基础上，来对架构设计决策的成本和收益进行建模。
1).整理场景
2).对场景求精
3).确定场景优先级
4).分配效用
5).架构策略涉及哪些质量属性及响应级别
6).使用内插法确定"期望的"质量属性响应级别的效用。
7).计算各架构策略的总收益
8).根据受成本限制影响的ROI选择架构策略
4.其他评估方法
SAEM、SAABNet、SACMM、SASAM、ALRRA、AHP、COSMIC+UML
8.3ATAM方法架构评估实践
该方法评估软件体系结构4各基本阶段：演示、调查和分析、测试、报告ATAM。
8.3.1阶段1——演示(Presentation)
初始阶段，3各步骤：
1.介绍ATAM
向所有人介绍ATAM评估过程及其相关信息，说明评估中使用的分析技术及评估的预期结果，解答成员问题。
2.介绍业务驱动因素
从系统业务的角度定义要评估的系统功能，利益相关方、要达成的业务目标，还有一些其他必须好绿的系统限制信息。
利益相关者：最终用户、架构师、开发人员。
评估中使用Event框架，最终用户提供系统输入，架构师是时间框架的创建者，开发人员负责构建使用事件框架的事件驱动的应用程序。
3.介绍要评估的体系结构
这里要介绍一下要评估的架构了，侧重描述体系结构、事件可用性以及体系结构的质量要求。还需要演示架构。
关键问题：技术约束、架构与其他系统的交互、为满足质量属性而实施的架构方法。
举例：参考胡佛(Hoover)事件架构和“银行”(Banking)事件架构
8.3.2阶段2——调查和分析
这一阶段是对初始阶段的评估中重点关注的一些关键问题进行彻底调查。
第4步：确定架构方法
第5步：生成质量属性效用树
在评估阶段系统最重要的质量属性目标被确定，并确定优先次序和完善。
- 提供了一种使系统目标更加具体的方法，还提供了质量属性目标重要性的比较方式。因此它表达了系统整体的良好程度。
- 效用树包含了与系统有关的质量属性。
- 对利益相关者重要的质量属性要求(称之为情景)。
1)情景生成
2)质量属性效用树生成
第6步：分析体系结构方法
利用效用树，彻底调查和分析，找出处理响应质量属性架构的方法，根据这些质量属性分析这些架构方法，并提供适当的解释。涉及架构方法的风险、非风险、敏感点、权衡点。
简单说就是根据效用树的这些质量属性找到达成目标的方法，然后取分析这些方法，解释为啥这样做，并用风险、非风险、敏感点、权衡点来表达。
这一步可分4各阶段
- 调查架构方法。
- 创建分析问题。
- 分析问题的答案
- 找出风险、非风险、敏感点和权衡点。
具体的例子看书吧。
8.3.3阶段3——测试
第7步——头脑风暴和优先场景
第8步——分析架构方法
这一步与第6步类似，唯一区别是第6步的分析体系结构方法高优先级的质量属性来自效用树，这里是经过头脑风暴补充后的汇总结果来分析。
