『常识』系统架构_软件架构风格概述

转载自:http://jpkc.whu.edu.cn/jpkc/dxqyxxxtfgnjg/dzja/dzjc/jc3.htm

1         软件架构风格概述

软件体系结构设计的一个核心问题是能否使用重复的体系结构模式，即能否达到体系结构级的软件重用。也就是说，能否在不同的软件系统中，使用同一体系结构。基于这个目的，学者们开始研究和实践软件体系结构的风格和类型问题。

软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。它反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。按这种方式理解，软件体系结构风格定义了用于描述系统的术语表和一组指导构件系统的规则。

对软件体系结构风格的研究和实践促进了对设计的复用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。体系结构风格的不变部分使不同的系统可以 共享同一个实现代码。只要系统是使用常用的、规范的方法来组织，就可使别的设计者很容易地理解系统的体系结构。例如，如果某人把系统描述为"客户/服务器"模式，则不必给出设计细节，我们立刻就会明白系统是如何组织和工作的。

软件系统结构风格通常分为三种模式，即架构模式，设计模式，代码模式。这三种不同的模式存在于它们各自的抽象层次和具体层次。架构模式是一个系统的，多层次策略，涉及到大尺度的组件以及整体性质和力学。它描述软件系统里的基本结构组织或纲要，提供一些事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。架构模式的好坏可以影响到总体布局和构架结构。设计模式是中等尺度的结构策略， 它描述了普遍存在的相互通讯组件中重复出现的结构．这种结构解决了在一定背号中的具有一般性的设计问题，定义出了子系统或组件的微观结构。设计模式的好坏不会影响到系统的总体布局和总体框架。代码模式是底层次的模式，并与编程语言密切相关，它描述怎样利用一个特定的编程语言的特点来实现一个组件的某些特定的方面或关系。代码模式的好坏会影响到一个中等尺度组件的内部、外部结构或行为的底层细节，但不会影响到一个部件或子系统的中等尺度的结构，更不会影响到系统的总体布局和大尺度框架。

体系结构风格定义了一个系统家族，即一个体系结构定义一个词汇表和一组约束：词汇表中包含一些构件和连接器类型，而这组约束指出系统是如何将这些构件和连接器组合起来的。常见的软件体系结构风格涉及：

• 设计词汇表是什么？或者构件和连接器的类型是什么？
• 可容许的结构模式是什么？
• 基本的计算模型是什么？
• 风格的基本不变性是什么？
• 其使用的常见例子是什么？
• 使用此风格的优缺点是什么？
• 其常见特例是什么？

软件体系结构设计的一个中心问题是能否重用软件体系结构模式，或者采用某种软件体系结构风格。有原则地使用软件体系结构风格具有如下意义：

• 它促进了设计的复用，使得一些经过实践证实的解决方案能够可靠地解决新问题。
• 它能够带来显著的代码复用，使得体系结构风格中的不变部分可共享同一个解决方案。
• 便于设计者之间的交流与理解。
• 通过对标准风格的使用支持了互操作性，以便于相关工具的集成。
• 在限定了设计空间的情况下，能够对相关风格作出分析。
• 能够对特定的风格提供可视化支持。

与此同时，人们目前尚不能准确回答的问题是：

• 系统设计的哪个要点可以用风格来描述；
• 能否用系统的特性来比较不同的风格，如何确定用不同的风格设计系统之间的互操作；
• 能否开发出通用的工具来扩展风格；
• 如何为一个给定的问题选择恰当的体系结构风格，或者如何通过组合现有的若干风格来产生一个新的风格。

M.Shaw等人根据此框架给出了管道与过滤器、数据抽象和面向对象组织、基于事件的隐式调用、分层系统、仓库系统及知识库和表格驱动的解释器等一些常见的软件体系结构风格。

2         经典软件架构风格

2.1    管道和过滤器风格

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2    数据抽象与面向对象风格

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

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

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

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

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

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

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

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

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

2.3    基于事件的隐式调用风格

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

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

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

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

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

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

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

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

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

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

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

2.4    层次系统风格

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

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

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

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

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

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

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

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

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

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

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

2.5    仓库风格

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

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

　　图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)，操作简单、易学易用。在变更用户接口时，只需改写显示控制和数据检查程序，而不影响其他两层。检查的内容也只限于数据的 形式和值的范围，不包括有关业务本身的处理逻辑。
      图形界面的结构是不固定的，这便于以后能灵活地进行变更。例如，在一个窗口中不是放入几个功能，而是按功能分割窗口，以便使每个窗口的功能简洁单纯。在这层的程序开发中主要是使用可视化编程工具。

---

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

4.3 三层C/S结构的优点

1。 具有灵活的硬件系统构成

---

 
　 　对于各个层可以选择与其处理负荷和处理特性相适应的硬件。这是一个与系统可缩放性直接相关的问题。例如，最初用一台Unix工作站作为服务器，将数据层 和功能层都配置在这台服务器上。随着业务的发展，用户数和数据量逐渐增加，这时就可以将Unix工作站作为功能层的专用服务器，另外追加一台专用于数据层 的服务器。若业务进一步扩大，用户数进一步增加，则可以继续增加功能层的服务器数目，用以分割数据库。清晰、合理地分割三层结构并使其独立，可以使系统构 成的变更非常简单。因此，被分成三层的应用基本上不需要修正。
2。 提高程序的可维护性
　　三层C/S结构中，应用的各层可以并行开发，各层也可以选择各自最适合的开发语言。
3。 利于变更和维护应用技术规范
　　因为是按层分割功能，所以各个程序的处理逻辑变得十分简单。
4。 进行严密的安全管理
　　越关键的应用，用户的识别和存取权限设定愈重要。在三层C/S结构中，识别用户的机构是按层来构筑的，对应用和数据的存取权限也可以按层进行设定。例如，即使外部的入侵者突破了表示层的安全防线，若在功能层中备有另外的安全机构，系统也可以阻止入侵者进入其他部分。
　　此外，系统管理简单，可支持异种数据库，有很高的可用性。

4.4 三层C/S应用的开发

---

[su);dH 
　　三层C/S应用的开发必须遵从以下原则：保护已有投资；降低应用系统的风险； 满足当前的迫切需要；考虑未来的发展规划。
　　开发出的三层C/S应用系统必须是：功能丰富且具有高可用性；功能要能跨应用系统；系统要能跨平台运行。
　 　美国BEA系统有限公司产品计划和战略副总裁Jeri Edwards女士，按下述三种三层C/S应用系统的典型开发类型，分别举例介绍了他们的开发目标、开发过程、开发成果及经验体会。新建应用系统类型 (Greenfield)，如英国劳工局的劳动力市场系统；提升已有系统性能类型(Turbocharger)，如Apple公司的AppleOrder Global系统；综合集成已有系统类型(Integrator)，如AT&T的Zenith应用系统。Jeri Edwards女士根据三层C/S应用系统的开发经验和教训，总结出了实现C/S应用系统的黄金10原则 ：
　　(1) 尽量简化项目，使项目易于管理。应尽快建起一个初始系统，并尽早投入运行。当项目规模较大时，可以将其分割成由更小开发组担负的子项目。
　　(2) 要把精力花在设计上。首先要彻底弄清需求 ，然后建立一个原型，以便测试设计中的薄弱环节。后来增加的特性或部件要保证与系统结构兼容。
　　(3) 要奉行拿来主义。近来，可供选购的市售C/S产品很多，要坚持能买就买，为我所用的原则。必要时，买来后可对系统加以修改，其中既包括基础部件也包括应用。
　　(4) 严格遵守业界标准。
　　(5) 采用TP监控器或对象事务处理管理器 (Object Transaction Manager ，OTM)。
　　(6) 要循序渐进。及时得到用户的反馈；保证项目各部分的良好衔接；及早解决接口问题，以保证项目进展协调；坚持边分析，边设计；边编码，边测试的原则。
　　(7) 在应用开发过程中，不可忽视系统管理。
　　(8) 反复测试，包括用户信任测试、基准测试、系统测试、性能测试、系统集成测试、坚固性测试、服务交付测试等。
　　(9) 制定合理的工程进度。
　　(10) 制定完善的系统拓展计划，包括用户的培训和技术支持、高效的硬软件装载、已有数据和系统的平滑迁移。

---

>xkr k=M#-s\F_Z 62^
*G‑

4.5 三层C/S应用中的核心

 

每个C/S环境，从最小的LAN环境到超级网络环境，都使用某种形式的中间件。实际上，无论客户机何时给服务器发送请求，也无论它何时应用存取数据库文 件，都有某种形式的中间件传递C/S链路，用以消除通信协议、数据库查询语言、应用逻辑与操作系统之间潜在的不兼容问题。中间件是C/S环境中最重要的部 件。所谓中间件是一个用API定义的软件层，是具有强大通信能力和良好可扩展性的分布式软件管理框架。它的功能是在客户机和服务器或者服务器和服务器之间 传送高级通信，将客户机群和服务器群有机地粘合起来。其工作流程是：在客户机里的应用程序需要驻留网络上某个服务器的数据或服务时，搜索此数据的C/S应 用程序需访问中间件系统，该系统将查找数据源或服务，并在发送应用程序请求后重新打包响应，将其传送回应用程序。

---

N2n\M^J^ 
　 　TP监控器在中间件技术中扮演着越来越重要的角色，特别是在三层C/S系统中。据Standish Group的调查，TP监控器是近两年信息业界最热门的技术之一。1996年有57%的关键应用是构筑在TP监控器上的。TP监控器擅长提供事务性语义， 允许就环境速度和可靠性进行编程。作为一种中间件，TP监控器提供一种用于编写分布式应用程序的API，它通常包含一组强大的管理工具。TP监控器是一个 高性能、高并行性、多用户的快速响应软件运行环境，它能有效地管理大量的并发任务，进而提高系统资源的利用率。如果采用TP监控器，系统总投资可节约 30%以上，开发周期可缩短40%～50%。大多数投入应用的三层应用系统都配备有一套事务处理监控系统，BEA TUXEDO是目前应用最广泛的事务处理监控系统。
　 　BEA TUXEDO是用于分布计算的中间件基础结构，它使开放式应用系统具有高可缩放性、高灵活性和高可维护性。它不仅具有分布式交易处理和应用间报文通信的功 能，而且具有一系列极其完善的服务，可帮助企业建立和运行应用系统，使开发人员能够建立跨越多个平台、数据库和操作系统的应用程序。这样，可以灵活选配操 作平台以充分适应应用环境。它具有以下特点： 
　　1、支持多种软硬件平台。完全符合Open Group的X/Open标准，支持TCP/IP协议，支持包括Unix、Windows NT、AS/400和大型机专用系统在内的70多个硬件平台和操作系统。
　　2、结构开放、灵活。模块结构以高级程序接口ATMI(Application-to-Transaction Manager Interface)为中心，有丰富的ATMI函数可供调用。
　　3、开放的联机事务处理。可提供诸如事务性语义、透明的二段式提交、事务记录及分布事务处理管理结构等功能。
　　4、与DCE的结合。通过一套工具和程序库，实现了与Open Group组织的分布计算环境DCE的有机结合。
　　5、功能丰富，包括：应用管理；事件代理；通过鉴别服务、授权服务和数据加密服务，为客户提供安全保证；对COBOL语言的支持；应用动态调节、负载平衡等保证高可靠性的功能等。
六、三层C/S结构的应用现状
　 　目前，用三层C/S结构开发的应用还不太多，但其数量的确在逐日增加。图3显示了北美运行的应用开发形态。三层C/S型应用的比例1995年占 5%，1997年增加到7。8%，预计到1999年将占22。9%。二层C/S型应用和在原有系统上附加GUI型的应用，是被定位为向三层C/S型转化的 过
度形态。就当前来说，这种形态的比例要比三层C/S高，且要持续一段时间。那么，什么情况下应采用三层C/S呢?据Gartner Group的调查表明，具有下述特点的应
用应考虑采用三层C/S。
　　1、应用的服务或种类超过50个；
　　2、应用是用不同语言编写的；
　　3、两个以上的异构数据源，如2个不同的DBMS或1个DBMS和1个文件系统；
　　4、应用的生命周期超过3年；
　　5、高工作负荷，例如每天超过5万个事务处理或在同一系统访问同一数据库的并发用户数超过300个；
　　6、有至关重要的应用内部通信，包括像电子数据交换(EDI)这类企业的内部通信。
　　从传统的主机/终端型应用到三层C/S化，要考虑时间和费用问题，有的场合还不适合，需要循序渐进。

5         浏览器/服务器风格

5.1 B/S结构的基本概念

B/S结构，即Browser/Server(浏览器/服务器)结构，是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构。在这种结构下，客户机上只要安装一个浏览器（Browser），如Netscape Navigator或Internet Explorer，服务器安装Oracle、Sybase、Informix或 SQL Server等数据库。浏览器通过Web Server同数据库进行数据交互。用户界面完全通过WWW浏览器实现，一部分事务逻辑在前端实现，但是主要事务逻辑在服务器端实现，形成所谓3-tier结构。B/S结构，主要是利用了不断成熟的WWW浏览器技术，结合浏览器的多种Script语言(VBScript、JavaScript…)和ActiveX技术，用通用浏览器就实现了原来需要复杂专用软件才能实现的强大功能，并节约了开发成本，是一种全新的软件系统构造技术。随着Windows 98/Windows 2000将浏览器技术植入操作系统内部，这种结构更成为当今应用软件的首选体系结构。

以目前的技术看，局域网建立B/S结构的网络应用，并通过Internet/Intranet模式下数据库应用，相对易于把握、成本也是较低的。它是一次 性到位的开发，能实现不同的人员，从不同的地点，以不同的接入方式（比如LAN， WAN， Internet/Intranet等）访问和操作共同的数据库；它能有效地保护数据平台和管理访问权限，服务器数据库也很安全 。特别是在JAVA这样的跨平台语言出现之后，B/S架构管理软件更是方便、快捷、高效。

B／S三层体系结构采用三层客户／服务器结构，在数据管理层(Server)和用户界面层(Client)增加了一层结构，称为中间件 (Middleware)，使整个体系结构成为三层。三层结构是伴随着中间件技术的成熟而兴起的，核心概念是利用中间件将应用分为表示层、业务逻辑层和数 据存储层三个不同的处理层次，如图2所示。三个层次的划分是从逻辑上分的，具体的物理分法可以有多种组合。中间件作为构造三层结构应用系统的基础平台，提 供了以下主要功能：负责客户机与服务器、服务器与服务器间的连接和通信；实现应用与数据库的高效连接；提供一个三层结构应用的开发、运行、部署和管理的平 台。这种三层结构在层与层之间相互独立，任何一层的改变不会影响其它层的功能。 
       在B／S体系结构系统中，用户通过浏览器向分布在网络上的许多服务器发出请求，服务器对浏览器的请求进行处理，将用户所需信息返回到浏览器。而其余如数据 请求、加工、结果返回以及动态网页生成、对数据库的访问和应用程序的执行等工作全部由Web Server完成。随着Windows将浏览器技术植入操作系统内部，这种结构已成为当今应用软件的首选体系结构。显然B／S结构应用程序相对于传统的 C／S结构应用程序是一个非常大的进步。

5.2 C/S和B/S 的优缺点比较

C/S和B/S是当今世界开发模式技术架构的两大主流技术。C/S是美国 Borland公司最早研发，B/S是美国微软公司研发。目前，这两项技术以被世界各国所掌握，国内公司以C/S和B/S技术开发出产品也很多。这两种技 术都有自己一定的市场份额和客户群，各家企业都说自己的管理软件架构技术功能强大、先进、方便，都能举出各自的客户群体，都有一大群文人墨客为自己摇旗呐 喊，广告满天飞，可谓仁者见仁，智者见智。 
1、C/S架构软件的优势与劣势 
（1）、应用服务器运行数据负荷较轻。 
最简单的C/S体系结构的数据库应用由两部分组成，即客户应用程序和数据库服务器程序。二者可分别称为前台程序与后台程序。运行数据库服务器程序 的机器，也称为应用服务器。一旦服务器程序被启动，就随时等待响应客户程序发来的请求；客户应用程序运行在用户自己的电脑上，对应于数据库服务器，可称为 客户电脑，当需要对数据库中的数据进行任何操作时，客户程序就自动地寻找服务器程序，并向其发出请求，服务器程序根据预定的规则应答，送回结果，应用 服务器运行数据负荷较轻。 
（2）、数据的储存管理功能较为透明。 
在数据库应用中，数据的储存管理功能，是由服务器程序和客户应用程序分别独立进行的，前台应用可以违反的规则，并且通常把那些不同的（不管是已知 还是未知的）运行数据，在服务器程序中不集中实现，例如访问者的权限，编号可以重复、必须有客户才能建立定单这样的规则。所有这些，对于工作在前台程序上 的最终用户，是“透明”的，他们无须过问（通常也无法干涉）背后的过程，就可以完成自己的一切工作。在客户服务器架构的应用中，前台程序不是非常“瘦小 ”，麻烦的事情都交给了服务器和网络。在C/S体系的下，数据库不能真正成为公共、专业化的仓库，它受到独立的专门管理。 
（3）、C/S架构的劣势是高昂的维护成本且投资大。 
首先，采用C/S架构，要选择适当的数据库平台来实现数据库数据的真正“统一”，使分布于两地的数据同步完全交由数据库系统去管理，但逻辑上两地 的操作者要直接访问同一个数据库才能有效实现，有这样一些问题，如果需要建立“实时”的数据同步，就必须在两地间建立实时的通讯连接，保持两地的数据库服 务器在线运行，网络管理工作人员既要对服务器维护管理，又要对客户端维护和管理，这需要高昂的投资和复杂的技术支持，维护成本很高，维护任务量大。 
     其次，传统的C/S结构的软件需要针对不同的操作系统系统开发不同版本的软件，由于产品的更新换代十分快，代价高和低效率已经不适应工作需要。在JAVA这样的跨平台语言出现之后，B/S架构更是猛烈冲击C/S，并对其形成威胁和挑战。 
2、B/S架构软件的优势与劣势 
（1）、维护和升级方式简单。 
     目前，软件系统的改进和升级越来越频繁，B/S架构的产品明显体现着更为方便的特性。对一个稍微大一点单位来说，系统管理人员如果需要在几百甚至 上千部电脑之间来回奔跑，效率和工作量是可想而知的，但B/S架构的软件只需要管理服务器就行了，所有的客户端只是浏览器，根本不需要做任何的维护。无论 用户的规模有多大，有多少分支机构都不会增加任何维护升级的工作量，所有的操作只需要针对服务器进行；如果是异地，只需要把服务器连接专网即可，实现远程 维护、升级和共享。所以客户机越来越“瘦”，而服务器越来越“胖”是将来信息化发展的主流方向。今后，软件升级和维护会越来越容易，而使用起来会越来越简 单，这对用户人力、物力、时间、费用的节省是显而易见的，惊人的。因此，维护和升级革命的方式是“瘦”客户机，“胖”服务器。 
（2）、成本降低，选择更多。 
     大家都知道windows在桌面电脑上几乎一统天下，浏览器成为了标准配置，但在服务器操作系统上windows并不是处于绝对的统治地位。现在 的趋势是凡使用B/S架构的应用管理软件，只需安装在Linux服务器上即可，而且安全性高。所以服务器操作系统的选择是很多的，不管选用那种操作系统都 可以让大部分人使用windows作为桌面操作系统电脑不受影响，这就使的最流行免费的Linux操作系统快速发展起来，Linux除了操作系统是免费的 以外，连数据库也是免费的，这种选择非常盛行。 
     比如说很多人每天上“网易”（原文为新浪）网，只要安装了浏览器就可以了，并不需要了解“网易”的服务器用的是什么操作系统，而事实上大部分网站确实没有使用windows操作系统，但用户的电脑本身安装的大部分是windows操作系统。 
（3）、应用服务器运行数据负荷较重。 
     由于B/S架构管理软件只安装在服务器端（Server）上，网络管理人员只需要管理服务器就行了，用户界面主要事务逻辑在服务器 （Server）端完全通过WWW浏览器实现，极少部分事务逻辑在前端（Browser）实现，所有的客户端只有浏览器，网络管理人员只需要做硬件维护。 但是，应用服务器运行数据负荷较重，一旦发生服务器“崩溃”等问题，后果不堪设想。因此，许多单位都备有数据库存储服务器，以防万一。 

5.3 C/S 与 B/S 区别

      Client/Server是建立在局域网的基础上的，Browser/Server是建立在广域网的基础上的。 
（1）硬件环境不同： 
      C/S 一般建立在专用的网络上， 小范围里的网络环境， 局域网之间再通过专门服务器提供连接和数据交换服务。

B/S 建立在广域网之上的， 不必是专门的网络硬件环境，例如电话上网， 租用设备， 信息自己管理， 有比C/S更强的适应范围， 一般只要有操作系统和浏览器就行。 
（2）、对安全要求不同 
      C/S 一般面向相对固定的用户群， 对信息安全的控制能力很强。 一般高度机密的信息系统采用C/S 结构适宜，可以通过B/S发布部分可公开信息。 
B/S 建立在广域网之上， 对安全的控制能力相对弱， 面向是不可知的用户群。 
（3）、对程序架构不同 
      C/S 程序可以更加注重流程，可以对权限多层次校验，对系统运行速度可以较少考虑。 
B/S 对安全以及访问速度的多重的考虑， 建立在需要更加优化的基础之上。 比C/S有更高的要求，B/S结构的程序架构是发展的趋势，从MS的。Net系列的BizTalk 2000 Exchange 2000等，全面支持网络的构件搭建的系统。SUN和IBM推的JavaBean构件技术等，使B/S更加成熟。 
（4）、软件重用不同 
      C/S 程序可以不可避免的整体性考虑， 构件的重用性不如在B/S要求下的构件的重用性好。 
      B/S 对的多重结构，要求构件相对独立的功能。 能够相对较好的重用。就如买来的餐桌可以再利用，而不是做在墙上的石头桌子。 
（5）、系统维护不同 
      系统维护是软件生存周期中，开销大，相当重要。C/S 程序由于整体性，必须整体考察，处理出现的问题以及系统升级难， 可能是再做一个全新的系统。 B/S 构件组成方面构件个别的更换，实现系统的无缝升级。 系统维护开销减到最小，用户从网上自己下载安装就可以实现升级。
（6）、处理问题不同 
      C/S 程序可以处理用户面固定，并且在相同区域， 安全要求高的需求，与操作系统相关， 应该都是相同的系统。 B/S 建立在广域网上， 面向不同的用户群，分散地域， 这是C/S无法作到的，与操作系统平台关系最小。 
（7）、用户接口不同 
      C/S 多是建立在Window平台上，表现方法有限，对程序员普遍要求较高。 B/S 建立在浏览器上， 有更加丰富和生动的表现方式与用户交流， 并且大部分难度减低，降低开发成本。 
（8）、信息流不同 
      C/S 程序一般是典型的中央集权的机械式处理，交互性相对低。 B/S 信息流向可变化， B－B、 B－C、 B－G等信息流向的变化， 更像交易中心。

6         正交软件架构风格

6.1    正交软件架构风格概述

正交软件架构由组织层(Layer)和线索(Thread)的构件(Component)构成。层是由一组具有相同抽象级别(Level of Abstraction)的构件构成。线索是子系统的特例，它是由完成不同层次功能的构建组成（通过相互调用来关联），每一条线索完成整个系统中相对独立的一部分功能。每一条线索的实现与其他线索的实现无关或关联很少，在同一层中的构件之间是不存在相互调用的。

       如果线索是相互独立的，即不同线索中的构建之间没有相互调用，那么这个节都就是完全正交的。从以上定义，我们可以看出，正交软件架构是一种以垂直线索架构族为基础的层次化结构，其解不能思想是把应用系统的结构按功能的正交相关性，垂直分割为若干个线索（子系统），线索又分为几个层次，每个线索由多个具有不同层次功能和不同抽象级别的构件构成。各线索的相同层次的构建具有相同的抽象级别。因此，我们可以归纳正交软件架构的主要特征如下：

（1）    由完成不同功能的n(n>1)个线索（子系统）组成；

（2）    系统具有m(m>1)个不同抽象级别的层；

（3）    线索之间是相互独立的(正交的)；

（4）    系统有一个公共驱动层（一般为最高层）和公共数据结构（一般为最底层）。

对大型的和复杂的软件系统，其子系统（一级子线索）还可以划分为更低一级的子线索（二级子线索），形式多级正交结构。正交软件架构的框架如图所示：

图中是一个三级线索、五层结构的正交软件架构框架图，在该图中，ABDFK组成了一条线索，ACEJK也是一条线索，因为B，C处于同一层次中，所以不允许进行相互调用；H、J除了同意层次中，也不允许进行相互调用。一般来讲，第五层是一个物理数据库连接都见或设备勾结案，供整个系统公用。

在软件演化过程中，系统需求会不断发生变化。在正交软件架构中，因线索的正交性，每一个需求变动仅影响某一条线索，而不会涉及到其他线索。这样，就把软件需求的变动局部化了，产生的影响也被限制在一定范围内，因此容易实现。

6.2    设计和进化过程

基于正交软件家都的软件开发过程可以分为独立的两个阶段，这两个阶段分别是实验原型(Experimental Prototype)阶段和演化开发阶段。

实验原型阶段。这一阶段考虑的首要问题是要获得对系统的问题域的理解。为了达到这个目的，软件卡发组织需要构建一系列原型，与实际的最终用户一起进行讨论和评审，这些原型应该演示和支持全局改进的实现。但是，来自用户的最终需求是很模糊的，因此，整个第一个阶段的作用是使最终系统更加精确化，有助于决定实际开发的可行性。

演化开发阶段。实验原型阶段的结果可以决定是否开始实现最终系统，如果可以，开发进入第二个极端。与实验原型阶段相比，演化开发阶段的重点放在最终产品的开发商。这时，原型即被当作系统的规格说明，又可当作系统的演示版本。这意味着演化开发阶段的重点将转移到构件的精确化。

  虽然实验原型阶段的结果可以决定是否开始实现最终系统，但在实验原型阶段之后，并不是所有的功能需求都已经足够准确，然而，系统有哪些组成部分和这些部分该如何相互作用应该是明确的了。

  在每个阶段中，都必须以一系列的开发周期(Development Cycle)为单位安排和组织工作，一个开发周期的时间长短可根据软件项目的性质、功能复杂性能、开发阶段等因素决定。。每一个开发周期都要有不同的着重点，要有一个分析、设计和实现的过程，这个过程却取决于当前对系统的理解和前一个开发周期的结果。为了控制开发进度，在每一开发周期结束时，都必须对当前产品安排一次技术评审，评审组成果由最终用户代表和开发组织的管理人员组成。技术评审的目的是指当前产品中可能存在的问题，制定下一步开发周期的工作计划。

6.3    正交软件架构风格的优点

软件体系结构已经成为当今软件工程和软件开发中一个突出的研究领域， 对于软件项目的开发来说， 一个清晰的软件体系结构是首要的。正交软件体系结构具有以下优点：

(1) 结构清晰，易于理解。正交软件体系结构的形式有利于理解。 由于线索功能相互独立，不进行互相调用，结构简单、清晰，组件在结构图中的位置已经说明它所实现的是哪一级抽象， 担负的是什么功能。

(2) 易修改，可维护性强。 由于线索之间是相互独立的，所以对一个线索的修改不会影响到其他线索。 因此，当软件需求发生变化时，可以将新需求分解为独立的子需求， 然后以线索和其中的组件为主要对象分别对各个子需求进行处理，这样软件修改就很容易实现。 系统功能的增加或减少，只需相应的增删线索组件族， 而不影响整个正交体系结构，因此能方便地实现结构调整。

(3) 可移植性强，重用粒度大。 因为正交结构可以为一个领域内的所有应用程序所共享，这些软件有着相同或类似的层次和线索，可以实现体系结构级的重用。

7         基于层次消息总线的架构风格

7.1    JB/HMB风格的基本特征

目前对软件体系结构的研究集中在以下方面：各种体系结构风格的汇编和总结、体系结

构描述语言(architectural description languages，简称ADLS)、体系结构的形式化基础、体系结构分析技术、基于体系结构的软件开发、体系结构恢复和再工程、支持体系结构设计的工具和环境及特定领域的软件体系结构等。 青鸟工程在“九五”期间，对基于构件构架模式的软件工业化生产技术进行了研究，并实现了青鸟软件生产线系统151。以青鸟软件生产线的实践为背景，提出了基于层次消息总线的软件体系结构(Jade bird hierarchical message bus based style，以下简称JB/HMB风格)，设计了相应的体系结构描述语言，开发了支持软件体系结构设计的辅助工具集，并研究了采用JB/HMB风格进行应用系统开发的过程框架。

JB/HMB风格的提出基于以下的实际背景：

(1)      随着计算机网络技术的发展，特别是分布式构件技术的日渐成熟和构件互操作标准的出现，如CORBA，DCOM和EJB等，加速了基于分布式构件的软件开发趋势，具有分布和并发特点的软件系统已成为一种普遍的应用需求。

(2)    基于事件驱动的编程模式已在图形用户界面程序设计中获得广泛应用。在此之前的

程序设计中，通常使用一个大的分支语句(switch Statement)控制程序的转移，对不同的输人情况分别进行处理，程序结构不甚清晰。基于事件驱动的编程模式在对多个不同事件响应的情况下，系统自动调用相应的处理函数，程序具有清晰的结构。

(3)    计算机硬件体系结构和总线的概念为软件体系结构的研究提供了很好的借鉴和启发，

在统一的体系结构框架下(即总线和接口规范)，系统具有良好的扩展性和适应性。任何计算机厂商生产的配件，甚至是在设计体系结构时根本没有预料到的配件，只要遵循标准的接口规范，都可以方便地集成到系统中，对系统功能进行扩充，甚至是即插即用(即运行时刻的系统演化)。正是标准的总线和接口规范的制定，以及标准化配件的生产，促进了计算机硬件的产业分工和蓬勃发展。

JB/HMB风格基于层次消息总线、支持构件的分布和并发，构件之间通过消息总线进行通讯，如图所示。消息总线是系统的连接件，负责消息的分派、传递和过滤以及处理结果的返回。各个构件挂接在消息总线上，向总线登记感兴趣的消息类型。构件根据需要发出消息，由消息总线负责把该消息分派到系统中所有对此消息感兴趣的构件，消息是构件之间通讯的唯一方式，构件接收到消息后，根据自身状态对消息进行响应，并通过总线返回处理结果。由于构件通过总线进行连接，并不要求各个构件具有相同的地址空间或局限在一台机器上。该风格可以较好地刻画分布式并发系统，以及基于CORBA，DCOM和EJB规范的系统。

如图所示，系统中的复杂构件可以分解为比较低层的子构件，这些子构件通过局部消息

总线进行连接，这种复杂的构件称为复合构件。如果子构件仍然比较复杂，可以进一步分解。

如此分解下去，整个系统形成了树状的拓扑结构，树结构的末端结点称为叶结点，它们是系统中的原子构件，不再包含子构件，原子构件的内部可以采用不同于JB/HMB的风格，例如数据流风格、面向对象风格及管道/过滤器风格等，这些属于构件的内部实现细节。但要集成到JB/HMB风格的系统中，必须满足JB/HMB风格的构件模型的要求，主要是在接口规约方面的要求。另外，整个系统也可以作为一个构件，通过更高层的消息总线，集成更大的系统中。于是，可以采用统一的方式刻画整个系统和组成系统的单个构件。

7.2    构建模型

系统和组成系统的成分通常是比较复杂的，难以从一个视角获得对它们的完整理解，因

此一个好的软件工程方法往往从多个视角对系统进行建模，一般包括系统的静态结构、动态行为和功能等方面。例如，在Rumbaugh等人提出的OMT(object modeling technology)方法中，

采用了对象模型、动态模型和功能模型刻画系统的以上3个方面。

借鉴上述思想，为满足体系结构设计的需要，JB/HMB风格的构件模型包括了接口、静态结构和动态行为3个部分，如图所示。

在图中所示的构件模型中，左上方是构件的接口部分，一个构件可以支持多个不同的接口，每个接口定义了一组输入和输出的消息，刻画了构件对外提供的服务以及要求的环境服务，体现了该构件同环境的交互.右上方是用带输出的有限状态自动机刻画的构件行为，构件接收到外来消息后，根据当前所处的状态对消息进行响应，并可能导致状态的变迁.下方是复合构件的内部结构定义，复合构件是由更简单的子构件通过局部消息总线连接而成的.消息总线为整个系统和各个层次的构件提供了统一的集成机制。

7.3    构件接口

在体系结构设计层次上，构件通过接口定义了同外界的信息传递和承担的系统责任，构

件接口代表了构件同环境的全部交互内容，也是唯一的交互途径.除此之外，环境不应对构件做任何其他与接口无关的假设，例如实现细节等。

JB/HMB风格的构件接口是一种基于消息的互联接口，可以较好地支持体系结构设计。

构件之间通过消息进行通讯，接口定义了构件发出和接收的消息集合.同一般的互联接口相

比.JB/HMB的构件接口具有两个显著的特点.首先，构件只对消息本身感兴趣，并不关心消

息是如何产生的，消息的发出者和接收者不必知道彼此的情况，这样就切断了构件之间的直

接联系，降低了构件之间的藕合强度，进一步增强了构件的复用潜力，并使得构件的替换变得更为容易。另外，在一般的互联接口定义的系统中，构件之间的连接是在要求的服务和提供的服务之间进行固定的匹配，而在JB/HMB的构件接口定义的系统中，构件对外来消息的响应，不但同接收到的消息类型相关，而且同构件当前所处的状态相关.构件对外来消息进行响应后，可能会引起状态的变迁.因此，一个构件在接收到同样的消息后，在不同时刻所处的不同状态下，可能会有不同的响应。

消息是关于某个事件发生的信息，上述接口定义中的消息分为两类:(i)构件发出的消

息，通知系统中其他构件某个事件的发生或请求其他构件的服务；(ii)构件接收的消息，对系

统中某个事件的响应或提供其他构件所需的服务.接口中的每个消息定义了构件的一个端口，

具有互补端口的构件可以通过消息总线进行通讯，互补端口指的是除了消息进出构件的方向

不同之外，消息名称、消息带有的参数和返回结果的类型完全相同的两个消息.

当某个事件发生后，系统或构件发出相应的消息，消息总线负责把该消息传递到对此消息感兴趣的构件.按照响应方式的不同，消息可分为同步消息和异步消息.同步消息是指消息

的发送者必须等待消息处理结果返回才可以继续运行的消息类型.异步消息是指消息的发送

者不必等待消息处理结果的返回即可继续执行的消息类型.常见的同步消息包括(一般的)过

程调用。

7.4    消息总线

JB/HMB风格的消息总线是系统的连接件，构件向消息总线登记感兴趣的消息，形成构件-消息响应登记表.消息总线根据接收到的消息类型和构件一消息响应登记表的信息，定位并传递该消息给相应的响应者，并负责返回处理结果.必要时，消息总线还对特定的消息进行过滤和阻塞.下图给出了采用对象类符号表示的消息总线的结构。

7.5    运行时的演化

在许多重要的应用领域中，例如金融、电力、电信及空中交通管制等，系统的持续可用性是一个关键性的要求，运行时刻的系统演化可减少因关机和重新启动而带来的损失和风险。

此外，越来越多的其他类型的应用软件也提出了运行时刻演化的要求，在不必对应用软件进行重新编译和加载的前提下，为最终用户提供系统定制和扩展的能力。

JBI/HMB风格方便地支持运行时刻的系统演化，主要体现在以下3个方面：

(1)      动态增加或删除构件。在JB/HMB风格的系统中，构件接口中定义的输人和输出消息

刻画了一个构件承担的系统责任和对外部环境的要求，构件之间通过消息总线进行通讯，彼

此并不知道对方的存在。因此只要保持接口不变，构件就可以方便地替换。一个构件加人到系统中的方法很简单，只需向系统登记其所感兴趣的消息即可。但删除一个构件可能会引起系统中对于某些消息没有构件响应的异常情况，这时可以采取两种措施：一是阻塞那些没有构件响应的消息，二是首先使系统中的其他构件或增加新的构件对该消息进行响应，然后再删除相应的构件。系统中可能增删改构件的情况包括：当系统功能需要扩充时，往系统中增加新的构件。当对系统功能进行裁剪，或当系统中的某个构件出现问题时，需要删除系统中的某个构件。用带有增强功能或修正了错误的构件新版本代替原有的旧版本。

(2)      动态改变构件响应的消息类型。类似地，构件可以动态地改变对外提供的服务(即接

收的消息类型)，这时应通过消息总线对发生的改变进行重新登记。

(3)      消息过滤。利用消息过滤机制，可以解决某些构件集成的不匹配问题，详见“消息过滤”一节。消息过滤通过阻塞构件对某些消息的响应，提供了另一种动态改变构件对消息进行响应的方式。

7.6    JB/HMB风格的优点

以上讨论了JB/HMB风格的各组成要素，下面对JB/HMB风格的主要特点作总结。

(1)    从接口、结构和行为方面对构件进行刻画。在JB/HMB风格中，构件的描述包括接口、

静态结构和动态行为3个方面。

接口：构件可以提供一个或多个接口，每个接口定义了一组发送和接收的消息集合，

刻画了构件对外提供的服务以及要求的环境服务，接口之间可以通过继承表达相似性。

静态结构：复合构件是由子构件通过局部消息总线连接而成的，形成该复合构件的

内部结构。

动态行为：构件行为通过带输出的有限状态机刻画，构件接收到外来消息后，不但根

据消息类型，而且根据构件当前所处的状态对消息进行响应，并导致状态的变迁。

基于层次消息总线：消息总线是系统的连接件，负责消息的传递、过滤和分派，以及

处理结果的返回。各个构件挂接在总线上，向系统登记感兴趣的消息。构件根据需要发出消息，由消息总线负责把该消息分派到系统中对此消息感兴趣的所有构件。构件接收到消息后，根据自身状态对消息进行响应，并通过总线返回处理结果。由于构件通过总线进行连接，并不要求各个构件具有相同的地址空间或局限在一台机器上，系统具有并发和分布的特点。系统和复合构件可以逐层分解，子构件通过(局部)消息总线相连。每条消息总线分别属于系统和各层次的复合构件，我们把这种特征的总线称为层次消息总线。在系统开发方面，由于各层次的总线局部在相应的复合构件中，因此可以更好地支持系统的构造性和演化性。

统一描述系统和组成系统的构件：组成系统的构件通过消息总线进行连接，复杂构

件又可以分解为比较简单的子构件，通过局部消息总线进行连接，如果子构件仍然比较复杂，

可以进一步分解。系统呈现出树状的拓扑结构。另外，整个系统也可以作为一个构件，集成到更大的系统中。于是，就可以对整个系统和组成系统的各层构件采用统一的方式进行描述。

支持运行时刻的系统演化：系统的持续可用性是许多重要的应用系统的一个关键性

要求，运行时刻的系统演化可减少因关机和重新启动而带来的损失和风险。JB/HMB风格方便地支持运行时刻的系统演化，主要包括动态增加或删除构件、动态改变构件响应的消息类型和消息过滤。