第五章 软件体系结构评估.pdf

LOGO 软件体系结构概念篇软件体系结构概念篇软件体系结构概念篇软件体系结构概念篇 高占建高占建 gaozhanjian 2013年年11月月25日星期一日星期一 第五章 软件体系结构评估 ATAM 体系结构评估体系结构评估的结果的结果 体系结构评估体系结构评估的时机的时机 体系结构评估方式体系结构评估方式 体系结构评估概述体系结构评估概述 1 2 3 4 5 2 软件体系结构概念篇 体系结构评估概述 体系结构评估的目的体系结构评估的目的 软件系统的基础是它的体系结构 软件体系结构将影响系统很多质量属性 在软件体系结构确定下来以后 软件系统的这些属性就是可预见的 大型复杂软件系统在开发过程中所关注的主要问题之一就是质量 在软件系统的早 期设计阶段 选择合适的体系结构对系统的许多重要质量属性 比如 效率 可维护 性 可复用性 可移植性等起着决定性的影响 软件体系结构分析与评估的目的 就是为了在开发过程的早期 通过分析系统的质 量需求是否在软件体系结构中得到体现 识别软件体系结构设计中的潜在风险 预测 系统质量属性 并辅助软件体系结构决策的制定 2013年年11月月25日星期一日星期一3软件体系结构概念篇 体系结构评估概述 评估过程涉及的主要术语评估过程涉及的主要术语 质量属性 Quality Attributes 质量属性是一个组件或一个系统的非功能性特征 标准ISO IEC 9126 1定义了一个软件质量模型 这个模型共有六种特征 功能性 可 靠性 可用性 有效性 可维护性和可移植性 并且它们被分成子特征 根据各个软 件系统外部的可见特征来定义这些属性 2013年年11月月25日星期一日星期一4软件体系结构概念篇 体系结构评估概述 评估过程涉及的主要术语评估过程涉及的主要术语 敏感点 sensitivity point 和权衡点 tradeoff point 敏感点是一个或多个构件 和 或构件之间的关系 的特性 研究敏感点可使设计人 员或分析员明确在搞清楚如何实现质量目标时应注意什么 权衡点是影响多个质量属性的特性 是多个质量属性的敏感点 例如 改变加密级别可能会对安全性和性能产生非常重要的影响 提高加密级别可以 提高安全性 但可能要耗费更多的处理时间 影响系统性能 如果某个机密消息的处 理有严格的时间延迟要求 则加密级别可能就会成为一个权衡点 2013年年11月月25日星期一日星期一5软件体系结构概念篇 体系结构评估概述 评估过程涉及的主要术语评估过程涉及的主要术语 场景 scenarios 在进行体系结构评估时 一般首先要精确地得出具体的质量目标 并以之作为判定该 体系结构优劣的标准 我们把为得出这些目标而采用的机制叫做场景 场景是从风险承担者的角度对与系统的交互的简短描述 在体系结构评估中 一般采 用刺激 stimulus 环境 environment 和响应 response 三方面来对场景进行 描述 2013年年11月月25日星期一日星期一6软件体系结构概念篇 体系结构评估概述 评估过程涉及的主要术语评估过程涉及的主要术语 场景 scenarios 刺激是场景中解释或描述风险承担者怎样引发与系统的交互部分 例如 用户可能会激发某个功能 维护人员可能会做某个更改 测试人员可能会执行某种测试等 这些 都属于对场景的刺激 环境描述的是刺激发生时的情况 例如 当前系统处于什么状态 有什么特殊的约束条件 系统的负载是否很大 某个网络通道是否出现 了阻塞等 响应是指系统是如何通过体系结构对刺激做出反应的 例如 用户所要求的功能是否得到满足 维护人员的修改是否成功 测试人员的测试是否成功等 2013年年11月月25日星期一日星期一7软件体系结构概念篇 体系结构评估概述 体系结构评估的参与者体系结构评估的参与者 评估小组 组织评估并对评估结果进行分析 组成人员通常为评估小组负责人 评估 负责人 场景书记员 进展书记员 计时员 过程观察员 过程监督者 提问者 风险承担者 Stakeholders 在该体系结构及根据该体系结构开发的系统中有既得 利益的人 系统的体系结构涉及到很多人的利益 这些人都对体系结构施加各种影响 以保证自己的目标能够实现 2013年年11月月25日星期一日星期一8软件体系结构概念篇 体系结构评估方式 三种评估方式比较三种评估方式比较 20 世纪90 年代以来 软件体系结构的评估技术一直是研究的热点问题 软件体系结 构的评估技术不断出现 一些方法已经比较成熟并得到了应用和验证 基于调查问卷或检查表的评估方式 基于场景的评估方式 基于度量的评估方式 2013年年11月月25日星期一日星期一9软件体系结构概念篇 体系结构评估方式 基于调查问卷或检查表的评估方式基于调查问卷或检查表的评估方式 CMU SEI的软件风险评估过程采用了这一方式 调查问卷是一系列可以应用到各种体系结构评估的相关问题 其中有些问题可能涉及 到体系结构的设计决策 有些问题涉及到体系结构的文档 有的问题针对体系结构描 述本身的细节问题 检查表中包含一系列比调查问卷更细节和具体的问题 它们更趋向于考察某些关心的 质量属性 2013年年11月月25日星期一日星期一10软件体系结构概念篇 体系结构评估方式 基于调查问卷或检查表的评估方式基于调查问卷或检查表的评估方式 这一评估方式比较自由灵活 可评估多种质量属性 也可以在软件体系结构设计的多个阶 段进行 但是由于评估的结果很大程度上来自评估人员的主观推断 因此不同的评估人员可能 会产生不同甚至截然相反的结果 而且评估人员对领域的熟悉程度 是否具有丰富的 相关经验也成为评估结果是否正确的重要因素 尽管这一评估方式相对比较主观 但由于系统相关人员的经验和知识是评估软件体系 结构的重要信息来源 因而它仍然是进行软件体系结构评估的重要途径之一 2013年年11月月25日星期一日星期一11软件体系结构概念篇 体系结构评估方式 基于场景的评估方式基于场景的评估方式 场景是一系列有序地使用或修改系统的步骤 基于场景的方式由SEI首先提出并应用在体系结构权衡分析方法 Architecture Tradeoff Analysis Method ATAM 软件体系结构分析方法 Software Architecture Analysis Method SAAM 和设计中间产品积极评审方法ARID 这一评估方式分析软件体系结构对场景也就是对系统的使用或修改活动的支持程度 从而判断该体系结构对这一场景所代表的质量需求的满足程度 这一评估方式涉及到的基本活动 包括确定应用领域的功能和软件体系结构的结构之 间的映射 设计用于体现待评估质量属性的场景以及分析软件体系结构对场景的支持 程度 2013年年11月月25日星期一日星期一12软件体系结构概念篇 体系结构评估方式 基于度量的评估方式基于度量的评估方式 度量是指为软件产品的某一属性所赋予的数值 如代码行数 方法调用层数 构件个数等 近年来也出现了一些针对高层设计的度量 软件体系结构度量即是其中之一 基于度量的评估方式 赫尔辛基大学提出的基于模式挖掘的面向对象软件体系结构度量技术 Karlskrona和Ronneby提出的基于面向对象度量的软件体系结构可维护性评估 西弗吉尼亚大学提出的软件体系结构度量方法等都在这方面进行了探索 提出了一些 可操作的具体方案 2013年年11月月25日星期一日星期一13软件体系结构概念篇 体系结构评估方式 基于度量的评估方式基于度量的评估方式 基于度量的评估技术涉及三个基本活动 首先需要建立质量属性和度量之间的映射原则 即确定怎样从度量结果推出系统具有 什么样的质量属性 然后从软件体系结构文档中获取度量信息 最后根据映射原则分析推导出系统的某些质量属性 基于度量的评估方式提供更为客观和量化的质量评估 这一评估方式需要在软件体系结构的设计基本完成以后才能进行 而且需要评估人员 对待评估的体系结构十分了解 否则不能获取准确的度量 2013年年11月月25日星期一日星期一14软件体系结构概念篇 体系结构评估的时机 体系结构评估的时机体系结构评估的时机 迭代或增量生命周期模型 最近一次开发周期中 通用情况下 SA设计周期的任何阶 段 早期 SA确定之前 可以评估已有部分 也可以在若干项中选择 例如 发现评审 discovery review 目的在于发现重要的系统需求 以及初步的解决方案 中期 SA确定之后 具体实现之前 后期 SA已经确定 并且实现已完成 适用于评估遗产系统 目的在于理解遗产系 统的体系结构 以及能否满足要求的系统属性 有一条很好的实践原则 应该在开发小组开始制定依赖于体系结构的决策时 修改这些决策的代价超过体系 结构的评估的代价时 2013年年11月月25日星期一日星期一15软件体系结构概念篇 体系结构评估的结果 体系结构评估体系结构评估的结果的结果 体系结构评估的结果是一份报告 其形式和内容会随所用方法的不同而不同 但它能 够使我们找到如下两类问题的答案 该体系结构是否与所要开发的系统相适应 根据体系结构开发出来的系统能够满足其质量要求 即系统将会满足预期的性能要求 安全性要求 功能需求等 可以利用现有的资源实现系统的开发 这些资源包括人力 资金 旧的软件 如果有 和所规定的系统交付的时间 针对所要开发的系统 在备选的两个或多个体系结构中 哪一个是最合适的 2013年年11月月25日星期一日星期一16软件体系结构概念篇 体系结构评估的结果 体系结构评估体系结构评估的结果的结果 体系结构评估的结果是一份报告 其形式和内容会随所用方法的不同而不同 大多数 体系结构评估方法都可以得出如下结果 划分了优先级的质量属性需求 获取作为评估依据的质量属性需求是体系结构评估中的一项重要工作 任何一个构架都不可能满足很多的质量属性需求 所以这些评估方法都使用某种广泛认同的优先级排列 方法与质量属性的映射 对所分析问题的解答可以得出一种映射 这种映射表明了如何用体系结构方法实现 或不能实现 所期望的质量属 性 这种映射构成了体系结构的基本机理 有风险决策和无风险决策 有风险决策是那些可能带来问题的架构决策 无风险决策是指依赖于经常含在体系结构中的假设好的决策 2013年年11月月25日星期一日星期一17软件体系结构概念篇 ATAM ATAM Architecture Tradeoff Analysis Method 体系结构权衡分析方法 What is the Purpose of the ATAM The Purpose of ATAM is to assess the consequences of architectural decisions in light of quality attribute requirements 目的是从质量属性需求的角度评价体系结构决策的结果 The Purpose of ATAM is not to provide precise analyses the purpose is to discover risks created by architectural decisions 目的不是提供精确分析 而是发现体系结构决策带来的风险 2013年年11月月25日星期一日星期一18软件体系结构概念篇 ATAM ATAM process The ATAM processes is a short facilitated interaction between multiple stakeholders leading to the identification of risks sensitivities and tradeoffs ATAM过程是利益相关者之间交流的一个方便 快捷的手段 便于发现风险 敏感点 和权衡 2013年年11月月25日星期一日星期一19软件体系结构概念篇 ATAM ATAM Steps and Their Associated Stakeholders 2013年年11月月25日星期一日星期一20软件体系结构概念篇 ATAM Step 1 Present the ATAM ATAM方法的陈述 评估负责人 评估负责人向利益相关者介绍ATAM方法 在这一步 要对每个人解释参与的过程 并留出解答疑问的时间 明确其他工作的环境和预期 ATAM评估步骤简介 用于获取信息和分析的技术 效用树的生成 基于体系结构方法的获取和分析 对 场景的集体讨论及优先级的划分 评估的结果 所得出的场景及其优先级 用以理解和评估体系结构的问题 描述体 系结构的需求并给出其优先级的效用树 所确定出的一组体系结构方法 所发现的有 风险决策 无风险决策 敏感点和权衡等 2013年年11月月25日星期一日星期一21软件体系结构概念篇 ATAM Step 2 Present Business Drivers 商业动机的陈述 项目经理 项目决策者从商业角度 向相关人员介绍系统概况 系统最重要的功能 技术 管理 经济 政治方面的限制 商业目标和上下文 主要的利益相关者 体系结构的驱动因素 即促使形成该体系结构的主要质量属性目标 2013年年11月月25日星期一日星期一22软件体系结构概念篇 ATAM Step 3 Present Architecture 体系结构的陈述 架构师 架构师在适合的细节层次上描述体系结构 这是一个重要步骤 因为 大量的有效和 已归档的体系结构信息将直接影响可能的分析及分析的质量 技术限制 例如要求使用的操作系统 硬件 中间件等 该系统必须要与之交互的其他系统 用以满足质量属性需求的体系结构方法 architectural approaches 2013年年11月月25日星期一日星期一23软件体系结构概念篇 ATAM Step 4 Identify Architectural Approaches 确定体系结构方法 架构师 分析团队 架构师确定体系结构方法 分析团队捕获它们 但此时不进行不分析 确定体系结构方法和体系结构风格 它们代表了所评估的体系结构用以处理高优先级 的质量属性的手段 也就是 以一种可预见的方式确保满足的关键需求的手段 体系结构方法定义了系统的重要结构 描述了系统演化 对更改的响应 对攻击的防 范以及与其他系统集成的方式等 2013年年11月月25日星期一日星期一24软件体系结构概念篇 ATAM Step 5 Generate Quality Attribute Utility Tree 生成质量属性效用树 utility tree 架构团队 管理者 客户代表 共同确定出该系统的最重要的质量属性目标 并设置优先级 进行进一步的细化 这 一关键步骤对以后的分析起着重要作用 这是通过构建效用树实现的 效用树生成的结果是对具体质量属性需求 以场景形式 出现 的优先级的确定 这个优先级列表为后续其他ATAM步骤提供指导 它告诉ATAM团队应该在哪些方面 花些 相对有限的 时间 特别是应该在哪些地方探测 probe 架构方法和伴随的 风险决策 敏感点和权衡 2013年年11月月25日星期一日星期一25软件体系结构概念篇 ATAM Step 5 Generate Quality Attribute Utility Tree 效用树使质量属性需求具体化 从而迫使评估团队和客户更为精确地定义质量需求 2013年年11月月25日星期一日星期一26软件体系结构概念篇 ATAM Step 6 Analyze Architectural Approaches 分析体系结构方法 评估团队 架构团队 最高优先级的质量属性需求 第5步 和采用的体系结构方法 第4步 这一步 对 每一个效用树生成的高级别的场景 架构师应该确认构件 连接件 配置和有关的约 束 评估团队和架构团队解答与每一个体系结构方法相联系的一系列特定方法和特定质 量属性的问题 这些问题可能来源于体系结构风格的经验记录 体系结构的书籍或利益相关者的经验等 实践中 我们挖掘所有这 些方面的问题 这一步结束 形成了整个体系结构的最重要方面的一个粗线条画面 设计决策的理 由 和一个风险 敏感点和权衡点的列表 2013年年11月月25日星期一日星期一27软件体系结构概念篇 ATAM Step 7 Brainstorm and Prioritize Scenarios 集体讨论并确定场景优先级 所有利益相关者 利益相关者对两个场景进行集体讨论 用例场景 use case scenarios 描述利益相关者对系统使用情况的期望 在用例 场景中 利益相关者是最终用户 它们使用所评估系统来完成一些功能 变化场景 change scenarios 成长场景 Growth scenarios 描述期望体系结构在中短期内 可容纳的成长和变化的方式 预期的修改 在性 能或可用性方面的变化 移植到其他平台 与其他软件集成等 探索场景 exploratory scenarios 描述成长的极端情况 即体系结构可能受到变化的压力的方式 性能或可用性需 求的大幅度变化 基础设施或系统任务的重大变化等 一旦确定了若干个场景后 就必须对他们设置优先级 利益相关者投票的方式 通 常由一