软件体系结构评估.ppt

第九章第九章 软件体系结构评估软件体系结构评估 1 内容内容 9.19.1软件体系结构评估简介软件体系结构评估简介 9.29.2ATAMATAM方法方法 9.3 SAAM9.3 SAAM方法方法 9.4 ARID9.4 ARID方法方法 基本介绍 n软件系统的基础是它的体系结构，软件体系结 构将影响系统很多质量属性。 n在软件体系结构确定下来以后，软件系统的这 些属性就是可预见的。 n软件体系结构评估的目的 在开发过程的早期，通过分析系统的质量需 求是否在软件体系结构中得到体现，来识别 软件体系结构设计中的潜在风险，预测系统 质量属性，并辅助软件体系结构决策的制定 。 评估时机 n早评估：评估不需要完整的软件体系结构描述 ，可以在软件体系结构创建过程中的任何阶段 使用评估方法，对已经做出的软件体系结构决 策进行检查，或者确定还没有决定的软件体系 结构选项。 n晚评估：迟评估的时机是软件体系结构已经明 确并且实现已经完成的时候，这种情况在某个 组织继承某些遗留系统时发生，这些遗留系统 可能是在市场中购买的，也可能是从本组织现 有的存档中发掘的。 评估人员（2/2） n评估团队：其中的人员会实施评估并且进行分 析，团队中成员和他们确切的角色将在后面定 义； n利益相关人员：是软件体系结构和基于它开发 的系统的既得利益者。 评估结果和质量属性（1/4） n软件体系结构评估会产生一个评估报告，报告 的形式和内容随着所使用评估方法的不同而不 一样。 n通过软件体系结构评估可以回答下面两类问题 ： 软件体系结构是否适用于基于它的软件系统 ？ 如果对于目前的系统有多个软件体系结构可 以选择，那个是最合适的？ 评估结果和质量属性（2/4） n如果一个软件体系结构满足以下两个标准，那 么就认为它是适宜的： 系统的结果满足质量目标。也就是说，系统 的运行是可预期的，并且运行速度足够快， 满足系统的性能或时间需求；系统的修改按 照计划的方式进行，并且满足安全约束，系 统能够提供必须的功能。 系统能够使用现有的资源来开发，现有资源 包括：人员、预算、任何遗留系统以及交付 之前分配的时间。也就是说，软件体系结构 是可构建的。 评估结果和质量属性（3/4） n性能 系统响应能力 n可靠性 系统随着时间的进行而保持运行的能力 n可用性 系统有效工作的时间比例 n安全性 系统在为合法用户提供服务的同时抵制未授权的使用 请求和拒绝服务的能力 n可变性 快速有效地修改系统的能力 评估结果和质量属性（4/4） n可移植性 系统在不同计算环境中运行的能力 n功能性 系统能够按照预期工作的能力 n变化性 软件体系结构能够通过扩展或修改来得到新的软件体 系结构的程度 n可分解性 支持生产系统某个子集的能力 n概念完整性 能够统一所有层面系统设计概念的能力 评估的益处和代价（1/2） n评估的益处： 把利益相关人员召集在一起 强制特定质量目标的接合 生成冲突目标的优先级 对软件体系结构有一个清晰的说明 提高软件体系结构文档的质量 发现跨项目重用的机会 得到优化后的软件体系结构实践 评估的益处和代价（2/2） n评估的代价 人员开销 与参加软件体系结构评估的人员相关的机会成 本 n减小评估代价的方法 在相同领域内的重用 内容内容 9.19.1软件体系结构评估简介软件体系结构评估简介 9.2 ATAM9.2 ATAM方法方法 9.3 SAAM9.3 SAAM方法方法 9.4 ARID9.4 ARID方法方法 ATAM基本介绍 nATAM方法能够反映一个软件体系结构满足某些 特定质量目标的程度，同时还能够给出这些质 量目标相互之间的交互方式。 nATAM方法也可对遗留系统进行分析，提高对系 统质量属性的理解。 nATAM方法基本过程（4组） 介绍、调查和分析、测试、报告 ATAM方法步骤 1、ATAM方法介绍 2、商业动机的介绍 3、软件体系结构介绍 4、确定软件体系结构方法 5、产生质量属性效果树 6、分析软件体系结构方法 7、集体讨论并确定场景的优先级 8、再次分析软件体系结构方法 9、展示结果 步骤1、ATAM方法介绍 n评估负责人给召集在一起的利益相关人员介绍 ATAM方法。 nATAM方法中步骤的简要介绍。 n介绍评估中使用的获取和分析技术，包括效果 树的生成、基于软件体系结构方法的获取和分 析以及场景的集中讨论和优先级划分。 n介绍评估的结果，比如已经划分优先级的场景 、用于理解和评估软件体系结构的问题、一组 指定的软件体系结构方法、一组敏感点和折中 点等。 步骤2、商业动机的介绍 n项目决策者（最好是项目经理或系统关键客户 ）会从商业的角度来介绍系统的概况 。 n系统最重要的功能；任何技术、管理、经济或 政治方面的相关约束；与项目相关的商业目标 和上下文；主要的利益相关人员；软件体系结 构的驱动因素，即形成软件体系结构的主要质 量属性目标。 步骤3、软件体系结构介绍 n首席设计师会以恰当的详细程度来介绍软件体 系结构 软件体系结构相关文档的详细程度，可用的 时间，行为和质量需求的实质 n软件体系结构视图是设计师用于展示软件体系 结构的主要工具 功能、并发、代码和物理视图 步骤4、确定软件体系结构方法 n评估团队会得到软件体系结构方法，但并不会 对其进行分析，评估团队将要求设计人员为任 何使用的软件体系结构方法命名，也将确定任 何她们在上一个步骤中听到的软件体系结构方 法。 n这些软件体系结构方法定义了系统的关键结构 ，描述了系统的成长方式、应对变化的方式、 抵抗攻击的方式、与其它系统集成的方式等等 。 步骤5、产生质量属性效果树 n评估团队与项目决策者（软件体系结构团队、 项目经理和客户）一起工作，来确定系统最重 要的质量属性目标，并对它们进行优先级划分 和精化。 交易吞吐量 性能 可用性 可变性 数据延迟 硬件失败 (M,L) 把客户数据库的存储延迟最小化 到200毫秒 (H,M) 实时地提供视频 效果 安全性 新添加产品种类 修改COTS (L,H) 在少于20人-月的代价下加入 CORBA 中间件 (H,L) 在少于4人-周的代价下修改Web用 户界面 (L,H) 由于站点1的动力故障而需要 把请求转到站点3的时间要低于3秒 (M,M) 磁盘失败后重新启动的时间 要低于5分钟 (H,M) 用于监测并恢复网络失败的时间要 少于1.5分钟 数据完整性 数据保密性 (L,H) 信用卡和事务在99.999%的时间内 是安全的 (L,H) 用户数据局的授权在99.999% 的时 间内是安全的 (M,M) 最大化授权服务器的平均吞吐量 COTS软件失败 步骤6、分析软件体系结构方法 n评估团队可以调查实现重要质量属性的软件体 系结构方法，这可以通过查看软件体系结构决 策并且找出它们的风险决策、无风险决策、敏 感点和折中点来完成。 n这个步骤的输出包括： 与每个最高优先级的效果树场景相关的软件 体系结构方法或决策； 每个软件体系结构方法相关的分析问题； 设计人员对于问题的回答； 所确定的风险决策、无风险决策、敏感点和 折中点。 步骤7、集体讨论并确定场景的优先级 n了解主要的利益相关群体 n集体讨论3种类型的场景 用例场景，代表利益相关人员所期望的系统 使用方式； 成长场景，代表软件体系结构处理成长和变 化的方式； 探索场景，代表成长的极限形式，包括新的 性能或可用性需求、架构的主要改变或系统 的任务等等。 步骤8、再次分析软件体系结构方法 n评估团队会进行与步骤6中相同的活动，把新生 成的最高级别的场景对应到还没有发现的软件 体系结构元素上。 n如果步骤7并没有产生任何在之前的分析过程没 有被发现的高优先级场景，那么步骤8就是测试 活动，其目标就是尽量完整地发现信息。 步骤9、展示结果 n方法结果中应该包括以下元素 已具备文档的软件体系结构方法 场景集合以及它们的优先级划分 基于属性的问题集合 效果树 发现的风险决策 已具备文档的无风险决策 发现的敏感点和折中点 四个阶段 n阶段1（步骤1-3）：评估团队在这个阶段被创建，同时评 估组织与需要评估软件体系结构的组织建立合作伙伴关系 。 n阶段2（步骤4-6）：这个阶段以软件体系结构为中心，着 重于获取软件体系结构信息并且对其进行分析。 n阶段3 （步骤7-8） ：这个阶段以利益相关人员为中心， 着重于获得利益相关人员的观点然后验证第一个阶段的结 果。 n阶段（步骤9） ：在这个阶段中产生最终的报告，计划接 下来的动作，然后评估组织更新其业绩记录和经验基础。 内容内容 9.19.1软件体系结构评估简介软件体系结构评估简介 9.2 ATAM9.2 ATAM方法方法 9.3 SAAM9.3 SAAM方法方法 9.4 ARID9.4 ARID方法方法 SAAM基本介绍 n第一个具备文档说明并且广泛传播的软件体系结构分析 方法 n方法假设 实践人员会定期地对他们的软件体系结构有所声明 nSAAM方法的输入 一组场景 nSAAM方法的输出 代表系统未来变化的场景到软件体系结构的对应，软 件体系结构中潜在的复杂度高的区域，同时还有对每 个变化工作量的估计； 系统功能的理解，或者不同软件体系结构功能数量的 比较。 SAAM方法步骤 步骤1、场景的形成 n场景应该能够说明系统必须支持的活动类型， 同时还必须说明客户参与者将给系统带来的变 化类型。 n通过集体讨论的方式来获取场景。 n场景的获取和收集往往需要重复多次，形成场 景和软件体系结构描述的过程是相关的，同时 也是迭代的。 步骤2、描述软件体系结构 n候选的软件体系结构描述必须使用软件体系结 构分析中各个成员能够理解的概念，这些软件 体系结构描述除了包括相关连接子，还包括系 统的计算构件和数据构件。 n场景的形成和软件体系结构描述通常相互促进 软件体系结构描述的缺乏将强制性地要求利 益相关人员考虑针对当前软件体系结构专门 特征的场景。 场景反映了软件体系结构的需求，从而必须 在软件体系结构描述中实现。 步骤3、场景的分类和优先级划分 n直接场景 场景的进行不需要修改软件体系结构。 通过展示现有的软件体系结构在执行此场景 时的行为来决定。 n间接场景 场景没有被直接支持，但存在一些可表示的 软件体系结构的变化来支持场景 步骤4、间接场景的单独评估 n设计人员能够描述应该如何修改软件体系结构 来适应间接场景。 n列出为了支持间接场景对软件体系结构必须做 的修改，然后还要估计修改的代价。 步骤5、评估场景交互 n当多个间接场景需要修改软件体系结构的某个 构件时，它们就被认为在此构件中进行交互。 场景交互揭示了产品设计中的功能分配 。 场景交互能够暴露出软件体系结构文档的不 够详细，没有达到结构分解的要求。 步骤6、形成总体评估 n根据每个场景对于系统成功的相对重要程度， 每个场景会被赋予一个权重，这个权重常常也 与场景支持的商业目标相关。 n权值的决定是一个主观的过程，需要所有的利 益相关人员通过讨论甚至辩论来决定。 n如果比较多个软件体系结构，每个支持的直接 场景的数量也会影响评估，因为直接场景意味 着无需修改系统就能够支持某个用户任务。 内容内容 9.19.1软件体系结构评估简介软件体系结构评估简介 9.2 ATAM9.2 ATAM方法方法 9.3 SAAM9.3 SAAM方法方法 9.4 ARID9.4 ARID方法方法 ARID基本介绍 nATAM