系统质量属性和架构评估

软件系统属性包括功能属性和质量属性，软件架构关注的是质量属性。

1. 软件系统质量属性

1.1 质量属性概念

影响软件质量的主要因素划分为6种维度特性：功能性、可靠性、易用性、效率、维护性与可移植性。

• 功能性包括适合性、准确性、互操作性、依从性、安全性；
• 可靠性包括容错性、易恢复性、成熟性；
• 易用性包括易学性、易理解性、易操作性；
• 效率包括资源特性和时间特性；
• 维护性包括可测试性、可修改性、稳定性和易分析性；
• 可移植性包括适应性、易安装性、一致性和可替换性。

软件系统质量属性可以分为开发期质量属性和运行期质量属性2个部分。

1. 开发期质量属性

   易理解、可扩展、可重用、可测试、可维护、可移植

2. 运行期质量属性
   性能、安全性、可伸缩性、互操作性、可靠性、可用性、鲁棒性

1.2 面向架构评估的质量属性

架构评估所关注的质量属性：

1. 性能：单位时间内处理事务的数量或者完成某个事务处理所需的时间；
2. 可靠性：平均失效等待时间和平均失效间隔时间，修复时间很短时，MTTF和MTBF几乎相等。
   容错：在错误发生时确保系统正确的行为。
   健壮性：保护应用程序不受错误使用和错误输入的影响。
3. 可用性：系统能够正常运行的时间比例。
4. 安全性：可划分为机密性、完整性、不可否认性及可控性等特性。
5. 可修改性：可维护性、可扩展性、结构重组、可移植性。
6. 功能性：是系统能完成所期望的工作的能力。
7. 可变性：架构经扩充或变更而成为新架构的能力。
8. 互操作性：与其它系统相互作用。

1.3 质量属性场景描述

质量属性场景可以精确描述系统的质量属性。质量属性场景是一个具体的质量属性需求，是利益相关者与系统的交互的简短陈述。

质量属性场景有6部分：

• 刺激源：这是某个生成该刺激的实体(人、计算机系统或者任何其他刺激器)。
• 刺激: 该刺激是当刺激到达系统时需要考虑的条件。（引发系统反应的事件或动作，比如用户点击按钮、系统接收新数据这些）
• 环境：该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况。
• 制品：某个制品被激励。这可能是整个系统，也可能是系统的一部分。
• 响应：该响应是在激励到达后所采取的行动。
• 响应度量：当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。

质量属性场景主要关注可用性、可修改性、性能、可测试性、易用性和安全性

1. 可用性

   场景要素	可能的情况
   刺激源	系统内、外
   刺激	疏忽、错误、奔溃、时间
   环境	正常操作、降级模式
   制品	系统处理器、通信信道、持久存储器、进程
   响应	记录事件，通知各方，根据规则禁止错误或故障事件源，在指定的时间内不可用等。
   响应度量	系统必须可用的时间间隔
   可用时间
   系统可以在降级模式下运行的时间间隔
   故障修复时间

2. 可修改性

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

3. 性能

   场景要素	可能的情况
   刺激源	用户请求、其它系统触发
   刺激	定期、随机、偶然时间到达
   环境	正常模式、超载模式
   制品	系统
   响应	处理刺激、改变系统响应级别
   响应度量	等待时间、期限、吞吐量、抖动、缺失率、数据丢失率

4. 可测试性

   场景要素	可能的情况
   刺激源	开发人员、增量开发人员、系统验证人员、客户验收测试人员、系统用户
   刺激	已完成的分析、架构、设计、类和子系统集成；所交付的系统
   环境	设计时、开发时、编译时、部署时
   制品	设计、代码段、完整的应用
   响应	提供对状态值的访问，提供所计算的值，准备测试环境
   响应度量	已执行的可执行语句的百分比
   如果存在缺陷出现故障的概率
   执行测试的时间
   测试中最长依赖的长度
   准备测试环境的时间

5. 易用性

   场景要素	可能的情况
   刺激源	最终用户
   刺激	想要学习系统特性、有效使用系统、使错误的影响最低、适配系统、对系统满意
   环境	系统运行时或配置时
   制品	系统
   响应
   响应度量	任务时间、错误数量、解决问题的数量、用户满意度、用户知识的获得、成功操作在总操作中所占的比例、损失的时间/丢失的数据量

6. 安全性

   场景要素	可能的情况
   刺激源	正确识别、非正确识别身份未知的来自内部/外部的个人或系统；经过了授权/未授权它访问了有限的资源/大量资源
   刺激	试图显示数据，改变/删除数据，访问系统服务，降低系统服务的可用性
   环境	在线或离线、联网或断网、连接有防火墙或者直接连到了网络
   制品	系统服务、系统中的数据
   响应	用户身份认证、隐藏；阻止、允许访问数据；授权；记录访问日志；等等
   响应度量	避开安全访问所需要的成本；
   检测、确定攻击个人的可能性；
   拒绝服务下仍能提供服务的百分比；
   能恢复数据、服务；
   被破坏的数据范围；
   被拒绝的合法访问范围；

2. 系统架构评估

系统架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策。

系统架构评估的方法通常可以分为3类：基于调查问卷或检查表的方式、基于场景的方式和基于度量的方式。

1. 基于调查问卷或检查表的方法：
2. 基于场景的评估方法：架构权衡分析法（ATAM）和软件架构分析方法（SAAM）。分析软件架构对场景的支持程度，判断架构对这一场景质量需求的满足程度。
3. 基于度量的评估方法：3个基本活动，首先需要建立质量属性和度量之间的映射原则，然后从软件架构文档中获取度量信息，最后根据映射原则分析推导出系统的质量属性。

2.1 系统架构评估的重要概念

1. 敏感点和权衡点
   敏感点是一个或多个构件(和/或构件之间的关系)的特性。
   权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。
2. 风险承担者(Stakeholders) 或者称为利益相关人
3. 场景：从风险承担者的角度对与系统的交互的简短描述。在架构评估中，一般采用刺激(Stimulus)、环境(Environment) 和响应(Response) 三方面来对场景进行描述。

2.2 系统架构评估方法

1. SAAM方法
   一种非功能质量属性的架构分析方法，采用场景技术进行评估，将质量属性具体化为场景，主要质量属性是可修改性。
   SAAM的主要输入时问题描述、需求说明和架构描述。
   SAAM分析架构包括5个步骤：即场景开发、架构描述、单个场景评估、场景交互和总体评估。

1. ATAM

   主要针对性能、实用性、安全性和可修改性

   • 特定目标：在多个质量属性之间折中；
   • 质量属性：可修改、安全、性能和可用性；
   • 风险承担者：需要所有系统相关人员参与，场景、需求的收集；
   • 架构描述：基于4+1视图派生，逻辑视图被分为功能结构和代码结构；
   • 评估技术：用例、增长场景和探测场景。
   • 方法活动：场景和需求收集，架构视图和场景实现，模型属性构造，分析、折中。

   ATAM方法采用效用树(Utility tree) 这一工具来对质量属性进行分类和优先级排序。
   效用树的结构包括：树根—质量属性—属性分类—质量属性场景(叶子节点)。
   T A M主要关注4类质量属性：性能、安全性、可修改性和可用性。

2.3 ATAM的方法架构评估实践

ATAM评估有四个阶段：演示、调查和分析、测试和报告ATAM

1. 演示
   • 介绍ATAM：描述ATAM 评估过程。
   • 介绍业务驱动因素：着重业务视角，提供有关系统功能、主要利益相关方、业务目标和其他限制等。
   • 介绍要评估的架构：侧重可用性以及架构的质量要求。
2. 调查和分析
   • 确定架构方法
   • 生成质量属性效用树
   • 分析架构方法：调查架构方法→创建分析问题→分析问题的答案→找出风险、非风险、敏感点和权衡点。
3. 测试
   • 头脑风暴和优先场景：将头脑风暴的优先列表与生成质量属性效用树中所获取的优先方案进行比较。
   • 分析架构方法：
4. 报告ATAM
   提供评估期间收集的所有信息，呈现给利益相关者。

项目	SAAM	ATAM
特定目标	通过程序文档验证体系结构，注重发现潜在问题，可用于评价单系统或进行多系统比较	确定在多个质量属性之间折中的必要性
评估技术	场景技术	场景技术、启发式分析方法
质量属性	可修改性是主要分析内容	性能、可用性、安全性和可修改性
风险承担者	所有参与者	场景和需求收集过程中的相关人
架构描述	围绕功能、结构和分配描述	五个基本结构及其映射关系
方法活动	场景开发、体系结构描述、单个场景评估、场景交互和总体评估	场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中
知识库可复用性	不涉及	有基于属性的体系模型，可复用
方法验证（应用领域)	空中交通管制系统、嵌入式音频系统、修正控制系统	仍处于研究中