系统质量属性与架构评估

  • 8.1 软件系统质量属性
    • 8.1.1 质量属性概念
      • 开发期质量属性
      • 运行期质量属性
    • 8.1.2 面向架构评估的质量属性
    • 8.1.3 质量属性场景描述
  • 8.2 系统架构评估
    • 8.2.1 系统架构评估中的重要概念
    • 8.2.2 系统架构评估方法
      • SAAM 方法
      • ATAM方法
      • CBAM 方法
      • 其他方法
  • 8.3 ATAM方法架构评估实践
    • 8.3.1 阶段1——演示 (Presentation)
    • 8.3.2 阶段2——调查和分析
    • 8.3.3 阶段3——测试
    • 8.3.4 阶段4——报告ATAM

8.1 软件系统质量属性

8.1.1 质量属性概念

软件系统质量是软件满足需求和标准的能力。根据GB/T 16260.1定义，软件质量影响因素可划分为六个维度特性：功能性、可靠性、易用性、效率、维护性和可移植性。软件质量属性是描述系统满足利益相关者需求的可测量或可测试的属性，分为开发期和运行期质量属性。

开发期质量属性

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

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

运行期质量属性

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

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

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

软件系统架构评估主要关注质量属性。主要包括以下几种：性能、可靠性、可用性、安全性、可修改性、功能性、可变性、互操作性。

  • 性能关注系统的响应能力；
  • 可靠性关注系统在错误面前的维持功能能力；
  • 可用性关注系统能够正常运行的时间比例；
  • 安全性关注系统阻止非授权用户使用的能力；
  • 可修改性关注系统能够快速进行变更的能力；
  • 功能性关注系统能完成期望工作的能力；
  • 可变性关注架构的变更能力；
  • 互操作性关注软件与其他系统或环境的相互作用能力。

8.1.3 质量属性场景描述

为了精确描述软件系统的质量属性，通常采用质量属性场景，它是利益相关者与系统交互的简短陈述，由刺激源、刺激、环境、制品、响应和响应度量六部分组成。质量属性场景主要关注可用性、可修改性、性能、可测试性、易用性和安全性等六类质量属性。

  1. 可用性

  2. 可修改性


3. 性能

  1. 可测试性

  2. 易用性

  3. 安全性

8.2 系统架构评估

系统架构评估是在分析、评估架构的基础上，对架构策略进行决策。它利用数学或逻辑分析技术，提供关于系统一致性、正确性、质量属性、规划结果等方面的描述性、预测性和指令性分析结果。

系统架构评估方法通常分为三类：

  • 基于调查问卷或检查表的方式、基于场景的方式和基于度量的方式。基于调查问卷或检查表的方式依赖于系统相关人员的经验和知识，但主观性较强；
  • 基于场景的方式通过分析架构对场景的支持程度来评估质量需求的满足程度；
  • 基于度量的方式则建立在软件架构度量的基础上，通过映射原则分析推导出系统的质量属性。

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

  • 敏感点和权衡点是关键的架构决策，敏感点是一个或多个构件的特性，而权衡点是影响多个质量属性的特性。研究这些点可以帮助设计人员或分析员明确在实现质量目标时应注意什么。
  • 系统的架构涉及多个利益相关者，他们对架构施加影响以保证自己的目标能够实现。
  • 在进行架构评估时，需要通过场景来精确地得出具体的质量目标，场景是从风险承担者的角度对与系统的交互的简短描述，一般包括刺激、环境和响应三方面。

8.2.2 系统架构评估方法

SAAM 方法

SAAM是卡耐基梅隆大学软件工程研究所提出的一种基于场景的架构分析方法，用于评估架构的质量属性和风险。它主要通过场景技术，将质量属性具体化为场景进行分析。SAAM的目标是验证架构假设和原则，协调参与者共识，用于架构的最后版本但早于详细设计。其主要输入为问题描述、需求声明和架构描述。SAAM分析评估架构的过程包括场景开发、架构描述、单个场景评估、场景交互和总体评估五个步骤。它已被应用到众多系统中，这些系统包括空中交通管制、嵌入式音频系统等。

ATAM方法

CBAM 方法

  1. 整理场景：整理ATAM中获取的场景，并根据商业目标确定场景的优先级，选取优先级最高的1/3场景进行分析。
  2. 对场景进行求精：为每个场景获取最坏情况、当前情况、期望情况和最好情况下的质量属性响应级别。
  3. 确定场景的优先级：项目干系人对场景进行投票，根据每个场景的“所期望的”响应值进行投票，生成一个分值（场景的权值）。
  4. 分配效用：确定场景响应级别（最坏情况、当前情况、期望情况和最好情况）的效用表。
  5. 确定架构策略涉及的质量属性及响应级别，并形成“策略一场景一响应级别”的对应关系。
  6. 使用内插法确定“期望的”质量属性响应级别的效用。根据效用表和对应关系，确定架构策略及其对应场景的效用表。
  7. 计算各架构策略的总收益。根据场景的权值和架构策略的效用表，计算出架构策略的总收益得分。
  8. 根据成本限制下的ROI选择架构策略。根据开发经验估算架构策略的成本，结合收益计算出架构策略的ROI，按照ROI排序来确定优先级。

其他方法

  • SAEM方法是一种基于外部和内部质量属性的软件架构评估模型，包括对质量属性进行规约建模、为属性创建度量准则和评估质量属性等流程。它旨在为软件架构的质量评估创建一个基础框架，并已在相关系统领域得到应用。
  • SAABNet方法是一种基于人工智能技术的软件架构定性评估方法。它使用贝叶斯信念网络（BBN）来表示和使用开发过程中的定性知识，并允许不确定和不完整的推理。该方法可以帮助诊断软件架构问题、分析修改对质量属性的影响、预测架构的质量属性，并辅助架构设计决策。SAABNet将架构中的相关变量进行概率依赖建模，并通过测试验证其输出的正确性。该方法主要用于定性评估，而定量规约不是必要的。
  • SACMM（Software Architecture Change and Cost Measurement）方法是用于度量软件架构修改的一种结构化描述方式。当软件进行修改时，通常需要考虑软件架构是否也需要相应的修改。架构修改涉及到多个组件之间连接件的修改，而度量架构的修改可以提供有关软件修改的描述和预测修改的成本信息。
  • SASAM方法是一种静态评估软件架构的方法，通过映射和比较预期架构和实际架构来评估其一致性和完备性。它可以帮助分析产品线可能性、重用性、组件质量等10个评估目的，指导架构开发和演化过程。
  • ALRRA方法是一种软件架构可靠性风险评估方法，通过动态复杂度准则和动态耦合度准则来评估组件和连接件的复杂性。该方法结合失效模式和影响分析（FMEA）来定义故障引起的严重性因素，然后将复杂性和严重性因素组合起来定义组件和连接件的启发式风险因素。最后，利用风险分析模型和算法对架构层次的风险因素进行评估和分析。 ALRRA方法的步骤包括使用架构描述语言（ADL）建模软件架构、进行复杂性分析、使用FMEA和失效严重性分析、为组件和连接件定义可靠性风险因素、构造架构的CDG，并执行架构的风险评估和分析。
  • AHP方法是软件架构评估中的一种量化方式，它是一种简便、灵活且实用的多准则决策方法。AHP方法通过将复杂问题划分为有序层次，并进行两两对比来定量描述各元素的重要性。该方法可以结合定性分析和定量计算，处理各种决策因素，并对设计方案进行整体排名。
  • COSMIC+UML方法是一种用于评估软件架构可维护性的方法，它基于面向对象系统源代码的可维护性度量准则。该方法将软件架构描述方式与统一的软件度量COSMIC方法相结合，针对使用UML组件图描述的软件架构进行度量和评估。

8.3 ATAM方法架构评估实践

8.3.1 阶段1——演示 (Presentation)

ATAM（Architecture Tradeoff Analysis Method）是一种用于评估软件体系结构的方法，具有以下三个主要步骤：

  1. 标识体系结构步骤：
    在这一步骤中，评估负责人向相关参与者介绍ATAM评估过程，并说明使用的分析技术和预期结果。领导者解决小组成员的疑虑和问题。

  2. 介绍业务驱动因素：
    这一步骤着重于系统的业务视角，包括系统功能、利益相关方、业务目标和其他限制。通过定义系统的主要功能和涉及的利益相关方来划分阶段。

  3. 介绍要评估的体系结构：
    架构团队描述要评估的体系结构，包括体系结构、时间可用性和质量要求。关键问题包括技术约束、与其他系统的交互以及实施的架构方法。

通过ATAM方法，可以对软件体系结构进行综合评估，帮助决策者了解体系结构的优势和劣势，并做出相应的权衡。

8.3.2 阶段2——调查和分析

  1. 确定架构方法
    涉及了两种体系结构方法的讨论：胡佛的架构和“银行”活动架构。胡佛的架构具有高度的可修改性，组件独立且可重用；而“银行”活动架构存在一些缺陷，如可修改性较差和组件的相互依赖性较高。

  2. 生成质量属性效用树
    介绍了生成质量属性效用树的重要性，该步骤将所有利益相关方和评估人员的注意力集中在关系到体系结构成功的不同方面，以便确定系统最重要的质量属性目标，并建立情景优先列表，从而缩小风险和架构选择范围。

  3. 分析体系结构方法
    评估阶段的最后一步，称为”分析体系结构方法”。在这一步中，人们对前一步生成的效用树进行详细调查和分析，找出处理相应质量属性的架构方法，并确定每种架构方法的风险、非风险、敏感点和权衡点。首先，从效用树中提取高优先级场景，例如性能和可靠性。然后，根据这些场景的优先级来确定选择哪个质量属性更重要。例如，在一个场景中，处理用户错误的可靠性可能比操作速度的性能更重要。然后，将问题分为四个主要阶段：调查架构方法、创建分析问题、分析问题的答案以及找出风险、非风险、敏感点和权衡点。通过这一步的分析，可以更好地理解不同的架构方法，找到适合处理特定质量属性的方法，并识别潜在的风险和权衡点。

8.3.3 阶段3——测试

  1. 分析架构方法
    利益相关者通过头脑风暴活动提出各种用例、增长和探索性场景，并进行投票选出最重要的场景。这些场景与之前步骤中得出的优先方案进行比较，并加以整合。这一过程有助于更全面地考虑各种利益相关者的需求和优先级，为架构评估提供准确的参考。

8.3.4 阶段4——报告ATAM

ATAM评估的最后阶段是将评估期间收集到的所有信息呈现给利益相关者。主要发现包括效用树、场景、问题分析、风险和非风险、以及确定的架构方法。这些内容在前八个步骤中已经逐一介绍，通过整个ATAM评估过程，可以全面考虑各种利益相关者的需求和优先级，对架构进行深入的评估和改进。