风格与模式

体系结构风格不是对软件进行分类的标准。它仅仅是描述软件的不同角度。

管道-过滤器风格

在管道-过滤器风格下，每个功能模块都有一组输入和输出。功能模块称作过滤器；功能模块间的连接称为管道。

• 特性

1. 过滤器是独立运行的构件

   非临近的过滤器之间不共享状态。
   过滤器自身无状态

2. 过滤器是独立的实体

   对临近的过滤器不添加任何限制，不能与其他的过滤器共享数据，而且一个过滤器不知道它的上游和下游的标识。

3. 结果的正确性不依赖于各个过滤器运行的先后次序

   各过滤器在输入之后独立完成自己的计算，完整的计算在各个过滤器之间的拓扑结果中

• 优点

1. 具有较强的可维护性和可扩展性
2. 支持一些特定的分析，如吞吐量计算和死锁检测等。
3. 管道过滤器风格具有并发性

• 缺点

1. 交互能力弱
2. 过滤器之间的数据交换需要大量的处理空间，数据执行占用较多运行时间
3. 设计者也许不得不花费精力协调两个相对独立但又存在某种关系的数据流 之间的关系

4. 根据实际设计需要，设计者也需要对数据传输进行特定处理。

   面向对象风格

• 特点

  抽象、继承、封装、多态

• 对象关系

  依赖（弱） 关联（强） 聚合 组合

• 优点

1. 与人类习惯的思维方式比较一致
2. 继承性保证了软件的重用
3. 稳定、易于修改、易扩充、易维护

• 缺点

1. 为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象。

2. 必须修改所有显式调用它的其它对象，并消除由此带来的一些副作用。例如，如果A使用了对象B，C也使用了对象B，那么，C对B的使用所造成的对A的影响可能是料想不到的

   事件驱动风格

   事件驱动系统的基本观点是一个系统对外部的表现可以从它对事件的处理表征出来。

• 特征

1. 系统是由若干子系统或元素所组成的一个整体
2. 系统有一定的目标，各子系统在某一种消息机制的控制下，为了这个目标而协调行动
3. 在某一种消息机制的控制下，系统作为一个整体与环境相适应和协调
4. 在一个系统的若干子系统中，必定有一个子系统起着主导作用，而其他子系统则处于从属地位
5. 任一系统和系统内的任一元素，都有一个事件收集机制和一个事件处理机制，通过这种机制与周围环境发生作用和联系。

• 事件驱动风格设计时有下述几条基本原则

1. 从系统论的角度来看待描述的对象，合理分解子系统，保证各个子系统的独立性和社会性
2. 无论系统多么复杂，子系统性质差异多么大，任何子系统都可以按照有无子系统这一性质分为两类：管理系统和执行系统。
3. 为了达到系统目标，系统内的各个子系统通过传递消息和执行消息来协同操作。
4. 在一个完整系统中，必须有这样一个子系统，它没有上级，必须收集系统外的事件以及下级发出的事件
5. 管理类型的子系统一般不执行具体操作，它的主要功能是按照自己的职能指挥下级完成任务，功能性操作一般由执行类型的子系统完成
6. 在一般情况下，除最高级管理子系统外，子系统一般是“有问才答”，即使在必要的情况下需要积极寻找事件时，也必须征得上级系统得许可，保证了系统的控制流不会分散。

• 优点

1. 事件驱动风格非常适合于描述系统族，在属于同一族的任何系统中，系统的高级管理子系统的描述是完全类似的，便于重用
2. 由于最高管理子系统牢牢的掌握着控制权，又因为各同级子系统一般不 直接***，因此容易实现兵法处理和多任务操作
3. 基于事件驱动风格的系统具有良好的扩展性，设计者只需为某个对象注册一个事件处理接口就可以将该对象引入整个系统，同时并不影响其它的系统结构
4. 定义了包含执行子系统和管理子系统的类层次结构
5. 简化客户代码
6. 使整个系统的设计更具有一般化

• 不足

1. 事件驱动风格最大的不足在于构件削弱了自身对 系统计算的控制能力
2. 事件驱动风格中存在的另一个问题在于数据共享
3. 系统中各个对象的逻辑关系变得更加复杂

• 事件驱动风格和面向对象风格的关系

  基于面向对象风格的系统由多个封装起来的对象构成，对象之间通过消息传递实现通信，而事件驱动正是 对消息传递机制的一种实现。所以基于事件驱动风格 的系统往往都是面向对象的。

  分层风格

  一个分层系统采用层次化的组织方式构件，系统中的每一层都要承担两个角色。

1. 首先，它要为结构中下面层次的客户。
2. 其次，它要作为结构中下面层次的客户，调用下层提供的功能函数。

• 优点

1. 分层风格支持系统设计过程中逐级抽象
2. 基于分层风格的系统具有较好的可扩展性
3. 分层风格支持软件复用

• 缺点

1. 并不是所有的系统都适合用分层风格来描述

2. 对于抽象出来的功能具体应该放在哪个层次上也是设计者头疼的问题，很难找到一个合适的、正确的层次抽象方法。

   C/S（客户/服务器）风格

   在集中式计算技术时代广泛使用的是大型机/小型机计 算模型。它是通过一台物理上与宿主机相连接的非智 能终端来实现宿主机上的应用程序。20世纪80年代以后，集中式结构逐渐被以PC机为主 的微机网络所取代。个人计算机和工作站的采用，永 远改变了协作计算模型，从而导致了分散的个人计算 模型的产生。

• 基本概念

  c/s软件体系结构是基于资源不对等，且为实现共享而 提出来的，C/S体系结构定义了工作站如何与服务器相连，以实现数据和应用分布到多个处理机上。

• C/S体系结构有三个主要组成部分:数据库服务器、客户端应用程序和网络
  
• 服务器

1. 数据库安全性的要求
2. 数据库访问并发性的控制
3. 数据库前端的客户应用程序的全局参数 完整性规则
4. 数据库的备份与恢复

• 客户端

1. 提供用户与数据库交互的界面
2. 向数据库服务器提交用户请求并接收来自数据库的信息
3. 利用客户应用程序对存在客户端的数据执行应用逻辑要求

• 优点

1. C/S 体系结构具有强大的数据操作和事务处理能力，模型思想简单，易 于人们理解和接受。
2. 系统的客户应用程序和服务器构件分别运行在不同的计算机上，系统中每台服务器都可以适合各构件的要求，这对于硬件和软件的变化显示出 极大的适应性和灵活性，而且易于对系统进行扩充和缩小。
3. 在C/S体系结构中，系统中的功能构件充分隔离，客户应用程序的开发 集中于数据的显示和分析，而数据库服务器的开发则集中于数据的管理 ，不必在每一个新的应用程序中都要对一个DBMS进行编码。将大的应用处理任务分布到许多通过网络连接的低成本计算机上，以节约大量费用。

• 缺点

1. 开发成本较高
2. 客户端程序设计复杂
3. 信息内容和形式单一
4. 用户界面风格不一，使用繁杂，不利于推广
5. 软件移植困难
6. 软件维护和升级困难

7. 新技术不能轻易应用

   三层客户/服务器（c/s）

• 随着企业规模的扩大，软件的复杂度不断提高，传统的两层c/s结构存在一定的局限

1. 二层C/S结构是单一服务器且以局域网为中心的，难以扩展至大型企业广域网或Internet;
2. 软硬件的组合以及集成能力有限
3. 客户急的负荷太重，难以管理大量的客户机，系统能力容易变差
4. 数据安全性不好
   

• 由于三层C/S体系结构可以将整个应用逻辑驻留在增加的 应用服务器上，客户机上只有表示层，从而被称为“瘦 客户机”结构。将应用功能分为表示层、功能层和数
  据层。

1. 表示层是应用的用户接口部分，担负着用户与应用间的对话功能
2. 功能层相当于应用的本体，它用于将具体的业务逻辑编入程序
3. 数据层就是数据库管理系统，负责管理对数据库的读写

• 解决方案

  对三层进行明确分割，并在逻辑上使其独立。原来的数据层作为数据库管理系统已经独立出来，关键是要将表示层和功能层分离成各自独立的 程序，并且还要使这两层间的接口简洁明了。

• 中间件

  中间件对三层C/S体系结构是最重要的构件。这里的中间件是一个用API定义的软件层，是具有强大通信能力和良好可扩展性的分布式软件管理框架。功能是在客户机和服务器或者服务器和服务器间传送数据，实现客户机群和服务器群之间的通信。工作流程:在客户机里的应用程序需要驻留网络上某个服务器的数据或服务时，搜索此数据的C/S应用程序需访问中间件系统，该系统将查询数据源和服务，并在发送应用程序请求后重新打包响应，将其传送回应用程序。

• 优点

1. 允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，能提高系统和软件的可维护性和可扩展性。
2. 允许更灵活有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层;并且这些平台和各个组成部分可以具有良好的可升级性和开放性。
3. 应用的各层可以并行开发，可以选择各自最适合的开发语言。
4. 利用功能层有效地隔离开表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，为严格的安全管理奠定了坚实的基础。

• 要注意的问题

1. 三层C/S结构各层间的通信效率若不高，即使分配给各层的硬件能力很强，其作为整体来说也达不到所 要求的性能。

2. 设计时必须慎重考虑三层间的通信方法、通信频度及数据量。这和提高各层的独立性一样是三层C/S结构 的关键问题。

   B/S（浏览器/服务器）风格

   浏览器/服务器(B/S)风格就是上述三层应用结构的一种实现方式，其具体结构为:浏览器/Web服务器/数据库服务器。B/S体系结构主要是利用WWW浏览器技术，结合浏览器的多种脚本语言，用通用浏览器就实现了原来需要复杂的专用软件才能实现的强大功能，并节约了开发成本。从某种程度上来说，B/S结构是一种全新的软件 体系结构。
   

• 解决方案

  与前面描述的三层C/S结构的差异是应用程序以网页形式存放于WEB服务器上，用户运行时只需在客户端的浏览器中输入相应的网址，调用WEB服务器上的应用程序 并对数据库进行操作完成相应的数据处理工作。应用程序在一定程度上具有集中特征。B/S结构解决管理信息系统的功能覆盖范围只能是组织内部的局限性，也使诸如电子商务、客户关系管理等 新的企业计算机应用得以发展。

• 优点

1. 基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决。用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。
2. B/S体系结构还提供了异种机、异种网、异种应用服务的联机、联网、统一服务的最现实的开放性基础。

• 缺点

1. B/S体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。
2. B/S体系结构的系统扩展能力差，安全性难以控制。
3. 采用B/S体系结构的应用系统，在数据查询等响应速度上要远远地低于C/S体系结构。

4. B/S体系结构的数据提交一般以页面为单位，数据的动态
   交互性不强，不利于在线事务处理(OLTP)应用。

   HMB风格-基于层次消息总线

• 层次消息总线(Hierarchy Message Bus，HMB)体系结构风格由杨芙清院士提出。基于的背景是:

1. 基于分布式构件技术的日渐成熟和构件互操作标准的出现。
2. 基于事件驱动的编程模式已在图形用户界面程序设 计中获得广泛应用。
3. 计算机硬件体系结构和总线的概念为软件体系结构的研究提供了很好的借鉴和启发，在统一的体系结构框架下，系统具有良好的扩展性和适应性。
   

• HDB风格的构件接口

  HMB风格的构件接口是一种基于消息的互联接口，可以较好 地支持体系结构设计。构件之间通过消息进行通讯，接口定义了构件发出和接收的消息集合。当某个事件发生后，系统或构件发出相应的消息，消息总线负责把该消息传递到此消息感兴趣的构件。构件只对消息本身感兴趣，不关心消息的产生，消息的发送与接收者互不关心.按照响应方式的不同，消息可分为同步消息和异步消息。

• HMB风格的构件动态行为

  构件的行为就由外来消息的类型唯一确定，即一个消息和构件的某个操作之间存在着固定的对应关系。对 于这类构件，可以认为构件只有一个状态，或者在每次对消息响应之前，构件处于初始状态(单状态)。更通常的情况是，构件的行为同时受外来消息类型和自身当前所处状态的影响(多状态)。

• 运行时的系统演化

1. 动态增加或删除构件

   系统需要扩充功能时，需增加构件; 功能裁剪或构件出故障时，需删除构件; 优化或升级后的构件替换原有的老构件;
2. 动态改变构件响应的消息类型(需重新登记)

3. 消息过滤(可解决构件集成的不匹配问题)

   数据分享风格（库风格）

• 特征:采用数据共享风格构建的系统中通常有两
  类截然不同的功能构件;
• 中央数据单元构件(代表当前系统的每个状态);
• 一些相对独立的构件的集合(知识源)。
• 信息交互方式的差异导致了控制策略的不同。主要的 控制策略有两种，正是依据这两种不同的控制策略， 基于数据共享风格的系统被分成两个子类:
  1. 基于传统数据库型数据共享风格的应用系统(输入流的信息 服务触发系统的相应处理)
  2. 基于黑板型数据共享风格的应用系统(当前状态触发)。黑板模式对于不确定性求解策略的问题比较有用，在专家系统中，这种模式应用的比较广泛。
• 一个典型的黑板型数据共享系统包括以下三个部分:
  1. 知识源:知识源中包含独立的、与应用程序相关的知识，知识源之间不直接进行通讯，它们之间的交互只通过黑板来完成。
  2. 黑板数据结构:黑板数据是按照与应用程序相关的层次来组 织的解决问题的数据，知识源通过不断地改变黑板数据来解 决问题。
  3. 控制:控制完全由黑板的状态驱动，黑板状态的改变决定使 用的特定知识。
• 优点

1. 解决问题的多方法性

   对于一个专家系统，针对于要解决的问题，如果在其领域中没有独立的方法存在，而且对解空间的完全搜索也是不可行的，在黑板模式中可以用多种不同的算法来进行试验，并且也允许用不同的控制方法。

2. 具有可更改性和可维护性

   因为在黑板模式中每个知识源是独立的，彼此之间的通信通过黑板来完成，所以这使整个系统更具有可更改性和可维护性

3. 有可重用的知识源

   由于每个知识源在黑板系统中都是独立的，如果知识源和所基于的黑板系统有理解相同的协议和数据,我们就可以重用知识源。

4. 支持容错性和健壮性

   在黑板模式中所有的结果都是假设的，并且只有那些被数据和其它假设强烈支持的才能够生存。这对于噪声数据和不确定的结论有很强的容错性。

• 缺点

1. 测试困难

   由于黑板模式的系统有中央数据构件来描述系统的体现系统的状态，所以系统的执行没有确定的顺序，其结果的可再现性比较差，难于测试。

2. 不能保证有好的求解方案

   一个黑板模式的系统所提供给我们的往往是所解决问题的一个百分比，而不是最佳的解决方案。

3. 效率低

   黑板模式的系统在拒绝错误假设的时候要承受多余的计算 开销，所以导致效率比较低

4. 开发成本高

   绝大部分黑板模式的系统需要用几年的时间来进化，所以开发成本较高

5. 缺少对并行机的支持

   黑板模式要求黑板上的中心数据同步并发访问，所以缺少对不并行机的支持。

   解释器风格

• 基于解释器风格的系统核心在于虚拟机
• 一个基于解释器风格的系统通常包括：正在被解释执行的伪码和解释引擎
• 伪码：由需要被解释执行的源代码和解释引擎分析所得的中间代码组成
• 解释器引擎包括：语法解释器和解释器当前的运行状态
  
• 优点

1. 在文法规则比较简单的情况下，解释器风格工作的很好
2. 易于改变和扩展文法。因为解释器风格使用类来表示文法规则，用户可以使用继承来改变和扩展文法。已有的表达式可以采用增量的方式逐渐扩充，而新的表达式可以定义为旧的表达式变体
3. 易于实现文法
4. 可以用多种操作来“解释”一个句子

• 缺点

1. 无法解释复杂的文法规则:对于比较简单的文法规则，解释器风格工作的很好，而对于复杂的文法规则， 则由于文法层次的庞大而难于管理;
2. 应用范围比较狭窄

3. 在文法规则比较复杂，则文法的层次变得无法管理，系统中需要包含许多表示文法规则的类

   反馈控制环风格

   所谓对一个对象(或过程)进行控制，意味着设法使这个被控对象(或被控过程)的功能或特性有效的达到所期望的目标。为了成功设计一个控制系统，必须事先知道被控对象所具有的性质和特征，同时还须了解和掌握这些性质和特征随环境等因素变化的情况。根据上述的动态系统的定义，在系统中必然存在信 号的处理和传输。这时系统也可描述为传输环节或传输系统。传输环节具有唯一的作用方向，这由输入、输出信号的箭头方向给出。

• 自适应反馈控制环需要包括以下3方面的工作

1. 辨识被控对象的特征
2. 在辨识的基础上作出控制决策
3. 在决策的基础上实施修正动作

• 按照构成自适应控制环的目的的不同可以将其分为两种类型

1. 参数自适应控制环

2. 性能自适应控制环

   小结

   
   

   异构风格集成

   各种系统构建模式之间不仅有联系，而且在很多情况下它们往往是配合使用的。即面对一个实际系统，单纯的把它归到哪一种类型都是很勉强的。这样的系统可以称为复合型系统，这样的系统构建模式就称 为异构风格的集成。