软考-系统架构设计师-第十章 系统质量属性和架构评估

系统质量属性和架构评估

• • • 10.1 软件系统质量属性
    • 10.2 系统架构评估

      

      10.1 软件系统质量属性

      1. 基本概念

         软件系统质量属性是一个系统的可测量或可测试的属性，基于软件系统的生命周期，可以将软件的质量属性分为开发期的质量属性和运行期的质量属性。

      属性	子属性	作用及要点
      开发期质量属性	易理解性	指设计被开发人员理解的难以程度
      开发期质量属性	可扩展性	软件因新需求或需求变化而增加新功能的能力，也称灵活性
      开发期质量属性	可重用性	指重用软件系统或某一部分的难易程度
      开发期质量属性	可测试性	对软件的测试以证明其满足需求规范的难易程度
      开发期质量属性	可维护性	当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度
      开发期质量属性	可移植性	将软件从一个运行环境转移到另外一个不同的运行环境的难易程度
      运行期质量属性	性能	软件系统及时提供响应服务的能力，如速度、吞吐量和容量等
      运行期质量属性	安全性	软件系统同时兼顾向合法用户提供服务，以及阻止非授权访问的能力
      运行期质量属性	可伸缩性	当用户数和数据量增加时，软件系统维持高服务质量的能力
      运行期质量属性	互操作性	软件系统和其他系统交换数据和相互调用服务的难易程度
      运行期质量属性	可靠性	软件系统在一定时间内持续无故障运行的能力
      运行期质量属性	可用性	系统在一定时间范围内正常工作的时间占比
      运行期质量属性	鲁棒性	软件系统在非正常情况下（用户进行非法操作、相关软硬件系统发生故障）仍能正常运行的能力，也叫健壮性或容错性

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

         在架构评估过程中，评估人员普遍关注的质量属性

      属性	子属性	作用及要点
      性能	性能	效率指标：处理任务所需要的事件或单位时间内的处理量
      可靠性	容错	出现错误仍能保证系统正确运行， 且自动修正错误
      可靠性	健壮性	错误不对系统产生影响， 按既定程序忽略错误
      可用性	可用性	正常运行的时间比例
      安全性	安全性	系统向合法用户提供服务并阻止非法用户的能力
      可修改性	可维护性	局部修复使故障对架构的影响最小化
      可修改性	可扩展性	因松散耦合更容易实现新特性/性能， 不影响架构
      可修改性	结构重组	不影响重组进行灵活配置
      可修改性	可移植性	适应于多种环境（硬件平台、语言、操作系统）
      功能性	功能性	需求的满足程度
      可变性	可变性	整体架构可变
      互操作性	互操作性	通过可视化或接口方式提供更好的交互操作体验

      常见的质量属性和应对措施

      （1）. 可用性。

      • 1. 错误检测：心跳、ping/echo、异常
      • 1. 错误恢复：表决、主动冗余、被动冗余、重新同步、内测、检查点/回滚。
      • 1. 错误避免：服务下线、事务、进程监控器

           （2）. 性能

      • 1. 资源的需求：减少处理事件时对资源的占用、减少处理事件的数量、控制资源的使用
      • 1. 资源管理： 并发机制、增加资源
      • 1. 资源仲裁： 先来先服务、固定优先级、动态优先级、静态调度

           （3）. 可修改性

      • 1. 局部化修改：高内聚低耦合、预测变更、使用模块通用
      • 1. 防止连锁反应：信息隐藏、维持现有接口、限制通信路径、使用中介
      • 1. 推迟绑定时间：运行时注册、多态、配置文件

        （4）.安全性

        • 1. 抵抗攻击： 用户身份验证、用户授权、维护数据的机密性和完整性、限制暴露、限制访问
        • 1. 检测攻击： 入侵检测系统
        • 1. 从攻击中恢复：恢复状态、识别攻击者
          1. 质量属性场景描述

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

             （1）. 刺激源：生成该刺激的实体（人、计算机系统或者其他刺激器）

             （2）. 刺激（Stimulus）：指当刺激源到达系统时需要考虑的条件

             （3）. 环境（Environment）：指该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况

             （4）. 制品（Artifact）： 某个制品被激励，可能是整个系统也可能是系统的一部分

             （5）. 响应（Response）：当激励到达后所采取的行动

             （6）. 响应度量（Measurement）: 当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。

          10.2 系统架构评估

          系统架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策，通常分为：

          （1）基于调查问卷或者检查表的方法：缺点是很大程度上依赖评估人员的主观判断。

          （2）基于场景的评估：应用在架构权衡分析法（ATAM）和软件架构分析方法（SAAM）中。

          （3）基于度量的分析方法: 建立质量属性和度量之间的映射原则-> 软件文档中获取度量信息 -> 分析推导系统质量属性

          1. 系统架构评估中的重要概念
          • 1. 敏感点：实现质量目标应该注意的点，是一个或者多个构件的特性
          • 1. 权衡点：影响多个质量属性的敏感点
          • 1. 风险承担者或利益相关人：影响体系结构或被体系结构影响的群体
          • 1. 场景：确定架构质量评估目标的交互机制，一般采用触发机制、环境和影响三方面来描述。
            1. 系统架构评估方法

            （1）软件架构分析方法（Software Architecture Analysis Method， SAAM），是最早形成文档并得到广泛应用的软件架构分析方法。SAAM主要输入是

            问题描述、需求说明和架构描述 ，其分析过程主要包括：场景开发、架构描述、单个场景评估、场景交互和总体评估。

            

            （2）架构权衡分析法（Architecture Tradeoff Analysis Method， ATAM）。ATAM是一种架构评估方法，主要在系统开发前，针对性能、可用性、

            安全性和可修改性等质量属性进行评价和折中。传统的ATAM可以分为4个主要活动阶段，包括需求收集、架构视图描述、属性模型构造和分析、架构决策与

            折中，整个评估过程强调以属性作为架构评估的核心概念。

            现代的ATAM方法采用效用树对质量属性进行分类和优先级排序。用ATAM方法评估软件体系结构分为演示、调查和分析、测试和报告，如下图

            

            • 1. 阶段1 演示（Presentation）

                 使用ATAM评估软件体系结构的初始阶段，包括以下三个步骤：

                 a. 介绍ATAM：描述ATAM的评估过程

                 b. 介绍业务驱动因素：着重业务视角，提供有关系统功能、主要利益相关方、业务目标和其他限制等信息。

                 c. 介绍要评估的体系结构：侧重可用性和体系结构的质量要求

            • 1. 阶段2 调查和分析

                 使用ATAM技术评估架构的第二个阶段，对一些关键问题彻底调查，包括以下三个步骤：

                 a. 确定架构方法： 涉及能够理解系统关键需求的关键架构方法

                 b. 生成质量属性效用树： 确定最重要的质量属性，并确定优先次序。

                 c. 分析体系结构方法： 彻底调查和分析，找出处理相关质量属性的方法。包括4个主要阶段：调查架构方法 -> 创建分析问题 ->

                 分析问题答案-> 找出风险、 非风险、敏感点和权衡点。

            • 1. 阶段3 测试

                 a. 头脑风暴和优先场景：将头脑风暴的优先列表与生成质量属性效用树中所获取的优先方案进行比较

                 b. 分析架构方法

            • 1. 阶段4 报告ATAM

                 提供评估期间所有的报告，呈现给利益相关者

              评估方法的对比见下表

              项目	SAAM	ATAM
              特定目标	通过程序文档验证体系结构，注重发现潜在问题，可用于评价单系统或进行多系统的比较	确定在多个质量属性之间折中的必要性
              评估技术	场景技术	场景技术、启发式分析方法
              质量属性	可修改性是主要分析内容	性能、可用性、安全性和可修改性
              风险承担者	所有参与者	场景和需求收集过程中的相关人
              架构描述	围绕功能、结构和分配描述	五个基本结构及其映射关系
              方法活动	场景开发、体系结构描述、单个场景评估、场景交互和总体评估	演示、调查和分析、测试和报告
              知识库可复用性	不涉及	有基于属性的体系模型，可复用
              方法验证（应用领域）	空中交通管制系统、嵌入式音频系统、修正控制系统	仍在研究中

              （3）成本效益分析法（Cost Benefit Analysis Method， CBAM） 分为整理场景-> 对场景进行求精 -> 确定场景的优先级-> 分配效用->

              架构策略涉及哪些质量属性及响应级别 -> 使用内插法确定“期望的”质量属性响应级别的效用-> 计算各架构策略的总收益 ->

              根本受成本限制影响ROI选择架构策略。

              （4）其他评估方法

              • 1. SAEM方法：将软件架构看作一个最终产品以及涉及过程中的一个中间产品，从外部质量属性和内部质量属性阐述的评估模型。
              • 1. SAAB Net方法：辅助架构的定性评估，帮助诊断软件问题的可能原因，分析架构中的修改给质量属性带来的映像、预测架构的质量属性，帮助架构设计人员做决策。

                   SAABNet度量的对象包括架构属性、质量准则和质量因素。

              • 1. SACMM方法：一种软件架构修改的度量方法，首先基于内核定义差异度量准则来计算两个软件架构之间的距离，然后分析对象之间的相似性。
              • 1. SASAM方法：：通过对预期的架构和实际架构进行映射和比较来静态的评估软件架构。
              • 1. AALRRA方法：是软件架构可靠性风险评估方法，使用动态复杂度准则和动态耦合度准则来定义组件和连接件的复杂性因素。
              • 1. AHP方法：把定性分析和定量计算相结合，对各种决策因素进行处理。
              • 1. COSMIC+UML方法：针对不同表达方式的软件架构，采用统一的软件度量COSMIC方法来进行度量和评估。