【系统架构设计师】十二、系统质量属性与架构评估(系统架构评估|SAAM|ATAM|CBAM)

目录

二、系统架构评估

2.1 基础知识点

2.2 SAAM

2.3 ATAM

2.4 CBAM

2.5 其他评估

往期推荐

历年真题练习


二、系统架构评估

2.1 基础知识点

        系统架构评估是在对架构分析、评估的基础上,对架构策略的选取进行决策。它利用数学或逻辑分析技术,针对系统的一致性、正确性、质量属性、规划结果等不同方面,提供描述性、预测性和指令性的分析结果。系统架构评估的方法通常可以分为3类:

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

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

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

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

        系统架构风险:架构设计中潜在的、存在问题的架构决策所带来的隐患。

        敏感点:为了实现某种特定的质量属性,一个或多个构件所具有的特性。

        权衡点影响多个质量属性的特征(敏感点),是多个质量属性的敏感点。例如修改某个功能,影响到了架构的性能属性和安全性属性。

        风险承担者或利益相关人:影响体系结构或被体系结构影响的群体。

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

        场景:确定架构质量评估目标的交互机制,一般采用触发机制(教材中解释为“刺激”)、环境和影响三方面来描述。        

        软件架构评估在架构设计之后,系统设计之前,因此与设计、实现、测试都没有关系。评估的目的是为了评估所采用的架构是否能解决软件系统需求,但不是单纯的确定是否满足需求。

2.2 SAAM

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

        (1)特定目标。SAAM的目标是对描述应用程序属性的文档,验证基本的架构假设和原则
        (2)评估技术。SAAM 所使用的评估技术是场景技术。场景代表了描述架构属性的基础,描述了各种系统必须支持的活动和可能存在的状态变化。
        (3)质量属性。这一方法的基本特点是把任何形式的质量属性都具体化为场景,但可修改性是SAAM分析的主要质量属性。
        (4)风险承担者。SAAM 协调不同参与者之间感兴趣的共同方面,作为后续决策的基础,达成对架构的共识。
        (5)架构描述。SAAM 用于架构的最后版本,但早于详细设计,架构的描述形式应当被所有参与者理解功能、结构和分配被定义为描述架构的3个主要方面。
        (6)方法活动。SAAM的主要输入是问题描述、需求声明和架构描述。下图描绘了SAAM分析活动的相关输入及评估过程。包括5个步骤,即场景开发、架构描述、单个场景评估、场景交互和总体评估

2.3 ATAM

        架构权衡分析方法 (Architecture Tradeoff Analysis Method,ATAM) 是让架构师明确如何权衡多个质量目标,参与者有评估小组、项目决策者和其他项目相关人。

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

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

2.4 CBAM

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

        (1)整理场景。获取的场景,确定优先级,并选取优先级最高的1/3的场景进行分析。
        (2)对场景进行求精。为每个场景获取最坏情况、当前情况、期望情况和最好情况的质量属性响应级别。
        (3)确定场景的优先级。项目关系人对场景进行投票,其投票是基于每个场景“所期望的”响应值,根据投票结果和票的权值,生成一个分值(场景的权值)。
        (4)分配效用。对场景的响应级别(最坏情况、当前情况、期望情况和最好情况)确定效用表。
        (5)架构策略涉及哪些质量属性及响应级别,形成相关的“策略一场景一响应级别”的对应关系。
        (6)使用内插法确定“期望的”质量属性响应级别的效用。即根据第4步的效用表以及第5步的对应关系,确定架构策略及其对应场景的效用表
        (7)计算各架构策略的总收益。
        (8)根据受成本限制影响的ROI(投资回报率)选择架构策略。预估成本,结合第7步的收益,计算出架构策略的ROI,按ROI排序,从而确定选取策略的优先级。

2.5 其他评估

        (1) SAEM 方法:将软件架构看作一个最终产品以及涉及过程中的一个中间产品,从外部质量属性和内部质量属性阐述的评估模型。

        (2) SAABNet 方法:辅助架构的定性评估,帮助诊断软件问题的可能原因,分析架构中的修改给质量属性带来的影响、预测架构的质量属性,帮助架构设计人员做决策。SAABNet 度量的对象包括架构属性、质量准则和质量因素。

        (3) SACMM 方法:一种软件架构修改的度量方法,首先基于内核定义差异度量准则来计算两个软件架构之间的距离,然后分析对象之间的相似性。

        (4) SASAM 方法:通过对预期架构和实际架构进行映射和比较来静态地评估软件架构

        (5) ALRRA 方法:是软件架构可靠性风险评估方法,使用动态复杂度准则和动态耦合度准则来定义组件和连接件的复杂性因素。

        (6) AHP 方法:把定性分析和定量计算相结合,对各种决策因素进行处理。

        (7) COSMIC+UML 方法:针对不同表达方式的软件架构,采用统一的软件度量 COSMIC 方法来进行度量和评估

往期推荐

【系统架构设计师】十一、系统架构设计(层次架构风格|MVC|面向服务的架构风格|ESB)-CSDN博客文章浏览阅读829次,点赞16次,收藏15次。三层C/S架构:将处理功能独立出来,表示层和数据层都变得简单。表示层在客户机上,功能层在应用服务器上,数据层在数据库服务器上。既然将两层C/S架构中的数据从服务器中独立出来了。SOA是一种粗粒度、松耦合服务架构,服务之间通过简单、精确定义接口进行通信,不涉及底层编程接口和通信模型。企业服务总线ESB:简单来说是一根管道,用来连接各个服务节点。ESB的存在是为了集成基于不同协议的不同服务,ESB 做了消息的转化、解释以及路由的工作,以此来让不同的服务互联互通。https://shuaici.blog.csdn.net/article/details/140383777

【系统架构设计师】十一、系统架构设计(基于体系结构的软件设计|特定应用领域软件架构)-CSDN博客文章浏览阅读525次,点赞9次,收藏7次。基于体系结构(架构)的软件设计(ABSD)方法是体系结构驱动的,即指构成体系结构的商业、质量和功能需求的组合驱动的。在基于体系结构的软件设计方法中,采用视角与视图来描述软件架构,采用用例来描述功能需求,采用质量场景来描述质量需求。DSSA 就是专用于一类特定类型的任务(领域)的、在整个领域中能有效地使用的、为成功构造应用系统限定了标准的组合结构的软件构件的集合。DSSA 就是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考体系结构等组成的开发基础,其目标就是支持在一个特定领域中多个应用的生成。https://shuaici.blog.csdn.net/article/details/140434104

历年真题练习

        1.架构权衡分析方法(Architecture Tradeoff Analysis Method,ATAM)是在基于场景的架构分析方法(Scenarios-based Architecture Analysis Method,SAAM)基础之上发展起来的,主要包括场景和需求收集、(1)、属性模型构造和分析、属性模型折中等4个阶段。ATAM方法要求在系统开发之前,首先对这些质量属性进行(2)和折中。

            (1)A.架构视图和场景实现
                B.架构风格和场景分析
                C.架构设计和目标分析
                D.架构描述和需求评估

             (2)A.设计        B.实现        C.测试        D.评价

        2.识别风险、非风险、敏感点和权衡点是进行软件架构评估的重要过程。"改变业务数据编码方式会对系统的性能和安全性产生影响"是对(1)的描述,“假设用户请求的频率为每秒1个,业务处理时间小于30毫秒,则将请求响应时间设定为1秒钟是可以接受的"是对(2)的描述。

            (1)A.风险点        B.非风险
                C.敏感点        D.权衡点

            (2)A.风险点        B.非风险
                C.敏感点        D.权衡点

人工分割线-答案

        1. A、D

        2. D、B        解析:改变编码方式,影响了性能和安全性两种质量属性,因此是权衡点。
                                响应时间设定为1秒是可以接受的,则为非风险点。

  • 39
    点赞
  • 9
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

帅次

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值