教学课件第四周-理解质量属性.ppt
第四章 理解构架质量属性（Quality Attributes）,任课老师：黄武,提纲,质量属性概述系统的质量属性实践中的质量属性场景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）组件、系统或过程满足指定需求或用户/客户需求及期望的程度质量属性（quality attributes）是影响质量的相关因素，是对质量的描述,1.2.1 软件质量的描述,为了更好地理解影响软件质量的因素，人们定义了质量属性，然后构建了与软件质量相关的质量模型,图3-18 McCall质量模型,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个部分组成：刺激源（Source of stimulus）：生成刺激的实体（人、计算机或其他）刺激（Stimulus）：当刺激源产生的刺激达到系统后需要考虑的条件，引起系统发生反应的条件环境（Environment）：刺激到达时系统的状态（状态图），或指刺激在系统的某些条件内发生,2.2.2 质量属性场景组成（下）,制品（Artifact）：被刺激的部分，可能是整个系统，也可能是其中的一部分响应（Response）：刺激到达后系统所采取的措施响应度量（Response measure）：当响应发生时，我们以某种方式对其进行度量，便于我们对需求进行测试,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.2 成本与效益,不同构架会具有不同的开发成本比如：实现一个灵活性很高的构建通常需要更好的成本开发组织需要根据预算来设计构架,4.1.3 所希望系统生命期的长短,如果需要系统生命期很长，则可修改性，可扩充性和可移植性就变得非常重要，但这会影响到系统的上市时间另一方面，可修改性，可扩展的产品可能在市场上存在较长时间,4.1.4 目标市场,目标市场性质的影响针对通用软件，系统所运行的平台及其特性集将决定潜在市场的大小，可移植性和功能性就成为占有市场多大份额的关键而对于较大的专业市场，则应该考虑产品线策略,4.1.5 推出计划,如果产品作为一个基本功能集推出，以后将会发布很多特性，则构架的灵活性和可定制性就非常重要,4.1.6 与老系统的集成,如果新开发的系统必须与现有系统集成，则一定要定义合适的继承方法，应该在构架上保证接口的一致性,5.构架的质量属性,构架的质量属性包括：概念完整性在各个层次上统一系统设计的根本指导思想。概念完整性指的是，软件系统作为一个整体，对于使用者体现出的概念上的一致性、清晰度和简洁度 正确性和完整性这是构架能够满足系统的各种需求及运行时的资源要求的必要条件,5.1 构架的质量属性,可构建性保证能够由指定的开发小组在规定的时间里及时开发系统，并允许在开发过程中做某些更改，其目的是最大程度地实现并行开发,作业,阐述软件系统功能性和质量属性之间的关系我们在软件开发实践中通常关心系统的哪几种质量属性请写出性能质量属性的一般质量属性场景写出“目标市场，通用市场还是专用市场”这个商业质量属性的一般质量属性场景,
