如何评估架构.pptx

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