中南大学软件体系结构重点

1、第一章 软件体系结构概述（5分）一、 软件体系结构的定义l 国内普遍接受的定义：软件体系结构包括构件、连接件和约束，它是可预制和可重构的软件框架结构。l 软件体系结构 = 构件 + 连接件 + 约束二、 软件体系结构的优势l 容易理解l 重用l 控制成本l 可分析性第二章 软件体系结构风格（10分）一、 软件体系结构风格定义l 软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。An architectural style defines a family of systems in terms of a pattern of structural organization.l 体

2、系结构风格定义了一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。An architectural style defines a vocabulary of components and connector types, and a set of constraints on how they can be combined.二、 常见的体系结构风格l 管道和过滤器Ø 每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。Ø 过滤器风格的连接件就像是数据

3、流传输的管道，将一个过滤器的输出传到另一个过滤器的输入。l 数据抽象和面向对象组织Ø 数据的表示方法和它们的相应操作被封装在一个抽象数据类型或对象中。Ø 这种风格的构件是对象或者说是抽象数据类型的实例。Ø 对象通过函数和过程的调用来进行交互。l 基于事件的隐式调用Ø 构件不直接调用一个过程，而是触发或广播一个或多个事件。Ø 事件的触发者并不知道哪些构件会被这些事件影响。l 分层系统Ø 组织成一个层次结构。Ø 每一层都为上一层提供了相应的服务，并且接受下一层提供的服务。l 仓库系统Ø 构件：中心数据结构（仓库）和一些

4、独立构件的集合。Ø 仓库和在系统中很重要的外部构件之间的相互作用。l 过程控制环路Ø 源自于控制理论中的模型框架，将事务处理看成输入、加工、输出、反馈、再输入的一个持续的过程模型。Ø 通过持续性的加工处理过程将输入数据转换成既定属性的“产品”。l C2风格通过连接件绑定在一起的按照一组规则运作的并行构件网络。l C/S风格Ø 基于资源不对等，且为实现共享而提出来的。Ø 有三个主要组成部分：数据库服务器、客户应用程序和网络。Ø 优点：ü 具有强大的数据操作和事务处理能力，模型思想简单，易于人们理解和接受。ü 对于硬件

5、和软件的变化显示出极大的适应性和灵活性，而且易于对系统进行扩充和缩小。ü 将大的应用处理任务分布到许多通过网络连接的低成本计算机上，以节约大量费用。Ø 缺点：ü 开发成本较高。ü 客户端程序设计复杂。ü 信息内容和形式单一。ü 用户界面风格不一，使用繁杂，不利于推广使用。ü 软件移植困难。ü 软件维护和升级困难。ü 新技术不能轻易应用。l 三层C/S风格Ø 优点：ü 能提高系统和软件的可维护性和可扩展性。ü 具有良好的可升级性和开放性。ü 可以并行开发。ü

6、 有效地隔离开表示层与数据层，为严格的安全管理奠定了坚实的基础。Ø 缺点：ü 各层间的通信效率不高。ü 设计时必须慎重考虑三层间的通信方法、通信频率及数据量。l B/S风格（浏览器/Web服务器/数据库服务器）Ø 优点：ü 基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决。用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。ü 提供了异种机、异种网、异种应用服务器的联机、联网、统一服务的最现实的开放性基础。Ø 缺点：ü 缺乏对动态页面的支持能力

7、，没有集成有效的数据库处理功能。ü 系统扩展能力差，安全性难以控制。ü 数据查询等响应速度上，要远远低于C/S体系结构。ü 数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理(OLTP)应用。第三章 软件需求与架构（15分）一、 软件需求的概念需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。二、 软件需求的流程三、 软件需求的分类l 按层分：Ø 业务需求：反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。领域专家Ø 用户需求：描述用户使用产品必须要完成什么

8、任务，怎么完成的需求。用户Ø 系统需求：从系统的角度来说明软件的需求。开发人员l 按类分：Ø 功能需求：系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作。Ø 非功能需求：产品必须具备的属性或品质，如正确性、可靠性、性能、容错性和可扩展性等。Ø 设计约束：对解决方案的一些约束说明。四、 软件需求面临的主要困难l 知识技能问题l 态度问题l 合作关系l 用户说不清楚需求l 双方误解需求l 开发人员写不好需求文档l 用户经常变更需求五、 需求工程l 定义：把所有与需求直接相关的活动通称为需求工程。l 需求工程创建的第一份文档是需求陈述，

9、用于在项目开发之初理解客户的需求。l 分类：Ø 需求开发：目的是通过调查与分析，获取用户需求并定义产品需求。包括：ü 需求调查（需求获取）的目的是通过各种途径获取用户的需求信息（原始材料），产生需求陈述。ü 需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。ü 需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生软件需求规格说明书。Ø 需求管理：目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。包括：&#

10、252; 需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。ü 需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。 ü 需求变更控制是指依据“变更申请审批更改重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。l 需求工程结构图：六、 需求获取技术l 获取需求的方法Ø 面谈（访谈）：开放式问题和封闭式问题 Ø 问卷调查：潜在使用者太多或分布太广时Ø 会议（需求讨论会、重点问题讨论会、业务专题讨论会、设

11、计专题讨论会）Ø 文档研究Ø 任务示范（观察）：通过观察可以获得第一手的资料。Ø 用例与角色扮演Ø 原型设计（小规模试验）Ø 研究类似公司l 需求陈述Ø 是一份文档，陈述用户对软件的期望和需要，并对可能的规格要求加以说明。Ø 需求陈述用来明确软件的用途，它不仅要说明软件有什么用，还要在宏观层次上明确软件应具备的特性。Ø 核心内容ü 开发该软件的动机（愿景）是什么？ü 该项目的主要涉众是谁？ü 希望该软件具备哪些主要功能和特性？七、 需求建模l 需求模型分类：Ø 功能模型如UC

12、见下章Ø 业务流程模型如DFDü 数据流图(Data Flow Diagram, DFD)是结构化方法中用于表示系统逻辑模型的一种工具，它以图形的方式描绘数据在系统中流动和处理的过程。Ø 数据建模模型如ERü ER建模用于对数据进行建模（概念模型）ü 在ER图中包含三个图形符号，分别表示：实体（矩形）、属性（椭圆）、联系（菱形）八、 编写软件需求规格说明书l 需求分析的主要成果：软件需求规格说明书(Software Requirement Specification, SRS)l 要求的属性：Ø 正确：最重要的属性。Ø 清楚

13、：让人易读易懂，不在于文档的厚度。Ø 无二义性：是指每个需求只有唯一的含义。Ø 一致：指软件需求规格说明书中各个需求之间不会发生矛盾。Ø 必要：其中的各项需求对用户而言应当都是必要的。Ø 完备：指软件需求规格说明书中没有遗漏一些必要的需求。Ø 可实现：其中各项需求对开发方而言应当都是可实现的。Ø 可验证：其中的各项需求对用户方而言应当都是可验证的。Ø 确定优先级：先做优先级高的需求，后做（甚至放弃）优先级低的需求，这样可以将风险降到最低。l 阐述“做什么”而不是“怎么做”九、 需求确认l 需求确认是指开发方和客户方共同对软件

14、需求规格说明书进行评审，双方对需求达成共识后作出承诺。l 包含两个重要工作：Ø 需求评审Ø 需求承诺十、 需求跟踪技术l 需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性，确保所有的工作成果符合用户需求。l 跟踪有两种方式： Ø 正向跟踪。检查软件需求规格说明书中的每个需求是否都能在后继工作成果中找到对应点。 Ø 逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在软件需求规格说明书中找到出处。l 跟踪矩阵Ø 源跟踪矩阵（需求与需求来源）Ø 功能跟踪矩阵（需求与功能）Ø 依赖跟踪矩阵（一个需求与另一个需

15、求）十一、 需求变更控制l 需求发生变更的起因主要有： Ø 随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。 Ø 市场发生了变化，原先的需求文档可能跟不上当前的市场需求，因此要变更需求。l 需求变更控制的目的：Ø 如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。Ø 如果需求变更带来的坏处大于好处，那么拒绝变更。l 需求基线Ø 已经通过正式评审和批准的规格说明或产品，它可以作为进一步开发的基础，并且只有通过正式的变更控制过

16、程才能修改它。Ø 是被明确和固定下来的需求集合，是项目团队需要在某一特定产品版本中实现的特征和需求集合。第五章 统一建模语言UML（20分）（Unified Modeling Language）（重点看实验1）一、 用例图（Use Case Diagram）l 执行者和用例之间的关联关系（Association）：一根直线来表示l 执行者之间的泛化关系（Generalization）（或继承关系）用例之间的关系：l 包含关系：描述在多个用例中都有的公共行为，由用例A指向用例B，表示用例A中使用了用例B中的行为或功能，包含关系是通过在依赖关系上应用<<include>

17、>构造型（衍型）来表示的。l 扩展关系：扩展用例可以在基用例之上添加新的行为，但是基用例必须声明某些特定的“扩展点”，并且扩展用例只能在这些扩展点上扩展新的行为。扩展关系是通过在依赖关系上应用<<extend>>构造型（衍型）来表示的。l 泛化关系：Ø 当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。Ø 在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。Ø 泛化关系一般很少使用。二、 状态图(State Diagram)l 定义：

18、用来描述一个特定对象的所有可能状态及其引起状态转移的事件。Ø 通常用状态图来描述单个对象的行为Ø 只有那些具有重要交互行为的类，才会使用状态图来描述。Ø 一个状态图包括一系列对象的状态及状态之间的转换。l 组成元素：Ø 初始状态Ø 终止状态Ø 状态Ø 转移Ø 守护条件Ø 事件Ø 动作三、 活动图（Activity Diagram）l 定义：用来表示系统中各种活动的次序，它的应用非常广泛，既可用来描述用例的工作流程，也可以用来描述类中某个方法的操作行为。l 作用：Ø 描述业务流程

19、6; 描述用例路径Ø 描述方法执行流程（程序流程图）l 组成元素：Ø 起始活动(Start Activity)Ø 终止活动(End Activity)Ø 活动(Activity)Ø 转移(Transition)或流(Flow)Ø 决策(Decision)Ø 守护条件(Condition)Ø 同步条(Synchronization)Ø 泳道(Swimlane)四、 顺序图l 定义：Ø 用于确认和丰富一个使用情境的逻辑。Ø 将交互关系表现为一个二维图，纵向是时间轴，时间沿竖线向下延伸。横向

20、轴代表了在协作中各独立对象的类元角色，类元角色的活动用生命线表示。l 组成元素：Ø 生命线：用一条纵向虚线表示。Ø 对象：表示为一个矩形，其中对象名称标有下划线。Ø 激活：是过程的执行，包括等待过程执行的时间。激活部分替换生命线，使用长条的矩形表示。Ø 消息：对象之间的通信ü 调用消息：对应于激活，表示它将会激活一个对象。ü 发送消息：没有对应激活框，表示它不是一个调用消息，不会引发其他对象的活动。ü 返回消息ü 自身消息ü 创建消息ü 销毁消息ü 同步消息ü 异步消息

21、16; 交互片段：一个复杂的顺序图可以划分为几个小块，每一个小块称为一个交互片段。ü alt:多条路径，条件为真时执行。ü opt:任选，仅当条件为真时执行。ü par:并行，每一片段都并发执行。ü loop:循环，片段可多次执行。ü critical:临界区，只能有一个线程对它立即执行。五、 类图l 类之间的关系：Ø 关联关系(Association)ü 用于表示一类对象与另一类对象之间有联系ü 用实线连接有关联的对象所对应的类ü 通常将一个类的对象作为另一个类的属性Ø 自关联ü 一

22、些类的属性对象类型为该类本身Ø 多重性关联 ü 表示一个类的对象与另一个类的对象连接的个数。Ø 聚合关系(Aggregation)ü 表示一个整体与部分的关系。ü 成员类是整体类的一部分，即成员对象是整体对象的一部分，但是成员对象可以脱离整体对象独立存在。ü 在UML中，聚合关系用带空心菱形的直线表示。Ø 组合关系(Composition)ü 部分和整体具有统一的生存期。ü 部分对象与整体对象之间具有同生共死的关系。ü 整体类可以控制成员类的生命周期，即成员类的存在依赖于整体类。ü 在

23、UML中，组合关系用带实心菱形的直线表示。Ø 依赖关系(Dependency)ü 使用关系。ü 体现在某个类的方法使用另一个类的对象作为参数。ü 在UML中，依赖关系用带箭头的虚线表示。Ø 泛化关系(Generalization)ü 用于描述父类与子类之间的关系，父类又称作基类或超类，子类又称作派生类。ü 在UML中，泛化关系用带空心三角形的直线来表示。Ø 接口与实现关系(Realization)ü 类实现了接口，类中的操作实现了接口中所声明的操作。ü 在UML中，类与接口之间的实现关系用带空心

24、三角形的虚线来表示。六、 包图l 定义Ø 一种把元素组织到一起的通用机制Ø 用于描述包与包之间的关系Ø 包的图标是一个带标签的文件夹。l 包之间的关系Ø 引入关系：ü 一个包中的类可以被另一个指定包（以及嵌套于其中的那些包）中的类引用。ü 在依赖线上增加一个<<import>>衍型。Ø 泛化关系：表示一个包继承了另一个包的内容，同时又补充自己增加的内容。Ø 嵌套关系：一个包中可以包含若干个子包，构成了包的嵌套层次结构。七、 组件图（Component Diagram）l 定义：Ø

25、显示编译、链接或执行时组件之间的依赖关系，以及组件的接口和调用关系。Ø 组件就是一个实际文件，可以有以下几种类型：ü 源代码组件：一个源代码文件或者与一个包对应的若干个源代码文件。ü 二进制组件：一个目标码文件，一个静态的或者动态的库文件。ü 可执行组件：在一台处理器上可运行的一个可执行的程序单位，即所谓可执行程序。l 组件间关系：泛化关系、依赖关系l 组成元素：Ø 组件：系统中可以替换的部分，一般对应一个实际文件，如exe、jar、dll等文件，它遵循并提供了一组接口的实现。Ø 接口：一组操作的集合，它指明了由类或组件所请求或者所提

26、供的服务。Ø 部件：组件的局部实现。Ø 端口：被封装的组件与外界的交互点，遵循指定接口的组件通过它来收发消息。Ø 连接件：在特定语境下组件中两个部件之间或者两个端口之间的通信关系。Ø 供(Provided)接口与需(Required)接口八、 部署图(Deployment Diagram)l 定义：Ø 描述系统硬件的物理拓扑结构及在此结构上执行的软件。Ø 显示了系统的硬件和安装在硬件上的软件，以及用于连接异构计算机之间的中间件。l 组成元素：Ø 节点和连接：节点(Node)代表一个物理设备。在 UML 中，使用一个立方体表示

27、一个节点。节点之间的连线表示系统之间进行交互的通信路径，在 UML 中被称为连接。Ø 组件：在部署图中，组件代表可执行的物理代码模块，如一个可执行程序，逻辑上它可以与类或包对应。九、 对象图l 定义：对象图是类图在某一时刻的一个实例。十、 组合结构图l 定义：Ø 将每一个类放在一个整体中，从类的内部结构来审视一个类。Ø 组合结构图可用于表示一个类的内部结构。l 组成元素：Ø 部件(Part)：表示被描述事物所拥有的内部成分。Ø 连接件(Connector)：表示部件之间的关系。Ø 端口(Port)：表示部件和外部环境的交互点。十一、

28、通信图l 定义：Ø 通信图强调参与一个交互对象的组织。Ø 它与顺序图是同构图，也就是它们包含了相同的信息，只是表达方式不同而已，通信图与顺序图可以相互转换。Ø 当对象及其连接有利于理解交互时，选择通信图；当只需了解交互的次序时，选择顺序图。l 组成元素：执行者(Actor)、对象(Object)、连接(Link，也称为链)、消息(Message)和守护条件(Condition)。十二、 定时图l 定义：Ø 采用一种带数字刻度的时间轴来精确地描述消息的顺序Ø 可视化地表示每条生命线的状态变化Ø 可以把状态发生变化的时刻以及各个状态所持续

29、的时间具体地表示出来。十三、 交互概览图l 定义：Ø 交互图与活动图的混合物，可以把交互概览图理解为细化的活动图，在其中的活动都通过一些小型的顺序图来表示；也可以将其理解为利用标明控制流的活动图分解过的顺序图。Ø 用于将一些零散的顺序图组织在一起，它采用了活动图的构造方式，利用了活动图的各种控制节点，并把活动图的每个活动结点替换为一个交互或者交互使用。每个交互或者交互使用都使用一个顺序图表示。面向对象设计原则1、 单一职责原则(Single Responsibility Principle, SRP)定义：一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。Ev

30、ery object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.2、 开闭原则(Open-Closed Principle, OCP)定义：一个软件实体应当对扩展开放，对修改关闭。Software entities should be open for extension, but closed for modification.3、 里氏代换原则(Liskov Substitution Principle, LSP)定义：所

31、有引用基类（父类）的地方必须能透明地使用其子类的对象。Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.4、 依赖倒转原则(Dependence Inversion Principle, DIP)定义：高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象。High level modules should not depend upon low level mod

32、ules, both should depend upon abstractions. Abstractions should not depend upon details, details should depend upon abstractions.5、 接口隔离原则(Interface Segregation Principle, ISP)定义：客户端不应该依赖那些它不需要的接口。Clients should not be forced to depend upon interfaces that they do not use.6、 合成复用原则(Composite Reuse P

33、rinciple, CRP)定义：尽量使用对象组合，而不是继承来达到复用的目的。Favor composition of objects over inheritance as a reuse mechanism.7、 迪米特法则(Law of Demeter, LoD)定义：一个软件实体应当尽可能少的与其他实体发生相互作用。设计模式（重点看实验2、3）一、 创建型模式l 简单工厂模式（Simple Factory）Ø 定义：根据参数的不同返回不同类的实例，专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。Ø 优点：ü 实现了对责任的分割，它

34、提供了专门的工厂类用于创建对象。ü 客户端无须知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可。ü 通过引入配置文件，可以在不修改任何客户端代码的情况下更换和增加新的具体产品类，在一定程度上提高了系统的灵活性。Ø 缺点：ü 工厂类集中了所有产品创建逻辑，职责过重，不符合单一职责原则。ü 增加系统中类的个数。ü 系统扩展困难，不符合开闭原则。ü 由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构。Ø 适用范围：ü 工厂类负责创建的对象比较少。ü 客户端只知道传入工厂类

35、的参数，对于如何创建对象不关心。l 工厂方法模式(Factory Method Pattern)Ø 定义：ü 工厂父类负责定义创建产品对象的公共接口，而工厂子类则负责生成具体的产品对象，这样做的目的是将产品类的实例化操作延迟到工厂子类中完成，即通过工厂子类来确定究竟应该实例化哪一个具体产品类。ü Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer inst

36、antiation to subclasses.Ø 优点：ü 用户只需要关心所需产品对应的工厂，无须关心创建细节，甚至无须知道具体产品类的类名。ü 工厂可以自主确定创建何种产品对象，而如何创建这个对象的细节则完全封装在具体工厂内部。ü 在系统中加入新产品时，无须修改抽象工厂和抽象产品提供的接口，无须修改客户端，也无须修改其他的具体工厂和具体产品，而只要添加一个具体工厂和具体产品就可以了。Ø 缺点：ü 在添加新产品时，需要编写新的具体产品类，而且还要提供与之对应的具体工厂类，系统中类的个数将成对增加，在一定程度上增加了系统的复杂度。&#

37、252; 增加了系统的抽象性和理解难度。Ø 适用范围：ü 一个类不知道它所需要的对象的类。ü 一个类通过其子类来指定创建哪个对象。ü 将创建对象的任务委托给多个工厂子类中的某一个，客户端在使用时可以无须关心是哪一个工厂子类创建产品子类，需要时再动态指定。l 抽象工厂模式(Abstract Factory Pattern)Ø 定义：ü 提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。ü Provide an interface for creating families of related or depe

38、ndent objects without specifying their concrete classes.Ø 优点：ü 隔离了具体类的生成。ü 可以实现高内聚低耦合的设计目的。ü 能够保证客户端始终只使用同一个产品族中的对象。ü 增加新的具体工厂和产品族很方便，无须修改已有系统，符合“开闭原则”。Ø 缺点：ü 难以扩展抽象工厂来生产新种类的产品。ü 开闭原则的倾斜性（增加新的工厂和产品族容易，增加新的产品等级结构麻烦）Ø 适用范围：ü 一个系统不应当依赖于产品类实例如何被创建、组合和表达的

39、细节。ü 系统中有多于一个的产品族，而每次只使用其中某一产品族。ü 属于同一个产品族的产品将在一起使用。ü 系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于具体实现。l 单例模式(Singleton Pattern)Ø 定义：ü 确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例，这个类称为单例类，它提供全局访问的方法。ü Ensure a class has only one instance and provide a global point of access to it.Ø 优

40、点：ü 提供了对唯一实例的受控访问。ü 可以节约系统资源ü 允许可变数目的实例。Ø 缺点：ü 单例类的扩展有很大的困难。ü 单例类的职责过重。ü 滥用单例将带来一些负面问题。Ø 适用范围：ü 系统只需要一个实例对象。ü 客户调用类的单个实例只允许使用一个公共访问点。二、 结构型模式l 适配器模式(Adapter Pattern)Ø 定义：ü 将一个接口转换成客户希望的另一个接口，适配器模式使接口不兼容的那些类可以一起工作，其别名为包装器(Wrapper)。适配器模式既可以作为

41、类结构型模式，也可以作为对象结构型模式。ü Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.类适配器对象适配器Ø 优点：ü 将目标类和适配者类解耦。ü 增加了类的透明性和复用性。ü 灵活性和扩展性都非常好。Ø 缺点：ü 类适配器模式的缺点

42、是适配器类在很多编程语言中不能同时适配多个适配者类。ü 对象适配器模式的缺点是很难置换适配者类的方法。Ø 适用范围：ü 系统需要使用现有的类，而这些类的接口不符合系统的需要。ü 想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类一起工作。l 桥接模式(Bridge Pattern)Ø 定义：ü 将抽象部分与它的实现部分分离，使它们都可以独立地变化。ü Decouple an abstraction from its implementation so that the two can vary indepe

43、ndently.Ø 优点：ü 分离抽象接口及其实现部分。ü 桥接模式是比多继承方案更好的解决方法。ü 提高了系统的可扩充性，在两个变化维度中任意扩展一个维度，都不需要修改原有系统。ü 实现细节对客户透明，可以对用户隐藏实现细节。Ø 缺点：ü 会增加系统的理解与设计难度。ü 其使用范围具有一定的局限性。Ø 适用范围：ü 需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的继承联系。ü 抽象化角色和实现化角色可以以继承的方式独立扩展而互不影响。ü

44、一个类存在两个独立变化的维度，且这两个维度都需要进行扩展。ü 设计要求需要独立管理抽象化角色和具体化角色。ü 不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统。l 组合模式(Composite Pattern)Ø 定义：组合多个对象形成树形结构以表示“整体-部分”的结构层次。组合模式对单个对象（即叶子对象）和组合对象（即容器对象）的使用具有一致性。Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat i

45、ndividual objects and compositions of objects uniformly.Ø 优点：ü 可以清楚地定义分层次的复杂对象。ü 客户端可以一致的使用组合结构或其中单个对象。ü 更容易在组合体内加入对象构件。Ø 缺点：ü 设计变得更加抽象。ü 很难对容器中的构件类型进行限制。Ø 适用范围：ü 需要表示一个对象整体或部分层次。ü 客户端可以针对抽象构件编程，无须关心对象层次结构的细节。ü 对象的结构是动态的并且复杂程度不一样，但客户需要一致地处理它们。l

46、外观模式(Facade Pattern)Ø 定义：ü 外部与一个子系统的通信必须通过一个统一的外观对象进行，为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。ü Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.Ø 优点：ü 对客户屏蔽子系统组件，减少了

47、客户处理的对象数目并使得子系统使用起来更加容易。ü 实现了子系统与客户之间的松耦合关系。ü 降低了大型软件系统中的编译依赖性，并简化了系统在不同平台之间的移植过程。ü 只是提供了一个访问子系统的统一入口，并不影响用户直接使用子系统类。Ø 缺点：ü 不能很好地限制客户使用子系统类。ü 在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。Ø 适用范围：ü 当要为一个复杂子系统提供一个简单接口时可以使用外观模式。ü 客户程序与多个子系统之间存在很大的依赖性。

48、2; 使用外观模式定义系统中每一层的入口，层与层之间不直接产生联系，而通过外观类建立联系，降低层之间的耦合度。l 代理模式(Proxy Pattern)Ø 定义：ü 给某一个对象提供一个代理，并由代理对象控制对原对象的引用。ü Provide a surrogate or placeholder for another object to control access to it.Ø 优点：ü 协调调用者和被调用者。ü 远程代理使得客户端可以访问在远程机器上的对象。ü 虚拟代理通过使用一个小对象来代表一个大对象，可以减少系统

49、资源的消耗，对系统进行优化并提高运行速度。ü 保护代理可以控制对真实对象的使用权限。Ø 缺点：ü 有些类型的代理模式可能会造成请求的处理速度变慢。ü 实现代理模式需要额外的工作，有些代理模式的实现非常复杂。Ø 适用范围：ü 远程(Remote)代理。ü 虚拟(Virtual)代理。ü Copy-on-Write代理。ü 保护(Protect or Access)代理。ü 缓冲(Cache)代理。ü 防火墙(Firewall)代理。ü 同步化(Synchronization)代

50、理。ü 智能引用(Smart Reference)代理。三、 行为型模式l 职责链模式(Chain of Responsibility Pattern)Ø 定义：避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objec

51、ts and pass the request along the chain until an object handles it.Ø 优点：ü 降低耦合度。ü 可简化对象的相互连接。ü 增强给对象指派职责的灵活性。ü 增加新的请求处理类很方便。Ø 缺点：ü 不能保证请求一定被接收。ü 系统性能将受到一定影响，而且在进行代码调试时不太方便；可能会造成循环调用。Ø 适用范围：ü 有多个对象可以处理同一个请求，具体哪个对象处理该请求由运行时刻自动确定。ü 在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。ü 可动态指定一组对象处理请求。l 命令模式(Command Pattern)Ø 定义：ü 将一个请求封装为一个对象，从而使我们可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。ü Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queu