系统架构评估是在对架构予以分析、评估的底子上，对架构策略的选择作出决策。它运用数学或者逻辑分析技能，针对系统的同等性、正确性、质量属性、规划结果等差别方面，给出描述性、预测性以及指令性的分析结果。
系统架构评估的方法通常可分为三类：基于观察问卷或检查表的方式、基于场景的方式以及基于度量的方式。
1.基于观察问卷或检查表的方法。此方法的关键在于经心操持问卷或者检查表，充分运用系统相关职员的履历与知识，来获取对架构的评估。该方法的不敷之处在于在很大程度上依靠评估职员的主观推断。
2.基于场景的评估方法。基于场景的方式由卡耐基梅隆大学软件工程研究所率先提出，并应用于架构权衡分析法(Architecture Tradeoff Analysis Method,ATAM)和软件架构分析方法(Software ArchitectureAnalysis Method,SAAM)之中。它是通过剖析软件架构对场景(也就是对系统的使用或修改活动)的支持程度，进而判定该架构对这一场景所代表的质量需求的满足程度。
3.基于度量的评估方法。它创建在软件架构度量的底子之上，涉及三个根本活动，首先要确立质量属性和度量之间的映射原则，接着从软件架构文档中获取度量信息，末了依据映射原则分析推导出系统的质量属性。
系统架构评估中的告急概念重要包含以下几类，这些概念是分析架构质量、识别风险以及权衡决策的核心底子：
1. 敏感点（Sensitivity Point）
界说：敏感点是系统中一个或多个构件（或构件间关系）的特性，与实现特定质量属性精密相关。通过分析敏感点，能够明白在满足质量目标时必要关注的关键操持决策。
示例：数据库连接池的配置是性能的敏感点，调整其参数大概会直接影响系统吞吐量。
2. 权衡点（Tradeoff Point）
界说：权衡点是影响多个质量属性的敏感点，必要在差别质量目标之间进行折中的决策。它是架构操持中必要偏重关注的复杂决策点。
示例：提高加密级别可能会增强安全性，但会增长计算开销，致使性能下降，所以加密级别是安全性与性能的权衡点。
3. 风险承担者（Stakeholders）
界说：风险承担者（利益相关者）是对系统架构有影响或者受其影响的群体，包括用户、开发职员、测试职员、运维职员等。
作用：在评估过程中必要协调差别利益方的需求，确保架构满足多方目标。例如，用户关注可用性，架构师关注可维护性。
4. 场景（Scenarios）
界说：场景是描述系统与外部交互的机制，通过“刺激（Stimulus）-环境（Environment）-响应（Response）”三个要素构建，用于准确分析质量属性的实现效果。
应用：例如，“用户并发量激增时（刺激），系统在10秒内响应哀求（响应）”是一个性能场景。
5. 风险点与非风险点
风险点：指架构操持中可能致使质量目标无法实现的潜在问题，如高并发场景下未采用分布式缓存可能引发性能瓶颈。
非风险点：指已履历证可行的架构决策，例如使用冗余服务器提升可用性已被证明有效的。#架构评估#
本日就讲到这里啦，贪多嚼不烂哦，下次介绍SAAM，拜拜喽
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
