5.5 系统架构的评估
5.5.1 系统架构评估概述
体系结构评估可以只针对一个体系结构，也可以针对一组体系结构。
评估人员所关注的是系统的质量属性，所有评估方法所普遍关注的质量属性有：
- 性能
是指系统的响应能力，既要经过多长时间才能对某个事件做出响应，或者在某段事件内系统所能处理的事件的个数。经常用单位事件内所处理事务的数量或系统完成某个事务处理所需的事件来对性能进行定量的表示。
性能测试经常要使用基准测试程序。 - 可靠性
是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。
可靠性通常用平均失效等待时间（MTTF）和平均失效间隔时间（MTBF）来衡量。
在失效率为常数和修复时间很短的情况下，MTTF和MTBF几乎相等。可靠性分为两个方面：
（1）容错：在错误发生时确保系统正确的行为。
（2）健壮性：保护应用程序不受错误使用和错误输入的影响。 - 可用性
是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。 - 安全性
是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。
安全性是根据系统可能受到的安全威胁的类型来分类的。安全性又可分为机密性、完整性、不可否认性及可控性等特性。
其中机密性保证信息不泄露给未授权用户、实体或过程；完整性保证信息的完整和准确，防止信息被非法修改；可控性保证对信息的传播及内容具有控制的能力，防止为非法者所用。 - 可修改性
是指能够快速以较高的性能价格对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。
（1）可维护性
主要体现在问题的修复上：在错误发生后，“修复”软件系统。
（2）可扩展性
使用新特性来扩展软件系统，以及使用改进版本来替换构件并删除不需要或不必要的特性和构件。
（3）结构重组
重新组织软件系统的构件及构件间的关系，例如通过将构件移动到一个不同的子系统而改变它的位置。
（4）可移植性
使软件系统用于多种硬件平台、用户界面、操作系统、编程语言或编译器。
可移植性是系统能够在不同计算环境下运行的能力。 - 功能性
是系统所能完成所期望的工作的能力。 - 可变性
是指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。 - 互操作性
作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。
软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。
5.5.2 评估中重要概念
敏感点和权衡点是关键的体系结构决策。
敏感点是一个或多个构件的特性，敏感点可使设计人员或分析人员明确在搞清楚如何实现质量目标时应注意什么。
权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。例如，改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性，但可能要耗费更多的处理时间，影响系统性能。如果某个机密消息的处理有严格的时间延迟要求，则加密级别可能成为一个权衡点。
风险承担者或者称为利益相关人。系统的体系结构涉及很多人的利益，这些人都对体系结构施加各种影响。
系统生产者
风险承担者 | 定义 | 所关心的问题 |
软件系统架构师 | 负责软件体系结构以及在相互竞争的质量需求间进行权衡的人 | 对其他风险承担者提出的质量需求的缓解和调停 |
开发人员 | 设计人员或程序员 | 体系结构描述的清晰与完整、各部门的内聚性与受限耦合、清楚的交互机制 |
维护人员 | 系统初次部署完成后对系统进行更改的人 | 可维护性，确定出某个更改发生后必须对系统中哪些地方进行改动的能力 |
集成人员 | 负责构件集成和组装的开发人员 | 与上同 |
测试人员 | 负责系统测试的开发人员 | 集成、一致的错误处理协议，受限的构件耦合、构件的高内聚性、概念的完整性 |
标准专家 | 负责所开发软件必须满足的标准细节的开发人员 | 对关心问题的分离、可修改性和互操作性 |
性能工程师 | 分析系统的工作产品以确定系统是否满足其性能及吞吐量需求的人员 | 易理解性、概念完整性、性能、可靠性 |
安全专家 | 负责保证系统满足其安全性需求的人员 | 安全性 |
项目经理 | 负责各小组配置资源、保证开发进度、保证不超出预算的人员，负责与客户沟通 | 体系结构层次清晰，便于组建小组；任务划分结构、进度标志和最后期限等 |
产品线经理 | 设想该体系结构和相关资产怎样在该组织的其他开发中得以重用的人员 | 可重用性，灵活性 |
系统消费者
风险承担者 | 定义 | 所关心的问题 |
客户 | 系统的购买者 | 开发的进度、总体预算、系统的有用性、满足需求的情况 |
最终用户 | 所实现系统的使用者 | 功能性、可用性 |
应用开发者（对产品体系结构而言） | 利用该体系结构及其他已有可重用构件，通过将其实例化而构建产品的人员 | 体系结构的清晰性、完整性、简单交互机制、简单裁减机制 |
任务专家、任务规划者 | 知道系统将会怎样使用以实现战略目标的客户代表 | 功能性、可用性、灵活性 |
系统服务人员
风险承担者 | 定义 | 所关心的问题 |
系统管理员 | 负责系统运行的人员 | 容易找到可能出现问题的地方 |
网络管理员 | 管理网络的人员 | 网络性能、可预测性 |
技术支持人员 | 在系统咋该领域中的使用和维护提供支持的人员 | 使用性、可服务性、可裁减性 |
其他人员
风险承担者 | 定义 | 所关心的问题 |
领域代表 | 类似系统或所考察系统将要在其中运行的系统的构建者或拥有者 | 可操作性 |
系统设计师 | 整个系统的体系结构设计师，负责在软件和硬件之间进行权衡并选择硬件环境的人 | 可移植性、灵活性、性能和效率 |
设备专家 | 熟悉该软件必须与之交互的硬件的人员，能够预测硬件技术的未来发展趋势的人员 | 可维护性、性能 |
场景在进行体系结构评估时，一般首先要精确得出具体的质量目标，并以之作为判定该体系结构优劣的标准。为得出这些目标而采用的机制叫做场景。
场景是从风险承担者的角度对与系统的交互的简短描述。一般采用刺激、环境、响应三方面对场景进行描述。
5.5.3 主要评估方法
1.SAAM
1983年Kazman提出的一种非功能质量属性的体系结构分析方法，是最早形成文档并得到广泛使用的软件体系结构分析方法。
（1）特定目标
对描述应用程序属性的文档，验证基本的体系结构假设和原则。
此外，该分析方法有利于评估体系结构固有的风险。
SAAM指导对体系结构的检查，使其主要关注潜在的问题点，如需求冲突，或仅从某一参与者的观点出发的不全面的系统设计。
SAAM不仅能够评估体系结构对于特定系统需求的使用能力，也能被用来比较不同的体系结构。
（2）评估技术
SAAM所使用的评估技术是场景技术。场景代表了描述体系结构属性的基础，描述了各种系统必须支持的活动和将要发生的变化。
（3）质量属性
把任何形式的质量属性都具体化为场景，但是可修改性是SAAM分析的主要质量属性。
（4）风险承担者
SAAM协调不同参与者所感兴趣的方面，作为后续决策的基础，提供了对体系结构的公共理解。
（5）体系结构描述
SAAM用于体系结构的最后版本，但早于详细设计。体系结构的描述形式应被当做所有参与者理解。功能、结构和分配被定义为描述体系结构的三个主要方面。
（6）方法活动
主要输入问题是：问题描述、需求声明和体系结构描述。
SAAM分析评估体系结构的过程包括5个步骤，即场景开发、体系结构描述、单个场景评估、场景交互和总体评估。
（7）方法验证
SAAM是一种成熟的方法，已被应用到众多系统中，这些系统包括空中交通管制、嵌入式音频系统、WRCS（修正控制系统）、KWIC[8]（根据上下文查找关键词系统等）。
2.ATAM
是在SAAM的基础上发展起来的，主要针对性能、实用性、安全性和可修改性，在系统开发前对这些质量属性进行评价和折中。
（1）特定目标
在考虑多个相互影响的质量属性的情况下，从原则上提供一种理解软件体系结构的能力的方法。
（2）质量属性
分析多个相互竞争的质量属性。开始考虑的是性能、实用性、安全性和可修改性。
（3）风险承担者
在场景、需求收集有关的活动中，ATAM方法需要所有系统相关人员的参与。
（4）体系结构描述
体系结构空间受到历史遗留系统、互操作性和以前失败的项目约束。
（5）评估技术
可以把ATAM方法视为一个框架，该框架依赖于质量属性，可以使用不同的分析技术。它集成了多个优秀的单一理论模型，其中每一个都能够高效、实用地处理属性。
（6）方法活动
ATAM被分为4个主要活动领域（或阶段），分别是场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中。
（7）目前知识库的可重用性
领域知识库通过基于属性的体系结构风格（ABAS）维护。ABAS有助于从体系结构风格的概念转向基于特定质量属性模型的推理能力。
（8）方法验证
该方法已应用到多个软件系统，但仍处在研究之中。
Clement认为在未来5-10年内，体系结构的分析是体系结构发展的5个方向之一。
