如何评估架构

关注软件架构的系列主题

-如何评估架构Overview202月-23一、引言二、ATAM三、CBAM提纲四、架构编档与评估为什么要评估软件架构时间参与者收益技巧前置条件结果为什么要评估软件架构？

我们需要了解软件架构设计的原因，因为很多事情都依赖于架构，并且我们能够对架构进行评估。

在每个基于架构的开发方法中都应该进行架构评估。软件架构评估的重要因素时间参与者收益技巧前置条件结果时间

在软件的生命期内近可能早的评估软件架构几乎总是经济高效的。

可以在系统生命周期的许多个点上进行架构评估。参与者项目负责人、架构师有经验的评估团队其他涉众软件架构评估的重要因素时间参与者收益技巧前置条件结果经济性在8年的时间内对架构进行评估的经验表明，进行全面的架构评估平均可以节约10%的成本促进编档向被评审人员说明架构评估的重点并要求他们在评估前表述构架，意味着被评审人员必须对架构进行编档了解原理架构评估通常侧重于需要回答的一些具体问题的某几个特定的方面，回答这些问题通常需要解释设计选择及其基本原理验证需求讨论和检查架构满足其需求的情况可以展开对需求的讨论，结果是能更清楚的理解需求，通常还能够知道需求的优先级架构改进架构评估不仅在评估后得到了更好的架构，随着时间的推移，组织就培养了一种提倡优秀的架构设计的文化软件架构评估的重要因素时间参与者收益技巧前置条件结果提问技巧

ATAM和CBAM方法就是“提问技巧”的示例，在假定的架构上就可以很好的应用它，并且可以在生命期的早期应用。度量技巧提问技巧的补充是度量技巧，它依赖于对某些类似的定量度量，使用度量技巧时，必须有已经存在的、可以被度量的工作产品。软件架构评估的重要因素时间参与者收益技巧前置条件结果前置条件表述清晰的架构目标与需求，只有需求明确，才能评估一个架构是好还是坏；可控制的范围，列出几个明确的目标，数量最少应该有3-5个；经济高效，ATAM与CBAM方法适用于大中型项目，对于小项目可能就不是经济高效的了；关键人员参与，务必确保能够系统、清晰表述架构的人能参与；称职的评估团队，在理想状态下，评估团队应该是公司内的一个独立实体，它们必须公正、客观并受人尊重。软件架构评估的重要因素时间参与者收益技巧前置条件结果结果（应该包含，但不限于）一个简洁清晰的架构表述一个简洁清晰的业务目标表述代表质量需求的场景集合架构决策到质量需求的映射确定的敏感点和权衡点集合有风险决策和无风险决策风险主题的集合根据ROI（投资回报率）对架构策略的排序（仅限于CBAM）一、引言二、ATAM三、CBAM提纲四、架构编档与评估ATAM概念ATAM，架构权衡分析法，是评估软件架构的一种综合全面的方法，它不仅可以揭示出架构满足特定质量目标的情况，而且可以使我们更清楚的认识到质量目标之间的联系-即如何权衡诸多质量目标。第0阶段通常是评估小组的负责人与项目决策者进行沟通，做好评估前的准备工作第1阶段通常是评估小组与项目决策者联合工作，收集有价值的资料并对其进行整理分析第2阶段通常是评估小组、项目决策者以及架构涉众联合工作，继续第一阶段的分析，并最终给出评估结果第3阶段通常是评估小组和评估的客户，是对前两个阶段工作的总结以及进行自我反省与改进评估小组，由3-5个有经验的架构师组成项目决策者，项目经理、开发经理等对项目决策负责的人架构涉众，高级主管，开发人员、测试人员、运维人员等分析阶段ATAM分析阶段（1-3）第1阶段与第2阶段合起来又称为ATAM的分析阶段，一共有9步组成，其中第1～6步在第1阶段执行，第7～9步在第2阶段执行。第一步由评估负责人向参加会议的项目负责人介绍ATAM，要将整个流程做一个全面的介绍并回答问题第二步由项目负责人从商业的角度向评估小组介绍系统的概况，包括：系统最重要的功能，任何相关的技术、管理、经济和政治限制，与该项目相关的商业目标和上下文，主要的涉众，构架的驱动因素（即促使形成该架构的主要质量属性目标）第三步由项目架构师向评估小组介绍整个架构，这里有一些具体的方法第三步，架构描述方法描述驱动架构形成的需求，以及现在已采用的标准/模型/方法（2～3张幻灯片）重要的架构信息（4～8张幻灯片）上下文图：系统将存在的上下文，该系统将与之交互的人或其他系统；模块或分层视图：描述系统功能分解的模块（可以是子系统或层），以及作为其具体内容；组件-连接器视图：进程、线程及其同步关系、数据流及将其连接起来的事件；部署视图：CPU、存储器、外设/传感器以及连接它们的网络和通信设备；还显示了在各个处理器上执行的进程。架构方法、模式或所采用的战术，包括它们实现了什么质量属性以及这些方法如何实现这些属性的描述（6～8张幻灯片）商业产品的使用及其选择/集成（1～2张幻灯片）；对1～3个最重要的用例场景的介绍。如果有可能的话，包括对每个场景的运行时资源使用情况的介绍（1～3张幻灯片）；对1～3个最重要的变更场景的介绍。如果有可能的话，根据所变更的模块或接口来描述变更的影响，即预计的变更的规模/难度（1～3张幻灯片）；与实现促使形成该架构的需求相关的架构问题/风险（2～3张幻灯片）术语表（1张幻灯片）第三步需要项目架构师介绍项目的架构，下面这个20页PPT的提纲是很好的参考。ATAM分析阶段（4-6）第四步评估小组对项目构架中很明显的模式和方法进行记录和分类，便于后续的分析第五步评估小组通过“质量属性效用树”的方式对系统的质量属性进行梳理与场景对应，分为三层，分别是质量属性、属性求精以及场景描述第六步评估小组要对其中的场景进行细致的分析，目的是为了找出这些架构在支持这些场景的实现时存在哪些风险，哪些敏感点，哪些权衡点第五步，质量属性效用树质量属性属性求精场景性能交易响应时间在系统处于峰期负载时，为对地址变更通知作出响应，用户更新病人的账户，交易要在0.75秒内完成（H，M）吞吐量在峰期负载下，系统每秒能够完成150次范式化的事务可配置性医院提高某项服务的费用。配置小组在一个工作日内完成该改变，不需要改变原代码（H，M）易用性熟练度培训让有2年及以上行业经验的员工能在1周内掌握该系统的核心功能（M，L）质量属性：不必过分追求质量属性的命名，按照涉众能够接受的名字即可，其含义主要还是取决于场景。场景：一个场景中不能包含过多的质量属性，并且每个场景都应该有自己的优先级和难易度的定义（例如H、M和L分别对应了高、中、低）。第六步，架构分析有敏感点架构A有风险场景A分析记录架构A为有风险决策有敏感点架构B有风险场景B分析有敏感点架构A有风险场景C分析记录架构B为有风险决策记录架构A为权衡点有敏感点架构D无风险场景D分析记录架构D为无风险决策分析阶段1-6总结第一阶段结束后，评估小组将得到一份关于架构的记录与分析文档，其中包括质量属性效用树、敏感点、有风险决策、无风险决策以及权衡点，这些内容将作为第二阶段的输入物。

在第二阶段启动之前，评估小组应该拿出1-2周的时间来与项目组成员进行一些非常正式的沟通，使得了解能够更加的彻底，当涉众被召集到一起后，第二阶段就开始了，在其正式步骤开始之前，评估小组还需要向涉众介绍一遍ATAM的评估方法。ATAM分析阶段（7-9）第七步涉众集中讨论已经给出的质量属性效能树中的场景，可以为其进行优先级排序，并可以补充新的场景。第八步按照第六步的方法对涉众评选出来的部分最优先的场景再进行一次架构分析。第九步形成最后的ATAM文档（在引言中已经描述）第七步，如何让涉众确定场景优先级让他们通过投票表决来确定哪些场景是最重要的。在分配选票时，每个涉众都会拿到相当于总场景数的30%的选票，并且此数值只入不舍。在投票时，涉众可以随意使用这些选票：可以把这6张选票都投给1个场景，也可以给1个场景投1张选票，或者是介于以上两者之间的其他方式。

最终，我们可以选择“在某得票数之上”的场景，例如，评估小组可能只考虑得票数最多的前5个场景。ATAM主要步骤及对结果提供的信息质量属性需求的优先级划分所有架构方法的编目针对方法或质量属性的分析问题架构方法与质量属性的对应有风险决策和无风险决策敏感点和权衡点（1）ATAM方法表述（2）商业动机的表述**（3）架构的表述****（4）确定架构方法******（5）生成质量属性效用树**（6）分析架构方法*********（7）集体讨论并确定场景优先级**（8）分析架构方法*********（9）结果的表述*表示该步骤是该结果的次要提供者**表示该步骤是该结果的主要提供者结果步骤第七步，如何让涉众确定场景优先级ATAM不是需求评估它只会告诉你在当前给定的条件下，总体需求是否得到了满足，并且是足够好的满足ATAM不是代码评估因为它在开发之前就可以启动ATAM不是系统测试因为它在开发之前就可以启动ATAM不是精确方法ATAM所发现的敏感点、权衡点，有风险决策、无风险决策都是由参与者的能力决定的总体来说，ATAM是一个重量级的架构健壮性评估方法，它通过对场景的分析，挖掘出架构设计中的问题及风险点，以便项目组进行改进。一、引言二、ATAM三、CBAM提纲四、架构编档与评估CBAM概念ATAM遗漏了一个重要的考虑事项：在大型复杂系统中最大的权衡通常必须考虑经济性。我们需要一个考虑成本、收益、风险和进度的软件的“经济”模型。CBAM，成本收益分析方法，它构建在ATAM之上，提供了对技术的经济问题以及构架决策的评估。效用-响应曲线分析场景对应场景设计架构策略计算每个策略产生的收益根据策略成本计算ROI1000效用质量属性响应abBi=∑(bi,j×Wj)jRi=Bi/Ci

确定效用-响应曲线

规划效用-响应曲线通常可以采用以下四步来实现。1000效用质量属性响应ab第一步对从ATAM中继承过来的场景进行整理，可以选择让涉众重新投票来确定优先级（经济性评估可能会导致优先级变化），取1/3的场景进行后续评估。第二步对场景的响应目标进行求精，定义出每个场景最坏、最好、当前以及期望的响应目标第三步再次确定优先级，这次的不同是在确定了响应目标的前提下，当然我们可以采用投票的方式，取1/2的场景进行后续评估。第四步根据每个场景的四个响应值，来确定其相对应的效用，这里只是给出一个效用得分。需要注意的时，最坏的响应目标也未必对应着0分，当然最好的也未必就是100分，要根据实际情况给出。结果示例响应目标场景描述票数最坏当前期望最好1减少手工干预导致的分配请求挂起的数据分配故障1010%挂起5%挂起1%挂起0%挂起3减少在订单提交过程中失败的订单数量1510%失败5%失败1%失败0%失败5减少会导致丢失订单的订单故障1510%丢失1%以下丢失0%丢失0%丢失效用得分场景描述票数最坏当前期望最好1减少手工干预导致的分配请求挂起的数据分配故障101080951003减少在订单提交过程中失败的订单数量152570951005减少会导致丢失订单的订单故据最坏、当前、期望、最好四个基本点，构造整个效用-响应曲线对应场景设计架构策略

每一个架构策略都有可能对应一到多个场景，每一个场景也有可能对应一道多个架构策略。为了能够计算架构策略的收益，因此必须给出每个场景在采用了架构之后能够达到的新响应情况，如下表所示。策略名称描述影响的场景当前的响应架构达到的响应1订单提交的持续性订单一到达系统就存储该订单35%失败2%失败51%以下丢失0%丢失5订单的重新分配允许操作人员重新分配订单15%挂起2%挂起7被迫的完成订单允许操作人员跳过由于数据质量限制导致的系统不可用15%挂起3%挂起计算每个策略产生的收益

根据效用-响应曲线，代入架构达到的响应，计算出架构达到的响应效用。

根据每个场景架构达到的效用与其当前的效用的差值，我们可以得出效用提升的大小，再乘以票数（暨权重）就可以得到这个场景的收益。

一个架构策略对应的所有场景的收益和就是这个架构策略的总收益。策略名称影响的场景票数当前的效用架构达到的效用收益1订单提交的持续性315709015*20=3005157010015*30=4505订