质量属性和架构评估

软件系统的质量属性

这里涉及到的质量属性是软件系统开发和运行阶段涉及到的质量属性，了解即可。

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

开发期质量属性

开发期质量属性主要指 软件开发阶段所关注的质量属性，主要包含 6 个方面。

1. 易理解性：指被开发人员理解的难易程度。
2. 易扩展性：软件因适应新需求或需求变化而增加新功能的能力，也称为灵活性。
3. 可重用性：指重用软件系统或某一部分的难易程度。
4. 可测试性：对软件测试以证明其满足需求规范的难易程度。
5. 可维护性：当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度。
6. 可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。

运行期质量属性

运行期质量属性主要指在 软件运行阶段所关注的质量属性，主要包含 7 个方面。

1. 性能： 性能是指软件系统及时提供相应服务的能力，如速度、吞吐量和容量等的要求。
2. 安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
3. 可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提高能力。
4. 互操作性：指本软件系统与其他系统交换数据和相互调用服务的难易程度。
5. 可靠性：软件系统在一定的时间内持续无故障运行的能力。
6. 可用性：指系统在一定时间内正常工作的时间所占的比例。可用性会受到系统错误，恶意攻击，高负载等问题的影响。
7. 鲁棒性： 是指软件系统在非正常情况（如用户进行了非法操作、相关的软硬件系统发生了故障等）下仍能够正常运行的能力，也称为健壮性或容错性。

架构评估的质量属性

在架构设计已经做好之后，要对架构设计进行一个评审。这就类似需求阶段结束之后，要对需求进行评审；设计会有设计评审。

质量属性

每个质量属性都需要掌握三个点：定义、特性、架构里如何设计（策略）达到这个质量属性

性能

指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。

如 响应时间、吞吐量

设计策略：优先级策略、增加计算资源、减少计算开销、引入并发机制、采用资源调度等

可靠性

是指软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。如 MTTF、MTBF、MTTR。

设计策略：心跳、Ping/Echo、冗余、选举。

可用性

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

设计策略：心跳、Ping/Echo、冗余、选举。

提示

可靠性和可用性主要是定义不一样，可靠性强调有了错误之后是能恢复（整体）；可用性强调系统正常运行的时间的比例。这两者架构设计的时候是分不开的。

安全性

是指 系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。 如 保密性、完整性、不可抵赖性、可控性。

设计策略：入侵检测、用户认证、用户授权、追踪审计。

可修改性

指能够快速的 以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量。

设计策略：接口-实现分类、抽象、信息隐藏。

功能性

是 系统所能完成所期望工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。

可变性

指 体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时，可变性是很重要的。

互操作性

作为系统 组成部分的软件不是独立存在的，经常与其它系统或自身环境相互作用。为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据机构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，也影响应用的软件体系结构。

质量属性场景

如果我们要测量某个架构是否满足某一个质量属性，我们要构造和这个质量属性所相关的场景，看能不能满足这个质量属性，这就是进行架构评估的主要手段。

质量属性场景是一种 面向特定质量属性的需求。它由 6 部分组成：

1. 刺激源（Source）：这是某个 生成刺激源的实体（人、计算机系统或者任何其它刺激源）。
2. 刺激（Stimulus）：该刺激是 当刺激到达系统时需要考虑的条件
3. 环境（Environment）：该刺激 在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其它情况。
4. 制品（Artifact）：某个制品 被激励。这可能是整个系统，也可能是系统的一部分。
5. 响应（Response）：该响应是 在激励到达后 所采取的行动。
6. 响应度量（Measurement）：当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。

提示

刺激可以理解为是操作主体所进行的操作和行为；刺激源就是操作主体；制品可以简单理解为操作的客体、对象；

刺激源在一定的环境下对制品进行刺激，制品在刺激之后产生响应，响应是可以进行度量的。

可修改性质量属性场景描述实例：

架构评估

• 敏感点：是指 为了实现某种特定的质量属性，一个或多个构件所具有的特性。（某个功能影响力一种质量属性，则这个功能就是一个敏感点）

• 权衡点：是 影响多个质量属性的特性，是多个质量属性的敏感点。（如果一个功能影响了多个质量属性，则这个功能就是一个权衡点）

• 风险点与非风险点不是以标准专业术语形式出现的，只是一个常规概念，即 可能引起风险的因素，可成为风险点。某个做法如果有隐患，有可能导致一些问题，则为风险点；而如果 某件事是可行的可接受的，则为非风险点。

• 软件架构评估在 架构设计之后，系统设计之前，因此与设计、实现、测试都没有关系。评估的目的是 为了评估所采用的架构是否能解决软件系统需求，不是单纯的确定是否满足需求（这是最基础的要求，还需要考虑质量属性、成本等问题）。

三种常用的评估方式

基于调查问卷（检查表）的方式

类似于需求获取中的 问卷调查方式，只不过是架构方面的问卷，要求评估人员对领域熟悉。

基于度量的方式

制定一些 定量指标来度量架构，如代码行数等。要制定质量属性和度量结果之间的映射，要求评估人员对架构熟悉。

基于场景的方式

主要方法。首先要 确定应用领域的功能和软件架构的结构之间的映射，然后要设计用于 体现待评估质量属性的场景（即 4+1 视图中的场景），最后 分析软件架构对场景的支持程度。要求评估人员即对领域熟悉，也对架构熟悉。从三个方面对场景进行设计：刺激（事件）；环境（事件发生的环境）；响应（架构响应刺激的过程）

提示

事件就是用来触发场景的，比如管理员点击查询按钮，场景是 要求 3 秒内 返回，响应就是 返回的结果。刺激就是输入，响应就是输出。

基于场景的架构分析方法 SAAM

SAAM 是一种 非功能质量属性的架构评估方法，是 最早形成文档并得到广泛应用的的软件架构分析方法。

• 特定目标。SAAM 的目标是对 描述应用程序属性的文档，验证基本的架构假设和原则。
• 质量属性。这一方法的基本特点是把任何形式的质量属性都具体化为场景，但 可修改性是 SAAM 分析的主要质量属性。
• 架构描述： SAAM 用于 架构的最后版本，但早于详细设计。架构的描述形式应当被所有参与者理解。
• 功能、结构和分配被定义为描述架构的 3 个主要方面。
• 方法活动： SAAM 的 主要输入是问题描述、需求声明和架构描述。下图描绘了 SAAM 分析活动的相关输入及评估过程。包括 5 个步骤，即 场景开发、架构描述、单个场景评估、场景交互和总体评估。

需求关注的是问题空间、架构关注的是解空间，将问题空间和解空间关联在一起分析是否能解决问题。

架构权衡分析法 ATAM

架构评估分析法 ATAM ，让架构师明确如何权衡多个质量目标，参与者有评估小组、项目决策者和其它项目相关人。

ATAM 被分为四个主要的活动领域，分别是 场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、架构决策与 折中。整个评估过程强调 以属性作为架构评估的核心概念。主要针对性能、可用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

成本效益分析法CBAM(了解即可)

用来 对架构建立的成本来进行设计和建模，让决策者 根据投资收益率来选择合适的架构，可以看作对 ATAM 的补充，在 ATAM 确定质量合理的基础上，再对效益进行分析。有下列步骤：

1. 整理场景（确定场景，并确定优先级，选择三分之一优先级最高的场景进行分析）；
2. 对场景进行细化（对每个场景详细分析，确定最好、最坏的情况）；
3. 确定场景的优先级（项目干系人对场景投票，根据投票结果确定优先级）；
4. 分配效用：（对场景响应级别确定效用表，建立策略、场景、响应级别的表格）；
5. 形成策略-场景-响应级别的对应关系；
6. 确定期望的质量属性响应级别的效用（根据效用表确定所对应的具体场景的效用表）；
7. 计算个架构策略的总收益；
8. 根据受成本限制影响的投资报酬率选择架构策略（估算成本，用上一步的收益减去成本，得出收益，并选择收益最高的架构策略）

其它评估方法(仅了解)