软件体系结构软件体系结构的质量属性.ppt

软件体系结构质量属性 张平健 华南理工大学软件学院 1 relationship of functionality and quality attributes functionality quality 2 功能与体系结构 lfunctionality and quality attributes are orthogonal. lfunctionality may be achieved through the use of any of a number of possible structures. 3 4 三类质量属性三类质量属性 l l 系统的质量属性系统的质量属性 l l 受构架影响的商业属性：例如：上市时间受构架影响的商业属性：例如：上市时间 l l 与构架本身相关的一些质量属性：概念完整性与构架本身相关的一些质量属性：概念完整性 5 质量因素从头考虑质量因素从头考虑 l软件体系结构技术的核心是在系统开发过程中尽 可能早地处理相关质量问题。 6 系统的质量属性系统的质量属性 l可用性 l可修改性 l性能 l安全性 l可测试性 l易用性 通过软件的执行才可见的质量因素 非执行可见的质量因素 7 例子：质量属性的分析例子：质量属性的分析 l中国地球系统科学数据共享网：提供科学数据共享服务的 软件平台，要为科学数据共享提供广泛的技术环境支持。 8 特点：数据来源分散。 l科学数据的采集和获取，是从科学工作者的研究 工作中一点一滴地收集起来的。它们掌握在各个 科研院所、科研人员手中。因此，作为科学数据 共享网的主要服务内容科学数据，可能是分 布在全国各地，甚至还可能来自国外。 9 特点：数据的海量存储 l目前人们掌握的科学数据是经历了数年、数十年 地收集整理而得到的。可以想象，数据量是相当 庞大的；尤其是气象、地震、地学等学科领域的 数据资源，更是巨大。显然，这需要借助海量存 储技术对科学数据资源进行存储和管理。 10 特点：运算量大 l由于数据量的庞大，所以科学数据资源的收集、 搜索方面的运算量是可观的。此外，科学数据共 享网不仅仅提供数据共享的功能，还会提供科学 数据计算等增值服务，这无形中也增加了系统的 运算量。 11 特点：使用人员广泛 l科学数据有其广泛深远的研究价值、社会价值和 经济价值。所以，对科学数据有使用需求的人员 是来自各行各业的，既有科研单位和学者，也有 政府机构和企业单位。 12 需求分析需求分析 l能够快捷地收集数据。科学数据分散在科研院所和科学家 当中。要设计开发一套收集数据的机制，使其能够快速地整 合到系统中，提供数据共享服务。数据收集的途径主要通过 网络媒介，而且不能影响系统所提供的网络服务的正常运行 。 l有效存储和管理海量的数据，并快速定位数据。该系 统能够提供目录服务，合理地管理数据；提供给用户查阅、 下载、使用数据的服务。当用户在系统中查找数据时，希望 能够快速定位数据，提供服务，平均响应时间最长不超过20 秒。 l保护数据版权，保证数据的安全性。科学数据存在着版 权的问题。在数据使用上，需要版权保护。此外，由于一些 数据有其时效性和保密性，所以在提供服务时需要对数据访 问进行相应的安全控制。 13 非功能性需求非功能性需求 质量属性 针对质量属性的需求 可用性/可靠性 系统应能长期稳定地提供服务，近似7 x 24小时时工作强度； 在负载过负载过 重或是系统统崩溃溃的情况下，能保证证用户请户请 求不丢丢失 ； 当系统统出现现故障或崩溃时溃时 ，恢复时间时间 不超过过两小时时； 可维护维护 性 修改某个子系统统或服务时务时 ，不影响其他子系统统或服务务； 性能 高峰时时系统统的平均响应时间应时间 控制在20秒以内； 系统统能够满够满 足100个并发发的用户查询请户查询请 求； 系统统至少能够够支持2000个用户户的在线线服务务； 安全性 对对有保密性要求的数据实实施安全控制； 提供系统统运行日志监监控信息，供管理员员了解系统统运行状态态； 商业业属性 2005年中期完成系统统，年底前投入正式使用； 能够够利用现现有系统统的可利用资资源； 初期总总共投资资2000万，分别别用于系统统的集成建设设和开发发、共享 数据标标准的制定。 14 系统需求的获取系统需求的获取 l一般两种途径： l用户直接主动地提供的需求。主要是一些功能性需 求和领域知识。 l另一条是构架师设计“对话问题”，通过对用户提问， 进一步与他们沟通，从而得到更明确的需求。 （构架师以软件系统各方面的质量属性为索引，系统 地启发用户谈出他们实际需要、 但没有表达出来或 是表达不完全的内容。这些需求虽不是具体的功能 ，但是对系统设计和实现具有巨大的影响） 15 质量属性场景（质量属性场景（quality attribute quality attribute scenarioscenario） 人，计算机系统 或其它激励源 可以是整个系统 ，或系统的一部 分 16 质量属性场景（质量属性场景（quality attribute quality attribute scenarioscenario） l刻画质量属性的手段,6部分组成： l刺激源 l刺激 l环境 l制品 l响应 l响应度量 l以一种统一规范的方式来表达“质量属性”的需求 。 17 18 系统的质量属性系统的质量属性 l可用性 l可修改性 l性能 l安全性 l可测试性 l易用性 19 可用性（可用性（availabilityavailability） l与系统故障及其相关后果有关。 l所关注的方面： l如何检测系统故障 l系统故障发生的频度 l出现故障时会发生什么情况 l允许系统有多长时间非正常运行 l什么时候可以安全地消除故障 l如何防止故障的发生以及发生故障时要求进行哪种通知 20 可用性一般场景可用性一般场景 场景的部分 可能的值 l 源 系统内部，系统外部 l 刺激 缺陷：疏忽未响应、崩溃、时间错误、响应错误 l 制品 系统的处理器、通信通道、持久存储器、进程 l 环境 正常操作、降级模式 l 响应 系统应该检测事件，并进行如下一个或多个活动 l 将其纪录下来； l 通知适当的各方，包括用户和其它系统； l 根据已定义的规则禁止导致错误或故障的事件源； l 在一段预先指定的时间间隔内不可用，其中，时 间间隔取决于系统的关键程度；继续或降级运行。 l 响应度量 系统必须可用的时间间隔 可用时间 系统可在降级模式下运行的时间 修复时间 21 可用性说明可用性说明 这个属性对于一些安全性非常关键的系统是十 分重要的，例如：飞机上的软件，医院使用的系 统等等，如果系统“down”掉，会伤及人或有威胁 生命危险的一些系统。 它是在系统、组件或是应用程序发生故障时快 速恢复基本服务的系统管理策略。其目的是最大 程度地减少服务中断，而不是容错。 22 可用性定义可用性定义 l是系统正常运行的时间比例。一般将系统可用性 定义为： l在计算可用性时，通常不考虑预定的停机时间 l可理解为计算机在任一时刻正常工作的概率。 23 实现可用性的战术实现可用性的战术 l l 战术：战术：设计决策或策略，实现质量属性所采用的 方法或解决方案。 l可用性战术用于以下几方面： 错误检测（ fault detection ） 错误恢复（ fault recovery ） 错误预防（ fault prevention） l可用性战术阻止错误发展成故障；或者把错误的 影响限制在一定范围内，从而使修复成为可能。 24 错误检测错误检测 系统必须能够检测任何潜在的错误,从这些错 误中恢复或在第一时间阻止它们的发生.避免错误 发展成为故障。 l命令/响应 l心跳 l异常 25 命令/响应(ping/echo) l类似于ping命令, 在客户和服务器之间发送一个 packet来判断系统是否正常运行.这个战术一般用 于网络系统。 26 心跳(heartbeat monitor) l类似于“命令/响应”, 所不同的是“心跳”一般用于软 件组件之间。一个组件每隔一定的时间发出一个 心跳消息，另一个组件收听该消息；利用这种方 式告诉收听消息的组件它在正常运转。 27 例子：集群式服务器 28 例子：atm l自动柜员机可以定期向服务器发送上一次交易的 日志。该消息不仅起到了心跳的作用，而且传送 了要处理的数据。 29 异常（exception） l错误类： l疏忽：组件未能对某个输入做出响应 l崩溃：组件不断遭受疏忽的错误 l时间：组件做出了响应，但做出响应的时间太早或太 迟 l响应：组件用了一个不正确的值做出了响应 当识别出了上述错误类中的某一个时，就 会出现异常，异常处理程序通常在引入该异常 的相同进程中执行。例如：java和c+中的异 常处理机制 30 异常（exception） 当出现某些指定的硬件故障或软件错误时， 系统仍能执行规定的一组程序，或者说程序不会 因系统中的故障而中止或被修改，并且执行结果 也不包含系统中故障所引起的差错。 31 错误恢复战术错误恢复战术表决（表决（votingvoting） basic input value 1 2 3 4 1. voter sends out simple value to different processes at same time. 2. each processes does a simple calculation on the input value. 3. the result is sent back to the voter process. 4. if a process result is incorrect (fault), the process may be terminated/restarted. think about voting for your favourite sports star, if one candidate does something bad, you might not vote for him/her! process 1 process 2 process 3 voter 同时也可用于 错误检测 32 表决表决 版本1 版本2 版本n 表 决 器 结果 告警 多数 少数 33 主动冗余（热启动）主动冗余（热启动） active redundancy (hot restart)active redundancy (hot restart) do some action 1 2 3 1. controller requests processes to do an action. 2. each process receives request and works on the action. 3. a response is sent back from each process. if there is a fault, a recovery will be very fast. the controller could send out requests to check if a process is down and expect a receipt to show process up. process 1 process 2 process 3 controller 34 被动冗余被动冗余 ( (暖重起暖重起) ) 1. the main component receives new data. 2. the main component sends old data/state to backup components. 3. if fault happens, decision has to be made to what backup component to switch. main component data backup1 old data backup2 old data new data 1 2 3 35 备件备件 一般用于硬件/操作系统的解决方案 l出现故障时，必须将其重新启动为适当的软件配 置，并对其状态进行初始化，一般用原来组件的 数据和状态。 36 恢复策略恢复策略shadowshadow操作操作 设置出现故障的组件可以在短时间内以 “shadow模式”运行，以确保在恢复该组件之前， 模仿工作组件的行为。 37 恢复策略状态再同步（恢复策略状态再同步（ state state resynchronisationresynchronisation ） restore the new active component to that of the state of the previously active component dependent on downtime/upgrades/patches, etc. 一般用于主动/被动冗余. 38 恢复策略检查点恢复策略检查点/ /回滚（回滚（ checkpoint/rollbackcheckpoint/rollback ） l在执行的程序中设置若干测试点，在每个测试点 上检查输出结果。当测试程序检测出错误时，就 认为正在执行的程序是一个错误运行的系统，这 段程序要被重新执行，即程序的回滚。 39 fault prevention lremoval from service (via reboot, etc) ltransactions lprocess monitor (kill the nonperforming process and create a new instance of it, initialized to some appropriate state as in the spare tactic. ) 40 summary of availability tactics 41 example: availability tactics of an information system lfault detection ping: about every 5 seconds heartbeat: should receive a notice every 5 seconds exception handling lrecovery hot restart/switch: redirect to backup server backup communication path state resynchronization: backup db files, redo log lprevention removal from service: keep only minimal services transaction 42 可修改性（可修改性（ modifiabilitymodifiability ） l有关变更的成本问题，它提出两个关注点： l（1）可以修改什么（制品）？ l（2）何时进行变更以及由谁进行变更（环境）？ 43 可修改性的一般场景生成可修改性的一般场景生成 场景的部分 可能的值 l 源 最终用户，开发人员，系统管理员 l 刺激 希望增加/删除/修改/改变功能、质量属 性、容量 l 制品 系统用户界面、平台、环境或与目标系统 交互的系统 l 环境 在运行时、编译时、构建时、设计时 l 响应 查找构架中需要修改的位置，进行修改且 不会影响其它功能，对所做的修改进行测 试，部署所作的修改 l 响应度量 根据所影响的元素的数量度量的成本、努 力、资金；该修改对其他功能或质量属性 所造成的影响程度 44 可修改性可修改性 局部化修改 防止连锁反应 推迟绑定时 间 45 可修改性战术可修改性战术 l“局部化”修改战术 l“防止连锁反应”战术 l“推迟绑定时间”战术 46 “ “局部化局部化” ”修改战术修改战术 l目标：把变更限制在一定范围内 l在“设计”期间为模块分配责任，以把预期变更限制 在一定范围内。 47 “ “局部化局部化” ”修改战术修改战术 l维持语义的一致性 l预期期望的变更 l泛化该模块 l限制可能的选择 48 维持语义的一致性维持语义的一致性 l指模块中责任之间的关系；目标是确保这些责任 协同工作。责任越单一越好。（java类和方法的 设计原则，unix哲学） l子战术：抽象出通用服务： 例如：visual studio框架；中间件的使用。 49 预期期望的变更预期期望的变更 l考虑所预想变更的集合。 l战术目标是降低变更的影响，由于无法预期所有 的变更，实践中很难单独应用，通常结合语义一 致性来使用。 l例如 虚函数 void* 指针 50 泛化模块 l模块越广泛，需要作的变更越有可能通过调整输 入参数达到，而不用修改模块。 l例如：c+模板库、通用编程概念 51 限制可能的选择 l如果修改的范围非常大，影响很多模块，则限制 能进行的修改，从而降低影响。 l例如，软件产品线限制支持主流平台 52 防止连锁反应的战术防止连锁反应的战术 l l 模块之间的依赖性（模块之间的依赖性（b b依赖于依赖于a a） l（1）语法（数据格式、服务签名） l（2）语义（数据、服务语义） l（3）顺序（数据顺序、时间约束） l（4）a的一个接口的身份 l（5）a的位置 l（6）a提供的数据/服务质量 l（7）a的存在 l（8）a的资源行为 53 防止连锁反应的战术防止连锁反应的战术 l l 信息隐藏：信息隐藏： 将变更隔离在一个模块内，与预期期望的变更有很大的关将变更隔离在一个模块内，与预期期望的变更有很大的关 系。系。 l l 维持现有的接口维持现有的接口 如果如果b b依赖于依赖于a a的一个接口的名字和签名，则维持该接口及的一个接口的名字和签名，则维持该接口及 其语法能够使其语法能够使b b保持不变。保持不变。 54 维持现有的接口维持现有的接口 l添加接口 l添加适配器 lstub程序：如果修改要求删除a,且b依赖于a的签 名，则为a提供一个stub程序可使b保持不变 模块a 适配器 55 防止连锁反应的战术防止连锁反应的战术 l限制通信路径 reduce the number of modules that consume data produced by the given module and the number of modules that produce data consumed by it. l仲裁者的使用：管理依赖关系 data (syntax). repositories (both blackboard and passive) act as intermediaries between the producer and consumer of data to convert data format etc. 56 防止连锁反应的战术防止连锁反应的战术 l仲裁者的使用 service (syntax). the facade, bridge, mediator, strategy, proxy, and factory patterns to convert interface. identity of an interface of a. a broker pattern to hide identity. location of a (runtime). a name server enables the location of a to be changed without affecting b. a resource manager is an intermediary that is responsible for resource allocation. existence of a. the factory pattern has the ability to create instances as needed. 57 推迟绑定时间 l在运行时注册：即插即用 l配置文件：在启动时设置参数 l多态：允许方法调用的后期绑定 l组件更换：允许载入时间绑定 l遵守已定义的协议：允许独立进程的运行时绑定 58 summary of modifiability tactics 59 example: modifiability tactics of dw llocalize changes semantic coherence: modularization anticipated expected changes: interface/inheritance generalize module: use stl abstract common service: cwm, soap, mdx lprevention of ripple effect information hiding: oop use intermediary: design patterns, factory ldefer binding time configuration file adherence to defined protocol: xmla 60 性能（performance） l性能与时间有关。性能与事件发生时，将要耗费 多长时间做出响应有关。 61 性能的一般场景 l刺激源：刺激来自外部（有可能是多个）或内部源 l刺激： 刺激是事件到达。可以把到达模式刻画为周期性 的、随机的或是偶然的。 l制品：总是系统的服务 l环境：系统可以处在各种操作模式下，如正常、紧急或超 载模式 l响应：系统必须处理到达的事件。这可能会导致系统环境 的变化。 l响应度量：响应度量就是系统处理到达的事件所用的时间 （等待时间或必须处理事件的期限）、该时间的变化（抖 动）、在某一特定时间间隔内可以处理的事件数量（吞吐 量）或对不能处理的事件的描述（缺失率、 数据丢失） 。 62 性能战术 three tactic categories lresource demand lresource management lresource arbitration 63 resource demand tactics lincrease computational efficiency (improve algorithm) lreduce computational overhead (pass-by-ref) lmanage event rate (reduce the sampling frequency) lbound execution times (limit the number of iterations ) lbound queue sizes 64 resource management tactics lintroduce concurrency lmaintain multiple copies of either data or computations (client cache) lincrease available resources 65 resource arbitration tactics-scheduling policies lfirst-in/first-out lfixed-priority scheduling (based on semantic importance, deadline monotonic or rate monotonic ) ldynamic priority scheduling (round robin, earliest deadline first ) lstatic scheduling (pre-emption points and the sequence of assignment to the resource are determined offline ) 66 summary of performance tactics 67 example: performance tactics of dw lresource demand increase computation efficiency: new qc algorithm reduce computation overhead: various mappings lresource management introduce concurrency: mpi based multithreading maintain multiple copies: result set cache lresource arbitration scheduling policy: timing + on-demand: fifo 68 安全性（安全性（securitysecurity） l衡量系统向合法用户提供服务的同时，阻止非授 权使用的能力。 69 安全性的一般场景 l刺激源：攻击源可能是人，也可能是另一个系统。正确识别、非正确识 别，可能来自内部/外部；经过了授权/未经授权 l刺激：刺激就是攻击或试图违反违反安全性。未经授权的人或系统试图 显示信息、改变和/或删除信息、访问系统服务或降低系统服务的可用性。 l制品：攻击的目标可能是系统提供的服务，也可能是系统中的数据。 l环境：遇到攻击时有很多种可能的情形：在线或离线；联网或与网络断 开；连接有防火墙或直接连到了网络上。 l响应：对用户进行身份验证；隐藏用户的身份；阻止对数据和/或服务的 访问；允许访问数据和/或服务；授予或收回对访问数据和/或服务的许可； 根据身份记录访问/修改或试图访问/修改数据/服务；以一种不可读的格式存 储数据；识别无法解释的对服务的高需求；通知用户或另外一个系统，并 限制服务的可用性。 l响应度量：用成功的概率表示、避开安全防范措施所需要的时间/努力/ 资源；检测到攻击的可能性、确定攻击或访问/修改数据和/或服务的个人的 可能性；在拒绝服务攻击的情况下仍可以获得的服务的百分比；恢复数据/ 服务；被破坏的数据/服务和/或被拒绝的合法访问的范围 70 攻击 l试图突破安全防线的行为被称为攻击。 l例如 未经授权试图访问数据或服务 试图修改数据 试图使系统拒绝向合法用户提供服务 71 security tactics resisting attacks lgoals: non-repudiation, confidentiality, integrity, and assurance lauthenticate users (ca) lauthorize users (roles) lmaintain data confidentiality (vpn, ssl) lmaintain integrity (checksum) llimit exposure (limited services are available on each host) llimit access (firewalls) 72 security tactics detecting attacks lintrusion system: compare the access pattern to known attacking patterns lrecovering from attacks restoration using availability tactics identifying intruder using audit trail 73 summary of tactics for security 74 example: security tactics of an information system ldetecting attacks intrusion detection: via firewall, watch on db listening port and ftp port lresisting attacks authenticate users: complex enough password for dba authorize users: users cant modify data limit access: black list/white list 75 可测试性（可测试性（testabilitytestability） l通过测试揭示软件缺陷的容易程度 76 可测试性的一般场景 l刺激源：该测试由单元测试人员、集成测试人员、系统测试人 员或客户执行。可由其他开发人员或外部小组执行设 计测试。 刺激： 到达了开发过程中的一个里程碑。 制品： 设计过程、一段代码或整个系统。 环境： 测试可以在设计时、开发时、编译时或部署时进行 响应： 由于可测试性与可观察性和可控制性相关，因此所期望 的响应就是可以控制系统以执行所期望的测试，并可以 观察到对每个测试的响应。 响应度量： 在某些测试中执行的语句的百分比。最长测试链的长度 （对执行测试的困难的度量）以及对发现额外的缺陷的可 能性的估计。 77 testability tactics lrecord/playback (capture input/output info across interface for testing suite) lseparate interface from implementation (test stu