软件质量属性

1 质量属性QualityAttribute 2 主要内容 一 质量属性场景二 理解质量属性三 实现质量属性的战术四 设计架构 质量属性的定义 Aqualityattribute QA isameasurableortestablepropertyofasystemthatisusedtoindicatehowwellthesystemsatisfiestheneedsofitsstakeholders 质量属性是一个系统的可测量或可测试的属性 它被用来描述系统满足利益相关者需求的程度本章任务怎样描述质量属性怎样达成质量属性怎样应用质量属性 在架构决策时 3 系统的架构 功能和质量属性 软件开发时人们往往关注功能实情 导致软件系统修改的主因不是功能 而是系统难以维护 扩展 被黑客破坏等 系统的功能不能决定系统的架构质量是系统的属性 而功能是系统的目标 4 5 构架和质量属性之间的关系 质量属性不完全依赖于设计 实现和部署易用性涉及构架和非构架两方面的问题系统能否为用户提供取消操作 这一类属于构架层次的问题什么样的布局最直观 什么样的字体最清晰 这属于详细设计的部分 不属于构架设计 可修改性 划分功能的方式 这属于架构层次的问题模块中的编码技巧 非架构层次问题系统性能 组件间通讯数量 分配给每个组件的功能 资源共享的方式 等 这些都属于架构层次的问题实现某功能采用的算法 如何编码这些算法 等 都会影响系统性能 但属于非构架层次的问题 6 构架和质量属性之间的关系 构架不能独自实现质量属性构架为质量属性的实现打下了基础 但不关注实现细节的话 这个基础就失去了意义 复杂系统中 不能孤立地实现质量属性例如 为了可靠性 增加冗余处理器和进程 保证不会因单点故障使系统崩溃 但这样对安全性不利 系统会有更多的地方可能会遭到入侵 质量属性的来源 3类需求 1 FunctionalrequirementsTheserequirementsaresatisfiedbyincludinganappropriatesetofresponsibilitieswithinthedesign 2 QualityattributerequirementsTheserequirementsaresatisfiedbythestructuresandbehaviorsofthearchitecture 3 Constraints adesigndecisionthat salreadybeenmade satisfiedbyacceptingthedesigndecisionandreconcilingitwithotheraffecteddesigndecisions 7 8 描述质量属性需求的6个部分 刺激stimulus是到达系统的事件event刺激源stimulussource生成刺激的实体 计算机 人 可信或不可信 响应response刺激到达后采取的反应响应度量responsemeasure对响应效果进行度量环境 刺激发生时的各种条件制品 可能是系统 或系统的一部分 核心 9 用如下方式描述质量属性场景 刺激源 刺激 环境 响应 响应度量 制品 质量属性的一般场景 10 11 可用性场景的一个例子 外部系统 未曾预料的消息 正常操作 进程 通知操作员继续操作 没有停机 12 可修改性场景的一个例子 开发人员 希望改变用户界面 设计时 代码 修改不产生副作用 3小时内 一 质量属性场景 13 14 我们通常考虑如下质量属性 系统质量属性可用性Availability可修改性性能安全性可测试性易用性其他如商业属性 上市时间 概念属性等 在本课程中不讨论 15 可用性Availability Availabilityreferstotheabilityofasystemtomaskorrepairfaultssuchthatthecumulativeserviceoutageperioddoesnotexceedarequiredvalueoveraspecifiedtimeinterval可用性 通常关注如下方面 系统故障发生的频度 出现故障时会发生什么情况 会出人命吗 允许系统非正常运行多久 如何防止故障发生 发生故障时通知给哪里 等区分故障failure 错误error 过错 责任fault故障产生的原因即过错责任Fault和failure之间的状态 称之为error如果不进行纠正 错误会变成故障用户可以观察到故障 但看不到错误 16 可用性Availability 通常 将可用性定义为平均正常工作时间 MTBF 平均正常工作时间 MTBF 平均修复时间 MTTR 不计算正常停机时间whereMTBFreferstothemeantimebetweenfailuresandMTTRreferstothemeantimetorepair Hazardanalysis isatechniquethatattemptstocatalogthehazardsthatcanoccurduringtheoperationofasystem Catastrophic灾难性Thiskindoffailuremaycauseacrash Thisfailurerepresentsthelossofcriticalfunctionrequiredtosafelyflyandlandaircraft Hazardous有危险Thiskindoffailurehasalargenegativeimpactonsafetyorperformance orreducestheabilityofthecrewtooperatetheaircraftduetophysicaldistressorahigherworkload orcausesseriousorfatalinjuriesamongthepassengers Major显著Thiskindoffailureissignificant buthasalesserimpactthanaHazardousfailure forexample leadstopassengerdiscomfortratherthaninjuries orsignificantlyincreasescrewworkloadtothepointwheresafetyisaffected Minor不显著Thiskindoffailureisnoticeable buthasalesserimpactthanaMajorfailure forexample causingpassengerinconvenienceoraroutineflightplanchange Noeffect无影响Thiskindoffailurehasnoimpactonsafety aircraftoperation orcrewworkload 17 Asimplefaulttree 18 AvailabilityGeneralScenario 19 可用性的战术 20 DetectFaults错误检测 1 Ping echo节点间的异步 请求 回应 信息 检测可达性和往返延迟Monitor一个用来监视系统其他部分的组件Heartbeat监测者和被监测者之间交换的周期性信息TimestampSanitychecking健全性检查某项操作或输出的合理性ConditionmonitoringVoting TMR Replication 防止硬件错误 但避免不了逻辑错误Functionalredundancy功能性冗余防止设计或实施时的错误接收相同的输入 要给出相同的输出 但其内部实现要用不同的方法 DetectFaults错误检测 2 Analyticredundancy不仅限于组件的私有部分的多样性 而且在输入和输出方面也实现多样性 ExceptiondetectionSystemexceptions 被0除 总线地址失效等Parameterfence 防止对象的参数被覆盖Parametertyping参数限制timeout 22 RecoverfromFaults Activeredundancy hotspare热备份 Passiveredundancy warmspare暖备份 Spare coldspare冷备份 ExceptionhandlingRollbackSoftwareupgradeRetryIgnorefaultybehaviorDegradationReconfigurationShadowStateresynchronization Escalatingrestart逐步重启Non stopforwarding NSF 直通 23 PreventFaults RemovalfromserviceTransactions事务Atomic Consistent Isolated andDurablePredictivemodelExceptionpreventionIncreasecompetenceset扩充能力集合isthesetofstatesinwhichitis competent tooperate 24 ADesignChecklistforAvailability 1 25 ADesignChecklistforAvailability 2 26 ADesignChecklistforAvailability 3 27 ADesignChecklistforAvailability 4 28 互操作性Interoperability Interoperabilityisaboutthedegreetowhichtwoormoresystemscanusefullyexchangemeaningfulinformationviainterfacesinaparticularcontext 29 互操作性一般场景 30 一个互操作性示例 31 互操作性战术 32 ChecklisttoSupporttheDesignandAnalysisProcessforInteroperability 33 ChecklisttoSupporttheDesignandAnalysisProcessforInteroperability 2 34 ChecklisttoSupporttheDesignandAnalysisProcessforInteroperability 3 35 36 可修改性Modifiability 什么可以改变 系统的任何部分 功能 平台 环境 质量 容量何时修改 由谁来修改 修改的代价 可修改性一般场景 37 可修改性场景的一个例子 38 可修改性战术 39 40 性能Performance Anounceofperformanceisworthpoundsofpromises 性能最相关的即 时间 Sampleconcreteperformancescenario一个具体的性能属性场景 41 性能属性的战术 42 ADesignChecklistforPerformance 43 44 ADesignChecklistforPerformance 2 ADesignChecklistforPerformance 3 46 安全性Security 衡量系统在向合法用户提供服务的同时 阻止非授权使用的能力 confidentiality integrity andavailability CIA ConfidentialityisthepropertythatdataorservicesareprotectedfromunauthorizedaccessIntegrityisthepropertythatdataorservicesarenotsubjecttounauthorizedmanipulationAvailabilityisthepropertythatthesystemwillbeavailableforlegitimateuse AuthenticationverifiestheidentitiesofthepartiestoatransactionandchecksiftheyaretrulywhotheyclaimtobeNonrepudiationguaranteesthatthesenderofamessagecannotlaterdenyhavingsentthemessage andthattherecipientcannotdenyhavingreceivedthemessageAuthorizationgrantsausertheprivilegestoperformatask 安全性一般场景1 47 安全性一般场景2 48 一个安全性场景实例 49 安全性战术 50 安全性设计清单1 51 安全性设计清单2 52 安全性设计清单3 53 54 可测试性testability Testingleadstofailure andfailureleadstounderstanding 通过测试揭示软件缺陷的容易程度在开发设计良好的系统成本中 至少有30 50 用在了测试上 测试由各种开发人员 测试人员 验证人员 用户进行 对设计 代码 整个系统进行测试 可测试性的通用场景 55 一个可测试性的实例 56 可测试性的战术 57 可测试性的设计策略清单 1 58 可测试性的设计策略清单 2 59 可测试性的设计策略清单 3 60 61 易用性Usability ittakesageniustomakesomethingsimple 对用户来说 完成某个期望任务的容易程度和系统所提供的用户支持的种类 许多易用性问题属于质量属性系统构建完成后 最难添加的特性 往往属于架构内容关于什么是架构方面的内容 什么不是 往往基于对问题的表面分析 深入分析会发现 到处都有应该在架构方面考虑的问题 易用性一般场景 62 一个易用性场景实例 63 易用性战术 64 易用性设计策略 65 易用性设计策略 2 其他质量属性 Variability可变性特殊的可修改性Itreferstotheabilityofasystemanditssupportingartifactssuchasrequirements testplans andconfigurationspecificationstosupporttheproductionofasetofvariantsthatdifferfromeachotherinapreplannedfashion 用于软件产品线的维护Portability易于做改变 用于另外一种平台 其他质量属性 DevelopmentDistributability支持分布式软件开发ScalabilityhorizontalscalabilityaddingmoreresourcestologicalunitsverticalscalabilityaddingmoreresourcestoaphysicalunitDeployability可部署性Mobilitydealswiththeproblemsofmovementandaffordancesofaplatform 大小 显示器类型 输入设备类型 带宽 电池等 68 其他质量属性 Monitorabilitydealswiththeabilityoftheoperationsstafftomonitorthesystemwhileitisexecuting SafetySoftwaresafetyisaboutthesoftware sabilitytoavoidenteringstatesthatcauseorleadtodamage injury orlossoflifetoactorsinthesoftware senvironment andtorecoverandlimitthedamagewhenitdoesenterintobadstates 69 ISO IECFCD25010productqualitystandard 70 71 三 实现质量属性的战术 如果不顾及所有的质量属性 每一个好的质量属性都是有害的 72 可用性战术 刺激 响应 战术 返回 73 错误检测 命令 响应 ping echo一个组件发送ping 期望在预期时间内收到被审查组件的相应心跳 heartbeat组件定期发送消息 心跳 如果另一个组件没有收到 则通知纠错组件 心跳同时还可以传输数据异常 exceptions异常处理的程序前二者运行在不同进程上 异常处理通常在同一进程上 看图 74 错误恢复 检测和修复 表决冗余处理器的每个进程都有相同的输入 它们计算并发送给表决者一个输出值 如果检测到某个错误 就停止该处理器 表决规则可以是 多数规则 或 首选组件 等注意多样性问题 冗余组件运行不同算法主动冗余 热重启 所有冗余组件都以并行的方式对事件做出反应 仅用其一 发生错误 就切换到某一个组件利用可靠传输协议 将传递给任何一个冗余组件的消息 都传递给其他所有组件被动冗余 暖重启 多重冗余 由一个组件负责对事件作出相应 并通知其他组件更新状态出错后 在继续提供服务之前 确保备用状态是最新的可以经常切换 主组件 保持新状态备件替换各种的出现故障的组件定期对备件进行备份 设定检查点 出错后重新初始化 恢复时间可能稍长 看图 75 错误恢复 重新引入 影子Shadow以前出现故障的物体 在恢复之前 模仿工作组件的内容状态再同步组件重新提供服务之前 需要更新其状态检查点 回滚使用上一个一致的检查点 看图 76 错误预防 从服务中删除执行某些活动 防止预期可能发生的错误重启 防止内存泄露事务将一些有序的步骤绑定为事务 以备需要进程监视器利用监视进程检查进程中存在的错误 监视进程可以删除没有在运行的进程 看图 77 可修改性战术 返回 刺激 响应 战术 78 局部化变更 维持语义一致性语义 指的是模块内各责任之间的关系要确保这些责任能够协调一致地工作 而不过多地依赖其他模块耦合 内聚的程度是度量一致性的一个指标同时还应该根据是否支持预期的变更 来判断一致性程度预期可能的变更在实践中 往往很难预期所有重要的变更 经验 泛化该模块使模块能根据输入计算更广泛的功能可以把输入看作是为该模块定义了一种语言 对其进行解释限制可能的选择实际中可选范围往往很大 可能会影响很多模块例如 处理器的变更 可以限制使用相同家族的成员正交 看图 79 防止连锁反应 一个模块对另一个模块的依赖性 有8种 一 语法数据 由A产生并由B使用的数据 必须与B所假定的数据类型一致服务 由A产生并由B使用的服务的特征 必须与B所假定的类型一致二 语义数据 由A产生并由B使用的数据的语义 必须与B的假定的一致服务 由A产生并由B使用的服务的语义 必须与B的假定的一致三 顺序数据 要使B正确运行 必须以一个固定的顺序接收A产生的数据控制 要使B正确运行 A必须在一定时限内执行四 A的一个接口的身份A可有多个接口 要使B正确运行 该接口必须与B的假定一致 修改A会导致修改B Intobject 1交0空0交1空 大头序小头序 接口1输出接口2输出 看图 80 防止连锁反应 一个模块对另一个模块的依赖性 有8种 五 A的位置要使B正确运行 A运行时的位置必须与B的假定一致例如 B假定A位于同一处理器的不同进程上六 A提供的服务 数据的质量要使B正确运行 A提供的服务 数据的质量必须与B的假定一致七 A的存在性要使B正确运行 A必须存在如果B请求A的服务 A必须存在或能动态地创建八 A的资源行为要使B正确运行 A的资源行为必须与B的假定一致 修改A会导致修改B 看图 81 防止连锁反应 PREVENTRIPPLEEFFECTS 信息隐藏信息隐藏 就是把某个实体的责任分解为更小的部分 并选择使哪些信息成为公有的 哪些私有目的是使变更被隔离在一个模块内维持现有接口语法依赖性容易用这种方法屏蔽变更 但语义 质量 资源等的依赖性 很难通过维持接口来屏蔽创建抽象接口 与具体实现相分离添加接口 提供最新的服务或数据添加适配器 给A添加适配器 把A包装起来 提供原始A的信息提供一个占位程序A 如果变更删除了A 就提供一个占位A 向B提供A的签名 而B不用修改 如果只需要A的签名的话 限制通信路径限制与给定模块A贡享数据的模块 即减少两类模块的数量 1 使用由A生产的数据的模块数量 2 给A提供数据的模块的数量 看图 82 防止连锁反应 PREVENTRIPPLEEFFECTS 仲裁者的使用 对于非语义型的依赖 可以在A B间插入一个仲裁者 管理与该依赖相关的活动 仲裁者是 数据 语法 存储库充当数据生产和使用者之间的仲裁者 一些库例子 某些订阅 发布模式 将语法转换为B的语法MVC和PAC模式把一种形式的数据 输入 转换为另一种形式的数据 抽象组件中的格式 服务 语法 桥 调停者 代理和工厂模式都提供了把服务语法从一种形式转换到另一种形式的仲裁者 防止A的变化扩散到BA的接口的身份 可以使用经纪人模式屏蔽一个接口中身份的变化 让经纪人与A的新身份进行连接 B不变A的位置 运行时 由A负责在名称注册服务器中 注册其位置 B则检索此位置A的资源行为让一个资源管理器来管理A所涉及的资源A的存在性工厂模式可以根据需要创建实例 因此 B对A的依赖性由该工厂的操作来满足 看图 83 推迟绑定时间 支持部署时 变更 及非开发人员的修改 运行时注册即插即用 但需要额外的管理注册的开销配置文件在开机启动时 根据其设置参数多态允许方法调用的后期绑定组件更换允许载入时绑定遵守已定义的协议允许各个独立进程在运行时绑定 看图 84 性能战术 返回最近 刺激 响应 战术 85 资源需求 提高计算效率改进关键算法 用一种资源换取另一种资源减少计算开销例如删除一些仲裁者管理事件速率降低对环境监视的强度控制采样频率限制执行时间限制队列的大小 86 资源管理 引入并发不同的线程上处理不同的事件流维持数据或计算的多个副本 注意一致性 例 高速缓存 增加可用资源提供额外的处理器 内存 速度更快的网络 等 87 资源仲裁 对竞争的资源进行调度 常见的调度策略FIFO 适用于相同优先级固定优先级调度 可能使低优先级请求等待过多时间 常见优先级策略为 语义重要性时限时间 时限短 到期 的请求优先级高速率单调 对于周期任务 选择周期短的优先级高动态优先级轮转时限优先静态 脱机 调度系统执行前 基于被调度任务的时间参数来安排调度适用具有确定性时间要求的系统 例如空管 88 安全性战术 刺激 响应 战术 89 抵抗攻击 对用户身份进行验证确保用户或计算机是它所声称的用户或计算机密码 数字证书对用户进行授权经过身份验证的用户 有什么样的访问权限访问控制维护数据的机密性加密数据 VPN SSL维护完整性限制暴露信息限制访问防火墙根据消息源或目的端口 来限制访问 北斗 90 检测攻击 将网络通信模式与数据库中的进行对比检测攻击的 传感器 将各传感器进行融合记录日志分析工具和控制台 91 从攻击中恢复 恢复状态 防守性 维持重要副本数据识别攻击者 惩罚性 维持审计追踪 92 可测试性战术 刺激 响应 战术 93 可测试性战术 管理输入输出记录 回放 捕获跨接口的信息 将其作为测试专用软件的输入将接口和实现分离占位程序可以使得系统剩余部分得到检测特化访问路线 接口测试工具独立地捕获某些变量值内部监视内置监视器 94 易用性战术 刺激 响应 战术 95 易用性战术 运行时用户主动 撤销混合主动 提供进展指示器系统主动 预测与用户相关的某些信息维持任务的一个模型维持用户的一个模型维持系统的一个模型设计时将用户接口 可能频繁改变 与应用的其余部分分离开支持该战术的架构模式 MVC PAC Seeheim Arch Slinky 96 Seeheim简介 Seeheim模型将软件体系结构分为4个部分 核心模块 FunctionalCore 核心应用接口 FunctionalCoreAdapter 对话控制器 DialogueContro1ler 界面构件 PresentationComponent FunctionCore对领域应用进行建模 FunctionalCoreAdapter为用户界面与核心应用之间建立一个缓冲区 以减少二者之间的耦合 它通过一些交互协议为用户界面与核心应用之间提供同步或者异步的数据交换 DialogueController是Seeheim模型中的核心部分 它通过界面构件接收来自用户的各种输入请求 通过转换后利用核心应用接口与核心模块进行数据交换 保证多个视图间的一致性 以完成特定的用户任务在DialogueContro11er中可以嵌套定义Seeheim子模型 这样可以从不同粒度上对GUI系统进行建模 PresentationComponent对界面构件的具体交互动作和输入输出进行设计 97 战术与构架模式 风格 的关系 设计师会选择一个精心设计的模式或模式集合 来实现一个或多个战术根据战术 创建构架模式和策略选择了战术之后 设计师的任务才开始任何设计都使用多个战术对设计师来说 分析过程包括理解在实现中所应用的战术 明智地选择战术组合来实现系统的目标例 海战 制空 飞机 航母 98 四 空中交通管制 高可用性设计方案分析 99 高可用性设计案例分析 空中交通管制 AirTrafficControl ATC 对实时性和安全性要求极高由FAA 联邦航空局 管理 客户从顺利起飞到安全抵达整个过程 飞机都要受ATC某个部分的管理 地面控制部分负责管理飞机在机场地面的运动 控制塔台控制飞机在该终端控制区域空间的飞行 该系统有多个中途中心 我们要讨论的系统叫ISSS InitialSectorSuiteSystem 初始区段组系统 对22个中途中心的软硬件进行升级 从A港到B港的飞行控制示意 101 各中途控制中心管辖 102 ISSS需求与质量分析 两个最重要的质量属性极高的可用性 不正常状态只能持续极短时间高性能 必须在不丢失任何数据的情况下 对大量数据 每中心最大飞机数量2440 进行处理 通信网络必须能处理这种负载 软件必须快速带预测性地进行计算其他重要属性开放性能够提交该系统的子集能够更改功能 处理软硬件的升级能够与众多外部系统相接并协同工作必须满足众多涉众的要求 特别是控制人员的需求 某区段组的控制台 一个中心可以有多个区段 雷达控制员 监视雷达数据 与机组人员联系 保证飞机安全隔离数据控制员 获取每一架飞机的数据 飞行计划等 104 ISSS系统的规模 每个中途中心支持210个控制台 每个控制台都有工作站级的CPU IBMRS 6000要求每个中心能同时管理400 2440架飞机每个场站需要16 40台雷达一个中途中心可能需要60 90个控制位置 每控制位置需要一个或多个控制台ISSS系统要求使用Ada语言 源代码超过100万行 105 ISSS系统必须完成如下功能 获取存储在现有ATC系统主计算机 HCS 中的雷达目标数据转换雷达报告 以供显示 将其广播给所有的控制台 每个控制台选择自己需要的数据 每控制台都能显示任何方位的数据处理冲突警告 撞机 或其他计算机发来的数据提供与HCS的接口 用于输入及查询飞行计划提供网络管理等多方面的监控信息 允许场站管理人员重新配置所安装的系统提供记录能力 以供事后回放在控制台提供图形界面 特殊功能 如一定透明性 当主计算机 主通信网络 主雷达传感器出现故障时 提供后备功能 106 ISSS的架构解决方案 可用性 一年内停机时间不能超过5分钟 这个质量属性决定了整个架构的决策下面给出一些主要视图 并说明其战术ISSS的物理视图模块分解视图进程视图客户机 服务器视图分层视图组件 连接器视图 物理视图 108 物理视图 主计算机HCS是中途中心的核心每个中心有两台主计算机 一台负责常规处理 一台在前者出现故障时接管处理 主计算机负责对监控数据和飞行计划数据处理通用控制台CommonConsoles是空管人员的工作站 1区段有1 4台控制台本地通信网LCN是ISSS系统的主要网络 每台主机都通过双LCN接口单元 每一个都叫做LIU H 与LCN相连LCN由4个并行的令牌环网组成 以提供冗余能力并平衡总负载一个把监控数据广播到各个处理器 第2个实现处理器间的点到点通信 第3个把显示数据从通用控制台发送到数据记录部件备用 第4个是备用的 109 物理视图 增强直接访问雷达信道 EDARC 提供飞机方位的后备信息 并将飞行数据块信息限定显示在控制台上使用EDARC是为了防止主机发送的信息丢失 EDARC实质上提供了原始雷达数据 到ESI 外部系统接口 处理器的接口后备通信网 BCN 是采用TCP IP协议的以太网LCN BCN都有相应的监控控制台 M C 测试与培训子系统提供了在不影响正常操作情况下 对新的软硬件测试以及对用户进行培训的功能中央处理器采用大型机上的处理器 在ISSS系统的早期版本中用以提供数据存储和回放的功能 110 模块分解视图 ISSS的模块被称为计算机软件配置项 CSCI 按照美政府软件开发标准定义 每个CSCI都围绕一个中心问题展开显示管理通用系统服务 提供实用程序记录 分析 回放 捕捉会话 事后分析全国空域系统修改 对驻留主机的软件做相应修改IBMAIX操作系统分解视图反映了几个可修改战术语义一致性 为每个CSCI分配定义良好不重叠的责任抽象通用服务战术 通用系统服务记录回放战术 预期变更 泛化模块 维持接口稳定战术 仔细设计软件的接口 111 进程视图 112 进程视图 ISSS按多处理器环境设计 处理器在逻辑上组成处理器组 成组的目的是要分别运行一个或多个应用程序的副本 容错 可用性 PAS 主地址空间SAS 备用地址空间一个主地址空间和x相应备用地址空间集合被称为操作单元 操作单元驻留在同一地址处理器组的处理器中未以这种容错方式实现的ISSS的其它部分 则在不同的处理器上独立运行 称为功能组FG该视图反应的可用性战术状态再同步 shadowing 主动冗余 从服务中删除 113 进程视图 各应用程序之间按C S模式进行交互操作单元内PAS将状态变化通知给SASSAS等待超时 或其他标志PAS SAS自身失效的消息 以便接替PAS 有以下步骤 某SAS提升为新PASPAS重新设定与本操作单元中各客户机的关系 然后通知各客户机 原操作单元故障启动某个新SAS 替换原来的PAS新SAS向新PAS通告自己的存在 新PAS将状态通知给SAS 使其保持最新如果SAS内部错误 则在另外的处理器上启动新SAS 新SAS与PAS协调 并接收状态数据 114 进程视图 如果需要添加新操作单元 采用如下步骤确定必要的输入数据及所在位置确定哪些操作单元需要用到新操作单元的数据以一种避免死锁的方式 将新操作单元的通信加入到整个通信拓扑结构中设计消息 实现所期望的数据流确定在评审时必须要用的内部状态数据 以及在从PAS到SAS的更新通信中必须包括的状态数据将状态数据划分为能够很好地适应网络要求的消息定义必须用到的消息类型规划PAS失效时的切换保证切换时的数据一致性保证各个处理步骤能够在不超过一次 心跳 的时间内完成规划与其他操作单元的数据共享和数据锁定协议 115 客户机 服务器视图 116 客户机 服务器视图 应用程序以此方式和系统交互 精心设计了接口 使用简单的消息协议反映了如下战术维持接口的稳定性组件更换遵守已定义协议 117 软件架构的分层视图 118 保证容错的组件 连接器视图 119 容错 PAS SAS模式捕获单个应用程序内的错误 并从中恢复 容错层次 则捕获应用程序间交互的错误 并从中恢复 ISSS系统提供了多种不同层次的错误检测和恢复机制 每个层次上都能异步地 检测自身 同级实体和低层实体的错误处理来自低层的例外情况诊断 恢复 报告或提交例外情况 120 容错 每一层次都要在下层所产生的可用性的基础上进一步提高系统的可用性 层次包括 物理层操作系统运行时环境应用程序本地可用性组可用性全局可用性系统监视与控制在每一层上都要做错误检测和隔离工作除常规可用性战术外 容错视图还使用了 命令和响应 心跳 作为检测故障的方法 将错误过滤到适当的地方以进行纠正 过滤到备件上 已进行恢复 121 将视图彼此关联起来 一个视图的元素 可能在其他视图中以另一种形式出现通过分析视图彼此间的关系映射 更深入地了解系统 ATC系统如何实现其质量属性 123 ISSS后记 ISSS系统使用寿命长 成本高 规模大 作用重要且受各方面关注通过包括硬件 软件冗余以及分层错误检测在内的标准容错机制 和代码模板 以及采用消息传递的分布式计算 该架构能满足复杂的 广泛的使用要求由一流专家组成的小组对ISSS构架进行了大量的软件审核 遍历几个更改场景 测试了其可修改性 对监控 M C 的人机界面做重大修改在ISSS系统中引入第三方开发的ATC应用程序在系统中添加新的空中交通管制图用一个具有类似功能的芯片更换RS 6000处理器删除ISSS中对支持电子飞行条的要求把系统的飞行跟踪能力提供50 结果表明 修改能直接了当地进行 说明架构经过精心的设计美国政府放弃ISSS 转向一个功能更简单 成本更低的方案 124 五 设计架构 几乎在我们遇到的所有成功面向对象系统中都具有 但失败的系统中缺少的两个特性是 存在一个强大的构想 应用管理良好的迭代式增量开发周期 GradyBooch 主要内容 生命期中的架构设计构架形成团队结构及其与构架的关系创建骨架系统 演变交付生命期 软件概念 初步需求分析 构架和系统核心设计 开发一个版本 交付最终版本 交付该版本 获取客户反馈 汇总客户反馈 7类设计决策 用于指导质量设计sevencategoriesofdesigndecisions AllocationofresponsibilitiesCoordinationmodelDatamodelManagementofresourcesMappingamongarchitecturalelementsBindingtimedecisionsChoiceoftechnology 126 架构就是一系列设计决策 Discussionquestions 1 Whatistherelationshipbetweenausecaseandaqualityattributescenario Ifyouwantedtoaddqualityattributeinformationtoausecase howwouldyoudoit Doyousupposethatthesetoftacticsforaqualityattributeisfiniteorinfinite Why Discussthechoiceofprogramminglanguage anexampleofchoiceoftechnology anditsrelationtoarchitectureingeneral andthedesigndecisionsintheothersixcategories Forinstance howcancertainprogramminglanguagesenableorinhibitthechoiceofparticularcoordinationmodels Wewillbeusingtheautomatictellermachineasanexamplethroughoutthechaptersonqualityattributes Enumeratethesetofresponsibilitiesthatanautomatictellermachineshouldsupportandproposeaninitialdesigntoaccommodatethatsetofresponsibilities Justifyyourproposal 127 Discussionquestions 2 Thinkaboutthescreensthatyourfavoriteautomatictellermachineuses Whatdothosescreenstellyouaboutbindingtimedecisionsreflectedinthearchitecture Considerthechoicebetweensynchronousandasynchronouscommunication achoiceinthecoordinationmechanismcategory Whatqualityattributerequirementsmightleadyoutochooseoneovertheother Considerthechoicebetweenstatefulandstatelesscommunication achoiceinthecoordinationmechanismcategory Whatqualityattributerequirementsmightleadyoutochooseoneovertheother Mostpeer to peerarchitectureemployslatebindingofthetopology Whatqualityattributesdoesthispromoteorinhibit 128 129 设计架构 基于质量属性驱动的设计 ADD ADD把一组质量属性场景看作是输入 基于对质量属性与构架之间的关系的了解 进行构架设计ADD可看作是对某些开发方法 如RUP的扩展 将ADD集成到构架设计中 然后遵循RUP过程 130 AttributeDrivenDesign ADD是一种定义软件架构的方法 该方法将分解过程建立在软件必须满足的质量属性之上 ADD是一个递归的分解过程 在递归的每一个阶段 都选择战术和架构模式来满足一组质量属性需求 在软件生命期中 ADD位于需求分析之后 在知道 当前分解阶段的 构架驱动因素之后 ADD就可以开始了 131 AttributeDrivenDesign ADD的结果是构架视图的最初几个层次 并非所有细节都是由ADD得到的 系统被描述为功能 功能交互的一组容器 尽管粒度可能很粗 但它为实现功能提供了一个框架 由ADD得到的架构