《软件质量属性》PPT课件.ppt

质量属性Quality Attribute1主要内容n一、质量属性场景n二、理解质量属性n三、实现质量属性的战术n四、设计架构2质量属性的定义nA quality attribute(QA)is a measurable or testable property of a system that is used to indicate how well the system satisfies the needs of its stakeholders.l质量属性是一个系统的可测量或可测试的属性，它被用来描述系统满足利益相关者需求的程度n本章任务l怎样描述质量属性l怎样达成质量属性l怎样应用质量属性（在架构决策时）3系统的架构、功能和质量属性n软件开发时人们往往关注功能l实情：导致软件系统修改的主因不是功能，而是系统难以维护、扩展、被黑客破坏等。n系统的功能不能决定系统的架构n质量是系统的属性，而功能是系统的目标4构架和质量属性之间的关系n质量属性不完全依赖于设计、实现和部署l易用性涉及构架和非构架两方面的问题-系统能否为用户提供取消操作？这一类属于构架层次的问题-什么样的布局最直观?什么样的字体最清晰?这属于详细设计的部分，不属于构架设计。l可修改性：-划分功能的方式这属于架构层次的问题-模块中的编码技巧非架构层次问题l系统性能：-组件间通讯数量、分配给每个组件的功能、资源共享的方式，等，这些都属于架构层次的问题-实现某功能采用的算法、如何编码这些算法，等，都会影响系统性能，但属于非构架层次的问题。5构架和质量属性之间的关系n构架不能独自实现质量属性l构架为质量属性的实现打下了基础，但不关注实现细节的话，这个基础就失去了意义。n复杂系统中，不能孤立地实现质量属性l例如，为了可靠性，增加冗余处理器和进程，保证不会因单点故障使系统崩溃。但这样对安全性不利，系统会有更多的地方可能会遭到入侵6质量属性的来源：3类需求n1.Functional requirements lThese requirements are satisfied by including an appropriate set of responsibilities within the design.n2.Quality attribute requirements lThese requirements are satisfied by the structures and behaviors of the architecture.n3.Constraints：a design decision thats already been made.lsatisfied by accepting the design decision and reconciling it with other affected design decisions.7描述质量属性需求的6个部分n刺激stimulusl是到达系统的事件eventn刺激源stimulus sourcel生成刺激的实体（计算机、人-可信或不可信）n响应responsel刺激到达后采取的反应n响应度量response measurel对响应效果进行度量n环境:l刺激发生时的各种条件n制品：l可能是系统，或系统的一部分核核心心8用如下方式描述质量属性场景刺激源刺激源刺激刺激环境环境响应响应响应度量响应度量制品制品9质量属性的一般场景10可用性场景的一个例子外部外部系统系统未曾未曾预料预料的消的消息息正常正常操作操作进程进程通知操通知操作员继作员继续操作续操作没有停机没有停机11可修改性场景的一个例子开发开发人员人员希望希望改变改变用户用户界面界面设计时设计时代码代码修改不修改不产生副产生副作用作用3小时内小时内12一、质量属性场景13我们通常考虑如下质量属性n系统质量属性l可用性Availabilityl可修改性l性能l安全性l可测试性l易用性n其他如商业属性（上市时间）、概念属性等，在本课程中不讨论14可用性AvailabilitynAvailability refers to the ability of a system to mask or repair faults such that the cumulative service outage period does not exceed a required value over a specified time intervaln可用性，通常关注如下方面：l系统故障发生的频度、出现故障时会发生什么情况（会出人命吗）、允许系统非正常运行多久、如何防止故障发生、发生故障时通知给哪里，等n区分故障failure错误error过错、责任faultl故障产生的原因即过错责任lFault和failure之间的状态，称之为errorl如果不进行纠正，错误会变成故障l用户可以观察到故障、但看不到错误15可用性Availabilityn通常，将可用性定义为l 平均正常工作时间平均正常工作时间（MTBFMTBF）l平均正常工作时间平均正常工作时间(MTBF)(MTBF)+平均修复时间平均修复时间(MTTR)(MTTR)l不计算正常停机时间不计算正常停机时间lwhere MTBF refers to the mean time between failures and where MTBF refers to the mean time between failures and lMTTR refers to the mean time to repair.MTTR refers to the mean time to repair.=16Hazard analysis：is a technique that attempts to catalog the hazards that can occur during the operation of a system.nCatastrophic灾难性lThis kind of failure may cause a crash.This failure represents the loss of critical function required to safely fly and land aircraft.nHazardous有危险lThis kind of failure has a large negative impact on safety or performance,or reduces the ability of the crew to operate the aircraft due to physical distress or a higher workload,or causes serious or fatal injuries among the passengers.nMajor显著lThis kind of failure is significant,but has a lesser impact than a Hazardous failure(for example,leads to passenger discomfort rather than injuries)or significantly increases crew workload to the point where safety is affected.nMinor 不显著lThis kind of failure is noticeable,but has a lesser impact than a Major failure(for example,causing passenger inconvenience or a routine flight plan change).nNo effect 无影响lThis kind of failure has no impact on safety,aircraft operation,or crew workload.17A simple fault tree18Availability General Scenario19可用性的战术20Detect Faults错误检测-1nPing/echol节点间的异步“请求/回应”信息。检测可达性和往返延迟nMonitorl一个用来监视系统其他部分的组件nHeartbeatl监测者和被监测者之间交换的周期性信息nTime stampnSanity checking健全性检查l某项操作或输出的合理性nCondition monitoringnVoting(TMR)nReplication:防止硬件错误，但避免不了逻辑错误nFunctional redundancy功能性冗余l防止设计或实施时的错误l接收相同的输入，要给出相同的输出。但其内部实现要用不同的方法Detect Faults错误检测-2nAnalytic redundancyl不仅限于组件的私有部分的多样性，而且在输入和输出方面也实现多样性。nException detectionlSystem exceptions：被0除、总线地址失效等lParameter fence：防止对象的参数被覆盖lParameter typing 参数限制ltimeout22Recover from FaultsnActive redundancy(hot spare热备份)nPassive redundancy(warm spare暖备份)nSpare(cold spare冷备份)nException handlingnRollbacknSoftware upgradenRetrynIgnore faulty behaviornDegradationnReconfigurationnShadownState resynchronizationnEscalating restartl逐步重启nNon-stop forwarding(NSF)l直通23Prevent FaultsnRemoval from servicenTransactions事务lAtomic,Consistent,Isolated,and DurablenPredictive modelnException preventionnIncrease competence set 扩充能力集合lis the set of states in which it is“competent”to operate.24A Design Checklist for Availability-125A Design Checklist for Availability-226A Design Checklist for Availability-327A Design Checklist for Availability-428互操作性InteroperabilitynInteroperability is about the degree to which two or more systems can usefully exchange meaningful information via interfaces in a particular context.29互操作性一般场景30一个互操作性示例31互操作性战术32Checklist to Support the Design and Analysis Process for Interoperability33Checklist to Support the Design and Analysis Process for Interoperability-234Checklist to Support the Design and Analysis Process for Interoperability-335可修改性Modifiabilityn什么可以改变？l系统的任何部分：功能、平台、环境、质量、容量n何时修改、由谁来修改？n修改的代价36可修改性一般场景37可修改性场景的一个例子38可修改性战术39性能Performance：An ounce of performance is worth pounds of promises.n性能最相关的即：时间40Sample concrete performance scenario一个具体的性能属性场景41性能属性的战术42A Design Checklist for Performance43A Design Checklist for Performance-244A Design Checklist for Performance-3安全性Security：衡量系统在向合法用户提供服务的同时，阻止非授权使用的能力nconfidentiality,integrity,and availability(CIA)lConfidentiality is the property that data or services are protected from unauthorized accesslIntegrity is the property that data or services are not subject to unauthorized manipulationlAvailability is the property that the system will be available for legitimate use.lAuthentication verifies the identities of the parties to a transaction and checks if they are truly who they claim to belNonrepudiation guarantees that the sender of a message cannot later deny having sent the message,and that the recipient cannot deny having received the messagelAuthorization grants a user the privileges to perform a task46安全性一般场景147安全性一般场景248一个安全性场景实例49安全性战术50安全性设计清单151安全性设计清单252安全性设计清单353可测试性testability：Testing leads to failure,and failure leads to understandingn通过测试揭示软件缺陷的容易程度l在开发设计良好的系统成本中，至少有30-50%用在了测试上。l测试由各种开发人员、测试人员、验证人员、用户进行。l对设计、代码、整个系统进行测试54可测试性的通用场景55一个可测试性的实例56可测试性的战术57可测试性的设计策略清单-158可测试性的设计策略清单-259可测试性的设计策略清单-360易用性Usability：it takes a genius to make something simple.n对用户来说，完成某个期望任务的容易程度和系统所提供的用户支持的种类。l许多易用性问题属于质量属性l系统构建完成后，最难添加的特性，往往属于架构内容l关于什么是架构方面的内容、什么不是，往往基于对问题的表面分析；深入分析会发现：到处都有应该在架构方面考虑的问题。61易用性一般场景62一个易用性场景实例63易用性战术64易用性设计策略65易用性设计策略-2其他质量属性nVariability可变性l特殊的可修改性lIt refers to the ability of a system and its supporting artifacts such as requirements,test plans,and configuration specifications to support the production of a set of variants that differ from each other in a preplanned fashion.l用于软件产品线的维护nPortabilityl易于做改变，用于另外一种平台其他质量属性nDevelopment Distributabilityl支持分布式软件开发nScalabilitylhorizontal scalability-adding more resources to logical unitslvertical scalability-adding more resources to a physical unitnDeployability可部署性nMobilityldeals with the problems of movement and affordances of a platform(大小、显示器类型、输入设备类型、带宽、电池等)68其他质量属性nMonitorabilityldeals with the ability of the operations staff to monitor the system while it is executing.nSafetylSoftware safety is about the softwares ability to avoid entering states that cause or lead to damage,injury,or loss of life to actors in the softwares environment,and to recover and limit the damage when it does enter into bad states69ISO/IEC FCD 25010 product quality standard70三、实现质量属性的战术如果不顾及所有的质量属性，如果不顾及所有的质量属性，每一个好的质量属性都是有害的每一个好的质量属性都是有害的71可用性战术刺激刺激响应响应战术战术返回返回72错误检测n命令/响应：ping/echol一个组件发送ping，期望在预期时间内收到被审查组件的相应n心跳：heartbeatl组件定期发送消息（心跳），如果另一个组件没有收到，则通知纠错组件。l心跳同时还可以传输数据n异常：exceptionsl异常处理的程序n前二者运行在不同进程上，异常处理通常在同一进程上看看图图73错误恢复检测和修复n表决l冗余处理器的每个进程都有相同的输入，它们计算并发送给表决者一个输出值。（如果检测到某个错误，就停止该处理器）l表决规则可以是“多数规则”或“首选组件”等l注意多样性问题冗余组件运行不同算法n主动冗余（热重启）l所有冗余组件都以并行的方式对事件做出反应（仅用其一）l发生错误，就切换到某一个组件l利用可靠传输协议，将传递给任何一个冗余组件的消息，都传递给其他所有组件n被动冗余（暖重启/多重冗余）l由一个组件负责对事件作出相应，并通知其他组件更新状态l出错后，在继续提供服务之前，确保备用状态是最新的l可以经常切换“主组件”，保持新状态n备件l替换各种的出现故障的组件l定期对备件进行备份、设定检查点，出错后重新初始化。l恢复时间可能稍长看看图图74错误恢复重新引入n影子Shadowl以前出现故障的物体，在恢复之前，模仿工作组件的内容n状态再同步l组件重新提供服务之前，需要更新其状态n检查点/回滚l使用上一个一致的检查点，看看图图75错误预防n从服务中删除l执行某些活动，防止预期可能发生的错误l重启，防止内存泄露n事务l将一些有序的步骤绑定为事务，以备需要n进程监视器l利用监视进程检查进程中存在的错误，监视进程可以删除没有在运行的进程。看看图图76可修改性战术返回刺激刺激响应响应战术战术77局部化变更n维持语义一致性l语义，指的是模块内各责任之间的关系l要确保这些责任能够协调一致地工作，而不过多地依赖其他模块l耦合、内聚的程度是度量一致性的一个指标l同时还应该根据是否支持预期的变更，来判断一致性程度n预期可能的变更l在实践中，往往很难预期所有重要的变更（经验）n泛化该模块l使模块能根据输入计算更广泛的功能l可以把输入看作是为该模块定义了一种语言，对其进行解释n限制可能的选择l实际中可选范围往往很大，可能会影响很多模块l例如，处理器的变更，可以限制使用相同家族的成员l正交看看图图78防止连锁反应：一个模块对另一个模块的依赖性，有8种n一、语法l数据：由A产生并由B使用的数据，必须与B所假定的数据类型一致l服务：由A产生并由B使用的服务的特征，必须与B所假定的类型一致n二、语义l数据：由A产生并由B使用的数据的语义，必须与B的假定的一致l服务：由A产生并由B使用的服务的语义，必须与B的假定的一致n三、顺序l数据：要使B正确运行，必须以一个固定的顺序接收A产生的数据l控制：要使B正确运行，A必须在一定时限内执行n四、A的一个接口的身份lA可有多个接口，要使B正确运行，该接口必须与B的假定一致修修改改A会会导导致致修修改改BIntobject1 交交0空空 0交交1 空空大头序大头序 小头序小头序接口接口1输出输出 接口接口2输出输出看看图图79防止连锁反应：一个模块对另一个模块的依赖性，有8种n五、A的位置l要使B正确运行，A运行时的位置必须与B的假定一致-例如，B假定A位于同一处理器的不同进程上n六、A提供的服务/数据的质量l要使B正确运行，A提供的服务/数据的质量必须与B的假定一致n七、A的存在性l要使B正确运行，A必须存在l如果B请求A的服务，A必须存在或能动态地创建n八、A的资源行为l要使B正确运行，A的资源行为必须与B的假定一致修修改改A会会导导致致修修改改B看看图图80防止连锁反应：PREVENT RIPPLE EFFECTSn信息隐藏l信息隐藏，就是把某个实体的责任分解为更小的部分，并选择使哪些信息成为公有的，哪些私有l目的是使变更被隔离在一个模块内n维持现有接口l语法依赖性容易用这种方法屏蔽变更，但语义、质量、资源等的依赖性，很难通过维持接口来屏蔽l创建抽象接口，与具体实现相分离l添加接口：提供最新的服务或数据l添加适配器：给A添加适配器，把A包装起来，提供原始A的信息l提供一个占位程序A：如果变更删除了A，就提供一个占位A，向B提供A的签名，而B不用修改（如果只需要A的签名的话）n限制通信路径l限制与给定模块A贡享数据的模块。即减少两类模块的数量，1，使用由A生产的数据的模块数量。2，给A提供数据的模块的数量看看图图81防止连锁反应：PREVENT RIPPLE EFFECTSn仲裁者的使用：对于非语义型的依赖，可以在A、B间插入一个仲裁者，管理与该依赖相关的活动。仲裁者是：l数据（语法）：存储库充当数据生产和使用者之间的仲裁者。一些库例子：-某些订阅-发布模式，将语法转换为B的语法-MVC和PAC模式把一种形式的数据（输入）转换为另一种形式的数据（抽象组件中的格式）l服务(语法)：-桥、调停者、代理和工厂模式都提供了把服务语法从一种形式转换到另一种形式的仲裁者。防止A的变化扩散到BlA的接口的身份：-可以使用经纪人模式屏蔽一个接口中身份的变化。让经纪人与A的新身份进行连接，B不变lA的位置（运行时）-由A负责在名称注册服务器中，注册其位置，B则检索此位置lA的资源行为-让一个资源管理器来管理A所涉及的资源lA的存在性-工厂模式可以根据需要创建实例，因此，B对A的依赖性由该工厂的操作来满足看看图图82推迟绑定时间：支持部署时（变更）及非开发人员的修改n运行时注册l即插即用。但需要额外的管理注册的开销n配置文件l在开机启动时，根据其设置参数n多态l允许方法调用的后期绑定n组件更换l允许载入时绑定n遵守已定义的协议l允许各个独立进程在运行时绑定看看图图83性能战术返回最近刺激刺激响应响应战术战术84资源需求n提高计算效率l改进关键算法。用一种资源换取另一种资源n减少计算开销l例如删除一些仲裁者n管理事件速率l降低对环境监视的强度n控制采样频率n限制执行时间n限制队列的大小85资源管理n引入并发l不同的线程上处理不同的事件流n维持数据或计算的多个副本（注意一致性）l例：高速缓存。n增加可用资源l提供额外的处理器、内存、速度更快的网络。等。86资源仲裁：对竞争的资源进行调度n常见的调度策略lFIFO：适用于相同优先级l固定优先级调度：可能使低优先级请求等待过多时间。常见优先级策略为：-语义重要性-时限时间：时限短（到期）的请求优先级高-速率单调：对于周期任务，选择周期短的优先级高l动态优先级-轮转-时限优先l静态（脱机）调度-系统执行前，基于被调度任务的时间参数来安排调度-适用具有确定性时间要求的系统，例如空管。87安全性战术刺激刺激响应响应战术战术88抵抗攻击n对用户身份进行验证l确保用户或计算机是它所声称的用户或计算机-密码、数字证书n对用户进行授权l经过身份验证的用户，有什么样的访问权限l访问控制n维护数据的机密性l加密数据，VPN，SSLn维护完整性n限制暴露信息n限制访问l防火墙根据消息源或目的端口，来限制访问北北斗斗89检测攻击n将网络通信模式与数据库中的进行对比l检测攻击的“传感器”l将各传感器进行融合l记录日志l分析工具和控制台90从攻击中恢复n恢复状态（防守性）l维持重要副本数据n识别攻击者（惩罚性）l维持审计追踪91可测试性战术刺激刺激响应响应战术战术92可测试性战术：n管理输入输出l记录/回放：捕获跨接口的信息，将其作为测试专用软件的输入l将接口和实现分离-占位程序可以使得系统剩余部分得到检测l特化访问路线/接口-测试工具独立地捕获某些变量值n内部监视l内置监视器93易用性战术刺激刺激响应响应战术战术94易用性战术n运行时l用户主动：撤销l混合主动：提供进展指示器l系统主动：预测与用户相关的某些信息-维持任务的一个模型-维持用户的一个模型-维持系统的一个模型n设计时l将用户接口（可能频繁改变）与应用的其余部分分离开-支持该战术的架构模式：MVC、PAC。Seeheim、Arch/Slinky95Seeheim简介nSeeheim模型将软件体系结构分为4个部分：核心模块(Functional Core)，核心应用接口(Functional Core Adapter)，对话控制器(Dialogue Contro1ler)，界面构件(Presentation Component)。Function Core对领域应用进行建模。Functional Core Adapter为用户界面与核心应用之间建立一个缓冲区，以减少二者之间的耦合。它通过一些交互协议为用户界面与核心应用之间提供同步或者异步的数据交换。Dialogue Controller是Seeheim模型中的核心部分。它通过界面构件接收来自用户的各种输入请求，通过转换后利用核心应用接口与核心模块进行数据交换，保证多个视图间的一致性，以完成特定的用户任务在Dialogue Contro11er中可以嵌套定义Seeheim子模型。这样可以从不同粒度上对GUI系统进行建模。Presentation Component对界面构件的具体交互动作和输入输出进行设计。96战术与构架模式（风格）的关系n设计师会选择一个精心设计的模式或模式集合，来实现一个或多个战术n根据战术，创建构架模式和策略l选择了战术之后，设计师的任务才开始l任何设计都使用多个战术l对设计师来说，分析过程包括理解在实现中所应用的战术；明智地选择战术组合来实现系统的目标n例：海战-制空：飞机-航母97四、空中交通管制:高可用性设计方案分析98高可用性设计案例分析：空中交通管制（Air Traffic Control）nATC：l对实时性和安全性要求极高l由FAA（联邦航空局）管理客户l从顺利起飞到安全抵达整个过程，飞机都要受ATC某个部分的管理：地面控制部分负责管理飞机在机场地面的运动；控制塔台控制飞机在该终端控制区域空间的飞行；该系统有多个中途中心；n我们要讨论的系统叫ISSS（Initial Sector Suite System）初始区段组系统：对22个中途中心的软硬件进行升级。99从A港到B港的飞行控制示意各中途控制中心管辖101ISSS需求与质量分析n两个最重要的质量属性l极高的可用性：不正常状态只能持续极短时间l高性能：必须在不丢失任何数据的情况下，对大量数据（每中心最大飞机数量2440）进行处理。通信网络必须能处理这种负载，软件必须快速带预测性地进行计算n其他重要属性l开放性l能够提交该系统的子集l能够更改功能、处理软硬件的升级l能够与众多外部系统相接并协同工作l必须满足众多涉众的要求，特别是控制人员的需求。102某区段组的控制台，一个中心可以有多个区段雷达控制员：监视雷达数据，与机组人员联系，保证飞机安全隔离雷达控制员：监视雷达数据，与机组人员联系，保证飞机安全隔离数据控制员：获取每一架飞机的数据（飞行计划等）数据控制员：获取每一架飞机的数据（飞行计划等）ISSS系统的规模n每个中途中心支持210个控制台，每个控制台都有工作站级的CPU：IBM RS/6000n要求每个中心能同时管理400-2440架飞机n每个场站需要16-40台雷达n一个中途中心可能需要60-90个控制位置，每控制位置需要一个或多个控制台nISSS系统要求使用Ada语言（源代码超过100万行）104ISSS系统必须完成如下功能n获取存储在现有ATC系统主计算机(HCS)中的雷达目标数据n转换雷达报告，以供显示，将其广播给所有的控制台。每个控制台选择自己需要的数据，每控制台都能显示任何方位的数据n处理冲突警告（撞机）或其他计算机发来的数据n提供与HCS的接口，用于输入及查询飞行计划n提供网络管理等多方面的监控信息，允许场站管理人员重新配置所安装的系统n提供记录能力，以供事后回放n在控制台提供图形界面。特殊功能（如一定透明性）n当主计算机、主通信网络、主雷达传感器出现故障时，提供后备功能105ISSS的架构解决方案n可用性：一年内停机时间不能超过5分钟，这个质量属性决定了整个架构的决策n下面给出一些主要视图，并说明其战术lISSS的物理视图l模块分解视图l进程视图l客户机服务器视图l分层视图l组件连接器视图106物理视图物理视图n主计算机HCS是中途中心的核心l每个中心有两台主计算机，一台负责常规处理，一台在前者出现故障时接管处理。l主计算机负责对监控数据和飞行计划数据处理n通用控制台Common Consoles是空管人员的工作站。1区段有1-4台控制台n本地通信网LCN是ISSS系统的主要网络。每台主机都通过双LCN接口单元（每一个都叫做LIU-H）与LCN相连nLCN由4个并行的令牌环网组成，以提供冗余能力并平衡总负载l一个把监控数据广播到各个处理器，第2个实现处理器间的点到点通信，第3个把显示数据从通用控制台发送到数据记录部件备用；第4个是备用的108物理视图n增强直接访问雷达信道(EDARC),l提供飞机方位的后备信息，并将飞行数据块信息限定显示在控制台上l使用EDARC是为了防止主机发送的信息丢失。lEDARC实质上提供了原始雷达数据、到ESI（外部系统接口）处理器的接口n后备通信网（BCN）是采用TCP/IP协议的以太网nLCN、BCN都有相应的监控控制台(M&C)n测试与培训子系统提供了在不影响正常操作情况下，对新的软硬件测试以及对用户进行培训的功能n中央处理器采用大型机上的处理器。在ISSS系统的早期版本中用以提供数据存储和回放的功能109模块分解视图nISSS的模块被称为计算机软件配置项(CSCI)。按照美政府软件开发标准定义。每个CSCI都围绕一个中心问题展开l显示管理l通用系统服务：提供实用程序l记录、分析、回放：捕捉会话，事后分析l全国空域系统修改：对驻留主机的软件做相应修改lIBM AIX操作系统n分解视图反映了几个可修改战术l语义一致性：为每个CSCI分配定义良好不重叠的责任l抽象通用服务战术：通用系统服务l记录回放战术：l预期变更、泛化模块、维持接口稳定战术：仔细设计软件的接口110进程视图111进程视图nISSS按多处理器环境设计，处理器在逻辑上组成处理器组。成组的目的是要分别运行一个或多个应用程序的副本，容错、可用性。lPAS：主地址空间lSAS：备用地址空间l一个主地址空间和x相应备用地址空间集合被称为操作单元。操作单元驻留在同一地址处理器组的处理器中l未以这种容错方式实现的ISSS的其它部分，则在不同的处理器上独立运行。称为功能组FGn该视图反应的可用性战术l状态再同步、shadowing、主动冗余、从服务中删除112进程视图n各应用程序之间按C/S模式进行交互n操作单元内PAS将状态变化通知给SASnSAS等待超时，或其他标志PAS、SAS自身失效的消息，以便接替PAS。有以下步骤：l某SAS提升为新PASlPAS重新设定与本操作单元中各客户机的关系，然后通知各客户机，原操作单元故障l启动某个新SAS，替换原来的PASl新SAS向新PAS通告自己的存在，新PAS将状态通知给SAS，使其保持最新l如果SAS内部错误，则在另外的处理器上启动新SAS，新SAS与PAS协调，并接收状态数据113进程视图n如果需要添加新操作单元，采用如下步骤l确定必要的输入数据及所在位置l确定哪些操作单元需要用到新操作单元的数据l以一种避免死锁的方式，将新操作单元的通信加入到整个通信拓扑结构中l设计消息，实现所期望的数据流l确定在评审时必须要用的内部状态数据，以及在从PAS到SAS的更新通信中必须包括的状态数据l将状态数据划分为能够很好地适应网络要求的消息l定义必须用到的消息类型l规划PAS失效时的切换l保证切换时的数据一致性l保证各个处理步骤能够在不超过一次“心跳”的时间内完成l规划与其他操作单元的数据共享和数据锁定协议。114客户机服务器视图：115客户机服务器视图n应用程序以此方式和系统交互，n精心设计了接口，使用简单的消息协议n反映了如下战术l维持接口的稳定性l组件更换l遵守已定义协议116软件架构的分层视图117保证容错的组件-连接器视图118容错nPAS/SAS模式捕获单个应用程序内的错误，并从中恢复。容错层次，则捕获应用程序间交互的错误，并从中恢复。nISSS系统提供了多种不同层次的错误检测和恢复机制。每个层次上都能异步地：l检测自身、同级实体和低层实体的错误l处理来自低层的例外情况l诊断、恢复、报告或提交例外情况119容错n每一层次都要在下层所产生的可用性的基础上进一步提高系统的可用性。层次包括：l物理层l操作系统l运行时环境l应用程序l本地可用性l组可用性l全局可用性l系统监视与控制n在每一层上都要做错误检测和隔离工作n除常规可用性战术外，容错视图还使用了“命令和响应”“心跳”作为检测故障的方法。将错误过滤到适当的地方以进行纠正；过滤到备件上，已进行恢复。120将视图彼此关联起来n一个视图的元素，可能在其他视图中以另一种形式出现n通过分析视图彼此间的关系映射，更深入地了解系统121ATC系统如何实现其质量属性目标目标实现方式实现方式所使用的战术所使用的战术高可用性高可用性硬件冗余（网络、处理器）硬件冗余（网络、处理器）、软件冗余（分层错误检、软件冗余（分层错误检测与恢复）测与恢复）状态再同步、状态再同步、shadowing、主动冗、主动冗余、从服务中删除、限制暴露、命令余、从服务中删除、限制暴露、命令/响应、心跳、异常、备件响应、心跳、异常、备件高性能高性能分布式多处理器、前端可分布式多处理器、前端可调度性分析、