架构评估的重要概念
 

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

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

权衡点：指影响多个质量属性的特性，是多个质量属性的敏感点。

风险点：可能引起风险的因素，可能导致一些问题。

非风险点：如果某件事是可行的、可接受的，则为非风险点。

系统架构风险	如果业务逻辑的描述尚未达成共识，可能导致部分业务功能模块规则的矛盾，影响系统的可修改性。
敏感点	对查询请求处理时间的要求，将影响系统的数据传输协议和处理过程的设计。
权衡点	更改系统的加密级别将对安全性和性能产生影响

 软件系统质量属性
软件系统质量属性（Quality Attribute）是一个系统的可测量或者可测试的属性，用来描述系统满足利益相关者需求的程度。

可维护性:  当修改缺陷、增加功能、提高质量属性时, 识别修改点并实施修改的难易程度。

可修改性：能够快速的以较高的性价比对系统进行变更的能力。

可扩展性：软件因适应新需求或需求变化而增加新功能的能力，也称灵活性。

可伸缩性：当用户数和数量增加是，软件系统维持高服务质量的能力。

可靠性：持续无故障运行的能力。

可用性：正常工作的时间所占的比例。

鲁棒性：在非正常情况下仍能正常运行的能力。

 面向架构评估的质量属性

1. 可用性
定义	系统能够正常运行的时间比例、两次故障之间的时间长度、出现故障时系统能够恢复正常的速度。MTBF = MTTF + MTTR
指标	平均无故障时间(MTTF）平均故障间隔时间(MTBF）平均故障修复时间(MTTR)
架构策略	Ping/Echo、心跳、异常检测、主动冗余、被动冗余、检查点、双机热备
质量属性场景	1) 系统宕机后，能在10秒内感知错误，并自动启动热备份系统。 2) 主站点断电后，在5秒内将请求重定向到备用站点。 3) 系统应7x24小时工作。 4) 主站宕机后，系统能够在10秒内自动切换至备用站点并恢复正常运行。 5) 系统采用双机热备，主备机必须实时监测对方状态，以便完成系统的实时切换。 6）系统出现严重故障不得不停止服务时，修复时间不超过20分钟

2. 可修改性
定义	能够快速的以较高的性价比对系统进行变更的能力。 可修改型考虑的内容：可维护、可扩展、结构重构组、可移植
指标	修改所影响的元素的数量，对其它功能/质量属性所造成影响的程度。 系统在改变功能、质量属性时，需要付出的成本、努力、资金和难度。 查找架构中需要修改的位置，进行修改且不会影响其它功能。 对所作修改进行测试的难易程度。
架构策略	接口-实现分离
质量属性场景	1）系统支持横向存储扩展，要求在2人天内完成所有的扩展与测试工作。 2）支持对系统的外观进行调整和配置，调整工作需要在4人天内完成。 3）平台支持硬件扩容与升级，能够在3人天内完成所有部署与测试工作。 4）针对界面风格的修改需要在3人天内完成。 5) 业务功能和界面的调整与修改不超过10人月。

3. 性能
定义	指系统的响应能力，系统完成某个事务处理所需的时间，单位时间内所处理事务的数量。
指标	响应时间、吞吐量、效率、期限、抖动、缺失率、数据丢失率
架构策略	资源调度、资源仲裁、负载均衡、增加计算资源、提高计算效率、减少计算开销、控制资源使用
质量属性场景	1) 正常负载情况下，系统应在0.3秒内对用户的界面操作请求进行响应。 2）正常负载情况下，用户支付商品费用后在3秒内确认订单支付信息。 3）在并发用户数量10万的负载情况下，用户请求的平均响应时间应小于3秒。 4) 如果每秒钟用户查询请求的数量是10个，处理单个请求的时间为30毫米，则系统应保证在1秒内完成用户的查询请求。 5) 系统在展示商品的实时视频时，需要保证视频画面具有1024x768像素的分辨率，40帧/秒的速率。 6) 实时状态视频传输必须保证画面具有1024*786的分辨率，40帧/秒的速率。 7) 系统应支持大于50个终端设备的并发请求。 8）系统需要支持不低于2G的数据缓存。

4. 可测试性
定义	系统测试过程中的效率，发现系统缺陷或故障的难易程度。
指标	执行测试的时间
质量属性场景	1）系统需要内置接口函数，支持开发团队进行功能调试与系统诊断。 2）平台提供机器学习算法的远程调试功能，支持算法工程师进行远程调试。 3）系统本身需提供远程调试接口，支持开发团队进行远程排错。

5. 易用性
定义	用户在使用系统时的容易程度。
指标	用户满意度、学习曲线、想要学习系统特性、有效使用系统、对系统满意
质量属性场景	1）平台应该与目前国内外主流的机器学习应用开发平台的界面风格保持一致。 2）具有友好的用户界面。 3）新用户学习使用系统的时间少于1小时。

6. 安全性
定义	系统在向合法用户提供服务的同时，阻止非授权用户使用的能力。
指标	检测攻击、抵抗攻击、从攻击中恢复 机密性：保证信息不泄露给未授权的用户、实体或过程。 完整性：保证信息的完整和准确，防止信息被非法修改。 不可否认性：信息交换的双方不能否认其在交换过程中发送或接收信息的行为。 可控性：保证对信息的传播及内容具有控制的能力，防止为非法者所用。
架构策略	入侵检测IDS、入侵防护IPS、追踪审计、检测攻击
质量属性场景	1）系统需要为所有的用户操作行为进行详细记录，便于后期查阅与审计。 2) 系统支持对恶意攻击行为进行检测与报警。 3）预防核心数据库被非授权用户访问。 4）系统应对用户信息数据库的所有操作都进行完整记录。 5）用户密码需要加密传输。 6）用户操作停滞时间超过一定时限需要重新登录验证

7. 可靠性
定义	系统能够持续无故障运行的能力，在意外或错误使用的情况下，维持软件系统的功能特性的基本能力。
指标	容错：在错误发生时，确保系统正确的行为，并进行内部修复。 健壮性：应用程序不受错误使用和错误输入的影响，在发生意外错误时，确保应用系统处于预先定义好的状态，保证软件按照某种已经定义好的方式终止执行。

8. 功能性
定义	系统能完成所期望的工作的能力。
质量属性场景	1）管理员能够在页面上灵活设置折扣力度规则和促销活动逻辑，设置后即可生效。 2）用户名是系统唯一标识，要求以字母开头，由数字和字母组合而成，长度不少于6个字符。 3）平台用户分为算法工程师、软件工程师和管理员三种角色，不同角色的功能界面有所不同。 4）支持初学者和高级用户两种界面操作模式，用户可根据自己的情况灵活选择合适的模式。 5) 用户目前分为普通用户、银卡用户、金卡用户和白金用户四个等级，后续需要能够根据消费情况进行动态调整。

9. 互操作性
定义	指本软件系统与其它系统交换数据和相互调用服务的难易程度。

10. 可变性
定义	架构经扩充/变更，而成为新架构的能力。

 质量属性场景描述
 

质量属性场景（Quality Attribute Scenario）是一个具体的质量属性需求，是利益相关者与系统的交互的简短陈述。

场景：从风险承担者的角度对系统的交互的简短描述，描述了各种系统必须支持的活动和可能存在的状态变化，一般用刺激、环境、响应三方面来对场景进行描述。

3种类型的场景

用例场景：对系统典型的使用、引出信息，面向最终用户。

增长场景：对系统的修改，代表了架构发展的方式。
探索场景：可能会对系统造成过载的极端修改，架构中极端的增长形式。

场景要素	概念	情况
1. 刺激源	生成刺激的实体	最终用户、开发人员、系统管理员
2. 刺激	当刺激到达系统时，需要考虑的条件	希望增加、删除、修改、概念功能、质量属性、容量
3. 环境	刺激在某些条件内发生	系统设计时、编译时、构建时、运行时
4. 制品	某个制品被激励，被刺激的客体	用户界面、平台、与目标系统交互的系统
5. 响应	在激励到达后所采取的行动	查找架构中需要修改的位置，进行修改且不影响其他功能，对所做修改进行测试，部署所做的修改
6. 响应度量	当响应发生时，应当能够以某种方式对其进行度量	根据所影响元素的数量度量的成本、努力、资金； 该修改所造成影响的程度

 系统架构评估

 

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

3类系统架构评估的方法

1. 基于问卷调查或检查表的方法

2. 基于场景的评估方法

3. 基于度量的评估方法

基于场景的评估方法

软件架构分析法 SAAM

架构权衡分析法 ATAM

成本效益分析法 CBAM

 1. 软件架构分析方法 SAAM
 

基于场景的架构分析方法 Scenarios-based Architecture Analysis Method

SAAM的基本特点是把任何形式的质量属性都具体化为场景，但可修改性是SAAM分析的主要质量属性。是最早形成文档并得到广泛使用的软件架构分析方法，最初用于比较不同软件体系的架构，以分析系统架构的可修改性，后来实践证明也可用于其它非功能质量属性，最终发展成了评估一个系统架构的通用方法。

SAAM的优点

1. 有利于评估架构固有的风险。

2. 指导对架构的检查，主要关注潜在的问题点。

3. 评估架构对于特定系统需求的使用能力。

4. SAAM被用来比较不同的架构。

SAAM的主要输入

1. 问题描述

2. 需求声明

3. 架构描述

SAAM分析评估架构的过程包括5个步骤

1. 场景开发

通过各类风险承担者协商讨论，开发一些任务场景，体现系统所支持的各种活动。

2. 架构描述

体现系统的计算构件、数据构件以及构件之间的关系（数据和控制）。

3. 单个场景评估

对场景生成一个关于特定架构的场景描述列表（直接场景和间接场景）。

4. 场景交互评估

通过对场景交互的分析，得出系统中所有场景对系统中的构件所产生的影响的列表。

5. 总体评估

对场景和场景间的交互作一个总体的权衡和评价。

	SAAM方法	ATAM方法
定义	基本特点是把任何形式的质量属性都具体化为场景，但可修改性是SAAM分析的主要质量属性。是最早形成文档并得到广泛使用的软件架构分析方法。	主要针对性能、可用性、安全性、可修改性，在系统开发之前，对这些质量属性进行评价和折中。 分析多个相互竞争的质量属性，权衡取舍。
特定目标	对描述应用程序属性的文档，验证基本的架构假设和原则。	在考虑多个相互影响的质量属性的情况下，确定在多个质量属性之间折中的必要性，提供一种架构策略
质量属性	可修改性	性能、可用性、安全性、可修改性
评估技术	场景技术	场景技术
风险承担者	不同参与者感兴趣的共同方面	所有系统相关人员
架构描述	用于架构的最后版本，但早于详细设计。 描述架构的3个主要方面：功能、结构、分配	基于5种基本结构： 1. 功能结构 2. 代码结构 3. 过程结构 4. 数据结构 5. 部署结构
方法活动	1. 场景开发 2. 架构描述 3. 单个场景评估 4. 场景交互 5. 总体评估	场景和需求收集 架构视图描述和场景实现 属性模型构造和分析 对质量属性进行评价和折中
领域知识库的可重用性	不考虑	领域知识库通过ABAS维护。 ABAS 基于属性的架构风格。 基于特定质量属性的模型 基于属性的架构分析的标准问题集合
方法验证	空中交通管制、嵌入式音频、修正控制WRCS、根据上下文查找关键词KWIC

 2. 架构权衡分析法 ATAM
 

架构权衡分析法（Architecture Tradeoff Analysis Method）是一种系统架构评估方法，在系统开发之前，主要针对性能、可用性、安全性和可修改性等质量属性进行评价和折中。ATAM可以分为4个主要的活动阶段，包括需求收集、架构视图描述、属性模型构造和分析、架构决策与折中，整个评估过程强调以属性作为架构评估的核心概念，

4个主要的活动领域

1. 场景和需求收集

2. 架构视图描述 + 场景实现

3. 属性模型构造和分析

4. 对质量属性进行评价和折中

质量属性效用树 Utility tree 

对质量属性进识别和优先级排序。

树的结构：效用(树根) — 质量属性 — 属性分类 — 质量属性场景(叶子节点）

效用树沿着2个维度进行优先级排序：场景对系统成功的重要性；场景实现的难易程度。

每个场景有一个优先级对：(重要度，难易度）  例如：(H，L）表示该场景重要且易实现

 架构权衡分析法的4个阶段
 

一. 描述和介绍阶段 

1. 介绍ATAM方法

2. 描述业务目标

3. 描述体系结构

二. 调查和分析阶段 

1. 确定架构方法

2. 生成质量属性效用树

3. 分析架构方法

三. 测试阶段 

1. 讨论场景和对场景分级

2. 分析架构方法

四. 报告阶段 

描述评估结果。

 3. 成本效益分析法 CBAM
 

成本效益分析法(Cost Benefit Analysis Method）对架构设计决策的成本和收益进行建模，根据投资收益率ROI来选择合适的架构。作为ATAM的补充，在ATAM确定满足质量属性的基础上，再对效益进行分析。

 架构评估案例分析

【问题1】所有评估方法所普遍关注的质量属性有：安全性、性能、可用性、可靠性、功能性、可修改性、可变性、互操作性。

【问题2】敏感点指为了实现某种特定的质量属性，一个或多个构件所具有的特性。权衡点指影响多个质量属性的特性，是多个质量属性的敏感点。

【问题3】目前架构评估方法主要有SAAM和ATAM，请说明使用这两种方法进行架构评估的步骤或阶段。

SAAM包括5个步骤：

1. 场景开发

2. 体系结构描述

3. 单个场景评估

4. 场景交互

5. 总体评估

ATAM分为9个步骤：

1. 描述ATAM方法

2. 描述业务动机

3. 描述体系结构

4. 确定体系结构方法

5. 生成质量属性效用树

6. 分析体系结构方法

7. 讨论和分级场景

8. 分析体系结构方法

9. 描述评估结构

风险承担者	定义	所关心的问题
软件架构设计师	负责软件体系结构以及在相互竞争的质量属性间进行权衡的人	对其它风险承担者提出的质量需求的缓解和调停
开发人员	设计人员/程序员	体系结构描述的清晰与完整， 各部分的内聚性与受限耦合， 清楚的交互机制
项目经理	负责配置资源、保证开发进度	体系结构层次清晰，便于组建小组，任务划分结构，进度标志和最后期限
客户	系统的购买者	开发的进度、总体预算、系统的可用性、满足需求的情况