架构师备考-背诵精华（系统架构评估）

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

重要概念

敏感点：敏感点是一个或多个构件的特性。研究敏感点可使设计人员或分析人员明确在搞清楚如何实现质量目标时应注意什么。
权衡点：权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。例如，改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性，但可能要耗费更多的处理时间，影响系统性能。如果某个机密消息的处理有严格的时间延迟要求，则加密级别可能就会成为一个权衡点。
风险点：风险点是指那些可能导致项目质量属性目标无法实现的不确定事件或条件
非风险点：非风险点是指那些不会对项目质量属性目标实现构成威胁的事件或条件。它们通常是项目中的确定因素，不具备风险的特点
风险承担者/利益相关人：系统的架构涉及很多人的利益，这些人都对架构施加各种影响，以保证自己的目标能够实现。
场景：进行架构评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该架构优略的标准。为得出这些目标而采用的机制称之为场景。
- 场景是从风险承担者的角度对系统的交互的简单描述。在架构评估中，一般采用刺激、环境和响应三方面对场景进行描述。
  - 刺激用于描述利益相关者如何引发与系统的交互。
  - 环境用于描述刺激发生时的系统情况
  - 响应用于描述系统是如何对刺激做出反应的。

架构评估方法

系统架构评估的方法通常可以分为3类：基于调查问卷或检查表的方式、基于场景的方式、基于度量的方式

基于调查问卷或检查表的方式：该方法的关键是要设计好问卷或检查表，充分利用系统相关人员的经验和知识，获得对架构的评估。该方法的缺点是在很大程度上依赖于评估人员的主观推断。
基于场景的方式：基于场景的方式由卡耐基梅隆大学软件工程研究所首先提出并应用在架构权衡分析法（ATAM）和软件架构分析方法（SAAM）中。它是通过分析软件架构对场景的支持程度，从而判断该架构对这一场景所代表的质量需求和满足程度。
基于度量的方式：它是建立在软件架构度量的基础上的，涉及3个基本活动，首先需要建立质量属性和度量之间的映射原则，然后从软件架构文档中获取度量信息，最后根据映射原则分析推导出系统的质量属性。

SAAM 软件体系结构分析方法

SAAM 的目标是对描述应用程序属性的文档，验证基本的架构假设和原则。
SAAM 使用的评估技术是场景技术。场景代表了描述架构属性的基础，描述了各种系统必须支持的活动和可能存在的状态变化。
可修改性是SAAM 分析的主要质量属性
SAAM 的主要输入是问题描述、需求声明和架构描述。
SAAM 分析评估架构的过程包括 5个步骤包括：场景开发、架构描述、单个场景评估、场景交互和总体评估。
SAAM 是一种成熟的方法，已被应用到众多系统中，这些系统包括空中交互管制、嵌入式音频系统、WRCS （修正控制系统）、KWIC （根据上下文查找关键词系统）等

ATAM 系统权衡分析法

系统权衡分析方法（ATAM）是在SAAM 的基础上发展起来的，主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。
架构描述基于5种基本结构来进行，这5种结构是从Kruchten 的 4+1 视图派生而来的。其中逻辑视图被分为功能结构和代码结构。这些结构加上它们之间适当的映射可以完整地描述一个架构。
评估技术。可以把ATAM 方法视为一个框架，该框架依赖于质量属性，可以使用不同的分析技术。它集成了多种优秀的单一理论模型，其中每种都能够高效、实用的处理属性。该方法使用了场景技术。从不同的架构角度，有3种不同类型的场景：
- 用例（包括对系统典型的使用、引出信息）
- 增长场景（用于涵盖那些对它的系统的修改）
- 探测场景（用于涵盖那些可能会对系统造成过载的极端修改）

ATAM 还使用特定的启发式分析方法，在对一个质量属性构造了一个精确分析模型时要进行分析，定性的启发式分析方法就是这种分析的粗粒度版本。
ATAM 被分为 4个主要的活动领域，分别是场景和需求收集、架构视图和场景实现、属性模型构造和分析、架构决策与折中。整个评估过程强调以属性作为架构评估的核心概念。
现在的ATAM 的4个活动分为：描述和介绍阶段、调查和分析阶段、测试阶段、报告阶段
ATAM 采用有效用树这一工具来对质量属性进行分类和优先级排序。效用树的结构包括：树根-质量属性-属性分类-质量属性场景。得到初始效用树后，需要修剪这棵树，保留重要场景（通常不超过50个），再对场景按重要性给定优先级,再按场景实现的难易程度来确定优先级(H/M/L的形式)，这样对所选定的每个场景就有一个优先级对（重要度、难易度)，如（H、L）表示该场景重要且易实现。

架构评估实践

阶段1-- 演示

演示阶段包括的步骤有：介绍ATAM、介绍业务驱动因素（需求）、介绍要评估的体系结构

介绍 ATAM：评估小组负责人向参加会议的项目干系人介绍ATAM 评估方法
介绍业务驱动因素：项目决策者从业务的角度介绍系统的概况。该描述应该包括系统最重要的功能、技术/管理/经济和政治方面的任何相关限制、与该项目相关的业务目标和上下文、主要的项目干系人，以及架构的驱动因素等。
介绍要评估的体系结构：包括技术约束（如操作系统、硬件和中间件等）将与本系统进行交互的其它系统、用以满足质量属性要求的架构方法等。

阶段2-- 调查和分析

调查和分析步骤包括：确定架构方法、生成质量属性效用树、分析体系结构方法

确定架构方法：通过理解架构方法来分析架构，在这一步，由架构设计师确定架构方法。
生成质量属性效用树：评估小组、设计小组、管理人员和客户代表一起确定系统最重要的质量属性目标，并对这些质量目标设置优先级和细化。
分析体系结构方法：这一步的主要结果是一个架构方法或风格的列表，与之相关的一些问题，以及设计师对这些问题的回答。通常产生一个风险列表、敏感点和权衡点列表。

这一步分为四个主要阶段
- 找出风险、非风险、敏感点和权衡点
- 分析问题的答案：根据架构对上述分析问题提供合理的解释或答案
- 创建分析问题：收集上面讨论过的高优先级场景中产生的分析问题。在现实生活中，所有利益相关者都会收集分析问题。分析问题与上面讨论的每种架构方法相关联，并面向重要的质量属性
- 调查架构方法：在识别出对系统目标至关重要的质量属性后，我们分析结构并确定它如何支持这些质量属性。我们对体系结构进行详细的调查，以了解这些质量属性要求是否得到满足。

阶段3-- 测试

测试阶段包括：头脑风暴和优先场景、分析架构方法

头脑风暴和优先场景：项目干系人进行两项相关的活动，分别是集体讨论用例场景和改变场景。用例场景是场景的一种，在用例场景中，项目干系人是一个终端用户，使用系统执行的一些功能。一旦收集了若干个场景后，必须设置优先级。评估人员通过投票表决的方式来完成。
分析架构方法：在收集并分析了场景之后，设计师就可把最高级别的场景映射到所描述的架构中，并对相关的架构如何有助于该场景的实现做出解释。在这一步中，评估小组要重复第6步中的工作，把新得到的最高优先级场景与尚未得到的架构工作产品对应起来。在第7步中，如果未产生任何在以前的分析步骤中都没有发现的高优先级场景，则在第8步就是测试步骤。

阶段4-- 报告 ATAM

最后，要把ATAM 分析中所得到的各种信息进行归纳，并反馈给项目干系人。ATAM 的评估结果包括一个简洁的架构描述、表达清楚的业务目标、用场景集合捕获的质量属性、所确定的敏感点和权衡点的集合、有风险决策和无风险决策、风险主题的集合。

ATAM 团队的主要发现通常包括：

一种效用树
一组生成的场景
一组分析问题
一套确定的风险和非风险；确定的架构方法

CBAM 成本效益分析法

在大型复杂系统的构建过程中，经济性通常是需要考虑的首要因素。因此，需要从经济角度建立成本、收益、风险和进度等方面的软件的"经济"模型。成本效益分析法（CBAM）是在ATAM 上构建，用来对架构设计决策的成本和收益进行建模，是优化此类决策的一种手段。CBAM 的思想就是架构策略影响系统的质量属性，反过来这些质量属性又会为系统的项目干系人带来一些收益，CBAM 协助项目干系人根据其投资回报（ROI）选择架构策略。CBAM 在 ATAM 结束时开始，它实际上使用了ATAM 评估的结果。

步骤

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

SAEM

将软件架构看作一个最终产品以及设计过程中的一个中间产品，从外部质量属性和内部质量属性两个角度来阐述它的评估模型，旨在为软件架构的质量评估创建一个基础框架。

外部属性指用户定义的质量属性，而内部属性指开发者决定的质量属性。该软件架构评估模型包含以下几个流程。

对待评估的质量属性进行规约建模，参考ISO/IEC 9126-1 标准中的质量模型，先从用户的角度描述架构的外部质量属性，再基于外部质量属性规约从开发者的角度描述架构的内部质量属性。
为外部和内部的质量属性创建度量准则，先从评估目的，评估角度，评估环境出发来定义架构评估的目标，再根据目标相关的属性来提出问题，然后回答每个问题并提出相应的度量准则。
评估质量属性，包括数据集、度量和结果分析3个活动。该模型已在相关系统领域得到应用。

SAABNet

软件架构定性的评估技术依赖于专家知识，包括某些特定类型问题的解决方案以及可能的诱导因素、统计知识、审美观等，这些定性的知识比较含糊且难以文档化。SAABNet 是一种用来表达和使用定性知识以辅助架构的定性评估。

SACMM

SACMM 方法是一种软件架构修改的度量方法，首先基于图内核定义差异度量准则来计算两个软件架构之间的距离，图内核的基本思想是将结构化的对象描述为它的字结构的集合，通过子结构的配对比较来分析对象之间的相似性。

SASAM

SASAM 方法通过对预期架构（架构设计阶段的相关描述材料）和实际架构（源代码中执行的架构）进行映射和比较来静态地评估软件架构，并将静态评估与架构开发方法PuLSE-DSSA 结合，识别出10种不同的目的和需求来指导静态的架构评估。

静态评估方法对预期架构模型和实际架构模型中的每个元素进行映射，比较某个模型元素或关联是否在两个架构模型中都存在，还是只存在于其中某个架构模型中，从而得到评估结果，其中映射需要手工完成，比较评估可以在软件架构可视化和评估工具SAVE 中执行。10个评估目的包括：

产品线可能性。分析几个不相干的系统是否适用于某个共有的架构，即分析它们是否能成为预期产品线的一部分。
产品对准性。评估系统的软件架构是否与产品线的软件架构一致。
重用可能性。分析组件是否能重用
组件充分性。评估组件的内在质量。
对软件架构的理解
一致性。评估架构文档和执行的一致性
完备性。检测未被文档化的架构实体。
软件系统或产品线的文档
控制演化
支持架构结构的分解

ALRRA

ALRRA 是一种软件架构可靠性风险评估方法，该方法使用动态复杂度准则和动态耦合度准则来定义组件和连接件的复杂性因素，其中，动态复杂度准则在某个场景的执行中分析组件的动态行为来度量组件的复杂性，动态耦合度准则在某个场景的执行中分析连接件的消息传递协议来度量连接件的复杂性。该方法利用失效模式和影响分析（FMEA）来定义故障引起的后果的严重性因素，并将复杂度和严重性因素组合起来定义组件和连接件的启发式风险因素，然后基于组件依赖图定义风险分析模型和风险分析算法，将组件和连接件的风险因素集成到架构层次的风险因素中。

使用 ALRRA 方法进行软件架构可靠性评估的步骤

使用架构描述语言（ADL）建模软件架构
使用仿真进行复杂性分析
使用FMEA 和失效严重性分析
为组件和连接件启发式的定义可靠性风险因素
构造架构的CDG ，对每个结点 Ci 赋予组件的可靠性风险hrfi，对Ci 和Cj 之间连接件赋连接件的可靠性风险hrfij。
用图遍历算法执行架构的风险评估和分析，架构的可靠性风险因素可以通过集成其组件和连接件的风险因素获取。

AHP

层次分析法（AHP）是多种架构评估度量方法的基础理论。AHP 的特点是把复杂问题中的各种因素通过划分为相联系的有序层次使之条理化，并在一般情况下通过两两对比，根据一定客观现实的主观判断结构，把专家意见和分析者的客观判断结果直接、有效地结合起来，将一定层次上元素的某些重要性进行定量描述，之后利用数学方法计算反应每一层次元素的相对重要性次序的权值，并最后通过所有层次之间的总排序计算所有元素的相对权重及对权重进行排序。

层次分析法对AHP 问题域的分析、度量一般分为5步

通过对系统的深入认知，确定该系统的总目标，得出规划决策所涉及的范围、所要采取的措施方案和政策、实现目标的准则以及策略和各种约束条件等，并广泛收集在分析过程中要用到的多种信息。
建立一个多层次的递阶结构，按目标的不同、实施功能的差异，将系统分为几个等级层次。
确定以上递阶结构中相邻层次元素间的相关程度，通过构造比较判断矩阵即矩阵运算的数学方法，确定对于上一层次的某个元素而言本层次中与其相关元素的重要性排序，即相对权值。
计算各层元素对系统目标的合成权重，进行总排序，确定递阶结构图中底层的各个元素的重要程度。
根据分析计算结果，考虑相应的决策。

软件架构评估包括对各种质量属性的评估以及其他一些非功能非质量因素的评估，这些属性之间有时存在某些冲突。AHP 是一种重要的辅助决策方法，通常被用来解决这些冲突。AHP 可以帮助对提供的设计方案进行整体排名。

COSMIC + UML

基于面向对象系统源代码的可维护性度量准则.针对不同表达方式的软件架构，采用统一的软件度量COSMIC 方法来进行度量和评估。例如，针对UML 组件图描述的软件架构，其可维护性度量包括以下3个步骤。

将面向对象的度量准则与COSMIC 方法相关联。
对COSMIC 标记进行完善以适用于描述UML 组件图。
提出UML 组件图的度量准则：复杂度、耦合度和内聚度等

该方法主要是为了辅助分析软件架构的演化方案是否可行，并在开源软件DCMMS 的软件架构UML 组件图上得以验证。