软件工程-体系结构设计

随着网络的发展和系统规模的壮大，软件体系结构已经在软件工程领域中有着广泛的应用，但迄今为止还没有一个被大家所公认的定义，许多专家学者从不同角度和不同侧面对软件体系结构进行了刻画，这里使用下面这个定义：

软件体系结构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把体系结构的不同部分组合（连接）起来。这一定义注重区分处理构件、数据构件和连接构件，这一方法在其他的定义和方法中基本上得到保持。

软件体系结构是一个很重要的设计内容，也是设计工作开始就要做的内容，其重要性表现在如下几方面：

（1）体系结构是系统的高层表示，是不同的系统相关人员讨论的焦点。

（2）在系统开发的早期阶段给出系统的体系结构，实际上就是对系统分析的过程。分析当前体系结构的设计能否满足系统关键性需求，如系统的性能、可靠性和可维护性等。这样的分析评估具有极深的影响。

（3）系统体系结构的内容是关于系统的组织和组件间的互操作，其形式是一个紧凑的、易于管理的描述单元。体系结构能在具有相似需求的系统之间互用，由此来支持大规模的软件复用。产品体系结构的开发就是希望有一个通用的产品体系结构供一系列相关系统使用。

如果每个项目都要从头开始设计软件的体系结构，那么开发的效率就会极大地降低，因此提出了软件体系结构风格的研究和应用。

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

系统结构设计是概要设计的一个主要内容，为了保证系统体系结构设计按质量完成，须按照如下原则进行设计，这些原则已经在前两节中详细讲解，在这里应用该原则。

（1）分解-协调原则。整个系统是一个整体，具有整体目的功能。但是这些目的和功能的实现是由相互联系的各个组成部分共同工作的结果。解决复杂问题的重要原则就是把它分解为多个小问题来处理。

（2）自顶向下原则。首先明确系统总的目的和范围，然后逐层分解，即先确定上层模块的功能，再确定下层模块的功能。

（3）信息隐藏、抽象原则。上层模块只规定下层模块做什么和所属模块间的协调关系，不需要了解下层模块的内部结构。这样做使模块之间的层次关系清晰，易于理解、实施和维护。

（4）一致性原则。保证整个软件设计过程中具有统一的规范。

（5）明确性原则。每个模块功能明确、接口明确，消除功能含糊模块。

（6）模块之间的耦合尽可能小，模块内聚尽可能高。

（7）模块的扇入和扇出系数合理。一个设计好的系统平均扇入和扇出通常是3或4，一般不超过7，但是一些特殊模块的扇入和扇出可以大一些，如菜单模块、公用模块等。

（8）模块的规模适当。过大的模块可能会使系统分解得不充分，内部包含多个功能部分；如果模块过小又会使得模块之间的接口较多，增加接口的复杂性。

体系结构，按照如上原则进行设计和评审，并可以考虑使用一些范型的体系结构来解决，同时考虑系统的特殊需求。下面是Garlan和Shaw对通用体系结构风格的分类：

（1）数据流风格：批处理序列，管道/过滤器；

（2）调用/返回风格：主程序/子程序，面向对象风格，层次结构；（3）独立构件风格：进程通信，事件系统；

（4）虚拟机风格：解释器，基于规则的系统；

（5）仓库风格：数据库系统，超文本系统，黑板系统；

在本文中，我们将介绍几种主要的和经典的体系结构风格和它们的优缺点。

1.C2风格

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

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

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

（3）一个连接件可以和任意数目的其他构件和连接件连接；

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

此种软件体系风格如图4-9所示，图中构件与连接件之间的连接体现了C2风格中构建系统的规则。

图4-9　C2风格的体系结构

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

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

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

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

2.管道/过滤器风格

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

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

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

（1）使得软件具有良好的隐蔽性和高内聚、低耦合的特点。

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

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

图4-10　管道/过滤器风格的体系结构

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

（5）允许对一些如吞吐量、死锁等属性的分析。

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

但是，这样的系统也存在着若干不利因素：(www.xing528.com)

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

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

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

3.数据抽象和面向对象风格

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

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

（1）因为对象对其他对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其他的对象；

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

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

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

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

图4-11　数据抽象和面向对象风格

4.基于事件的隐式调用风格

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

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

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

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

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

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

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

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

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

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

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

5.层次系统风格

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

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

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

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

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

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

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

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

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

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

图4-12　层次系统风格

6.仓库风格

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

控制原则的选取产生两个主要的子类。若输入流中某类时间触发进程执行的选择，则仓库是一个传统型数据库；另一方面，若中央数据结构的当前状态触发进程执行的选择，则仓库是一个黑板系统。如图4-13所示，黑板系统的传统应用是信号处理领域，如语音和模式识别，另一应用是松耦合代理数据共享存取。

图4-13　黑板系统

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

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

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

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