《第三讲软件架构风格和设计原则》由会员分享，可在线阅读，更多相关《第三讲软件架构风格和设计原则（147页珍藏版）》请在金锄头文库上搜索。
1、第三讲 软件构架风格设计原则贾育 博士中培教育-中国信息化培训中心2011高级系统架构师培训班（上海）第一部分 软件架构风格建筑风格古希腊、古罗马建筑苏尼恩角上海神庙古罗马大斗兽场建筑风格中国建筑Christopher Alexander, The Timeless Way of Building, p247, 1979 每个模式是一个由三部分组成的规则，表达了特定环特定环 境境、问题问题和解决方式解决方式(solution)之间的关系。 作为现实世界的一个成分，每个模式表达了下列三者之 间的一种关系：特定环境，在该环境中反复出现的因素 forces)的系统，以及协调这些因素的某种方案。 作为
2、语言的一个成分，每个模式是一条指令，展示了这 种方案如何被一再重复使用重复使用，目的是协调同特定环境相 关的因素的系统。 简单地说，模式既是存在于现实世界中的事物，又是告模式既是存在于现实世界中的事物，又是告 诉我们如何以及何时创造该事物的规则。诉我们如何以及何时创造该事物的规则。模式既是过程 ，又是事物；既是活生生的事物的描述，又是创造该事 物的过程的描述。建筑模式 软件构架风格软件构架风格(Architectural style)又称为软件 构架模式(Architectural pattern)软件构架风格描述某一特定应用领域中系统组织 方式的惯用模式，以结构组织模式定义了一个系 统家族
3、关于构件和连接件类型的术语词汇表 一组约束它们组合方式的规定 一个或多个语义模型，规定了如何从各成分的特性决定 系统整体特性概括地说，一种软件构架风格刻划一个具有共享 结构和语义的系统家族软件构架风格概念构件和连接件的类型是什么？可允许的结构模式是什么？基本的计算模型是什么？风格的基本不变性是什么？其使用的常见例子是什么？使用此风格的优缺点是什么？常见的特例是什么？关键要素：提供一个词汇表、定义一套配置规则、定义 一套语义解释原则以及定义对基于这种风格的系统所进 行的分析讨论构架风格时要回答的问题典型的构架风格其他典型构架风格每个构件都有一组输入和输出输入和输出，构件读输入的数 据流，经过内部
4、处理，然后产生输出数据流。这 个过程通常通过对输入流的变换及增量计算变换及增量计算来完 成，所以在输入被完全消费之前，输出便产生 了。 这里的构件被称为过滤器过滤器，这种风格的连接件 就象是数据流传输的管道管道，将一个过滤器的输出 传到另一过滤器的输入。管道和过滤器实例 以Unix Shell编写的程序，Unix既提供一种符号，以连接 各组成部分（Unix的进程），又提供某种进程运行时机 制以实现管道 传统的编译器，一个阶段的输出是另一个阶段的输入（包 括词法分析、语法分析、语义分析和代码生成）管道和过滤器优点 使得软构件具有良好的隐蔽性隐蔽性和高内聚、低耦合高内聚、低耦合的特点 ； 允许设计
5、者将整个系统的输入/输出行为看成是多个过过 滤器的行为的简单合成滤器的行为的简单合成； 支持软件复用软件复用。只要提供适合在两个过滤器之间传送的 数据，任何两个过滤器都可被连接起来； 系统维护和增强系统性能简系统维护和增强系统性能简单。新的过滤器可以添加到 现有系统中来；旧的可以被改进的过滤器替换掉； 允许对一些如吞吐量、死锁等属性的分析属性的分析 支持并行执行并行执行。每个过滤器是作为一个单独的任务完成 ，因此可与其它任务并行执行管道和过滤器缺点 通常导致进程成为批处理导致进程成为批处理的结构。这是因为虽然过滤器 可增量式地处理数据，但它们是独立的，所以设计者必 须将每个过滤器看成一个完整的
6、从输入到输出的转换； 不适合处理交互不适合处理交互的应用。当需要增量地显示改变时，这 个问题尤为严重； 因为在数据传输上没有通用的标准数据传输上没有通用的标准，每个过滤器都增加 了解析和合成数据的工作，这样就导致了系统性能下降导致了系统性能下降 ，并增加了编写过滤器的复杂性。管道和过滤器这种风格建立在数据抽象数据抽象和面向对象面向对象的基础上，数据数据的 表示方法和它们的相应操作操作封装在一个抽象数据类型或 对象中。这种风格的构件是对象构件是对象，或者说是抽象数据类型的实 例。对象是一种被称作管理者的构件，因为它负责保持 资源的完整性。对象是通过函数和过程的调用来交互调用来交互 的。数据抽象和
7、面向对象组织优点 因为对象对其它对象隐藏对象隐藏它的表示，所以可以改变一个 对象的表示，而不影响其它的对象； 设计者可将一些数据存取操作的问题分解成一些交互交互的 代理程序的集合。缺点 为了使一个对象和另一个对象通过过程调用等进行交互 ，必须知道对象的标知道对象的标识。只要一个对象的标识改变了， 就必须修改所有其他明确调用它的对象； 必须修改所有显式调用它的其它对象，并消除由此带来 的一些副作副作用。例如，如果A使用了对象B，C也使用了 对象B，那么，C对B的使用所造成的对A的影响可能是 料想不到的。数据抽象和面向对象组织构件不直接调用一个过程，而是触发或广播一个或多个触发或广播一个或多个 事
8、件事件。系统中的其它构件中的过程在一个或多个事件中 注册，当一个事件被触发，系统自动调用系统自动调用在这个事件中 注册的所有过程，这样，一个事件的触发就导致了另一 模块中的过程的调用。这种风格的构件是一些模块构件是一些模块，模块既可以是一些过程， 又可以是一些事件的集合。过程可以用通用的方式调用 ，也可以在系统事件中注册一些过程，当发生这些事件 时，过程被调用。这种风格的主要特点是事件的触发者并不知道哪些构件并不知道哪些构件 会被这些事件影响会被这些事件影响。这样不能假定构件的处理顺序，甚 至不知道哪些过程会被调用，因此，许多隐式调用隐式调用的系 统也包含显式调用作为构件交互的补充形式。基于事
9、件的隐式调用实例 在编程环境中用于集成各种工具 数据库管理系统中确保数据的一致性约束 用户界面系统中管理数据 Debugger的断点事件 当Debugger在断点处停下时，该事件触发系统自动调用处 理程序，如编辑程序卷屏到断点，变量监视器刷新变量数 值。而Debugger本身只声明事件，并不关心哪些过程会启 动，也不关心这些过程做什么处理基于事件的隐式调用优点 为软件复用软件复用提供了强大的支持。当需要将一个构件加入现 存系统中时，只需将它注册到系统的事件中。 为改进系统改进系统带来了方便。当用一个构件代替另一个构件时 ，不会影响到其它构件的接口。基于事件的隐式调用缺点 构件放弃了对系统计算的
10、控制放弃了对系统计算的控制。一个构件触发一个事件时 ，不能确定其它构件是否会响应它。而且即使它知道事件 注册了哪些构件的构成，它也不能保证这些过程被 调用 的顺序。 数据交换的问题。有时数据可被一个事件传递，但另一些 情况下，基于事件的系统必须依靠一个共享的仓库进行交 互。在这些情况下，全局性能和资源管理全局性能和资源管理便成了问题。 既然过程的语义必须依赖于被触发事件的上下文约束，关 于正确性的推理存在问题正确性的推理存在问题。基于事件的隐式调用层次系统组织成一个层次结构，每一层为上层服务，并作为下层客每一层为上层服务，并作为下层客 户。户。在一些层次系统中，除了一些精心挑选的输出函数外，内
11、部的 层只对相邻的层可见。这样的系统中构件在一些层实现了虚拟机（ 在另一些层次系统中层是部分不透明的）。连接件通过决定层间如 何交互的协议交互的协议来定义，拓扑约束包括对相邻层间交互的约束。这种风格支持基于可增加抽象层抽象层的设计。允许将一个复杂问题分解复杂问题分解 成一个增量步骤序列的实现。由于每一层最多只影响两层，同时只 要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为 软件复用提供了强大的支持分层系统实例 分层通信协议，每一层提供一个抽象的功能作为上层通信 的基础，较低层次定义低层的交互，最底层通常只定义物 理连接分层系统优点 支持基于抽象程度递增抽象程度递增的系统设计，使设计
12、者可以把一个复杂系 统按递增的步骤进行分解； 支持功能增强功能增强，因为每一层至多和相邻的上下层交互，因此功能 的改变最多影响相邻的上下层； 支持复用复用。只要提供的服务接口定义不变，同一层的不同实现可 以交换使用。这样，就可以定义一组标准的接口，而允许各种不 同的实现方法。缺点 并不是每个系统都可以很容易地划分为分层的模式，甚至即使一 个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设 计师不得不把一些低级或高级的功能综合起来； 很难找到一个合适的、正确的层次抽象方法。分层系统在仓库风格中，有两种不同的构件：中央数据结构中央数据结构说明 当前状态，独立构件独立构件在中央数据上执行，仓库
13、与外构件 间的相互作用在系统中会有大的变化。控制原则的选取产生两个主要的子类。若输入流中某类 时间触发进程执行的选择，则仓库是一传统型数据库传统型数据库； 另一方面，若中央数据结构的当前状态触发进程执行的 选择，则仓库是一黑板系统黑板系统。实例 信号处理领域，如语音和模式识别 松耦合数据共享仓库系统及知识库黑板系统的组成 知识源知识源：知识源中包含独立的、与应用程序相关的知识，知 识源之间不直接进行通信，它们之间的通信通过黑板来完成 黑板数据结构黑板数据结构：黑板数据是按照与应用程序相关的层次来组 织的解决问题的数据，知识源通过不断地改变黑板数据来解 决问题 控制控制：控制完全由黑板的状态驱动
14、，黑板状态的改变决定使 用的特定知识仓库系统及知识库产生背景 在集中式计算技术时代广泛使用的是大型机/小型机计算 模型。它是通过一台物理上与宿主机相连接的非智能终端 来实现宿主机上的应用程序。 20世纪80年代以后，集中式结构逐渐被以PC机为主的微 机网络所取代。个人计算机和工作站的采用，永远改变了 协作计算模型，从而导致了分散的个人计算模型的产生。客户/服务器风格基本概念 C/S软件构架是基于资源不对等，且为实现共享而提出来 的，是20世纪90年代成熟起来的技术，C/S构架定义了 工作站如何与服务器相连，以实现数据和应用分布到多个 处理机上。 C/S构架有三个主要组成部分：数据库服务器、客户
15、应用数据库服务器、客户应用 程序和网络程序和网络。客户/服务器风格构架客户/服务器风格任务分配 服务器 数据库安全性的要求； 数据库访问并发性的控制； 数据库前端的客户应用程序的全局数据完整性规则 数据库的备份与恢复。 客户应用程序 提供用户与数据库交互的界面； 向数据库服务器提交用户请求并接收来自数据库服务器的信 息； 利用客户应用程序对存在于客户端的数据执行应用逻辑要 求。客户/服务器风格处理流程客户/服务器风格优点 C/S 构架具有强大的数据操作和事务处理能力强大的数据操作和事务处理能力，模型思想简 单，易于人们理解和接受。 系统的客户应用程序和服务器构件分别运行在不同的计算机 上，系统
16、中每台服务器都可以适合各构件的要求，这对于硬 件和软件的变化显示出极大的适应性和灵活适应性和灵活性，而且易于对 系统进行扩充和缩小。 在C/S构架中，系统中的功能构件充分隔离功能构件充分隔离，客户应用程序 的开发集中于数据的显示和分析，而数据库服务器的开发则 集中于数据的管理，不必在每一个新的应用程序中都要对一 个DBMS进行编码。将大的应用处理任务分布到许多通过网 络连接的低成本计算机上，以节约大量费用。 客户/服务器风格缺点 开发成本较高 客户端程序设计复杂 信息内容和形式单一 用户界面风格不一，使用繁杂，不利于推广使用 软件移植困难 软件维护和升级困难 新技术不能轻易应用客户/服务器风格构架三层客户/服务
