北京大学软件工程国家工程研究中心建设概要

软件体系结构(Software Architecture),讲义六：软件体系结构设计,基于体系结构的软件开发模型,ABSDM,基于体系结构的软件开发模型,体系结构需求,基于体系结构的软件开发模型,体系结构设计,基于体系结构的软件开发模型,体系结构文档化文档是在系统演化的每一个阶段，系统设计与开发人员的通讯媒介，是为验证体系结构设计和提炼或修改这些设计（必要时）所执行预先分析的基础。体系结构文档化过程的主要输出结果是体系结构需求规格说明和测试体系结构需求的质量设计说明书这两个文档。生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约。软件体系结构的文档要求与软件开发项目中的其他文档是类似的。文档的完整性和质量是软件体系结构成功的关键因素。文档要从使用者的角度进行编写，必须分发给所有与系统有关的开发人员，且必须保证开发者手上的文档是最新的。,基于体系结构的软件开发模型,体系结构复审体系结构设计、文档化和复审是一个迭代过程。从这个方面来说，在一个主版本的软件体系结构分析之后，要安排一次由外部人员（用户代表和领域专家）参加的复审。复审的目的是标识潜在的风险，及早发现体系结构设计中的缺陷和错误，包括体系结构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能与性能的要求等等。由外部人员进行复审的目的是保证体系结构的设计能够公正地进行检验，使组织的管理者能够决定正式实现体系结构。,基于体系结构的软件开发模型,体系结构实现,基于体系结构的软件开发模型,体系结构演化,软件体系结构设计方法,软件体系结构设计已经成为大型软件系统开发过程中不可或缺的步骤，因为非功能需求的介入，这个任务变得非常复杂和随意若干体系结构设计方法基于模式的设计 (pattern-based design)基于目标图的推理 (goal graph based reasoning)基于属性的体系结构风格 (attribute-based architectural style, ABAS)多重视图模型 (multiple view model)基于评估和转换的设计 (evaluation and transformation based design)基于体系结构的产品线设计 (architecture-based product lines design),同体系结构设计相关的四个问题,为了使软件体系结构在实际软件开发中有用，必须解决四个问题：如何显式地描述软件体系结构？体系结构描述语言（ADL），形式化地表示和分析软件体系结构，例如Adage, Aesop, Rapide, SADL, UniCon等如何为软件设计好的体系结构？当考虑许多非功能需求时，该任务益发具有挑战性如何分析现有的体系结构？如何预测体系结构是否能够产生满足需求的实现？软件体系结构的目的不仅是描述系统重要的方面，而且通过暴露它们，使设计人员可以进行讨论如何使软件实现同体系结构设计保持一致？在实际的软件开发中，实现同体系结构文档差距很大，以致体系结构设计只被作为遗产保存这四个问题是密切相关的，并在过去的十年里各方面取得了很大的进展！,一、基于模式的设计,模式的使用在许多工程领域是普遍的，对公共设计形式的确定和共享的理解是成熟工程领域的特点之一一个模式提供了有效的语义环境：关注点、期望的演化路径、计算范型和与其他相似系统之间的关系依据其规模不同，模式经常被分为三个层次：体系结构风格 (architecture styles)设计模式 (design patterns)编程泛型基于模式的体系结构设计方法使用丰富的风格知识库，指导体系结构的设计，有助于分析冲突的需求和不同设计的折衷,设计模式*,设计模式概述模式是指从某个具体的形式中得到的一种抽象，在特殊的非任意性的环境中，该形式不断地重复出现。一个软件体系结构的模式描述了一个出现在特定设计语境中的特殊的再现设计问题，并为它的解决方案提供了一个经过充分验证的通用图示。解决方案图示通过描述其组成构件及其责任和相互关系以及它们的协作方式来具体指定。,设计模式*,设计模式概述MVC模式,设计模式*,一个好的模式必须做到以下几点：解决一个问题：从模式可以得到解，而不仅仅是抽象的原则或策略。是一个被证明了的概念：模式通过个记录得到解而不是通过理论或推测。描述了一种关系：模式并不仅仅描述模块，它给出更深层的系统结构和机理。模式有重要的人为因素：所有的软件服务于人类的舒适或生活质量，而最好的模式追求它的实用性和美学,设计模式*,模式的组成成分：模式名称 用简单的词汇描述一个设计问题、解法或者后果问题 什么时候要使用设计模式、解释问题及其背景用一个强制条件集来表达解决方案必须满足的需求必须考虑的约束必须具有哪些期望的特性解决方案 描述设计的基本要素，它们的关系、各自的任务以及相互之间的合作规定了特定的结构、规定了运行期间的行为后果 描述应用设计模式后的结果和权衡,设计模式*,设计模式的描述Erich Gamma博士等人采用下面的固定模式来描述：,（1）模式名称和分类（2）目的（3）别名（4）动机（5）应用（6）结构,（7）成分（8）合作（9）后果（10）实现（11）例程代码 （12）已知的应用（13）相关模式,设计模式*,设计模式方法分类模式Coad的面向对象模式1992年，美国的面向对象技术的大师Peter Coad从MVC的角度对面向对象系统进行了讨论，设计模式由最底层的构成部分（类和对象）及其关系来区分。他使用了一种通用的方式来描述一种设计模式：模式所能解决问题的简要介绍与讨论模式的非形式文本描述以及图形表示；模式的使用方针：在何时使用以及能够与哪些模式结合使用。基本的继承和交互模式：主要包括OOPL所提供的基本建模功能，继承模式声明了一个类能够在其子类中被修改或被补充，交互模式描述了在有多个类的情况下消息的传递。面向对象软件系统的结构化模式：描述了在适当情况下，一组类如何支持面向对象软件系统结构的建模。与MVC框架相关的模式。,设计模式*,设计模式方法分类模式代码模式码模式的抽象方式与OOPL中的代码规范很相似，该类模式有助于解决某种面向对象程序设计语言中的特定问题。主要目标在于：指明结合基本语言概念的可用方式；构成源码结构与命名规范的基础；避免面向对象程序设计语言（尤其是C+语言）的缺陷。代码模式与具体的程序设计语言或者类库有关，它们主要从语法的角度对于软件系统的结构方面提供一些基本的规范。这些模式对于类的设计不适用，同时也不支持程序员开发和应用框架，命名规范是类库中的名字标准化的基本方法，以免在使用类库时产生混淆。,设计模式*,设计模式方法分类模式框架应用模式在应用程序框架“菜谱”中有很多“菜谱条”，它们用一种不很规范的方式描述了如何应用框架来解决特定的问题。程序员将框架作为应用程序开发的基础，特定的框架适用于特定的需求。“菜谱条”通常并不讲解框架的内部设计实现，只讲如何使用。不同的框架有各自的“菜谱”。,设计模式*,设计模式方法分类模式形式合约形式合约也是一种描述框架设计的方法，强调组成框架的对象间的交互关系。有人认为它是面向交互的设计，对其他方法的发展有启迪作用。但形式化方法由于其过于抽象，而有很大的局限性，仅仅在小规模程序中使用。优点符号所包含的元素很少，并且其中引入的概念能够被映射成为面向对象程序设计语言中的概念。例如，参与者映射成为对象。形式合约中考虑到了复杂行为是由简单行为组成的事实，合约的修订和扩充操作使得这种方法很灵活，易于应用。,设计模式*,设计模式方法分类模式形式合约缺点在某些情况下很难用，过于繁琐。若引入新的符号，则又使符号系统复杂化。强制性地要求过分精密，从而在说明中可能发生隐患（例如冗余）。形式合约的抽象程度过低，接近面向对象的程序设计语言，不易分清主次。,一个简单的例子(1/2),需求：假设在一个系统中，需要有一个数据源和多种不同的显示方式，例如，电子表格、柱状图、饼图等，不同视图中的数据需要保持一致，并且可能会在今后增加新的显示方式如何设计这样一个系统，同时满足功能需求和非功能需求？如果体系结构设计人员熟悉各种模式或者有一个模式列表可供参考，那么Observer模式（又称为Publish-Subscribe模式）是个可能的候选者在Observer模式的环境描述中，“当把系统划分为一组相互协作的类时，需要维护相关对象之间的一致性。Observer模式不希望通过类的紧密耦合实现一致性，因为这样会降低它们的可复用性。”这正是我们所需要的模式！,一个简单的例子(2/2),基于结构描述和例子，不难设计出该系统。设计人员还知道使用这种模式的后果，例如主体和观察者可以独立变化复用主体，而不必复用相关的观察者复用观察者，而不必复用相关的主体，等等这个例子似乎是直接和完美的，但实际上，因为系统规模和复杂性的增加，应用这些模式到实际的环境中并不容易事实上，这种方法为你提供了有价值的风格和模式的列表，但并没有告诉你多少关于如何使用这个知识库。这使得体系结构设计缺少正规化，更像直觉的工艺，而非理性的工程！,二、基于目标图的推理,基于目标图的推理 (goal graph based reasoning)该方法的目标是使模式背后的推理结构显式化，并且服从于系统的分析该方法使用目标图，表达模式在各种需求上的应用效果,方法的主要任务,把需求表示为设计目标功能需求和非功能需求皆被表达为要达到的目标特别是，非功能需求被表达为“软”目标。这里的“软”目标意味着它们通常没有清晰的评价标准说明目标之间的关系目标之间，特别是非功能目标之间，不是独立的。它们的关系要在目标图中显式地表示出来说明已知的解决方案如何达到目标模式中的解决方案被表示为可实施的“软”目标一方面，可实施的“软”目标把设计目标转化为解决方案另一方面，它们仍被看作目标，因为仍然有不同的途径实现它们识别目标和解决方案中不希望的相关性模式的副作用也能在图中使用相关联接显式地声明说明替代解决方案如何从其它方面作用于目标每个建议的解决方案，可以通过达到的非功能“软”目标，进行分析,Observer模式的目标图,在设计中应用Observer模式,三、基于属性的体系结构风格,基于属性的体系结构风格 （attribute-based architectural style, ABAS）是对通常体系结构风格描述的一种扩充， 用于获取SA层次上的结构和分析技巧，显式地把推理框架（定性或定量）与体系结构风格关联起来这些推理框架基于特定的质量属性模型每个ABAS只同一个属性推理框架关联对于那些从多个视角感兴趣的体系结构风格，它们具有多个ABASs例如，pipe-and-filter性能ABAS vs. pipe-and-filter可靠性ABASABAS是质量属性刻画的内容和分析模型的组合关键在于，ABAS将反复出现的针对质量属性的重要问题和典型的解决方案相结合,ABAS的动机来源(1/2),ABAS的研究动机来源于体系结构风格：Shaw and Garlan in “Software Architecture: perspectives on an emerging discipline”, Buschmann et al in “Pattern-Oriented Software Architecture”质量属性的分析模型：例如性能的速率单调分析 (M. Klein, T. Ralya, B. Pollak, R. Obenza, M. Gonzales Harbour, A Practitioners Handbook for Real-Time Analysis, Kluwer Academic, 1993)，可用性的Markov模型体系结构评估问卷：在AT&T的体系结构调查问卷 (J. Maranzano, Best Current Practices: Software Architecture Validation, AT&T, 1993),ABAS的动机来源(2/2),ABAS是对体系结构风格的描述，但增加了相关质量属性的分析模型例如，在描述层次风格时，Shaw and Garlan写道，“如果系统逻辑上可以组织成层次化的，考虑性能时要求逻辑上的高层功能和底层实现之间的紧密耦合”对关系到复杂软件系统的若干重要质量属性，诸如性能、可靠性、安全性等，已经存在较为成熟的分析模型然而，这些分析模型一般太过通用，需要很好地训练才能有效地使用它们。通常，当实施体系结构评估时，要在两三天的时间内对设计的有效性和风险进行评估一组评估调查问卷，即被证明有效的问题有助于对体系结构的推理和分析，并提供了对问题本质的描述,ABAS的结构 (1/2),问题描述该结构所要解决的设计问题，包括感兴趣的质量属性、使用的上下文环境、约束和相关的特定属性需求质量属性测量和刺激在问题描述部分讨论的内容浓缩，但关注同质量属性模型相关的可测量方面，包括刺激引起体系结构响应或变化的事件体系结构风格构件和连接件的类型、拓扑结构、对构件之间数据和控制信息的交互模式的描述，以及对构件或连接件中任何与质量属性密切相关的特性的描述质量属性参数在体系结构风格部分讨论的内容浓缩，但关注同质量属性模型参数相关的方面分析描述质量属性模型如何同体系结构风格的成份形式上相关，以及从模型得出的关于体系结构行为的结论注意：上述部分依赖于体系结构风格和质量属性的描述,ABAS的结构 (2/2),为了评估软件体系结构同质量需求的吻合程度，需求要以可测量、至少是可观察的方式描述出来，我们称之为质量属性测量质量属性参数表达了体系结构的特性，是体系结构的可调参数，决定了依赖参数是否满足质量需求刺激 (stimuli)是体系结构必须响应的事件,质量属性举例：性能 (1/2),例如，性能 (performance)是同时间相关的质量属性，通常由延迟时间或吞吐量度量两个质量属性测量延迟时间：从事件发生到对该事件的响应完成所经过的时间，以单位时间表达吞吐量：系统能够响应事件的频率，以单位时间的交易（或响应）表达刺激：体系结构必须响应的状态变化。对性能而言，事件的到达模式是重要的周期性的：事件到达有固定的间隔零星的：事件到达间隔的长短有一个界限随机的：事件的到达能以概率表达,质量属性举例：性能 (2/2),当一个刺激发生时，系统使用其资源执行计算或传送数据进行响应。多个并发的刺激响应需要仲裁或调度策略以解决冲突的请求同性能相关的质量体系参数包括需要的资源、资源分配的策略、资源请求或使用的特征资源特性：包括资源类型，如CPU或网络；资源特性，如CPU速度或网络带宽等资源调度策略：包括CPU调度、CPU分配、总线和网络仲裁、排队策略等资源使用：包括进程和消息的优先级、响应的抢占性、使用量（如执行时间）,从体系结构模型映射到属性模型,体系结构决策,体系结构特性,实际行为,期望的行为,质量属性模型参数,质量属性模型,预期行为,刺激,？,？,ABASs把体系结构特性的刻画映射到质量属性参数，然后通过建模把质量属性参数和刺激映射到预期行为那些调度和排队模型提供了关联质量属性参数（如排队策略、执行时间评估）和质量属性测量（如延迟时间、吞吐量）的基础某些参数（如执行时间）在体系结构层面不易被量化。这种情况下，执行时间预算被分配，进而转化为导出需求，以充实构件的细节,软件系统常见的质量属性(1/2),Performance系统响应能力，通常用“Benchmarks”度量Reliability系统长时间运行的能力，通常用“平均无故障时间”度量Availability系统能够正常运行的时间比例，通常用“平均故障时间”和“故障恢复时间”度量Security阻止非法入侵或拒绝服务的能力，通常用系统受到的各种威胁种类加以分类Modifiability快速、低成本修改系统的能力，通常使用特定的改变作为基准，记录进行这些改变所需花费的代价,软件系统常见的质量属性(2/2),Portability不同计算环境下运行的能力，一个系统可移植的程度局限于：所有关于任何特定计算环境的假设被限制在一个构件中（最坏的情况下，少数几个易于修改的构件）Functionality系统完成预定工作的能力Variability体系结构更改或扩充的能力，变化性机制包括run-time、compile-time、build-time or code-time等，当体系结构是整个产品家族的基础时，变化性显得尤为重要Subsetability支持系统生成子集的能力，即子集独立交付的能力，支持增量开发。是一种特殊的变化性Conceptual integrity在各个层次上统一系统设计能力，例如一致性,质量属性的刻画,在特定质量属性模型中，质量属性信息描述分为三部分外部刺激：导致体系结构响应或变化的事件体系结构决策：对实现属性响应有直接影响的体系结构方面响应：对可测量/可观察量的描述质量属性的实现设计决策旨在控制对刺激的响应,设计策略,刺激,响应,可用性设计决策（1/4）,目标恢复或者修复阻止错误发展成故障，或者把错误影响限制在一定范围之内，使得修复成为可能可用性设计决策,可用性设计决策（2/4）,错误检测命令/响应一个构件发出一个命令，测试在预定时间内收到一个来自审查构件的响应客户端可以采用该策略，以确保服务器对象和到服务器的路径在期望的性能边界内心跳（dead man计时器）一个构件定期发出一个心跳消息，另一个构件收听该消息，如果心跳失败通知错误处理构件自动柜员机可以定期向服务器发送上一次交易的日志，起到心跳和传送数据双重作用异常设置异常处理程序,可用性设计决策（3/4）,错误恢复表决运行在冗余处理器上的每个进程都具有相等的输入，它们计算发送给表决者一个简单的输出值，如果表决者检测到某一处理器的异常行为，那么就中止这一行为用于纠正算法的错误操作或处理器的故障，通常用在控制系统中主动冗余（热重启）所有的冗余构件都以并行的方式对事件作出响应，仅使用一个构件的响应，丢弃其它响应当错误发生时，系统停机时间就是切换时间，仅为几毫秒被动冗余（暖重启/双冗余/三冗余）一个主要构件对事件作出响应，并通知其它备用构件进行状态更新当错误发生时，在继续提供服务之前，要保证备用状态是最新的备用件备用件是计算平台配置用于更换不同的故障构件出现故障时，必须重新启动并重新初始化软件配置Shadow操作设置一个构件短时间内以“shadow模式”运行，以确保在恢复该构件之前，模仿工作构件的行为状态再同步主动和被动冗余要求所恢复的构件在重新提供服务前要更新其状态更新方法取决于可以承受的停机时间、更新的模式以及更新所要求的消息的数量检查点/回滚记录系统的一致状态，或者是定期收集状态数据，或者是对具体事件做出响应,可用性设计决策（4/4）,错误预防从服务中删除从操作中删除系统的一个构件，以执行某些活动来防止预期发生的故障事务绑定几个有序的步骤，以能够立刻撤销整个绑定如果进程中的一个步骤失败的话，可以使用事务来防止数据受到影响进程监视器一旦检测到进程中出现错误，监视进程就可以删除错误执行进程，并为该进程创建一个新的实例,可修改性设计决策,目标减少由某个变更直接影响的模块数量限制对局部化的模块的修改，防止连锁反应控制部署时间和成本可修改性设计决策,局部化修改维持语义的一致性抽象通用服务，由专门的模块封装通用的服务，以提供复用，注重模块责任的一致性对通用服务的修改只需要进行一次，而不需要在使用这些服务的每个模块中进行修改，不仅支持局部化修改，还防止连锁反应应用框架和中间件的使用预期期望的变更不关心模块责任的一致性，只关心如何使变更的影响达到最小不可能预期所有的变更，通常结合语义一致性使用泛化模块使一个模块更通用，根据不同的输入提供不同的功能通过调整参数而不是修改模块来进行变更限制可能的选择修改的范围非常大，因此可能修改很多模块限制可能的选择会降低修改所造成的影响,防止连锁反应修改所产生的连锁反应就是需要改变该修改并没有直接影响到的模块依赖性：如果改变了模块A以完成某个特定的修改，那么必须改变模块B，成为模块B依赖于模块A8种类型的依赖性语法数据：要使B正确编译或者执行，由A产生并由B使用的数据的类型必须与B所假定的数据类型一致服务：要使B正确编译或者执行，由A提供并且由B调用的服务的signature必须与B假定的一致语义数据：要使B正确执行，由A产生并由B使用的数据的语义必须与B所假定的数据类型一致服务：要使B正确执行，由A提供并且由B调用的服务的语义必须与B假定的一致顺序数据：要使B正确执行，必须以一个固定的顺序接受由A产生的数据控制：要使B正确执行，A必须在一定时间限制内执行,A的一个接口的身份A可以有多个接口，要使B正确编译和执行，该接口的身份必须与B假定的一样A的位置要使B正确执行，A的运行时为止必须与B假定的一样，例如A位于某个特定服务器的特定进程中A提供的服务/数据的质量要使B正确执行，涉及A所提供的数据或服务的一些质量属性必须与B假定的一样A的存在要使B正确执行，A必须存在A的资源行为要使B正确执行，A的资源行为必须与B的假定一致,防止连锁反应,信息隐蔽把某个实体的责任分解为更小的部分，并选择哪些信息是公有的，哪些信息是私有的目的是将变更隔离在一个模块内，防止扩散维持现有的接口添加接口通过添加新的接口提供新增的可见服务和数据，从而使得现有的接口不变并提供相同的signature添加适配器添加一个封装A的适配器，并提供原始signature提供一个占位程序A如果需要删除A，但是B仅依赖A的signature，那么为A提供一个占位程序能够使B保持不变限制通信路径减少使用由该模块所产生的数据的模块的数量，以及产生由该模块所使用的数据的模块的数量，以减少连锁反应,仲裁者的使用：如果B对A有非语义的任何形式的依赖，那么可以引入一个仲裁者来管理与该依赖相关的活动数据（语法）数据存储构件可以充当数据生产者和使用之间的仲裁者，将A产生的语法转换为B要求的语法服务（语法）Faade、Bridge、Proxy、Mediator、Strategy、Factory Method等模式都提供了把服务的语法从一种形式转换为另一种形式的仲裁者，可以防止A的变化扩散到BA的接口的身份可以使用经纪人模式屏蔽一个接口的身分的变化A的位置（运行时）Name服务器能够使A的位置发生变化时，不影响到BA的资源行为或由A控制的资源（运行时）资源管理器使一个负责进行资源分配的仲裁者A的存在工厂模式能够根据需要来创建实例，解决B对A的存在依赖,推迟绑定时间运行时注册支持即插即用操作，但需要管理注册的额外开销配置文件在启动时设置参数多态允许方法调用的后期邦定构件更换允许载入时间绑定遵守已定义的协议允许独立进程的运行时绑定,性能设计决策,目标对在一定时间限制内到达系统的事件生成一个响应产生响应时间的基本因素资源消耗资源包括CPU、数据存储、网络带宽、内存以及系统所定义的实体闭锁时间资源争用对一个资源争用越多，就越有可能引入等待时间资源的可用性资源离线、构件故障等原因都会导致资源不可用，以增加等待时间对其他计算的依赖需要等待自己启动的计算结果，或者等待别的构件提供的计算结果,性能设计决策,资源需求提高计算效率改进在关键的地方所使用的算法的效率将减少等待时间用一种资源换取另一种资源，例如可以把数据保存在硬盘上，也可以重新生成数据，取决于时间和空间资源的可用性减少计算开销如果没有计算请求，那就减少处理需求例如，删除仲裁者可以减少等待时间管理事件率降低监视环境对变量的取样频率，就可以减少需要管理的事件控制采样频率用一个较低的频率对排队的请求进行采样，也可以减少需要处理的事件限制执行时间限制用多少执行时间对事件作出响应对于迭代式、依赖于数据的算法，可以限制迭代次数限制队列大小控制了队列的到达事件的最大数量，因此控制了用来处理到达事件的资源,资源管理引入并发如果可以并行进行请求，可以减少闭锁时间通过在不同的线程上处理不同的事件流或创建额外的线程来处理不同的活动集来引入并发维持数据或计算的多个副本减少在中央服务器上进行所有的计算所引起的资源争用注意：要保证副本的数据一致和同步增加可用资源速度更快的处理器、额外的处理器、额外的内存以及速度更快的网络都可以减少等待时间,资源仲裁标准：最佳的资源使用、请求重要性、最小化所使用资源的数量、使等待时间最少、使吞吐量最大等先进/先出同等对待资源的所有请求一个请求可能会被另一个需要更长等待时间来生成响应的请求阻止固定优先级调度为每一个请求分配一个特定的优先级，并按照优先级的顺序分配资源确保高优先级的请求得到更好的服务，但是优先级较低的请求可能要等待很长时间才可能得到资源语义重要性、时限时间单调、速率单调动态优先级调度轮转：对请求进行排序，把资源分配给序列中的下一个请求时限时间最早优先：最早的挂起请求最早得到资源静态调度循环调度,安全性设计决策,抵抗攻击身份认证保证进行访问的用户或远程计算机确实是它所声称的用户或计算机密码、数字证书、生物识别用户授权保证经过了身份认证的用户有权访问和修改数据或者服务维护数据的机密性对数据进行保护，以防止未经授权的访问对数据和通信线路进行加密保护维护完整性对数据中的冗余信息，例如校验和哈希值，进行加密限制访问来自未知源的消息可能是某种形式的攻击防火墙根据消息源和目的地端口来限制访问,检测攻击通过“入侵检测”系统进行，将通信模式和已知攻击的历史模式进行比较可以根据数据包中的协议、TCP标记、有效负荷大小、源或目的地地址以及端口号等进行监测从攻击中恢复恢复状态可以采用可用性设计策略，都是从不一致的状态恢复到一致状态，特别要注意维护系统管理数据的冗余副本，如密码、访问控制列表、域名服务和用户资料数据等识别攻击者使用审计信息来追踪攻击者的操作审计信息包括系统中数据的变更、事务的执行和身份识别等信息,可测试性设计决策,目标允许在完成软件开发的一个增量后，较轻松地对软件进行测试测试专用软件：为被测试的软件提供输入并捕获输出可测试性决策设计,提供输入/捕获输出记录/回放捕获跨接口的信息，并将其作为测试专用软件的输入将接口与实现相分离将接口与实现相分离的策略允许占位实现的存在占位实现允许在缺少被占位构件时，对系统的其余部分进行测试,内部监视捕获内部状态，以支持测试过程内置监视器构件可以维持状态、性能负载、容量、安全性或其它可通过接口访问的信息当监视状态被激活时就记录以上信息，可以提高构件的可见性，有助于测试的实现例如，面向方面的编程,易用性设计决策,目标易用性与用户完成期望任务的难易程度以及系统为用户提供的支持有关易用性设计决策,运行时设计决策维持任务模型任务模型用于确定上下文，以使得系统了解用户试图做什么，并提供各种协助维持用户模型用户模型确定用户对系统的了解，用户在期望的响应时间方面的要求，以及特定于某个用户或某类用户的行为维持系统模型系统模型确定了期望的系统行为，以便为用户提供适当的反馈,设计时设计决策将用户接口与应用的其余部分分离开来在开发和部署中，预计用户接口会频繁发生变化，因此单独维护用户接口代码会把变更局部化使用以下模式模型-视图-控制器表示-抽象-控制。,四、多重视图模型,体系结构设计中的一个困难是：一个规模系统的体系结构通常非常复杂，不同的相关人员关注体系结构的不同方面，如何处理这种复杂性多重视图模型其中最著名是Rational公司提出的“4+1”模型,逻辑视图关注功能需求，即系统应该为用户提供什么服务。逻辑视图同应用领域紧密相关在该视图中，系统功能映射到概念构件和连接件。例如，管道过滤器风格中的构件和连接件针对终端用户的关注，通常使用领域术语，并同软件和硬件细节无关进程视图（或称执行视图）重视一些非功能需求，例如性能、可扩展性等，定义了运行实体和它们的属性它也有构件和连接件，构件是任务，连接件是消息、RPC、事件广播等该视图的主要用户是系统设计人员和集成人员,开发视图关注开发者和项目经理的兴趣该视图的构件和连接件分别映射到子系统或模块，聚焦于在软件开发环境中，软件模块的组织。软件被打包为子系统，并按层次组织物理视图考虑可用性、可靠性和可扩展性等把不同的元素，如网络、进程和任务等，映射到不同的节点上场景视图场景通常是最重要的需求。场景一方面作为设计中发现体系结构元素的驱动器，另一方面在设计完成后，充当确认和例证的角色场景应当是明确的，诸如陈述“系统应当是可修改的”是没有意义的，相反，关于修改性的一个可能的场景是“应用容易增加以下类型的新特性”,相对于其它方法，多重视图模型是最为成熟和获得广泛应用的。每种视图都有特定的符号体系和工具支持逻辑视图：Rational Rose的类图进程视图： Universal Network Architecture Service (UNAS)中的 Software Architects Lifecycle Environment (SALE)开发视图：Apex or Rational Rose物理视图：UNAS场景视图：use case图事实上，对一个体系结构而言，不是所有的视图都是必须的。该方法提供了一个框架，具体到一个项目，取决于设计人员决定哪些视图是有用的例如，如果软件中只有一个进程，那么进程视图是可以省略的,该模型把一个复杂的体系结构分为若干松耦合的视图，这使得不同用户可以更易于从不同方面理解体系结构设计工作变得简单和明确。基于有效的通讯和协调，设计人员可以并行地工作在不同的视图上允许设计人员在每个单个的视图上应用不同的设计方法，例如不同的体系结构风格应用于不同的视图，而不会相互冲突潜在的缺点在体系结构设计和详细设计之间没有清晰的界限。所有的视图都可以用于两类设计中；一些表示法，如类图、use case图也可以用于详细设计中，这使得体系结构设计的输出缺乏良好的定义另一个值得关注的是UML是一种通用建模语言，UML源自面向对象设计，并广泛用于详细设计中。尽管它能支持大多数的体系结构概念，它缺乏进行详尽分析所需要的语义支持,五、基于评估和转换的设计,类似于传统软件设计的原型方法，该范型倡导首先满足功能需求，然后通过迭代的评估