第四周_理解质量属.ppt

第四章理解构架质量属性 QualityAttributes 任课老师 黄武 提纲 质量属性概述系统的质量属性实践中的质量属性场景3 1可用性3 2可修改性3 3性能3 4安全性3 5可测试性3 5易用性商业质量属性构架的质量属性 1质量属性概述 构架设计要解决的4个问题精确的描述质量属性需求列举用于获取得到质量属性需求的构架决策将一种质量属性需求与相关构架决策相联系的方法将相关的构架决策变为设计的方法 1 1质量属性高于性能 我们经常设计系统并不是因为该系统在功能上有缺陷 而是由于系统的维护 移植或扩展十分困难 系统运行速度太慢 系统容易受到外界攻击实际上 我们修改系统是因为需要改进系统的质量 而这些质量是高于系统的功能性 1 1 1如何评判一个系统的好坏 我们开发一个系统是为了给用户使用 因此系统的质量好坏最终要由用户来评判评判的依据 系统是否能够满足客户的功能需求 直接 系统是否能够满足一定的质量需求 间接 比如 我们做一个远程数据库管理系统 功能完全实现 但是每次用户访问需要等待1分钟才能得到结果 用户能够满意吗 1 1 2功能相同品质不同的产品 品质决定了产品的价值 1 2功能性和质量属性的关系 功能性 functionality 是指系统能够完成所期望的工作的能力质量 Quality 组件 系统或过程满足指定需求或用户 客户需求及期望的程度质量属性 qualityattributes 是影响质量的相关因素 是对质量的描述 1 2 1软件质量的描述 为了更好地理解影响软件质量的因素 人们定义了质量属性 然后构建了与软件质量相关的质量模型 图3 18McCall质量模型 1 2 2功能性和质量属性是正交的 功能性和质量属性是正交的关系功能性可以通过任何一个结构来实现 功能性与结构无关为了要实现不同的质量属性 软件构架将限制系统的分解结构 比如A 7E的例子 1 3构架和质量属性的关系 构架是实现质量需求的软件创建中的第一阶段 软件构架确定了该构架对特定质量属性的支持 比如实时性 安全性等构架和质量属性的关系 对我们关心的许多系统质量属性的实现而言 构架具有重要意义对一个构架而言 往往只支持某些质量属性构架并不能独立实现质量属性 它为质量属性的实现提供了基础 但不是全部 1 3 1构架和质量属性关系举例 我们必须从设计 实现到部署的整个过程中考虑质量属性的实现易用性 Usability 涉及到构架和非构架两个方面可修改性 Modifiability 由划分功能的方式 构架 和模块中的编码技巧及注释 非构架 两方面决定系统的性能 Performance 既受到构架的影响又受到具体算法的影响分析质量属性可以使我们分离关注点 2 系统的质量属性 从70年代开始 很多软件团体就开始关注系统的质量属性 但以前的讨论中存在三个问题 为质量属性提供的定义是不可操作的 也就是没有一个具体客观的评判方法往往只关注于一个特定的方面属于哪个质量属性 仅关注分类 比如系统故障属于可用性 安全性还是易用性每个软件团体都有自己的用于质量属性的词汇 这样同一个事物被赋予不同的表达 不便于涉众之间的交流 2 1质量属性场景 质量属性场景 scenarios 是描述质量属性的手段 是一种面向特定的质量属性的需求质量属性场景在质量属性需求规范中的作用与用例在功能需求规范中所扮演的脚色相同 2 2如何描述质量属性场景 如何描述质量属性场景呢 用户的角度质量是指满足用户需求的程度 那么用户关心的是响应度量的问题2 开发者的角度开发者要找到影响软件响应度量的因素 包括什么引发软件响应 软件的什么部分在什么条件下做出如何的响应等 2 2 1质量属性场景组成 上 质量属性场景由以下6个部分组成 刺激源 Sourceofstimulus 生成刺激的实体 人 计算机或其他 刺激 Stimulus 当刺激源产生的刺激达到系统后需要考虑的条件 引起系统发生反应的条件环境 Environment 刺激到达时系统的状态 状态图 或指刺激在系统的某些条件内发生 2 2 2质量属性场景组成 下 制品 Artifact 被刺激的部分 可能是整个系统 也可能是其中的一部分响应 Response 刺激到达后系统所采取的措施响应度量 Responsemeasure 当响应发生时 我们以某种方式对其进行度量 便于我们对需求进行测试 2 2 3质量属性场景的图形表达 质量属性场景的6个部分 2 3一般的和具体的质量属性场景 一般质量属性场景是指那些独立于系统 很可能适合任何系统的场景 其具有可选参数具体质量属性场景是指适合正在考虑的某个特定系统的场景 是一般质量属性场景的一个特例我们可以把具体场景的集合用于描述系统的质量属性需求 2 4生成质量属性场景 特定系统场景的生成对于每个属性 我们都提供一张场景表 该表对质量属性场景中的每一部分都给出了可能的独立于系统的值 通过为每个元素选择一个值来生成一般的质量属性场景 通过从该表的每一列选择一个或多个条目 然后使结果变得可读来生成具体场景 2 4 1一般场景生成表 2 4 2质量属性场景的关系 质量属性 质量属性场景和系统的关系 3 实践中的质量属性场景 一般场景提供了一个生成大量一般的 独立于系统地 特定于质量属性的场景框架这里主要讨论6个质量属性及其一般场景可用性 Availability 可修改性 Modifiability 性能 Performance 安全性 Security 可测试性 Testability 易用性 Usability 3 1可用性 Availability 可用性与系统故障及其相关后果有关 当系统不再提供其规范中所说明的服务时 就出现了系统故障系统错误与故障不同 系统错误对用户而言不可见 当系统错误被用户看见就变成了故障比如 计算人体的心率if HR250 计算出错 return Last HR 屏蔽错误 未出现故障 3 1 1可用性关注的问题 如何检测故障发生故障的频度出现故障时的现象系统故障排除的时限如何防止故障的发生发生故障时的处理 3 1 2可用性的表示 故障修复时间 从出现故障到用户看不到故障的时间系统的可用性表示 可以使用系统正常运行的时间比例来表示平均正常工作时间a 平均正常工作时间 平均修复时间 根据这个公式我们可以得出一个百分比 从而定量地表示可用性 我们可以说99 的可用性 或者表示为1 的故障率 3 1 3可用性的分级 不可用性 平均修复时间 MTTR 平均故障间隔时间 MTBF 3 1 4可用性相关的术语 疏忽 Omission 组件未能对某个输入做出响应崩溃 Crash 组件不断遭受疏忽的错误时间 Timing 组件做出了响应 但做出响应的时间错误响应 Response 组件用一个不正确的值做出了响应 3 1 5可用性的一般场景生成 3 1 6可用性的一般场景图形 可用性的一般场景 3 1 7可用性的特定质量属性场景 在正常操作期间 进程收到一个未曾预料到的消息 该进程通知操作人员后继续操作 没有停机 3 2可修改性 Modifiability 任何一个系统都是可修改的 简单的修改可用通过系统配置在几分钟内完成 复杂的修改可能需要重做系统已满足新的需要 我们如何来评价一个系统的可修改性能 可修改性是关于变更的成本问题 3 2 1可修改性关注的问题 可以修改什么 如修改系统功能 系统运行的平台和环境 系统容量 质量属性等何时进行变更以及由谁进行变更 修改时间包括设计时修改 源代码 编译时修改 编译条件 部署时修改 系统配置 等修改人员可以是开发人员 用户或系统管理员等 3 2 2可修改性的一般质量属性场景 3 2 3可修改性场景举例 场景样例 开发人员在程序中增加数据积分处理功能 对源代码进行修改 要求在一周内完成修改并做测试 而且修改行为不会产生副作用 3 3性能 Performance 性能与事件发生时 将要耗费系统多长时间做出响应有关影响性能的因素包括 事件源的数量和到达模式到达系统的事件包括 周期性事件 随机事件或偶然事件 3 3 1性能的术语 等待时间 刺激达到和系统对其做出响应之间的时间处理期限 最长等待时间系统吞吐量 系统单位时间处理事务的次数响应抖动 等待时间的变化缺失率 由于系统太忙因而无法做出响应所导致的未处理事件的数量数据丢失 因为系统太忙所丢失的数据 3 3 2性能的一般质量属性场景 3 3 3性能的场景样例 场景样例 一个Web金融服务系统的性能场景样例 要求平均等待2秒钟完成一次交易 3 4安全性 Security 安全性是衡量系统在向合法用户提供服务的同时 阻止非授权使用的能力安全性就是要阻止以下三类攻击的发生未经授权试图访问数据或服务未经允许试图修改数据试图使系统拒绝向合法用户提供服务 3 4 1安全性系统 安全性系统被刻画为一个提供如下属性的系统 认可 交易不能被交易的任何一方拒绝机密性 未经授权不能访问数据或服务完整性 根据计划来提交数据或服务保证 交易各方是所声称的人可用性 系统可用于合法用途审核 在系统内部跟踪系统活动 3 4 2安全性一般质量属项场景 3 4 3安全性场景样例 场景样例 计算机病毒阻止系统提供的网络连接服务 通过杀毒软件进行清除 3 5可测试性 Testability 可测试性是指通过测试揭示软件缺陷的容易程度特别地 可测试性是指假设软件中至少有一个错误 软件在下次测试运行时不能正常工作的可能性如果要对系统进行正确的测试 那么必须能够 控制 每个组件的内部状态及其输入 然后 观察 其输出 3 5 1可测试性的相关因素 测试可以由开发人员 测试人员 验证人员或用户进行可以对代码 设计以及整个系统进行测试可测试性的响应度量处理是测试在发现缺陷方面的效率 以及要想达到某个期望的覆盖范围需要用多长时间进行测试 3 5 2可测试性一般质量属性场景 3 5 3可测试性场景样例 场景样例 单元测试人员在一个已完成系统组件上执行单元测试 3 6易用性 Usability 易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持种类比如 是否提供撤销 重做功能 3 6 1易用性的内容 易用性包括以下几方面内容 学习系统的特性有效地使用系统 提高用户操作效率将错误的影响降到最低使系统适应用户的需要提高用户自信和满意度 3 6 2易用性一般质量属性场景 3 6 3易用性场景样例 场景样例 想把错误的影响降到最低的用户希望在运行时可以取消系统操作 3 7其他系统质量属性 除了上面提到的六种质量属性之外 系统还存在着其他质量属性可扩充性包括功能可扩充或容量可扩充 该属性可归纳到可修改性中互操作性比如学习系统 游戏系统等对于其他质量属性 我们可以自己定义其源 刺激 环境 制品 响应和响应度量 4 商业质量属性 除了系统的质量属性之外 很多商业质量目标往往也会对系统的构架产生较大的影响商业目标也可以通过场景进行具体化 4 1我们所关心的商业目标 上市时间成本和收益所希望的系统生命期的长短目标市场 通用市场还是专用市场推出计划与老系统的集成 4 1 1上市时间 如果存在较大的竞争压力 则开发时间长短就成为一个重要的商业决策因素开发商在开发中通过购买或重用现有元素来缩短上市时间 4 1 1 1商业质量属性场景样例 上市时间场景样例 4 1 2成本与效益 不同构架会具有不同的开发成本比如 实现一个灵活性很高的构建通常需要更好的成本开发组织需要根据预算来设计构架 4 1 3所希望系统生命期的长短 如果需要系统生命期很长 则可修改性 可扩充性和可移植性就变得非常重要 但这会影响到系统的上市时间另一方面 可修改性 可扩展的产品可能在市场上存在较长时间 4 1 4目标市场 目标市场性质的影响针对通用软件 系统所运行的平台及其特性集将决定潜在市场的大小 可移植性和功能性就成为占有市场多大份额的关键而对于较大的专业市场 则应该考虑产品线策略 4 1 5推出计划 如果产品作为一个基本功能集推出 以后将会发布很多特性 则构架的灵活性和可定制性就非常重要 4 1 6与老系统的集成 如果新开发的系统必须与现有系统集成 则一定要定义合适的继承方法 应该在构架上保证接口的一致性 5 构架的质量属性 构架的质量属性包括 概念完整性在各个层次上