系统架构评估即对架构策略的选取进行决策，通常分为：
①基于调查问卷或检查表的方法，该方法主观因素较多
②基于场景的评估方法：应用在架构权衡分析法（**ATAM ） 和软件架构分析方法（**SAAM **）**中
③基于度量的评估方法：建立质量属性和度量之间的映射原则→在软件文档中获取度量信息→分析推导系统质量属性
一、系统架构评估的重要概念
1、敏感点定义 ：敏感点是架构设计中一个或多个决策 ，它对某个特定质量属性的实现具有显著影响。
-
关键词 ："决策" 、"单一质量属性" 、"显著影响"。
-
关键点拨：
-
它不是一个"问题"或"缺陷"，而是一个中性的设计选择。例如，"使用数据库连接池"是一个设计决策。
-
这个设计选择会敏感地影响 某个质量属性。继续上面的例子，"使用数据库连接池"这个决策，对性能这个质量属性有显著的正面影响（因为它减少了创建新连接的开销）。
-
因此，"数据库连接池"就是实现"性能"目标的一个"敏感点"。
-
-
记忆口诀 ："为了达到A质量，我们做了B决策，B就是A的敏感点。"
2、权衡点定义 ：权衡点是架构设计中一个或多个决策 ，它对多个质量属性 产生影响，并且这些影响是冲突的（即提升一个会损害另一个）。
-
关键词 ："决策" 、"多个质量属性" 、"冲突影响"。
-
关键点拨：
-
权衡点一定是敏感点，但敏感点不一定是权衡点。
-
它是架构师进行决策和权衡的焦点，是架构评估中最重要的关注点。
-
经典例子："采用数据加密"这个决策。
它对安全性 有正面 影响。但它对性能 有负面 影响（因为加解密运算需要消耗CPU资源）。因此，"数据加密"就是一个典型的权衡点。架构师需要在这里权衡：要多高的安全性能？愿意为此牺牲多少性能？
-
-
记忆口诀 ："一个决策，利弊兼有，需要权衡，这就是权衡点。"
3、风险承担者或利益相关人定义 ：所有对软件系统有利益关系 、关注点 或约束 的个人、团队或组织。他们的偏好和需求最终决定了哪些质量属性是重要的。
-
关键词 ："利益/关注点" 、"决定质量属性优先级"。
-
关键点拨：
-
架构评估不是 技术人员的自嗨，首要任务就是识别所有重要的风险承担者并听取他们的诉求。
-
不同的风险承担者关心不同的质量属性：
用户 ：关心性能、可用性、易用性。开发人员 ：关心可维护性、可扩展性。运维人员 ：关心可部署性、可监控性、可靠性。客户/老板：关心成本、上市时间、合规性。
-
架构评估的目标就是验证架构设计是否满足这些不同角色的质量需求。
-
-
记忆口诀 ："谁关心这个系统？他们关心什么？答案就是风险承担者及其关注点。"
4、场景核心定义 ：场景是对风险承担者与系统之间某种特定交互的简短、具体的描述 。它是将模糊的质量需求转化为可测试、可评估的具体用例的工具。
-
结构化描述：
-
刺激/触发：发生了什么？（例如，10000个用户同时提交订单。）
-
环境：在什么情况下发生的？（例如，系统正处于正常运行状态。）
-
响应/影响：系统应该如何响应？（例如，系统应在2秒内处理完95%的订单，并保持稳定。）
-
-
关键点拨：
-
场景是沟通的桥梁，它用业务和用户的语言描述技术问题，确保开发者、客户、管理者能在同一频道对话。
-
场景是评估的标尺，评估人员通过分析架构是否支持关键场景来判断其质量。
-
场景分为：
用例场景 （直接对应功能需求）增长场景 （关于未来的扩展和变更）探索场景（应对极端情况，如故障）
-
-
记忆口诀 ："在什么情况下，发生了什么事，系统应该怎么做？------ 这就是场景。"
二、系统评估方法
1、软件架构分析方法（Software Architecture Analysis Method，SAAM）。
SAAM是最早形成的 、最直观的 架构评估方法。它的核心目的是评估架构对于特定应用场景的适用性 ，并突出不同架构设计之间的功能性差异 。它特别擅长分析可修改性（即变化一个功能有多难）。
①场景开发 ：风险承担者 brainstorming 出大量应用场景 （use case scenarios）和修改场景 （growth scenarios）。这是所有评估的输入基础。
②架构描述：架构师向评估团队描述待评估的架构（可能是一个或多个候选架构）。
③单个场景评估 ：对每个场景，分析架构如何支持它。重点是识别直接场景 （架构已直接支持）和间接场景（需要对架构进行修改才能支持）。
④场景交互 ：这是SAAM的精华步骤 。找出那些需要修改同一个构件 的场景。这些场景被称为相互作用的场景。
⑤总体评估：基于所有间接场景的修改工作量，以及场景交互的复杂度，对架构做出整体评价和比较。
-
主要输出：
-
架构对于所需场景的支持程度。
-
架构的可修改性评估结果。
-
多个架构方案之间的比较排名。
-
2、架构权衡分析法（Architecture Tradeoff Analysis Method，ATAM）
ATAM是比SAAM更复杂、更全面 的方法。它的核心目的不是比较架构，而是理解架构决策如何影响多个质量属性之间的权衡 。它揭示的是为满足某个质量属性而做出的决策，会对其他质量属性产生什么后果。
ATAM的流程非常结构化，通常分为4个阶段和9个步骤。
-
Presentation (演示阶段)：
-
步骤1：ATAM方法演示 -> 给所有人讲清楚规则。
-
步骤2：商业动机演示 -> 项目经理讲"为什么要做这个系统"。
-
步骤3：架构演示 -> 架构师讲"系统是怎么设计的"。
-
-
Investigation & Analysis (调查与分析阶段)：
-
步骤4：识别体系结构步骤 -> 找出架构采用的设计模式（如微服务、缓存、负载均衡）。
-
步骤5：生成质量属性效用树 -> 这是ATAM的灵魂工具！
-
效用树 ：将模糊的质量目标（如"高性能"）层层分解为具体、可测量、可测试的场景（叶子节点）。
-
结构 ：
质量属性 -> 属性分类 -> 场景，并对每个场景进行优先级排序（高H，中M，低L）。这确保了评估聚焦于最重要的方面。
-
-
步骤6：分析架构 approaches -> 针对效用树中的高优先级场景，分析步骤4中识别的架构 approaches 是如何实现它们的。在此过程中，会产出敏感点和权衡点。
-
-
Testing (测试阶段)：
-
步骤7：头脑风暴和优先排序场景 -> 补充效用树之外的新场景。
-
步骤8：分析架构 approaches -> 同上，分析新场景。
-
-
Reporting (报告阶段)：
- 步骤9：结果陈述 -> 向所有风险承担者展示评估的最终产出。
-
主要输出（比SAAM丰富得多）：
-
已编撰的架构 approaches。
-
已划分优先级的质量属性需求（效用树）。
-
映射到架构 approaches 上的质量属性需求。
-
风险点：可能导致质量属性目标无法实现的决策。
-
敏感点：影响一个质量属性的决策。
-
权衡点 ：影响多个质量属性且需要权衡的决策。这是ATAM最重要的输出！
-
我们对比一下：
| 特性 | SAAM | ATAM |
|---|---|---|
| 核心目标 | 评估场景适用性 ，比较不同架构 | 理解架构决策的权衡 ，评估单一架构，多个质量属性之间折中 |
| 评估焦点 | 可修改性、功能性 | 多个质量属性 （性能、安全、可用性等）及其权衡 |
| 核心工具 | 场景 、场景交互分析 | 效用树 （用于优先级排序）、质量属性分析 |
| 主要输出 | 场景支持度、可修改性评分、架构排名 | 权衡点、风险点、敏感点、已编撰的架构决策 |
| 复杂度 | 相对简单 | 相对复杂、全面 |
| 适用阶段 | 架构设计早期，有多个候选方案时 | 架构设计相对稳定后，决策基本完成时 |
| 应用领域 | 空中交通管制系统、嵌入式音频系统、修正控制系统 | 仍处于研究中 |
三、其他评估方法
1）SAEM 方法：将软件架构看作一个最终产品以及涉及过程中的一个中间产品，从外部质量属性和内部质量属性阐述的评估模型。
2）SAABNet 方法：辅助架构的定性评估，帮助诊断软件问题的可能原因，分析架构中的修改给质量属性带来的影响、预测架构的质量属性，帮助架构设计人员做决策。SAABNet 度量的对象包括架构属性、质量准则和质量因素。
3）SACMM 方法：一种软件架构修改的度量方法，首先基于内核定义差异度量准则来计算两个软件架构之间的距离，然后分析对象之间的相似性。
4）SASAM 方法：通过对预期架构和实际架构进行映射和比较来静态地评估软件架构。
5）ALRRA 方法：是软件架构可靠性风险评估方法，使用动态复杂度准则和动态耦合度准则来定义组件和连接件的复杂性因素。
6）AHP 方法：把定性分析和定量计算相结合，对各种决策因素进行处理。
7）COSMIC+UML 方法：针对不同表达方式的软件架构，采用统一的软件度量 COSMIC 方法来进行度量和评估。