系统架构设计师 8：系统质量属性与架构评估

软件系统属性包括功能属性和质量属性，软件架构重点关注的是质量属性。为了精确、定量地表达系统的质量属性，通常会采用质量属性场景的方式进行描述。

在确定软件系统架构，精确描述质量属性场景后，就需要对系统架构进行评估。软件系统架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策。

一、软件系统质量属性

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

1. 性能。

    性能是指系统的响应能力。经常用单位时间内所处理事务的数量或系统完成某个事务处理所需的时间来对性能进行定量表示。

2. 可靠性。

    可靠性是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。可靠性通常用平均失效等待时间（MTTF）和平均失效间隔时间（MTBF）来衡量。

    可靠性可以分为容错和健壮性。

3. 可用性。

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

4. 安全性。

    安全性是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。

5. 可修改性。

    可修改性是指能够快速地以较高的性价比对系统进行变更的能力。通常以某些具体的变更为基准，通过考查这些变更的代价来衡量可修改性。可修改性包含可维护性、可扩展性、结构重组、可移植性 四个方面。

6. 功能性。

    功能性是系统能完成所期望的工作的能力。

7. 可变性。

    可变性是指架构经扩充或变更而成为新架构的能力。当要将某个架构作为一系列相关产品(例如，软件产品线)的基础时，可变性是很重要的。

8. 互操作性。

    为了支持互操作性，软件架构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。

2 质量属性场景

为了精确描述软件系统的质量属性，通常采用质量属性场景作为描述质量属性的手段。

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

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

2.1 可用性质量属性场景

2.2 可修改性质量属性场景

2.3 性能质量属性场景

2.4 可测试性质量属性场景

2.5 易用性质量属性场景

2.6 安全性质量属性场景

二、系统架构评估

1 系统架构评估中的重要概念

1.1 敏感点和权衡点

敏感点是构件或构件关系的特性。研究敏感点可使设计人员或分析员明确在搞清楚如何实现质量目标时应注意什么。

权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。例如，如果某个机密消息的处理有严格的时间延迟要求，则加密级别可能就会成为一个权衡点。

1.2 风险承担者

风险承担者 或者称为利益相关人。系统的架构涉及很多人的利益，这些人都对架构施加各种影响，以保证自己的目标能够实现。

1.3 场景

场景是从风险承担者的角度对与系统的交互的简短描述。在架构评估中，一般采用 刺激、环境和响应 三方面来对场景进行描述。

2 系统架构评估方法

架构评估中被公认的方法有：SAAM、ATAM、CBAM等。

2.1 SAAM

SAAM（Scenarios-based Architecture Analysis Method），基于场景的架构分析方法。

SAAM是最早形成文档并得到广泛使用的软件架构分析方法。

2.2 ATAM

ATAM（Architecture Tradeoff Analysis Method），架构权衡分析方法。

ATAM主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

2.3 CBAM

CBAM（(the Cost Benefit Analvsis Method），成本效益分析法。

CBAM用来对架构设计决策的成本和收益进行建模。它协助项目干系人根据其投资回报（Return On Investment，ROI）选择架构策略。

CBAM在ATAM结束时开始，它实际上使用了ATAM评估的结果。

三、ATAM方法架构评估实践

写得又啰嗦又没有重点，实在是看不下去。

如果有需要，买本畅销书看吧。

用ATAM方法评估软件体系结构，其工作分为四个基本阶段：

1. 演示。

2. 调查和分析。

3. 测试。

4. 报告。

1 演示

1.1 第一步：介绍ATAM

1.2 第二步：介绍业务驱动因素

1.3 第三步：介绍要评估的体系结构

1. 胡佛事件架构。

    一个事件由事件类型（Type）和事件参数（Args）两个主要部分组成。

    为了处理多个事件，系统中存在一个事件队列（Queue）组件。

    该框架的核心组件是事件管理器（Event Manager），该组件绑定事件队列和事件类型（Type Bindings）。事件管理器维护着事件类型注册表（EventType Registry）数据结构，并将事件类型注册到相关关联的处理程序中。

    该框架还有一个Handler组件，它是所有处理程序的基类。Handler组件包含两个主要的处理程序：STOP handler 和 IDLE handler。

2. “银行”事件架构。

2 调查和分析

2.1 第四步：确定架构方法

胡佛的架构具有高度的可修改性、一定的可扩展性；

“银行”活动架构的可修改性、可重用性、可靠性都比较差。

2.2 第五步：生成质量属性效用树

情景是一个说明利益相关者和系统之间的相互作用的陈述。

这些情景用来判断架构的质量目标。

生成质量属性效用树，以“效用”作为根节点，质量属性构成效用树的辅助级别，以场景作为叶子节点。

2.3 第六步：分析体系结构方法

1. 调查架构方法。

    可变性、可靠性、集成性、功能性、可修改性。

2. 创建分析问题。

    架构的组件可以重复用于未来的项目吗？（变化性）

    未来可以扩展框架以适应新的应用程序或新组件吗？（变化性）

    系统会处理用户提供的任何输入并处理无效输入吗？（可靠性）

    架构的行为是否一致？（概念完整）

    是否可以将任何新的应用程序特定功能添加到架构中？（可修改性）

    系统能否以短时间和成本效益的方式进行修改？（修改性）

    组件是否正确交互？（功能性）

    体系结构是否正确执行其事件处理任务？（功能）

3. 分析问题的答案。

4. 找出风险、非风险、敏感点和权衡点。

3 测试

3.1 第七步：头脑风暴和优先场景

利益相关者对场景进行投票。

3.2 第八步：分析架构方法

行为同第六步，区别在于这一步创建的分析问题主要针对头脑风暴得到的优先场景。

4 报告ATAM

ATAM团队将他们的发现呈现给利益相关者。

他们的发现包括：

1. 一种效用树。

2. 一组生成的场景。

3. 一组分析问题。

4. 一套确定的风险和非风险。

5. 确定的架构方法。