软件系统属性包括功能属性和质量属性，软件架构重点关注的是质量属性。为了精确、定量地表达系统的质量属性，通常会采用质量属性场景的方式进行描述。
在确定软件系统架构，精确描述质量属性场景后，就需要对系统架构进行评估。软件系统架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策。
一、软件系统质量属性
1 面向架构评估的质量属性
1. 性能。
性能是指系统的响应能力。经常用单位时间内所处理事务的数量或系统完成某个事务处理所需的时间来对性能进行定量表示。
2. 可靠性。
可靠性是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。可靠性通常用平均失效等待时间（MTTF）和平均失效间隔时间（MTBF）来衡量。
可靠性可以分为容错和健壮性。
3. 可用性。
可用性是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
4. 安全性。
安全性是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。
5. 可修改性。
可修改性是指能够快速地以较高的性价比对系统进行变更的能力。通常以某些具体的变更为基准，通过考查这些变更的代价来衡量可修改性。可修改性包含可维护性、可扩展性、结构重组、可移植性 四个方面。
6. 功能性。
功能性是系统能完成所期望的工作的能力。
7. 可变性。
可变性是指架构经扩充或变更而成为新架构的能力。当要将某个架构作为一系列相关产品(例如，软件产品线)的基础时，可变性是很重要的。
8. 互操作性。
为了支持互操作性，软件架构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。
2 质量属性场景
为了精确描述软件系统的质量属性，通常采用质量属性场景作为描述质量属性的手段。
质量属性场景是一种面向特定质量属性的需求。它由六部分组成：刺激源、刺激、环境、制品、响应、响应度量。
质量属性场景主要关注可用性、可修改性、性能、可测试性、易用性和安全性等六类质量属性。
2.1 可用性质量属性场景
| 场景要素 | 可能的情况 |
| 刺激源 | 系统内部、系统外部 |
| 刺激 | 疏忽、错误、崩溃、时间 |
| 环境 | 正常操作、降级模式 |
| 制品 | 系统处理器、通信信道、持久存储器、进程 |
| 响应 | 系统应该检测事件、并进行如下一个或多个活动： 将其记录下来通知适当的各方，包括用户和其他系统；根据已定义的规则禁止导致错误或故障的事件源 在一段预先指定的时间间隔内不可用，其中，时间间隔取决于系统的关键程度在正常或降级模式下运行 |
| 响应度量 | 系统必须可用的时间间隔 可用时间 系统可以在降级模式下运行的时间间隔 故障修复时间 |
2.2 可修改性质量属性场景
| 场景要素 | 可能的情况 |
| 刺激源 | 最终用户、开发人员、系统管理员 |
| 刺激 | 希望增加、删除、修改、改变功能、质最属性、容量等 |
| 环境 | 系统设计时、编译时、构建时、运行时 |
| 制品 | 系统用户界面、平台、环境或与目标系统交互的系统 |
| 响应 | 查找架构中需要修改的位置，进行修改且不会影响其他功能，对所做的修改进行测试，部署所做的修改 |
| 响应度量 | 根据所影响元素的数量度量的成本、努力、资金:该修改对其他功能或质量属性所造成影响的程度 |
2.3 性能质量属性场景
| 场景要素 | 可能的情况 |
| 刺激源 | 用户请求，其他系统触发等 |
| 刺激 | 定期事件到达、随机事件到达、偶然事件到达 |
| 环境 | 正常模式、超载（Overload）模式 |
| 制品 | 系统 |
| 响应 | 处理刺激、改变服务级别 |
| 响应度量 | 等待时间、期限、吞吐量、抖动、缺失率、数据丢失率 |
2.4 可测试性质量属性场景
| 场景要素 | 可能的情况 |
| 刺激源 | 开发人员、增量开发人员、系统验证人员、客户验收测试人员、系统用户 |
| 刺激 | 已完成的分析、架构、设计、类和子系统集成；所交付的系统 |
| 环境 | 设计时、开发时、编译时、部署时 |
| 制品 | 设计、代码段、完整的应用 |
| 响应 | 提供对状态值的访问，提供所计算的值，准备测试环境 |
| 响应度量 | 已执行的可执行语句的百分比 如果存在缺陷出现故障的概率 执行测试的时间 测试中最长依赖的长度 准备测试环境的时间 |
2.5 易用性质量属性场景
| 场景要素 | 可能的情况 |
| 刺激源 | 最终用户 |
| 刺激 | 想要学习系统特性、有效使用系统、使错误的影响最低、适配系统、对系统满意 |
| 环境 | 系统运行时或配置时 |
| 制品 | 系统 |
| 响应 | 1) 系统提供以下一个或多个响应来支持“学习系统特性”: 帮助系统与环境联系紧密；界面为用户所熟悉；在不熟悉的环境中，界面是可以使用的 2) 系统提供以下一个或多个响应来支持“有效使用系统”： 数据和（或）命令的聚合；已输入的数据和(或命令的重用；支持在界面中的有效导航具有一致操作的不同视图；全面搜索；多个同时进行的活动 3) 系统提供以下一个或多个响应来“使错误的影响最低”： 撤销；取消；从系统故障中恢复；识别并纠正用户错误；检索忘记的密码；验证系统资源 4) 系统提供以下一个或多个响应来“适配系统”： 定制能力；国际化 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. 确定的架构方法。
