第四周理解质量属性演示文稿

第四周理解质量属性演示文稿当前1页，总共62页。第四周理解质量属性ppt课件当前2页，总共62页。提纲质量属性概述系统的质量属性实践中的质量属性场景

3.1可用性

3.2可修改性

3.3性能

3.4安全性

3.5可测试性

3.5易用性商业质量属性构架的质量属性当前3页，总共62页。1质量属性概述构架设计要解决的4个问题精确的描述质量属性需求列举用于获取得到质量属性需求的构架决策将一种质量属性需求与相关构架决策相联系的方法将相关的构架决策变为设计的方法当前4页，总共62页。1.1质量属性高于性能我们经常设计系统并不是因为该系统在功能上有缺陷，而是由于系统的维护，移植或扩展十分困难，系统运行速度太慢，系统容易受到外界攻击实际上，我们修改系统是因为需要改进系统的质量，而这些质量是高于系统的功能性当前5页，总共62页。1.1.1如何评判一个系统的好坏我们开发一个系统是为了给用户使用，因此系统的质量好坏最终要由用户来评判评判的依据：系统是否能够满足客户的功能需求（直接）系统是否能够满足一定的质量需求（间接）比如： 我们做一个远程数据库管理系统，功能完全实现，但是每次用户访问需要等待1分钟才能得到结果，用户能够满意吗？当前6页，总共62页。1.1.2功能相同品质不同的产品品质决定了产品的价值当前7页，总共62页。1.2功能性和质量属性的关系功能性（functionality）是指系统能够完成所期望的工作的能力质量（Quality）——组件、系统或过程满足指定需求或用户/客户需求及期望的程度质量属性（qualityattributes）是影响质量的相关因素，是对质量的描述当前8页，总共62页。1.2.1软件质量的描述为了更好地理解影响软件质量的因素，人们定义了质量属性，然后构建了与软件质量相关的质量模型

可移植性可复用性互连性产品修改产品转移正确性可靠性效率易用性完整性可维护性可测试性灵活性产品运行图3-18McCall质量模型当前9页，总共62页。1.2.2功能性和质量属性是正交的功能性和质量属性是正交的关系功能性可以通过任何一个结构来实现，功能性与结构无关为了要实现不同的质量属性，软件构架将限制系统的分解结构，比如A-7E的例子当前10页，总共62页。1.3构架和质量属性的关系构架是实现质量需求的软件创建中的第一阶段，软件构架确定了该构架对特定质量属性的支持，比如实时性，安全性等构架和质量属性的关系：对我们关心的许多系统质量属性的实现而言，构架具有重要意义对一个构架而言，往往只支持某些质量属性构架并不能独立实现质量属性，它为质量属性的实现提供了基础，但不是全部当前11页，总共62页。1.3.1构架和质量属性关系举例我们必须从设计、实现到部署的整个过程中考虑质量属性的实现易用性（Usability）涉及到构架和非构架两个方面可修改性（Modifiability）由划分功能的方式（构架）和模块中的编码技巧及注释（非构架）两方面决定系统的性能（Performance）既受到构架的影响又受到具体算法的影响分析质量属性可以使我们分离关注点当前12页，总共62页。2.系统的质量属性从70年代开始，很多软件团体就开始关注系统的质量属性，但以前的讨论中存在三个问题：为质量属性提供的定义是不可操作的，也就是没有一个具体客观的评判方法往往只关注于一个特定的方面属于哪个质量属性(仅关注分类)，比如系统故障属于可用性、安全性还是易用性每个软件团体都有自己的用于质量属性的词汇，这样同一个事物被赋予不同的表达，不便于涉众之间的交流当前13页，总共62页。2.1质量属性场景质量属性场景（scenarios）是描述质量属性的手段，是一种面向特定的质量属性的需求质量属性场景在质量属性需求规范中的作用与用例在功能需求规范中所扮演的脚色相同当前14页，总共62页。2.2如何描述质量属性场景如何描述质量属性场景呢？用户的角度 质量是指满足用户需求的程度，那么用户关心的是响应度量的问题2.开发者的角度

开发者要找到影响软件响应度量的因素，包括什么引发软件响应，软件的什么部分在什么条件下做出如何的响应等当前15页，总共62页。2.2.1质量属性场景组成（上）质量属性场景由以下6个部分组成：刺激源（Sourceofstimulus）：生成刺激的实体（人、计算机或其他）刺激（Stimulus）：当刺激源产生的刺激达到系统后需要考虑的条件，引起系统发生反应的条件环境（Environment）：刺激到达时系统的状态（状态图），或指刺激在系统的某些条件内发生当前16页，总共62页。2.2.2质量属性场景组成（下）制品（Artifact）：被刺激的部分，可能是整个系统，也可能是其中的一部分响应（Response）：刺激到达后系统所采取的措施响应度量（Responsemeasure）：当响应发生时，我们以某种方式对其进行度量，便于我们对需求进行测试当前17页，总共62页。2.2.3质量属性场景的图形表达质量属性场景的6个部分刺激源刺激制品响应响应度量环境荨蔴疼痛手正常状态缩手在0.1s内完成缩手当前18页，总共62页。2.3一般的和具体的质量属性场景一般质量属性场景是指那些独立于系统，很可能适合任何系统的场景，其具有可选参数具体质量属性场景是指适合正在考虑的某个特定系统的场景，是一般质量属性场景的一个特例我们可以把具体场景的集合用于描述系统的质量属性需求当前19页，总共62页。2.4生成质量属性场景特定系统场景的生成 对于每个属性，我们都提供一张场景表，该表对质量属性场景中的每一部分都给出了可能的独立于系统的值。通过为每个元素选择一个值来生成一般的质量属性场景；通过从该表的每一列选择一个或多个条目，然后使结果变得可读来生成具体场景当前20页，总共62页。2.4.1一般场景生成表场景部分可能的值刺激源系统内部、外部刺激错误：疏忽、崩溃、时间、响应制品系统的处理器、通信通道、持久性存储器、进程环境正常、降级模式响应系统检测到事件，进行以下活动之一记录故障，通知用户或系统；根据已定义的规则禁止故障源等响应度量系统修复时间，系统可以在降级模式下运行的时间间隔等当前21页，总共62页。2.4.2质量属性场景的关系质量属性、质量属性场景和系统的关系通用系统质量属性可修改性性能安全性…一般质量属性场景……特定系统质量属性抽取特定系统组合……当前22页，总共62页。3.实践中的质量属性场景一般场景提供了一个生成大量一般的、独立于系统地、特定于质量属性的场景框架这里主要讨论6个质量属性及其一般场景可用性（Availability）可修改性（Modifiability）性能（Performance）安全性（Security）可测试性（Testability）易用性（Usability）当前23页，总共62页。3.1可用性（Availability）可用性与系统故障及其相关后果有关。当系统不再提供其规范中所说明的服务时，就出现了系统故障系统错误与故障不同，系统错误对用户而言不可见，当系统错误被用户看见就变成了故障比如，计算人体的心率 if(HR<30||HR>250) ///计算出错 {

return(Last_HR); ///屏蔽错误，未出现故障 }当前24页，总共62页。3.1.1可用性关注的问题如何检测故障发生故障的频度出现故障时的现象系统故障排除的时限如何防止故障的发生发生故障时的处理当前25页，总共62页。3.1.2可用性的表示故障修复时间：从出现故障到用户看不到故障的时间系统的可用性表示：可以使用系统正常运行的时间比例来表示

平均正常工作时间 a=

（平均正常工作时间+平均修复时间）根据这个公式我们可以得出一个百分比，从而定量地表示可用性，我们可以说99%的可用性，或者表示为1%的故障率当前26页，总共62页。3.1.3可用性的分级级别系统类型可用性不可用时间(分/年)1无管理的90.%50,0002管理的99.%5,0003管理好的99.9%5004容错的99.99%505高可用性的99.999%56非常高可用性的99.9999%0.57超高可用性的99.99999%0.05不可用性=平均修复时间(MTTR)/平均故障间隔时间(MTBF)当前27页，总共62页。3.1.4可用性相关的术语疏忽（Omission）：组件未能对某个输入做出响应崩溃（Crash）：组件不断遭受疏忽的错误时间（Timing）：组件做出了响应，但做出响应的时间错误响应（Response）：组件用一个不正确的值做出了响应当前28页，总共62页。3.1.5可用性的一般场景生成场景部分可能的值刺激源系统内部、外部刺激错误：疏忽、崩溃、时间、响应制品系统的处理器、通信通道、持久性存储器、进程环境正常、降级模式响应系统检测到事件，进行以下活动之一记录故障，通知用户或系统；根据已定义的规则禁止故障源等响应度量系统修复时间，系统可以在降级模式下运行的时间间隔等当前29页，总共62页。3.1.6可用性的一般场景图形可用性的一般场景刺激源：刺激：制品：响应：响应度量：环境：内部、外部（错误）忽略、崩溃、时间、响应进程、存储、处理器、通信正常、降级操作记录、通知、禁止、继续（正常/降级）或不可用修复时间、可用性、可获得/降级的时间间隔当前30页，总共62页。3.1.7可用性的特定质量属性场景在正常操作期间，进程收到一个未曾预料到的消息，该进程通知操作人员后继续操作，没有停机刺激源：刺激：制品：响应：响应度量：环境：系统外部未曾预料到的消息进程正常操作通知操作人员，继续操作没有停机当前31页，总共62页。3.2可修改性（Modifiability）任何一个系统都是可修改的，简单的修改可用通过系统配置在几分钟内完成，复杂的修改可能需要重做系统已满足新的需要，我们如何来评价一个系统的可修改性能？可修改性是关于变更的成本问题当前32页，总共62页。3.2.1可修改性关注的问题可以修改什么？ 如修改系统功能、系统运行的平台和环境、系统容量、质量属性等何时进行变更以及由谁进行变更？

修改时间包括设计时修改（源代码）、编译时修改（编译条件），部署时修改（系统配置）等

修改人员可以是开发人员、用户或系统管理员等当前33页，总共62页。3.2.2可修改性的一般质量属性场景场景部分可能的值刺激源开发人员、系统管理员、最终用户刺激希望修改功能，质量属性或系统容量制品系统用户界面、系统运行平台、环境或与目标系统交互的系统环境设计时、构建时、编译时、运行时响应查找构架中需要修改的位置，进行修改且不会影响其他功能，对所做的修改进行测试；部署所做的修改响应度量根据所影响的元素的数量的成本、资金；该修改对其他功能的影响当前34页，总共62页。3.2.3可修改性场景举例场景样例：开发人员在程序中增加数据积分处理功能，对源代码进行修改，要求在一周内完成修改并做测试，而且修改行为不会产生副作用刺激源：刺激：制品：响应：响应度量：环境：开发人员希望增加积分处理源代码设计时修改不产生副作用在1周内完成当前35页，总共62页。3.3性能（Performance）性能与事件发生时，将要耗费系统多长时间做出响应有关影响性能的因素包括：事件源的数量和到达模式到达系统的事件包括：周期性事件、随机事件或偶然事件当前36页，总共62页。3.3.1性能的术语等待时间：刺激达到和系统对其做出响应之间的时间处理期限：最长等待时间系统吞吐量：系统单位时间处理事务的次数响应抖动：等待时间的变化缺失率：由于系统太忙因而无法做出响应所导致的未处理事件的数量数据丢失：因为系统太忙所丢失的数据当前37页，总共62页。3.3.2性能的一般质量属性场景场景部分可能的值刺激源大量独立源中的一个，可能来自系统内部刺激定期、随机或偶然事件到达制品系统环境正常模式；超载模式响应处理刺激；改变服务级别响应度量等待时间、时间期限、吞吐量、抖动、缺失率、数据丢失当前38页，总共62页。3.3.3性能的场景样例场景样例：一个Web金融服务系统的性能场景样例，要求平均等待2秒钟完成一次交易刺激源：刺激：制品：响应：响应度量：环境：用户启动交易系统在正常操作下交易被处理平均等待时间为2秒当前39页，总共62页。3.4安全性（Security）安全性是衡量系统在向合法用户提供服务的同时，阻止非授权使用的能力安全性就是要阻止以下三类攻击的发生未经授权试图访问数据或服务未经允许试图修改数据试图使系统拒绝向合法用户提供服务当前40页，总共62页。3.4.1安全性系统安全性系统被刻画为一个提供如下属性的系统：认可——交易不能被交易的任何一方拒绝机密性——未经授权不能访问数据或服务完整性——根据计划来提交数据或服务保证——交易各方是所声称的人可用性——系统可用于合法用途审核——在系统内部跟踪系统活动当前41页，总共62页。3.4.2安全性一般质量属项场景场景部分可能的值刺激源授权或非授权用户；访问了有限的资源/大量资源刺激试图修改数据，访问系统服务制品系统服务、系统中的数据环境在线或离线、直接或通过防火墙入网响应对用户验证，阻止或允许访问数据或服务响应度量避开安全措施所需要的时间或资源；恢复数据/服务当前42页，总共62页。3.4.3安全性场景样例场景样例：计算机病毒阻止系统提供的网络连接服务，通过杀毒软件进行清除刺激源：刺激：制品：响应：响应度量：环境：计算机病毒阻止客户联网系统中的服务在正常操作下通过杀毒软件清除病毒在1分钟内清除病毒当前43页，总共62页。3.5可测试性（Testability）可测试性是指通过测试揭示软件缺陷的容易程度特别地，可测试性是指假设软件中至少有一个错误，软件在下次测试运行时不能正常工作的可能性如果要对系统进行正确的测试，那么必须能够“控制”每个组件的内部状态及其输入，然后“观察”其输出当前44页，总共62页。3.5.1可测试性的相关因素测试可以由开发人员、测试人员、验证人员或用户进行可以对代码、设计以及整个系统进行测试可测试性的响应度量处理是测试在发现缺陷方面的效率，以及要想达到某个期望的覆盖范围需要用多长时间进行测试当前45页，总共62页。3.5.2可测试性一般质量属性场景场景部分可能的值刺激源单元开发人员、系统集成人员、系统验证人员、测试人员、用户刺激已完成的一个阶段，如分析、构架、 类和子系统的集成，所交付的系统制品设计、代码段、完整的应用环境设计时、开发时、编译时、部署时响应可以控制系统执行所期望的测试响应度量已执行的可执行语句的百分比；最长测试链的长度，执行测试的时间，准备测试环境的时间当前46页，总共62页。3.5.3可测试性场景样例场景样例：单元测试人员在一个已完成系统组件上执行单元测试刺激源：刺激：制品：响应：响应度量：环境：单元测试人员执行单元测试系统中的组件在组件完成时组件具有控制行为的接口并且组件的输出是可观察的在3小时内测试了85%的路径当前47页，总共62页。3.6易用性（Usability）易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持种类比如：是否提供撤销、重做功能当前48页，总共62页。3.6.1易用性的内容易用性包括以下几方面内容：学习系统的特性有效地使用系统，提高用户操作效率将错误的影响降到最低使系统适应用户的需要提高用户自信和满意度当前49页，总共62页。3.6.2易用性一般质量属性场景场景部分可能的值刺激源最终用户刺激想要学习系统特性、有效使用系统、使错误的影响最低，适配系统制品系统环境在运行时或配置时响应上下文相关的帮助系统；数据和/或命令的集合，导航；撤销、取消操作，从系统故障中恢复；定制能力，国际化；显示系统状态响应度量任务时间，错误数量，用户满意度、用户知识的获得，成功操作的比例等当前50页，总共62页。3.6.3易用性场景样例场景样例：想把错误的影响降到最低的用户希望在运行时可以取消系统操作刺激源：刺激：制品：响应：响应度量：环境：用户使错误的影响最低系统运行时希望取消当前操作取消在1秒钟内完成当前51页，总共62页。3.7其他系统质量属性除了上面提到的六种质量属性之外，系统还存在着其他质量属性可扩充性 包括功能可扩充或容量可扩充，该属性可归纳到可修改性中互操作性 比如学习系统、游戏系统等对于其他质量属性，我们可以自己定义其源、刺激、环境、制品、响应和响应度量当前52页，总共62页。4.商业质量属性除了系统的质量属性之外，很多商业质量目标往往也会对系统的构架产生较大的影响商业目标也可以通过场景进行具体化当前53页，总共62页。4.1我们所关心的商业目标上