软件基本模型=实体(语言) + 连接和交互

1.概念：

　　软件架构设计的一个核心问题是能否使用重复的架构模式，即能否达到架构级的软件重用。也就是说，能否在不同的软件系绕中使用同一架构。软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式(idiomatic paradigm).

　　　　架构风格定义了一个系统家族，即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。按这种方式理解，软件架构风格定义了用于描述系统的术语表和一组指导构件系统的规则
    通用架构风格的分类如下
    (1)数据流风格:批处理序列、管道z过滤器。
    (2)调用返回风格:主/子程序、面向对象风格、层次结构。
    (3)独立构件风格、事件系统。
    (4)虚拟机风格:解释器、基于规则的系统
    (5)仓库风格:数据库系统、超文本系统、黑板系统

2.1    管道和过滤器风格 Pipes and Filters

　　　在管道/过滤器风格的软件体系结构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数
据流。这个过程通常通过对输入流的变换及增量计算来完成，所以在输入被完全消费之前，输出便产生了。因此，这里的构件被称为过滤器，这种风格的连接件就像
是数据流传输的管道，将一个过滤器的输出传到另一过滤器的输入。此风格特别重要的
过滤器必须是独立的实体，它不能与其它的过滤器共享数据，而且一个过滤器不知道它上游和下游的标识。一个管道/过滤器网络输出的正确性并不依赖于过滤器进
行增量计算过程的顺序。

　　图2-1是管道/过滤器风格的示意图。一个典型的管道/过滤器体系结构的例子是以Unixshell编写的程序。
Unix既提供一种符号，以连接各组成部分(Unix的进程)，又提供某种进程运行时机制以实现管道。另一个著名的例子是传统的编
译器。传统的编译器一直被认为是一种管道系统，在该系统中，一个阶段(包括词法分析、语法分析、语义分析和代码生成)的输出是另一个阶段的输入。

图 2?1管道/过滤器风格的体系结构

　　管道/过滤器风格的软件体系结构具有许多很好的特点：

　　(1)使得软构件具有良好的隐蔽性和高内聚、低耦合的特点；

　　(2)允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成；

　　(3)支持软件重用。重要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来；

　　(4)系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉；

　　(5)允许对一些如吞吐量、死锁等属性的分析；

　　(6)支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其它任务并行执行。

　　但是，这样的系统也存在着若干不利因素。

　　(1)通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。

　　(2)不适合处理交互的应用。当需要增量地显示改变时，这个问题尤为严重。

　　(3)因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。

2.2    数据抽象与面向对象风格     Data Abstraction and  Object-Oriented Organization

　　　　抽象数据类型概念对软件系统有着重要作用，目前软件界已普遍转向使用面向对象系统。这种风格建立在数据抽象和面向对象的
基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种被称作管理者的
构件，因为它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。

　　图2-2是数据抽象和面向对象风格的示意图。

图 2?2数据抽象和面向对象风格的体系结构

　　面向对象的系统有许多的优点，并早已为人所知：

　　(1) 因为对象对其它对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其它的对象。

　　(2) 设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。

　　但是，面向对象的系统也存在着某些问题：

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

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

2.3    基于事件的隐式调用风格  Event-Based Implicit Invocation

　　　　基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其它构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。

　　　　从体系结构上说，这种风格的构件是一些模块，这些模块既可以是一些过程，又可以是一些事件的集合。过程可以用通用的方式调用，也可以在系统事件中注册一些过程，当发生这些事件时，过程被调用。

　　　　基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。这样不能假定构件的处理顺序，甚至不知道哪些过程会被调用，因此，许多隐式调用的系统也包含显式调用作为构件交互的补充形式。

　　　　支持基于事件的隐式调用的应用系统很多。例如，在编程环境中用于集成各种工具，在数据库管理系统中确保数据的一致性约束，在用户界面系统中管理
数据，以及在编辑器中支持语法检查。例如在某系
统中，编辑器和变量监视器可以登记相应Debugger的断点事件。当Debugger在断点处停下时，它声明该事件，由系统自动调用处理程序，如编辑程
序可以卷屏到断点，变量监视器刷新变量数值。而Debugger本身只声明事件，并不关心哪些过程会启动，也不关心这些过程做什么处理。

　　隐式调用系统的主要优点有：

　　(1)为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。

　　(2)为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其它构件的接口。

　　隐式调用系统的主要缺点有：

　　(1)构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其它构件是否会响应它。而且即使它知道事件注册了哪些构件的构成，它也不能保证这些过程被调用的顺序。

　　(2)数据交换的问题。有时数据可被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下，全局性能和资源管理便成了问题。

　　(3)既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题。

2.4    层次系统风格  Layered systems

　　　　层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函数
外，内部的层只对相邻的层可见。这样的系统中构件在一些层实现了虚拟机(在另一些层次系统中层是部分不透明的)。连接件通过决定层间如何交互的协议来定
义，拓扑约束包括对相邻层间交互的约束。

　　　　这种风格支持基于可增加抽象层的设计。这样，允许将一个复杂问题分解成一个增量步骤序列的实现。由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件重用提供了强大的支持。

　　　　图2-3是层次系统风格的示意图。层次系统最广泛的应用是分层通信协议。在这一应用领域中，每一层提供一个抽象的功能，作为上层通信的基础。较低的层次定义低层的交互，最低层通常只定义硬件物理连接。

图 2?3层次系统风格的体系结构

　　层次系统有许多可取的属性：

　　(1)支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解；

　　(2)支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层；

　　(3)支持重用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，而允许各种不同的实现方法。

　　但是，层次系统也有其不足之处：

　　(1)并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来；

　　(2)很难找到一个合适的、正确的层次抽象方法。

2.5    仓库风格  Repositories

　　在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存贮上执行，仓库与外构件间的相互作用在系统中会有大的变化。

　　控制原则的选取产生两个主要的子类。若输入流中某类时间触发进程执行的选择，则仓库是一传统型数据库；另一方面，若中央数据结构的当前状态触发进程执行的选择，则仓库是一黑板系统。

　　图2-4是黑板系统的组成。黑板系统的传统应用是信号处理领域，如语音和模式识别。另一应用是松耦合代理数据共享存取。

图 2?4黑板系统的组成

　　我们从图2-4中可以看出，黑板系统主要由三部分组成：

　　(1)知识源。知识源中包含独立的、与应用程序相关的知识，知识源之间不直接进行通讯，它们之间的交互只通过黑板来完成。

　　(2)黑板数据结构。黑板数据是按照与应用程序相关的层次来组织的解决问题的数据，知识源通过不断地改变黑板数据来解决问题。

　　(3)控制。控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识。

2.6    C2风格

　　C2体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。C2风格中的系统组织规则如下：

　　(1)系统中的构件和连接件都有一个顶部和一个底部；

　　(2)构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；

　　(3)一个连接件可以和任意数目的其它构件和连接件连接；

　　(4)当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。

　    图2-5是C2风格的示意图。图中构件与连接件之间的连接体现了C2风格中构建系统的规则。

图 2?5 C2风格的体系结构

　　C2风格是最常用的一种软件体系结构风格。从C2风格的组织规则和结构图中，我们可以得出，C2风格具有以下特点：

　　(1)系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一起；

　　(2)所有构件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的；

　　(3)构件相对独立，构件之间依赖性较少。系统中不存在某些构件将在同一地址空间内执行，或某些构件共享特定控制线程之类的相关性假设。

3        客户/服务器风格

在软件体系结构的风格设计中， 客户/服务器(Client/Server，C/S)
风格无疑曾是最重要的风格。客户/服务器(Client/Server，C/S)计算技术在信息产业中占有重要的地位，
网络计算经历了从基于宿主机的计算模型到客户/服务器计算模型的演变。由服务器提供应用(数据)
服务，多台客户机进行连接。客户/服务器应用模式的特点是大都基于“胖客户机”结构下的两层结构应用软件。客户端软件一般由应用程序及相应的数据库连接程
序组成。服务器端软件一般是某种数据库系统。

　客户机和服务器都是独立的计算机。当一台连入网络的计算机向其他计算机提供各种网络服务(如数据、文件的共享等)时，它就被叫做服务器。而那些用于访问
服务器资料的计算机则被叫做客户机。严格说来，客户机／服务器模型并不是从物理分布的角度来定义，它所体现的是一种网络数据访问的实现方式。采用这种结构
的系统目前应用非常广泛。如宾馆、酒店的客房登记、结算系统，超市的POS系统，银行、邮电的网络系统等。

C/S模式可以充分利用两端硬件环境的优势，将任务合理分配到Client端和Server端来实现，降低了系统的通讯开销。目前大多数应用软件系
统都是 Client/Server形式的两层结构，由于现在的软件应用系统正在向分布式的Web应用发展，Web和Client/Server
应用都可以进行同样的业务处理，应用不同的模块共享逻辑组件；因此，内部的和外部的用户都可以访问新的和现有的应用系统，通过现有应用系统中的逻辑可以扩
展出新的应用系统。这也就是目前应用系统的发展方向。

　　传统的C／S体系结构虽然采用的是开放模式，但这只是系统开发一级的开放性，在特定的应用中无
论是Client端还是Server端都还需要特定的软件支持。由于没能提供用户真正期望的开放环境，C/S结构的软件需要针对不同的操作系统系统开发不
同版本的软件， 加之产品的更新换代十分快，已经很难适应百台电脑以上局域网用户同时使用。而且代价高， 效率低。

C/S结构的优点是能充分发挥客户端ＰＣ的处理能力，很多工作可以在客户端处理后再提交给服务器。对应的优点就是客户端响应速度快。

　　（1）应用服务器运行数据负荷较轻。最简单的C/S体系结构的数据库应用由两部
分组成，即客户
应用程序和数据库服务器程序。二者可分别称为前台程序与后台程序。运行数据库服务器程序的机器，也称为应用服务器。一旦服务器程序被启动，就随时等待响应

客户程序发来的请求；客户应用程序运行在用户自己的电脑上，对应于数据库服务器，可称为客户电脑，当需要对数据库中的数据进行任何操作时，客户程序就自动
地寻找服务器程序，并向其发出请求，服务器程序根据预定的规则做出应答，送回结果，应用服务器运行数据负荷较轻。

　　（2）数据的储存管理功能较为透明。在数据库应用中，数据的储存管理功能，是由
服务器程序和客户应用程序分别独立进行的，前台应用可以违反的规则，并且通常把那些不同的（不管是已知还是未知的）运行数据，在服务器程序中不集中实现，
例如访问者的权
限，编号可以重复、必须有客户才能建立定单这样的规则。所有这些，对于工作在前台程序上的最终用户，是“透明”的，他们无须过问（通常也无法干涉）背后的

过程，就可以完成自己的一切工作。在客户服务器架构的应用中，前台程序不是非常“瘦小”，麻烦的事情都交给了服务器和网络。在C/S体系的下，数据库不能
真正成为公共、专业化的仓库，它受到独立的专门管理。

缺点主要有以下几个：

（1）  只适用于局域网。而随着互联网的飞速发展，移动办公和分布式办公越来越普及，这需要我们的系统具有扩展性。这种方式远程访问需要专门的技术，同时要对系统进行专门的设计来处理分布式的数据。

（2）  客户端需要安装专用的客户端软件。首先涉及到安装的工作量，其次任何一台电脑出问题，如病毒、硬件损坏，都需要进行安装或维护。特别是有很多分部或专卖店 的情况，不是工作量的问题，而是路程的问题。还有，系统软件升级时，每一台客户机需要重新安装，其维护和升级成本非常高。

（3）  对客户端的操作系统一般也会有限制。可能适应于Win98， 但不能用于win2000或Windows XP。或者不适用于微软新的操作系统等等，更不用说Linux、Ｕnix等。

（4）  高昂的维护成本且投资大。首先，采用C/S架构，要选择适当的数据库
平台来实现数据库数据的真正“统一”，使分布于两地的数据同步完全交由数据库系统去管理，但逻辑上两地的操作者要直接访问同一个数据库才能有效实现，有
样一些问题，如果需要建立“实时”的数据同步，就必须在两地间建立实时的通讯连接，保持两地的数据库服务器在线运行，网络管理工作人员既要对服务器维护管

理，又要对客户端维护和管理，这需要高昂的投资和复杂的技术支持，维护成本很高，维护任务量大。其次，传统的C/S结构的软件需要针对不同的操作系统系统
开发不同版本的软件，由于产品的更新换代十分快，代价高和低效率已经不适应工作需要。在JAVA这样的跨平台语言出现之后，B/S架构更是猛烈冲击C
/S，并对其形成威胁和挑战。

4        三层C/S结构风格

4.1 三层C/S的基本硬件结构

传统的二层C/S结构存在以下几个局限：

l        它是单一服务器且以局域网为中心的，所以难以扩展至大型企业广域网或Internet；

l        受限于供应商；

l        软、硬件的组合及集成能力有限；

l        难以管理大量的客户机。

因此，三层C/S结构应运而生。三层C/S结构是将应用功能分成表示层、功能层和数据层三部分。其解决方案是：对这三层进行明确分割，并在逻辑上使
其独立。原来的数据层作为DBMS已经独立出来，所以关键是要将表示层和功能层分离成各自独立的程序，并且还要使这两层间的接口简洁明了。

一般情况是只将表示层配置在客户机中，与二层C/S结构相比，其程序的可维护性要好得多，是其他问题并未得到解决。客户机的负荷太重，其业务处理所需的数据要从服务器传给客户机，所以系统的性能容易变坏。

如果将功能层和数据层分别放在不同的服务器中，则服务器和服务器之间也要进行数据传送。但是，由于在这种形态中三层是分别放在各自不同的硬件系统上
的，所以灵活性很高，能够适应客户机数目的增加和处理负荷的变动。例如，在追加新业务处理时，可以相应增加装载功能层的服务器。因此，系统规模越大这种形
态的优点就越显著。

值得注意的是：三层C/S结构各层间的通信效率若不高，即使分配给各层的硬件能力很强，其作为整体来说也达不到所要求的性能。此外，设计时必须慎重考虑三层间的通信方法、通信频度及数据量。这和提高各层的独立性一样是三层C/S结构的关键问题。

4.2 三层C/S的功能

1.表示层
　
　表示层是应用的用户接口部分，它担负着用户与应用间的对话功能。它用于检查用户从键盘等输入的数据，显示应用输出的数据。为使用户能直观地进行操作，一
般要使用图形用户接口(GUI)，操作简单、易学易用。在变更用户接口时，只需改写显示控制和数据检查程序，而不影响其他两层。检查的内容也只限于数据的
形式和值的范围，不包括有关业务本身的处理逻辑。
      图形界面的结构是不固定的，这便于以后能灵活地进行变更。例如，在一个窗口中不是放入几个功能，而是按功能分割窗口，以便使每个窗口的功能简洁单纯。在这层的程序开发中主要是使用可视化编程工具。

　
　功能层相当于应用的本体，它是将具体的业务处理逻辑地编入程序中。例如，在制作订购合同的时要计算合同金额，按照定好的格式配置数据、打印订购合同，而
处理所需的数据则要从表示层或数据层取得。表示层和功能层之间的数据交往要尽可能简洁。例如，用户检索数据时，要设法将有关检索要求的信息一次传送给功能
层(参见图2)，而由功能层处理过的检索结果数据也一次传送给表示层。在应用设计中，一定要避免进行一次业务处理，在表示层和功能层间进行多几次数据交换
的笨拙设计。
通常，在功能层中包含有：确认用户对应用和数据库存取权限的功能以及记录系统处理日志的功能。这层的程序多半是用可视化编程工具开发的，也有使用COBOL和C语言的。
3. 数据层
　　数据层就是DBMS，负责管理对数据库数据的读写。DBMS必须能迅速执行大量数据的更新和检索。现在的主流是关系数据库管理系统(RDBMS)。因此，一般从功能层传送到数据层的要求大都使用SQL语言。