软件架构风格和设计原则.pptx

第三讲 软件构架风格设计原则 贾育 博士 中培教育-中国信息化培训中心 2011高级系统架构师培训班（上海） 第一部分 软件架构风格 建筑风格古希腊、古罗马建筑 苏尼恩角上海神庙 古罗马大斗兽场 建筑风格中国建筑 Christopher Alexander, The Timeless Way of Building, p247, 1979 每个模式是一个由三部分组成的规则，表达了特定环特定环 境境、问题问题和解决方式解决方式(solution)之间的关系。 作为现实世界的一个成分，每个模式表达了下列三者之 间的一种关系：特定环境，在该环境中反复出现的因素 forces)的系统，以及协调这些因素的某种方案。 作为语言的一个成分，每个模式是一条指令，展示了这 种方案如何被一再重复使用重复使用，目的是协调同特定环境相 关的因素的系统。 简单地说，模式既是存在于现实世界中的事物，又是告模式既是存在于现实世界中的事物，又是告 诉我们如何以及何时创造该事物的规则。诉我们如何以及何时创造该事物的规则。模式既是过程 ，又是事物；既是活生生的事物的描述，又是创造该事 物的过程的描述。 建筑模式 软件构架风格软件构架风格(Architectural style)又称为软件 构架模式(Architectural pattern) 软件构架风格描述某一特定应用领域中系统组织 方式的惯用模式，以结构组织模式定义了一个系 统家族 关于构件和连接件类型的术语词汇表 一组约束它们组合方式的规定 一个或多个语义模型，规定了如何从各成分的特性决定 系统整体特性 概括地说，一种软件构架风格刻划一个具有共享 结构和语义的系统家族 软件构架风格概念 构件和连接件的类型是什么？ 可允许的结构模式是什么？ 基本的计算模型是什么？ 风格的基本不变性是什么？ 其使用的常见例子是什么？ 使用此风格的优缺点是什么？ 常见的特例是什么？ 关键要素：提供一个词汇表、定义一套配置规则、定义 一套语义解释原则以及定义对基于这种风格的系统所进 行的分析 讨论构架风格时要回答的问题 典型的构架风格 其他典型构架风格 每个构件都有一组输入和输出输入和输出，构件读输入的数 据流，经过内部处理，然后产生输出数据流。这 个过程通常通过对输入流的变换及增量计算变换及增量计算来完 成，所以在输入被完全消费之前，输出便产生 了。 这里的构件被称为过滤器过滤器，这种风格的连接件 就象是数据流传输的管道管道，将一个过滤器的输出 传到另一过滤器的输入。 管道和过滤器 实例 以Unix Shell编写的程序，Unix既提供一种符号，以连接 各组成部分（Unix的进程），又提供某种进程运行时机 制以实现管道 传统的编译器，一个阶段的输出是另一个阶段的输入（包 括词法分析、语法分析、语义分析和代码生成） 管道和过滤器 优点 使得软构件具有良好的隐蔽性隐蔽性和高内聚、低耦合高内聚、低耦合的特点 ； 允许设计者将整个系统的输入/输出行为看成是多个过过 滤器的行为的简单合成滤器的行为的简单合成； 支持软件复用软件复用。只要提供适合在两个过滤器之间传送的 数据，任何两个过滤器都可被连接起来； 系统维护和增强系统性能简系统维护和增强系统性能简单。新的过滤器可以添加到 现有系统中来；旧的可以被改进的过滤器替换掉； 允许对一些如吞吐量、死锁等属性的分析属性的分析 支持并行执行并行执行。每个过滤器是作为一个单独的任务完成 ，因此可与其它任务并行执行 管道和过滤器 缺点 通常导致进程成为批处理导致进程成为批处理的结构。这是因为虽然过滤器 可增量式地处理数据，但它们是独立的，所以设计者必 须将每个过滤器看成一个完整的从输入到输出的转换； 不适合处理交互不适合处理交互的应用。当需要增量地显示改变时，这 个问题尤为严重； 因为在数据传输上没有通用的标准数据传输上没有通用的标准，每个过滤器都增加 了解析和合成数据的工作，这样就导致了系统性能下降导致了系统性能下降 ，并增加了编写过滤器的复杂性。 管道和过滤器 这种风格建立在数据抽象数据抽象和面向对象面向对象的基础上，数据数据的 表示方法和它们的相应操作操作封装在一个抽象数据类型或 对象中。 这种风格的构件是对象构件是对象，或者说是抽象数据类型的实 例。对象是一种被称作管理者的构件，因为它负责保持 资源的完整性。对象是通过函数和过程的调用来交互调用来交互 的。 数据抽象和面向对象组织 优点 因为对象对其它对象隐藏对象隐藏它的表示，所以可以改变一个 对象的表示，而不影响其它的对象； 设计者可将一些数据存取操作的问题分解成一些交互交互的 代理程序的集合。 缺点 为了使一个对象和另一个对象通过过程调用等进行交互 ，必须知道对象的标知道对象的标识。只要一个对象的标识改变了， 就必须修改所有其他明确调用它的对象； 必须修改所有显式调用它的其它对象，并消除由此带来 的一些副作副作用。例如，如果A使用了对象B，C也使用了 对象B，那么，C对B的使用所造成的对A的影响可能是 料想不到的。 数据抽象和面向对象组织 构件不直接调用一个过程，而是触发或广播一个或多个触发或广播一个或多个 事件事件。系统中的其它构件中的过程在一个或多个事件中 注册，当一个事件被触发，系统自动调用系统自动调用在这个事件中 注册的所有过程，这样，一个事件的触发就导致了另一 模块中的过程的调用。 这种风格的构件是一些模块构件是一些模块，模块既可以是一些过程， 又可以是一些事件的集合。过程可以用通用的方式调用 ，也可以在系统事件中注册一些过程，当发生这些事件 时，过程被调用。 这种风格的主要特点是事件的触发者并不知道哪些构件并不知道哪些构件 会被这些事件影响会被这些事件影响。这样不能假定构件的处理顺序，甚 至不知道哪些过程会被调用，因此，许多隐式调用隐式调用的系 统也包含显式调用作为构件交互的补充形式。 基于事件的隐式调用 实例 在编程环境中用于集成各种工具 数据库管理系统中确保数据的一致性约束 用户界面系统中管理数据 Debugger的断点事件 当Debugger在断点处停下时，该事件触发系统自动调用处 理程序，如编辑程序卷屏到断点，变量监视器刷新变量数 值。而Debugger本身只声明事件，并不关心哪些过程会启 动，也不关心这些过程做什么处理 基于事件的隐式调用 优点 为软件复用软件复用提供了强大的支持。当需要将一个构件加入现 存系统中时，只需将它注册到系统的事件中。 为改进系统改进系统带来了方便。当用一个构件代替另一个构件时 ，不会影响到其它构件的接口。 基于事件的隐式调用 缺点 构件放弃了对系统计算的控制放弃了对系统计算的控制。一个构件触发一个事件时 ，不能确定其它构件是否会响应它。而且即使它知道事件 注册了哪些构件的构成，它也不能保证这些过程被 调用 的顺序。 数据交换的问题。有时数据可被一个事件传递，但另一些 情况下，基于事件的系统必须依靠一个共享的仓库进行交 互。在这些情况下，全局性能和资源管理全局性能和资源管理便成了问题。 既然过程的语义必须依赖于被触发事件的上下文约束，关 于正确性的推理存在问题正确性的推理存在问题。 基于事件的隐式调用 层次系统组织成一个层次结构，每一层为上层服务，并作为下层客每一层为上层服务，并作为下层客 户。户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的 层只对相邻的层可见。这样的系统中构件在一些层实现了虚拟机（ 在另一些层次系统中层是部分不透明的）。连接件通过决定层间如 何交互的协议交互的协议来定义，拓扑约束包括对相邻层间交互的约束。 这种风格支持基于可增加抽象层抽象层的设计。允许将一个复杂问题分解复杂问题分解 成一个增量步骤序列的实现。由于每一层最多只影响两层，同时只 要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为 软件复用提供了强大的支持 分层系统 实例 分层通信协议，每一层提供一个抽象的功能作为上层通信 的基础，较低层次定义低层的交互，最底层通常只定义物 理连接 分层系统 优点 支持基于抽象程度递增抽象程度递增的系统设计，使设计者可以把一个复杂系 统按递增的步骤进行分解； 支持功能增强功能增强，因为每一层至多和相邻的上下层交互，因此功能 的改变最多影响相邻的上下层； 支持复用复用。只要提供的服务接口定义不变，同一层的不同实现可 以交换使用。这样，就可以定义一组标准的接口，而允许各种不 同的实现方法。 缺点 并不是每个系统都可以很容易地划分为分层的模式，甚至即使一 个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设 计师不得不把一些低级或高级的功能综合起来； 很难找到一个合适的、正确的层次抽象方法。 分层系统 在仓库风格中，有两种不同的构件：中央数据结构中央数据结构说明 当前状态，独立构件独立构件在中央数据上执行，仓库与外构件 间的相互作用在系统中会有大的变化。 控制原则的选取产生两个主要的子类。若输入流中某类 时间触发进程执行的选择，则仓库是一传统型数据库传统型数据库； 另一方面，若中央数据结构的当前状态触发进程执行的 选择，则仓库是一黑板系统黑板系统。 实例 信号处理领域，如语音和模式识别 松耦合数据共享 仓库系统及知识库 黑板系统的组成 知识源知识源：知识源中包含独立的、与应用程序相关的知识，知 识源之间不直接进行通信，它们之间的通信通过黑板来完成 黑板数据结构黑板数据结构：黑板数据是按照与应用程序相关的层次来组 织的解决问题的数据，知识源通过不断地改变黑板数据来解 决问题 控制控制：控制完全由黑板的状态驱动，黑板状态的改变决定使 用的特定知识 仓库系统及知识库 产生背景 在集中式计算技术时代广泛使用的是大型机/小型机计算 模型。它是通过一台物理上与宿主机相连接的非智能终端 来实现宿主机上的应用程序。 20世纪80年代以后，集中式结构逐渐被以PC机为主的微 机网络所取代。个人计算机和工作站的采用，永远改变了 协作计算模型，从而导致了分散的个人计算模型的产生。 客户/服务器风格 基本概念 C/S软件构架是基于资源不对等，且为实现共享而提出来 的，是20世纪90年代成熟起来的技术，C/S构架定义了 工作站如何与服务器相连，以实现数据和应用分布到多个 处理机上。 C/S构架有三个主要组成部分：数据库服务器、客户应用数据库服务器、客户应用 程序和网络程序和网络。 客户/服务器风格 构架 客户/服务器风格 任务分配 服务器 数据库安全性的要求； 数据库访问并发性的控制； 数据库前端的客户应用程序的全局数据完整性规则 数据库的备份与恢复。 客户应用程序 提供用户与数据库交互的界面； 向数据库服务器提交用户请求并接收来自数据库服务器的信 息； 利用客户应用程序对存在于客户端的数据执行应用逻辑要 求。 客户/服务器风格 处理流程 客户/服务器风格 优点 C/S 构架具有强大的数据操作和事务处理能力强大的数据操作和事务处理能力，模型思想简 单，易于人们理解和接受。 系统的客户应用程序和服务器构件分别运行在不同的计算机 上，系统中每台服务器都可以适合各构件的要求，这对于硬 件和软件的变化显示出极大的适应性和灵活适应性和灵活性，而且易于对 系统进行扩充和缩小。 在C/S构架中，系统中的功能构件充分隔离功能构件充分隔离，客户应用程序 的开发集中于数据的显示和分析，而数据库服务器的开发则 集中于数据的管理，不必在每一个新的应用程序中都要对一 个DBMS进行编码。将大的应用处理任务分布到许多通过网 络连接的低成本计算机上，以节约大量费用。 客户/服务器风格 缺点 开发成本较高 客户端程序设计复杂 信息内容和形式单一 用户界面风格不一，使用繁杂，不利于推广使用 软件移植困难 软件维护和升级困难 新技术不能轻易应用 客户/服务器风格 构架 三层客户/服务器风格 处理流程 三层客户/服务器风格 物理结构 三层客户/服务器风格 优点 允许合理地划分三层结构的功能，使之在逻辑上保持相逻辑上保持相 对独立性对独立性，能提高系统和软件的可维护性和可扩展性。 允许更灵活有效地选用相应的平台和硬件系统，使之在 处理负荷能力负荷能力上与处理特性上分别适应于结构清晰的三 层；并且这些平台和各个组成部分可以具有良好的可升升 级性和开放性级性和开放性。 应用的各层可以并行开发并行开发，可以选择各自最适合的开发 语言。 用功能层有效地隔离开表示层与数据层，未授权的用户 难以绕过功能层而利用数据库工具或黑客手段去非法地 访问数据层，为严格的安全管理安全管理奠定了坚实的基础。 三层客户/服务器风格 要注意的问题 三层C/S结构各层间的通信效率若不高，即使分配给各层 的硬件能力很强，其作为整体来说也达不到所要求的性 能。 设计时必须慎重考虑三层间的通信方法、通信频度及数据 量。这和提高各层的独立性一样是三层C/S结构的关键问 题 三层客户/服务器风格 基本概念 浏览器/服务器（B/S）风格就是上述三层应用结构的一 种实现方式，其具体结构为：浏览器/Web服务器/数据库 服务器。 B/S构架主要是利用不断成熟的WWW浏览器技术，结合 浏览器的多种脚本语言，用通用浏览器就实现了原来需要 复杂的专用软件才能实现的强大功能，并节约了开发成 本。从某种程度上来说，B/S结构是一种全新的软件构 架。 浏览器/服务器风格 构架 浏览器/服务器风格 优点 基于B/S构架的软件，系统安装、修改和维护全在服务器 端解决。用户在使用系统时，仅仅需要一个浏览器就可运 行全部的模块，真正达到了“零客户端”的功能，很容易 在运行时自动升级。 B/S构架还提供了异种机、异种网、异种应用服务的联 机、联网、统一服务的最现实的开放性基础。 浏览器/服务器风格 缺点 B/S构架缺乏对动态页面的支持能力，没有集成有效的数 据库处理功能。 B/S构架的系统扩展能力差，安全性难以控制。 采用B/S构架的应用系统，在数据查询等响应速度上，要 远远地低于C/S构架。 B/S构架的数据提交一般以页面为单位，数据的动态交互 性不强，不利于在线事务处理(OLTP)应用。 浏览器/服务器风格 正交软件构架由组织层和线索的构件构成。层层是由一组具有相同抽 象级别的构件构成。线索线索是子系统的特例，它是由完成不同层次功 能的构件组成（通过相互调用来关联），每一条线索完成整个系统 中相对独立的一部分功能。每一条线索的实现与其他线索的实现无 关或关联很少，在同一层中的构件之间是不存在相互调用的。 如果线索是相互独立的，即不同线索中的构件之间没有相互调用， 那么这个结构就是完全正交的。 正交软件构架 正交软件构架是一种以垂直线索构件族垂直线索构件族为基础的 层次化结构，基本思想是把应用系统的结构按功按功 能地正交性能地正交性，垂直分割为若干个线索（子系统） ，线索又被分为几个层次，每个线索由多个具有 不同层次功能和不同抽象级别的构件组成。 特征 正交软件构架由完成不同功能的n（n 1）个线索（ 子系统）组成； 系统具有m（m 1）个不同抽象级别的层； 线索之间是相互独立的（正交的）； 系统有一个公共驱动层（一般为最高层）和公共数据结 构（一般为最低层）。 正交软件构架 优点 结构清晰，易于理解。结构清晰，易于理解。由于线索功能相互独立，不进行 互相调用，结构简单、清晰，构件在结构图中的位置已 经说明它所实现的是哪一级抽象，担负的是什么功能。 修改，可维护性强。修改，可维护性强。由于线索之间是相互独立的，所以 对一个线索的修改不会影响到其他线索。系统功能的增 加或减少，只需相应的增删线索构件族，而不影响整个 正交构架，因此能方便地实现结构调整。 可移植性强，复用粒度大。可移植性强，复用粒度大。因为正交结构可以为一个领 域内的所有应用程序所共享，这些软件有着相同或类似 的层次和线索，可以实现构架级的复用。 正交软件构架 背景 计算机网络的发展，特别是分布式构件技术分布式构件技术的日渐成熟和构件 互操作标准的出现，加速了基于分布式构件的软件开发趋势， 强调分布和并发分布和并发的特点 基于事件驱动的编程模式基于事件驱动的编程模式在对多个不同事件响应的情况下，系 统自动调用相应的处理函数，程序具有清晰的结构 计算机硬件构架和总线总线的概念为软件构架的研究提供了借鉴和 启发。在统一的构架框架下，系统具有良好的扩展性和适应性 基于层次消息总线的构架 特点 消息总线 系统的连接件，负责消息的分派、传递和过滤以及处理结果的 返回。 各个构件构件挂在消息总线上，向总线登记感兴趣的消息类型。构 件根据需要发出消息，由消息总线把该消息分派到系统中所有 对此感兴趣的消息类型，消息是构件之间通信的唯一方式。 由于构件通过总线进行连接，并不要求各个构件具有相同的地地 址空间址空间或者局限在同一台机器上。 复杂构件 复杂构件可以分解为子构件，由局部消息总线进行连接 子构件可以采用不同于层次消息总线（HMB）的风格 基于层次消息总线的构架 HMB风格的构件模型 接口：一个构件可以支持多个不同的接口，每个接口定义了一组 输入和输出的消息刻画了构件对外提供的服务以及要求的环境服 务，体现了该构件与环境的交互 构件行为：用有限自动机刻画，构件接受到外部消息后，根据当 前的所处的状态对消息进行响应，并刻画可能导致的状态变迁 构件结构：复合构件的内部结构定义 基于层次消息总线的构架 构件接口 HMB风格的构件接口是一种基于消息的互联接口，可以较好地支 持构架设计。构件之间通过消息进行通讯，接口定义了构件发出 和接收的消息集合。 当某个事件发生后，系统或构件发出相应的消息，消息总线负责 把该消息传递到此消息感兴趣的构件。 按照响应方式的不同，消息可分为同步消息和异步消息。 特点 构件只对消息本身感兴趣，并不关心消息是如何产生的，消息的 发出者和接收者不必知道彼此的情况，这样切断了构件之间的直 接联系，降低了构件之间的耦合程度，增强构件的复用潜力 构件对外来的消息进行响应后可能会引起状态的变迁，因此，一 个构件接收到同样的消息后，在不同的状态下，可能会有不同的 响应 基于层次消息总线的构架 消息总线是系统的连接件，构件向消息总线登记感兴趣 的消息，形成构件消息响应登记表。消息总线根据接 收到的消息类型和构件消息响应登记表的信息，定位 并传递该消息给相应的响应者，并负责返回处理结果。 必要时，消息总线还对特定的消息进行过滤和阻塞 基于层次消息总线的构架 消息登记 构件向消息总线登记当前该响应的消息集合，只对消息类型感兴 趣，并不关心谁发出的消息 对挂在同一消息总线的构件而言，消息是一种共享的资源，构件 消息响应登记表记录了该总线上所有构件和消息的响应关系 消息分派和传递 消息总线负责消息在构件之间的传递，根据构件消息响应登记 表把消息分派到对此感兴趣的构件，并负责处理返回结果 消息过滤 不同来源的构件事先并不知道各自的接口，因此可能同一消息在 不同的构件中使用了不同的名字，或者不同的消息使用了相同的 名字，这样就造成构件集成时消息的冲突和不匹配 消息转换针对构件实例而言，即所有构件实例发出和接收的消息 类型都经过总线的过滤，采用简单换名的方法 消息阻塞是在消息总线没有发现响应消息的情况下使用的，可以 对系统发出警告，或者通知消息的发送构件 基于层次消息总线的构架 构件静态结构 基于层次消息总线的构架 构件动态结构 构件的行为就由外来消息的类型唯一确定，即一个消息 和构件的某个操作之间存在着固定的对应关系。对于这 类构件，可以认为构件只有一个状态，或者在每次对消 息响应之前，构件处于初始状态。 HMB中构件的行为同时受外来消息类型和自身当前所 处状态的影响，因此需要构件在对两个消息之间的响应 之间，保持其状态信息 HMB中采用带输出的有限状态机描述构件的行为 基于层次消息总线的构架 运行时刻的系统演化 动态增加或删除构件 当系统功能需要扩充时，往系统增加新的构件，向系统登记其 感兴趣的消息 当系统功能进行裁减时，或者某个构件除了问题时，需要删除 某个构件，一是阻塞那些没有构件响应的消息，二是首先使系 统中的其它构件或者增加新的构件对该消息进行响应，然后删 除相应的构件 用带有增强功能或修正了错误的新构件替代原有的旧版本 动态改变构件响应的消息类型 构件需要动态地改变对外提供的服务时，可以通过消息总线对 发生的改变进行重新登记 消息过滤 利用消息过滤机制解决构件集成的不匹配问题。消息过滤通过 阻塞构件对某些消息的响应，提供了动态改变构件对消息进行 响应的方式 基于层次消息总线的构架 ZIS支持下的应用结构 应用应用3 3代理代理 应用应用1 + 1 + 代理代理 应用应用n n代理代理 区 域 集 成 服 务 器 应用应用2 2代理代理 基于层次消息总线的多ZIS集成 区域集成服务器(ZIS)结构 代理(Agent)结构 XXX市组织系统结构 XXXXXX市委市委 区委区委1 1区委 区委2 2县委 县委 街道街道1 1街道街道2 2街道街道1 1街道街道2 2乡镇乡镇1 1乡镇乡镇2 2 XXX市组织干部全员管理系统 XXXXXX市委市委 区委区委1 1 区委区委2 2 县委县委 街道街道1 1 街道街道2 2 街道街道1 1 街道街道2 2 乡镇乡镇2 2 乡镇乡镇1 1 区域集 成 服务器 代理程序代理程序各节点应用各节点应用 区域集 成 服务器 区域集 成 服务器 区域集 成 服务器 为什么要使用异构结构 不同的结构有不同的处理能力的强项和弱点，一个系统 的构架应该根据实际需要进行选择，以解决实际问题。 关于软件包、框架、通信以及其他一些构架上的问题 ，目前存在多种标准。即使在某段时间内某一种标准占 统治地位，但变动最终是绝对的。 实际工作中，我们总会遇到一些遗留下来的代码，它 们仍有效用，但是却与新系统有某种程度上的不协调。 然而在许多场合，将技术与经济综合进行考虑时，总是 决定不再重写它们。 即使在某一单位中，规定了共享共同的软件包或相互 关系的一些标准，仍会存在解释或表示习惯上的不同 异构结构风格 C/S与B/S混合之“内外有别”模型 优点：外部用户不直接访问数据库服务器，能保证企业数据库的 相对安全，企业内部用户的交互性较强，数据查询和修改的响应 速度较快 缺点：企业外部用户维护数据时，速度较慢且繁琐，数据的动态 交互性不强 异构结构风格 C/S与B/S混合之“查改有别”模型 集成了B/S和C/S的优点 缺点：外部用户直接通过Internet连接到数据库服务器 ，企业数据容易暴露给外部用户，给数据安全造成威胁 异构结构风格 异构实例 异构结构风格 定义 Hayes-Roth对DSSA的定义如下:“DSSA就是专用于一 类特定类型的任务（领域）的、在整个领域中能有效地 使用的、为成功构造应用系统限定了标准的组合结构的 软件构件的集合”。 Tracz的定义为：“DSSADSSA就是一个特定的问题领域中就是一个特定的问题领域中 支持一组应用的领域模型、参考需求、参考构架等组成支持一组应用的领域模型、参考需求、参考构架等组成 的开发基础，其目标就是支持在一个特定领域中多个应的开发基础，其目标就是支持在一个特定领域中多个应 用的生成用的生成”。 特定领域软件构架 领域 垂直域：定义了一个特定的系统族，包含整个系统族 内的多个系统，结果是在该领域中可作为系统的可行解 决方案的一个通用软件构架，如商业领域、电信领域、 银行领域等 水平域：定义了在多个系统和多个系统族中功能区域 的共有部分，在子系统级上涵盖多个系统族的特定部分 功能，无法为系统提供完整的通用构架，如用户界面、 字符处理、数据库管理等 DSSA 基本活动 DSSA 领域模型 DSSA 公共构件 以及复用机制 领域分析 领域设计 领域实现 领域分析 DSSA 建立过程 定义领域范围定义领域范围：确定什么在感兴趣的领域中以及本过 程到何时结束。 定义领域特定的元素：定义领域特定的元素：编译领域字典和领域术语的同 义词词典。识别领域中应用间的共同性和差异性； 定义领域特定的设计和实现需求约束定义领域特定的设计和实现需求约束：描述解空间中 有差别的特性有差别的特性。不仅要识别出约束，并且要记录约束对 设计和实现决定造成的后果，还要记录对处理这些问题 时产生的所有问题的讨论； 定义领域模型和构架定义领域模型和构架：产生一般的构架，并说明构成 它们的模块或构件的语法和语义； 产生、搜集可复用的产品单元产生、搜集可复用的产品单元：为DSSA增加构件使得 它可以被用来产生问题域中的新应用。 DSSA 三层次系统模型 DSSA DSSA和构架风格的比较 DSSA以问题域为出发点，构架风格以解决域为出发构架风格以解决域为出发 点点。 DSSA只对某一个领域进行设计专家知识的提取、存储 和组织，但可以同时使用多种构架风格；而在某个构架 风格中进行构架设计专家知识的组织时，可以将提取的 公共结构和设计方法扩展到多个应用领域。 DSSA通常选用一个或多个适合所研究领域的构架风格 ，并设计一个该领域专用的构架分析设计工具。 构架风格的定义和该风格应用的领域是直交的，提取的 设计知识比用DSSA提取的设计专家知识的应用范围要 广。 DSSA和构架风格是互为补充的两种技术。 DSSA 第二部分 面向对象设计原则 从程序设计方法的角度看，面向对象是一种新的程 序设计范型(paradigm)，其基本思想是使用对象、 类、继承、封装、聚合、关联、消息、多态性等基 本概念来进行程序设计。 自八十年代以来，面向对象方法已深入到计算机软件领域的几乎所有分支。它 不仅是一些具体的软件开发技术与策略，而且是一整套关于如何看待软件系统 与现实世界的关系，用什么观点来研究问题并进行问题求解，以及如何进行系 统构造的软件方法学。从这个意义上讲： 面向对象方法是一种运用对象、类、继承、封 装、聚合、关联、消息、多态性等概念来构造系 统的软件开发方法。 什么是面向对象 面向对象方法的基本思想 一、从现实世界中客观存在的事物出发来构造系统 强调直接以问题域（现实世界）中的事物为中心来思考问 题、认识问题，并根据这些事物的本质特征，把它们抽象 为系统中的对象，作为系统的基本构成单位。这可以使系 统直接映射问题域，保持问题域中事物及其相互关系的本 来面貌。 二、充分运用人类日常的思维方法 强调运用人类在日常的逻辑思维中经常采用的思想方法与 原则，例如抽象、分类、继承、聚合、封装、关联等等。 这使得软件开发者能更有效地思考问题，并以其他人也能 看得懂的方式把自己的认识表达出来。 主要特点： 从问题域中客观存在的事物出发来构造软件系统，用对 象作为对这些事物的抽象表示，并作为系统的基本构成 单位。 用对象的属性表示事物的静态特征；用对象的操作（服 务）表示事物的动态特征。 对象的属性与操作结合为一体，封装成一个独立的、不 可分的实体，对外屏蔽其内部细节。 对事物进行分类。把具有相同属性和相同操作的对象归 为一类，类是这些对象的抽象描述，每个对象是它的类 的一个实例。 通过在不同程度上运用抽象的原则可以得到较一般的类和较 特殊的类。特殊类继承一般类的属性与操作，从而简化系统 的构造过程及其文档。 比较复杂的对象可以把比较简单的对象作为它的构成部分 ，即整体对象由部分对象聚合而成。 对象之间通过消息进行通讯，以实现对象之间的动态联系。 通过关联表达各类对象之间具有特定意义的关系。 总结：用类和对象作为系统的基本构成单位。对象对应问题 域中的事物，其属性与操作刻画了事物的静态特征和动态特 征，它们之间的继承关系、聚合关系、消息和关联如实地表 达了问题域中事物之间实际存在的各种关系。 因此，无论系统的构成成分，还是通过这些成分之间的关系 而体现的系统结构，都可直接地映射问题域。 类，一般类，特殊类，抽象 抽象与分类：忽略 事物的非本质特征 ，只注意那些与当 前目标有关的本质 特征，从而找出事 物的共性，叫做抽 象；把具有共同性 质的事物划分为一 类，得出一个抽象 的概念，叫做分 类。 类是具有相同属性和操作的一组对象的集合，它为属于该 类的全部对象提供了统一的抽象描述，其内部包括属性和 操作两个主要部分。类的作用是用来创建对象，对象是类 的一个实例。 不同程度的抽象可得到不同层次的分类 较多地忽 略事物之 间的差别 得到较一 般的类 较多地注 意事物之 间的差别 得到较特 殊的类 运输工具 火车汽车 飞机 卡车轿车 轮船车辆 如果类A具有类B的全部属性和全部操作，而且具有自己特有的某些属性或 操作，则A叫做B的特殊类，B叫做A的一般类。 另一定义：如果类A的全部对象都是类B的对象，而且类B中存在不属于类A的 对象，则A是B的特殊类，B是A的一般类。 可以证明，以上两种定义是等价的 一般类和特殊类的定义 继承： 特殊类拥有其一般类的全部属性与操作，称作特 殊类对一般类的继承。 继承意味着自动地拥有，或曰隐含地复制 继承简化了人 们对事物的认 识和描述，非 常有益于软件 复用，是OO技 术提高软件开 发效率的重要 原因之一。 由继承机制 保证 由一组具有继承关 系的类所组成的结 构称作一般-特殊 结构。它是一个以 类为结点，以继承 关系为边的连通的 有向图。 继承关系的语义：“is a kind of” 公司人员 姓名 身份证号码 股东 股份 职员 工资 例： 多继承：允许一个特殊类具有一个以上一般类的 继承模式称作多继承 多继承特殊类 的内部情况 在职研究生 姓名 学号 班级 专业 职称 专业 在职单位 来自“人员”类 来自“研究生”类 来自“教职工”类 本类中显示定义 人员 姓名 教职工 职称 专业 研究生 学号 班级 专业 在职研究生 在职单位 例: 封装：把对象的属性和操作结合成一个独立的系统单位， 并尽可能隐蔽对象的内部细节。 售报亭售报亭 属 性 操 作 报刊A 报刊B 钱箱 报刊零售 款货清点 顾 客 封装的重要意义： 使对象能够集中而完整地描述并对应一个 具体的事物。 体现了事物的相对独立性，使对象外部不 能随意存取对象的内部数据，避免了外部 错误对它的“交插感染”。 对象的内部的修改对外部的影响很小，减 少了修改引起的“波动效应”。 由封装机制 保证 封装带来的问题： 编程的麻烦 执行效率的损失 解决办法： 不强调严格封装， 实行可见性控制。 （混合型OOPL） 例如： C+ 消息：消息是向对象发出的服务请求 目前在大部分面向对象的编程语言中，消息其实就是函数（或过程） 调用。 但是，函数调用只是实现消息的方式之一，上述理解只适合于顺序系 统 聚合： 一个（较复杂的）对象由其他若干（较简单的）对象作为其构成部 分，称作聚合。 聚合刻画了现实事物之间的构成关系。 两种方式： 部 分 对 象 部 分 对 象 整体对象 嵌套对象 整 体 对 象部 分 对 象 部 分 对 象 整 体 对 象 对象指针或对象标识 描述紧 密、固定 的关系， 例如汽车 与发动机 描述松 散、 灵活 的关系， 例如公司 与法律顾 问 紧密、固定的聚合方式又称做组合 整体-部分结构： 由一组具有聚合关系 的类所形成的结构称 作整体-部分结构。 它是一个以类为结点 ，以聚合关系为边的 连通有向图。 聚合关系又称整体-部分关系，它是对象实例之间的一种关系。有时说两个类 之间存在着整体-部分关系，是指一个类的对象实例以另一个类的对象实例作 为组成部分。 这种关系的语义是“has a”或“is a part of” 例： 汽 车 发动机 1 4，6 0，10，1 车 轮 公 司 0，m 0，m 法律顾问 关联： 对象之间的静态联系（即通过对象属性体现的联系）称作关 联。 关联的表示符号称作实例连接 城市 0,m 0,m 有航线 城市之间有航线 教 师学 生 0,m1 指导论文 教师为学生指导论文 例： 用集合论的观点和系统需求讨论关联概念 关联是两个或者多个类上的一个关系，其中的元素提供了被开发系统的 应用领域中一组有意义的信息。 例：设A和B是两个类，它们的对象实例集合是 A=a1,a2,an B=b1,b2,bm A和B的笛卡儿积AB= , , , , , , 这个笛卡儿积集合中 有n m个元素，它们 可以组合成2（ n m）个 子集合。 但是只有某个子集合 中的元素提供了被开 发系统的应用领域中 一组有意义的信息时 ，才有必要把它定义 为系统中的一个关 联。 多态：多态是指同一个命名可具有不同的语义。OO方法中，常指在一般类中定义 的属性或操作被特殊类继承之后，可以具有不同的数据类型或表现出不同 的行为。 多边形 边数 顶点数据 绘图 X Y 轴向矩形 x边数 *顶点数据 *绘图 正多边形 *顶点数据 *绘图 例： 传统方法 数据结构+算法=程序设计以对象为中心组织数据与操作 数据对象的属性 操作 对象的操作 类型与变量 类与对象实例 函数（过程）调用消息传送 类型与子类型一般类与特殊类，继承 构造类型整体-部分结构，聚合 指针关联 不同点 思想观念：从对象出发认识问题域；构造策略：以对象作为构成系统的基本 单位，将对象的数据与操作紧密结合；保证机制：由支持封装、继承、多态的机制保 证其原则的实现。 方法的比较 面向对象方法 面向对象本质论 面向对象分析 编写代码访问存储在数据库中的几何形状的描述， 再把得到的几何形状显示出来。 例子：问题的描述 在数据库中查找几何形状的列表； 打开形状列表； 以某种规则将这个列表排序； 在显示器上显示单个的几何形状； 识别形状的具体类型 获得形状的位置 调用适当的函数，并传递形状的位置给它，来显示这个形 状 解决问题步骤 分析者将问题拆分成多个功能步骤，这些步骤组合 起来就可以解决实际的问题。 把问题分解成小块来解决，比一次处理整个问题要 简单。 功能分解 模块化可以帮助你写出更容易理解的代码，更容易 理解的代码也更容易维护； 模块化并不能帮助你写出能应付所有可能出现的变 化代码 模块化方式处理变化 实际问题的描述：在学习班上，当课间的听完演讲 后，需要到其他的分会场去参加其他的技术演讲， 一种做法是： 获得参加会议的听众的人名单； 对于名单上的每个人： 查找他的下一技术演讲的题目； 查找他的下一参会的地点； 查找到他下一分会场的路径； 告诉他怎样去下一个地点。 责任转移模式处理需求变化 第一种方法，对每个人都指明确地指出路径，必须 注意许多细节，除了你之外的任何人对任何事情都 没有责任。 用第二种方法，你给出了一个普遍的指令，并期望 每个人都能自己知道如何完成你给出的任务。 对比：第一种方案中你对所有事情负责，而第二种 方案参会者对他们自己的行为负责；组织方式的巨 大差异。 揭示问题的本质 概念（conceptual） 展示了问题领域中的概念； 一个概念模型可以在对实现软件有很少或毫无注意的情况 下勾勒出来。 规格（Specification） 我们只看软件的接口，而不看软件的实现。 实现（implementation） 置身于代码当中，使常规视角 目标： 一个层次（概念层次）上通信而在另一个层次（实现层次 ）上执行； 请求者不知道发生了什么，只知道概念上发生了什么。 软件开发过程的视角 面向对象范式的核心是“对象”的概念 所有的东西都聚焦于对象 围绕对象-而非函数-组织代码 面向对象范式 考察问题域，发现候选的对象： 人员组织物品设备 事件表格 结构 . 建立类图（1）：发现对象，定义对象类 审查与筛选 （1）舍弃无用的对象 （2）对象的精简 （3）与实现条件有关的对象推迟到OOD考虑 用类表示对象 消息 考察对象在行为上的依赖关系，即： 当一个对象在执行它的一个服务时，需要其他对象向它提供什么服务 例： 学生 报到 教务员 注册 区别控制流内部的消息和控制流之间的消息 面向对象的设计原则 类的设计原则 可维护性 可复用性 面向对象的设计目标 现在存在的问题 过于僵硬 过于脆弱 复用率低 黏度过高 可维护性 重要性 较高的生产效率 较高的软件质量 恰当使用复用可以改善系统的可维护性 传统的复用 代码的剪贴使用 算法的复用 数据结构的复用 可复用性 7种设计坏味道 1.僵化性：僵化性： 很难加入新功能，因为每个改动都会迫使系统 其他部分的改动，而且范围越来越大，最后不得不放弃。 2.脆弱性：脆弱性： 与僵化共存，对系统的改动会导致系统中不相 干地方出现问题，而且难以预料。 3.低复用：低复用： 很难解开系统的纠结，使之成为一些可在其他 系统中重用的组件。 4.粘滞性：粘滞性： 做正确的事情比做错误的事情要困难，对设计 的更改仅考虑眼前利益。 5.复杂性复杂性( (不必要的不必要的) )： 设计中包含有不具任何直接好处的 基础结构，过度设计。 6.重复性重复性( (不必要的不必要的) )： 设计中包含有重复的结构，而该重 复的结构本可以使用单一的抽象进行统一。 大门时间哦团 队人出于自己的目的复制相同的代码，然后各自修改。 7.晦涩性：晦涩性： 很难阅读、理解。没有很好地表现出意图。 软件系统开始变坏的表现 单一职责原则（SRP，Single Responsibility Principle) 强调的是职责的分离，在某种程度上对职责的理解 ，构成了不同类之间耦合关系的设计关键，因此单 一职责原则或多或少成为设计过程中一个必须考虑 的基础性原则。 其核心的思想是：一个类，最好只做一件事，只有 一个引起它变化的原因。 单一职责原则 Open-Closed Principle (OCP) 定义 Software entities should be open for extension, but closed for modification. 一个软件实体应当对扩展开放，对修改关闭 “抽象化”是OCP的关键 “开闭”原则(OCP) 开闭原则建议去依赖一个抽象类，而不是一个具体类 对可变性的封装原则 Principle of Encapsulation of Variation (EVP) 找一个可变的因素把它封装起来 一种可变性不应当散落到代码的很多角落里，而应当被封 装在一个对象里 一种可变性不应当与另一种可变性混合在一起 “开闭”原则(OCP) 解释 “派生类通过其基类的接口必须可用，而用户无需知其差 别”，子类型必须能够替换其基类型 “白马，马也；乘白马，乘马也。骊马，马也；乘骊马， 乘马也。”（墨子小取） 里氏代换原则(LSP) Dependency Inversion Principle (DIP) 要依赖于抽象，不要依赖于具体 抽象层次包含的是应用系统的商务逻辑和宏观的、对整个 系统来说重要的战略性的决定，是必然性的体现 具体层次则含有一些次要的，与实现相关的算法和逻辑以 及战术性的决定，带有相当大的偶然性 依赖倒转原则(DIP) 表述 Abstractions should not depend upon details. Details should depend upon abstractions.（抽象不应 当依赖细节，细节应当依赖抽象） Program to an interface, not a implementation.（ 要针对接口编程，而不要针对实现编程） 依赖倒转原则(DIP) Interface Segregation Principle (ISP) 从一个客户角度来讲，一个类对另一个类的依赖性 应当建立在最小的接口上 原则 角色分割 定制服务 接口隔离原则(ISP) 聚合(Aggregation)关系 是关联的一种，是强的关联关系，是整体与个体的关系。 类图中的关系 依赖(Dependency)关系 是类与类之间的连接，依赖总是单向的。依赖表示一个类 依赖于另一个类的定义。 通常被依赖的对象以方法的参数或返回表示。 类图中的关系 Law of Demeter (LoD) 又称为最少知识原则 Least Knowledge Principle (LKP) 表述 only talk to your immediate friends“只与你直接的朋 友们通信” Dont talk to strangers “不要与陌生人讲话” 每一个软件单位对其他的单位都只有最少的知识，而且局 限于那些与本单位密切相关的软件单位 迪米特法则(LoD) 狭义迪米特法则 如果两个类不必彼此直接通信，那么这两个类就不应当发 生直接的相互作用。如果其中一个类需要调用另一个类的 某一方法的话，可以通过第三者转发这个调用 迪米特法则(LoD) 狭义迪米特法则 与依赖倒转原则的互补使用 迪米特法则(LoD) 广义迪米特法则控制信息过载 在类的划分上，应当创建弱耦合的类。类之间的耦合越弱 ，就越有利于复用 在类的结构设计上，每一个类都应当尽量降低成员的访问 权限(Accessibility) 在类的设计上，只要有可能，一个类应当设计成不变类 (Immutable) 在对其它类的引用上，一个对象对其实例的引用应当降到 最低 迪米特法则(LoD) 组合/聚集复用原则(CARP ，Composite/Aggregate Reuse Principle)。 组合和聚集都是对象建模中关联（Association）关系 的的一种。 聚集表示的是整体和部分的关系，表示“含有”，整体由部分 组合而成，部分可以脱离部分作为一个独立的个体而存在。 组合则是一种更强的“拥有”，部分组成整体，而且不可分割 ，部分不能脱离整体而单独存在。 合成关系中，部分和整体的生命周期一样，组合的新的 对象完全支配其组成部分，包括它们的创建和湮灭等。 一个合成关系的成分对象是不能与另一个合成关系共享 的。 组合/聚集复用原则 重用发