如何评估架构PPT课件.pptx

关注软件架构的系列主题 如何评估架构Overview 2020 3 22 1 一 引言 二 ATAM 三 CBAM 提纲 四 架构编档与评估 2 为什么要评估软件架构 为什么要评估软件架构 我们需要了解软件架构设计的原因 因为很多事情都依赖于架构 并且我们能够对架构进行评估 在每个基于架构的开发方法中都应该进行架构评估 3 软件架构评估的重要因素 时间在软件的生命期内近可能早的评估软件架构几乎总是经济高效的 可以在系统生命周期的许多个点上进行架构评估 参与者项目负责人 架构师有经验的评估团队其他涉众 4 软件架构评估的重要因素 经济性在8年的时间内对架构进行评估的经验表明 进行全面的架构评估平均可以节约10 的成本 促进编档向被评审人员说明架构评估的重点并要求他们在评估前表述构架 意味着被评审人员必须对架构进行编档 了解原理架构评估通常侧重于需要回答的一些具体问题的某几个特定的方面 回答这些问题通常需要解释设计选择及其基本原理 验证需求讨论和检查架构满足其需求的情况可以展开对需求的讨论 结果是能更清楚的理解需求 通常还能够知道需求的优先级 架构改进架构评估不仅在评估后得到了更好的架构 随着时间的推移 组织就培养了一种提倡优秀的架构设计的文化 5 软件架构评估的重要因素 提问技巧ATAM和CBAM方法就是 提问技巧 的示例 在假定的架构上就可以很好的应用它 并且可以在生命期的早期应用 度量技巧提问技巧的补充是度量技巧 它依赖于对某些类似的定量度量 使用度量技巧时 必须有已经存在的 可以被度量的工作产品 6 软件架构评估的重要因素 前置条件表述清晰的架构目标与需求 只有需求明确 才能评估一个架构是好还是坏 可控制的范围 列出几个明确的目标 数量最少应该有3 5个 经济高效 ATAM与CBAM方法适用于大中型项目 对于小项目可能就不是经济高效的了 关键人员参与 务必确保能够系统 清晰表述架构的人能参与 称职的评估团队 在理想状态下 评估团队应该是公司内的一个独立实体 它们必须公正 客观并受人尊重 7 软件架构评估的重要因素 结果 应该包含 但不限于 一个简洁清晰的架构表述一个简洁清晰的业务目标表述代表质量需求的场景集合架构决策到质量需求的映射确定的敏感点和权衡点集合有风险决策和无风险决策风险主题的集合根据ROI 投资回报率 对架构策略的排序 仅限于CBAM 8 一 引言 二 ATAM 三 CBAM 提纲 四 架构编档与评估 9 ATAM概念 ATAM 架构权衡分析法 是评估软件架构的一种综合全面的方法 它不仅可以揭示出架构满足特定质量目标的情况 而且可以使我们更清楚的认识到质量目标之间的联系 即如何权衡诸多质量目标 评估小组 由3 5个有经验的架构师组成 项目决策者 项目经理 开发经理等对项目决策负责的人 架构涉众 高级主管 开发人员 测试人员 运维人员等 分析阶段 10 ATAM分析阶段 1 3 第1阶段与第2阶段合起来又称为ATAM的分析阶段 一共有9步组成 其中第1 6步在第1阶段执行 第7 9步在第2阶段执行 11 第三步 架构描述方法 描述驱动架构形成的需求 以及现在已采用的标准 模型 方法 2 3张幻灯片 重要的架构信息 4 8张幻灯片 上下文图 系统将存在的上下文 该系统将与之交互的人或其他系统 模块或分层视图 描述系统功能分解的模块 可以是子系统或层 以及作为其具体内容 组件 连接器视图 进程 线程及其同步关系 数据流及将其连接起来的事件 部署视图 CPU 存储器 外设 传感器以及连接它们的网络和通信设备 还显示了在各个处理器上执行的进程 架构方法 模式或所采用的战术 包括它们实现了什么质量属性以及这些方法如何实现这些属性的描述 6 8张幻灯片 商业产品的使用及其选择 集成 1 2张幻灯片 对1 3个最重要的用例场景的介绍 如果有可能的话 包括对每个场景的运行时资源使用情况的介绍 1 3张幻灯片 对1 3个最重要的变更场景的介绍 如果有可能的话 根据所变更的模块或接口来描述变更的影响 即预计的变更的规模 难度 1 3张幻灯片 与实现促使形成该架构的需求相关的架构问题 风险 2 3张幻灯片 术语表 1张幻灯片 第三步需要项目架构师介绍项目的架构 下面这个20页PPT的提纲是很好的参考 12 ATAM分析阶段 4 6 13 第五步 质量属性效用树 14 第六步 架构分析 有敏感点 架构A有风险 场景A分析 记录架构A为有风险决策 有敏感点 架构B有风险 场景B分析 有敏感点 架构A有风险 场景C分析 记录架构B为有风险决策 记录架构A为权衡点 有敏感点 架构D无风险 场景D分析 记录架构D为无风险决策 15 分析阶段1 6总结 第一阶段结束后 评估小组将得到一份关于架构的记录与分析文档 其中包括质量属性效用树 敏感点 有风险决策 无风险决策以及权衡点 这些内容将作为第二阶段的输入物 在第二阶段启动之前 评估小组应该拿出1 2周的时间来与项目组成员进行一些非常正式的沟通 使得了解能够更加的彻底 当涉众被召集到一起后 第二阶段就开始了 在其正式步骤开始之前 评估小组还需要向涉众介绍一遍ATAM的评估方法 16 ATAM分析阶段 7 9 17 第七步 如何让涉众确定场景优先级 让他们通过投票表决来确定哪些场景是最重要的 在分配选票时 每个涉众都会拿到相当于总场景数的30 的选票 并且此数值只入不舍 在投票时 涉众可以随意使用这些选票 可以把这6张选票都投给1个场景 也可以给1个场景投1张选票 或者是介于以上两者之间的其他方式 最终 我们可以选择 在某得票数之上 的场景 例如 评估小组可能只考虑得票数最多的前5个场景 18 ATAM主要步骤及对结果提供的信息 结果 步骤 19 第七步 如何让涉众确定场景优先级 总体来说 ATAM是一个重量级的架构健壮性评估方法 它通过对场景的分析 挖掘出架构设计中的问题及风险点 以便项目组进行改进 20 一 引言 二 ATAM 三 CBAM 提纲 四 架构编档与评估 21 CBAM概念 ATAM遗漏了一个重要的考虑事项 在大型复杂系统中最大的权衡通常必须考虑经济性 我们需要一个考虑成本 收益 风险和进度的软件的 经济 模型 CBAM 成本收益分析方法 它构建在ATAM之上 提供了对技术的经济问题以及构架决策的评估 Ri Bi Ci 22 确定效用 响应曲线 规划效用 响应曲线通常可以采用以下四步来实现 23 结果示例 根据最坏 当前 期望 最好四个基本点 构造整个效用 响应曲线 24 对应场景设计架构策略 每一个架构策略都有可能对应一到多个场景 每一个场景也有可能对应一道多个架构策略 为了能够计算架构策略的收益 因此必须给出每个场景在采用了架构之后能够达到的新响应情况 如下表所示 25 计算每个策略产生的收益 根据效用 响应曲线 代入架构达到的响应 计算出架构达到的响应效用 根据每个场景架构达到的效用与其当前的效用的差值 我们可以得出效用提升的大小 再乘以票数 暨权重 就可以得到这个场景的收益 一个架构策略对应的所有场景的收益和就是这个架构策略的总收益 架构策略1总收益 300 450 750架构策略5总收益 100架构策略7总收益 50 26 根据策略成本计算ROI 估算成本的方式通常以人 天为单位 因此如果我们要估算一个架构策略的成本就应该考察实现它所需要的人 天数 一般来说这由提出它的架构师给出 如果最终这个架构策略被采纳 那么项目组就应该将其视为一个任务 并按照其估算监督它的执行 由于每个场景在计算其收益时已经考虑该场景的重要性 暨权重 因此每个架构策略也就具有了横向可比性 通过最终的ROI可以得出架构策略应该被执行