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

下面是Garlan和Shaw对通用体系结构风格的分类：

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

（2）调用/返回风格：主程序/子程序；面向对象风格；层次结构

（3）独立构件风格：进程通讯；事件系统

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

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

限于篇幅，在本文中，我们将只介绍几种主要的和经典的体系结构风格和它们的优缺点。有关新出现的软件体系结构风格，将在后续文章中进行介绍。 C2体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。C2风格中的系统组织规则如下：

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

（2）构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；（3）一个连接件可以和任意数目的其它构件和连接件连接；

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

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

图3 C2风格的体系结构

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（3）因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。抽象数据类型概念对软件系统有着重要作用，目前软件界已普遍转向使用面向对象系统。这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种被称作管理者的构件，因为它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。

图5是数据抽象和面向对象风格的示意图。图5数据抽象和面向对象风格的体系结构

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

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

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

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

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

（2）必须修改所有显式调用它的其它对象，并消除由此带来的一些副作用。例如，如果A使用了对象B，C也使用了对象B，那么，C对B的使用所造成的对A的影响可能是料想不到的。基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其它构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。

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

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

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

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

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

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

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

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

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

（3）既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题。层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层可见。这样的系统中构件在一些层实现了虚拟机（在另一些层次系统中层是部分不透明的）。连接件通过决定层间如何交互的协议来定义，拓扑约束包括对相邻层间交互的约束。

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

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

图6层次系统风格的体系结构

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

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

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

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

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

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

（2）很难找到一个合适的、正确的层次抽象方法。在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存贮上执行，仓库与外构件间的相互作用在系统中会有大的变化。

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

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

图7黑板系统的组成

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

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

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

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

-----------------------------------------------------

以下内容节选自清华大学版《系统分析师教程》

仅供学习、参考使用，详细内容请查阅原著

-----------------------------------------------------

3.4.1系统设计概述

系统设计是信息系统开发过程中另一个重要阶段。这一阶段中，要根据前一阶段系统分析的结果，在已经获得批准的系统分析报告的基础上，进行新系统设计。

系统设计的主要目的就是为系统制定蓝图，在各种技术和实施方法中权衡利弊，精心设计，合理使用各种资源，最终勾画出新系统的详细设计方案。

但是，实际情况往往与主观设定存在差距，项目开发过程中并不总是能按总体计划分阶段顺利推进，甚至造成反复，究其原因有：

1.传统方法认为“系统设计之前，用户的所有的需求都能被预先定义”。

2.在生命周期法中，系统分析通常用数据流图、数据字典、判断表等工具来描述目的系统的逻辑模型，这些文字和图形工具被认梢猿浞址从承孪低车穆呒δ堋?/P>

3.生命周期法将开发过程严格划分为几个不同阶段，并严格分离，即后一个阶段工作必须在前一阶段结束才能进行，把各个阶段工作的变化幅度限制在一个特定的范围内。

3.4.1.1系统设计的内容和步骤

为保证总体结构设计的顺利完成，主要应遵循以下几条原则：

1.分解-协调原则。整个系统是一个整体，具有整体的目的和功能。但这些目的和功能的实现又是由相互联系的各个组成部分共同工作的结果。解决复杂问题的一个很重要的原则就是把它分解成多个小问题分别处理，在处理过程中根据系统总体要求协调各部门的关系。在系统中，应按以下要求分解：

按系统的功能进行分解

按管理活动和信息运动的客观规律分解

按系统的工作规程分解

按用户工作的特殊需要分解（如按保密的要求）

按开发、维护和修改的方便性分解

协调的依据主要是：

目的调节

工作进程调节

工作规范和技术规范协调

信息协调（指信息的提供和收回）

业务内容协调（如某些业务指标的控制）

2.自顶向下的原则

3.信息隐蔽、抽象的原则

4.一致性的原则

5.明确性原则

6.模块之间的耦合尽可能小，模块内部组合要尽可能紧凑。

7.模块的扇入系数和扇出系数要合理。

8.模块的规模适当

3.4.2系统总体结构设计

系统总体结构设计是要根据系统分析的要求和组织的实际情况来对新系统的总体结构形式和可利用的资源进行大致设计，这是一种宏观、总体上的设计和规划。

3.4.2.1子系统划分

1.子系统划分的原则

为了方便今后系统开发和系统运行，子系统的划分应遵循如下几点原则：

子系统要具有相对独立性。

子系统之间数据的依赖性尽量小

子系统划分的结果应使数据冗余较小

子系统的划分应便于系统分阶段实现

子系统的划分应考虑到各类资源的充分利用

2.系统划分方法的分类

3.4.2.2子系统结构设计

子系统结构设计的任务是确定划分后的子系统的模块结构，并画出模块结构图。这个工程中必须考虑以下几个问题：

每个子系统如何划分多个模块

如何确定子系统之间、模块之间传送的数据及其调用关系

如何评价并改进模块结构的质量

如何从数据流图导出模块结构图

3.4.2.3网络设计

网络设计首先要根据系统的要求选择网络的结构。然后根据系统结构划分的结果，安排网络和设备的分布，再根据物理位置来考虑联网布线和配件，最后就是根据实际业务的要求划定网络个结点的级别、管理方式、数据读写的权限、选择相应的软件系统等。

3.4.2.4硬件设备及配置

在确定了系统的划分后，就可以考虑各子系统的设备，即计算机和网络设备的配置问题，以及如何将这些分布的设备和任务、功能、数据资源等集中统一管理。

3.4.3系统模块结构设计

3.4.3.1模块的概念

模块是组成系统的基本单位，它的特点是可以组合、分解和更换。系统中任何一个处理功能都可以看成是一个模块。根据模块功能具体化程度的不同，可以分为逻辑模块和物力模块。在系统逻辑模型中定义的处理功能可视为逻辑模块。物理模块是逻辑模块的具体化，可以是一个计算机程序、子程序或若干条程序语句，也可以是人工过程的某项具体工作。

3.4.3.2模块结构图

模块结构图主要关心的是模块的外部属性，即上下级模块、同级模块之间的数据传递和调用关系，并不关心模块的内部。

模块结构图式结构设计中描述系统结构的图形工具。作为一种文档，它必须严格地定义模块的名字、功能和接口，同时还应当在模块结构图上反映出结构化设计的思想。

3.4.3.3模块的变化型分析与事务型分析

一个系统的模块结构图一般有两种标准形式，变换型模块结构和事务型模块结构。

变换型模块结构描述的是变换型系统。变换型系统由3部分组成：输入、数据加工（中心变换）和输出，它的功能是将输入的数据经过加工后输出。事务型系统由3层组成：事务层、操作层和细节层。它的功能是对接收的事务按其类型选择某一事务处理。

1.变换型分析

变换型分析过程可以分为3步

（1）找出系统底层逻辑输入、主加工和逻辑输出

（2）设计顶层模块和第一层模块

（3）对输入、变换、输出模块逐个分解，便可得到初始结构图

2.事务型分析

事务型分析也是“自顶向下，逐步细化”的原则进行。先设计模块，其功能就是整个系统的功能。下面有一个“分析模块”和“调度模块”。前者分析事务的类型，后者根据不同的类型调用相应的下层模块。

3.4.3.4模块的耦合与内聚

一个合理的模块划分，应该是内部联系强，模块间尽可能独立，接口明确、简单，有适当的公用性，要满足“欧和小，内聚大”的原则。

3.4.4系统详细设计

3.4.4.1代码设计

代码是用来表征客观事物的一组有序的符号，以便易于计算机和人工识别与处理。代码的类型指代码符号的表示形式，一般有数字型、字母型、数字字母混合型等。3种类型的代码各有所长，应根据使用者的要求、信息量的多少、信息交换的频度、使用者的习惯等方面综合考虑。

代码设计应该遵循以下基本原则：

性，一个对象可能有多个名称，也可按不同的方式对它进行描述。但在一个编码体系中，一个对象只能赋予它的代码。

合理性，代码结构与相应的分类体系相对应。

可扩充性。应留有充分的余地，以备将来不断扩充的需要。

简单性。结构尽可能简单，以减少各种差错。

适用性。代码尽可能反映对象的特点，以助记忆，便于填写。

规范性。国家有关编码标准是代码设计的重要依据，已有标准的必须遵循。在一个代码体系中，代码结构、类型、编写个是必须统一。

系统性。有一定的分组规则，从而在整个系统中具有通用性。

3.4.4.2输出设计

从系统开发的角度看，输出决定输入，即输入信息只有根据输出要求才能确定。

3.4.4.3输入设计

输入设计的目的是保证向系统输入正确的数据。

3.4.4.4处理过程设计

总体结构设计将系统分解成许多模块，并决定了每个模块的外部特征：功能与界面。计算机处理过程的设计则要确定每个模块的内部特征，即内部的执行过程，包括局部的数据组织、控制流、每一步的具体加工要求及种种事实细节。通过这样的设计，为编写程序制定一个周密的计划。

处理过程设计的关键是用一种合适的表达方法来描述每个模块的执行过程。这种表示方法应该简明、精确，并由此能直接导出用编程语言表示的程序。常用的描述方式由图形、语言和表格等3类。

1.程序流程图

2.盒图（NS图）

3.形式语言

4.决策树

5.决策表

3.4.4.5数据存储设计

信息系统的主要任务是通过大量的数据获得管理所需要的信息，这就必须存储和管理大量的数据。因此建立一个良好的数据组织结构和数据库，使整个系统都可以迅速、方便、准确地调用和管理所需的数据，是衡量信息系统开发工作好坏的主要指标之一。

3.4.4.6用户界面设计

用户界面是系统与用户之间的接口，也是控制和选择信息输入输出的主要途径。用户界面设计应坚持友好、简便、实用、易于操作的原则。

用户界面设计包括菜单方式、会话方式、操作提示方式，以及操作权限管理方式等。

3.4.4.7安全控制设计

从数据环境和数据处理两方面看，影响系统安全的因素有：

环境性因素。

数据处理因素。

3.4.5系统设计报告

系统设计阶段的最终结果是系统设计报告。系统设计报告是下一步系统实施的基础。

从系统调查、系统分析到系统设计是信息系统开发的主要工作，这3个阶段的工作量几乎占了总开发工作量的70%，而且这3个阶段所用的工作图表较多，涉及面广，较为复杂。

与传统的软件开发方式相比，基于构件的软件开发方法有什么突破呢？一、体系结构软件体系结构代表了系统公共的高层次的抽象，它是系统设计成败的关键。其设计的核心是能否使用重复的体系模式。传统的应用系统体系结构从基于主机的集中式框架，到在网络的客户端上通过网络访问服务器的框架，都不能适应目前企业所处的商业环境，原因是：企业过分地依赖于某个供应商的软件和硬件产品。这种单一供应商使得企业难以利用计算供应商的免费市场，将计算基础设施的重要决定交给第三方处理，这显然不利于企业在合作伙伴之间共享信息。不能适应远程访问的分布式、多层次异构系统。封装的应用系统在出现某种组织需要时，难以用定制来维护系统，从而难以满足多变的需求。不能实现分析、设计核心功能重用，最多只能实现代码重用。如今，应用系统已经发展成为在Intranet和Internet上的各种客户端可远程访问的分布式、多层次异构系统。CBSD为开发这样的应用系统提供了新的系统体系结构。它是标准定义的、分布式、模块化结构，使应用系统可分成几个独立部分开发，可用增量方式开发。这样的体系结构实现了CBSD的以下几点目标:能够通过内部开发的、第三方提供的或市场上购买的现有构件，来集成和定制应用软件系统。鼓励在各种应用系统中重用核心功能,努力实现分析、设计的重用。系统都应具有灵活方便的升级和系统模块的更新维护能力。封装最好的实践案例，并使其在商业条件改变的情况下，还能够被采用，并能保留已有资源。由此看出,CDSD从系统高层次的抽象上解决了复用性与异构互操作性，这正是分布式网络系统所希望解决的难题。二、开发过程传统的软件开发过程在重用元素、开发方法上都与CBSD有很大的不同。虽然面向对象技术促进了软件重用，但是，只实现了类和类继承的重用。在整个系统和类之间还存在很大的缺口。为填补这个缺口，人们曾想了许多方法，如系统体系结构、框架、设计模式等。自从构件出现以来，软件的重用才得到了根本改变。CBSD实现了分析、设计、类等多层次上的重用。图1显示了它的重用元素分层实现。在分析抽象层上，重用元素有子系统、类；在设计层上重用元素有系统体系结构、子系统体系结构、设计模式、框架、容器、构件、类库、模板、抽象类等。在软件开发方法上，CBSD引导软件开发从应用系统开发转变为应用系统集成。建立一个应用系统需要重用很多已有的构件模块，这些构件模块可能是在不同的时间、由不同的人员开发的，并有各种不同的用途。在这种情况下，应用系统的开发过程就变成对构件接口、构件上下文以及框架环境一致性的逐渐探索过程。例如，在J2EE平台上，用EJB框架开发应用系统，主要工作是将应用逻辑,按session Bean、entity Bean设计开发,并利用JTS事务处理的服务实现应用系统。其主要难点是事务划分、构件的部署与开发环境配置。概括地说，传统的软件开发过程是串行瀑布式、流水线的过程;而CBSD是并发进化式，不断升级完善的过程。图2显示了它们的不同。三、软件方法学软件方法学是从各种不同角度、不同思路去认识软件的本质。传统的软件方法学是从面向机器、面向数据、面向过程、面向功能、面向数据流、面向对象等不断创新的观点反映问题的本质。整个软件的发展历程使人们越来越认识到应按客观世界规律去解决软件方法学问题。直到面向对象方法的出现，才使软件方法学迈进了一大步。但是，高层次上的重用、分布式异构互操作的难点还没有解决。CBSD发展到今天，才在软件方法学上为解决这个难题提供了机会。它把应用业务和实现分离，即逻辑与数据的分离，提供标准接口和框架，使软件开发方法变成构件的组合。因此，软件方法学是以接口为中心，面向行为的设计。图3是其开发过程。归纳起来，CBSD的软件开发方法学应包括下面几方面：对构件有明确的定义。基于构件的概念需要有构件的描述技术和规范，如UML、JavaBean、EJB、Servlet规范等。开发应用系统必须按构件裁剪划分组织，包括分配不同的角色。有支持检验构件特性和生成文档的工具，确保构件规范的实现和质量测试。总之，传统的软件方法学从草稿自顶向下进行，对重用没有提供更多的辅助。CBSD的软件方法学要丰富得多，它是即插即用，基于体系结构，以接口为中心，将构件有机组合，它把自顶向下和自底向上方法结合起来进行开发。四、开发组织机构传统软件的开发组织一般由分析员、设计员、程序员和测试员组成。对一个小的应用系统来说，一个熟练的开发人员，可能兼顾以上多个角色。但对CBSD来说,因为构件开发与应用系统集成往往是分开进行的，因此整个开发过程由六个角色来完成，他们是:构件开发者也是构件供货商，这些大多数是中间件构件提供(续致信网上一页内容)者。应用构件集成者针对某应用领域将已有构件组合成更大的构件模块或容器，作为系统部署的基本单元。应用系统部署者将系统部署基本单元放入选定的平台环境或基本框架中，完成软件定制的要求。开发平台服务器供应商提供服务器、操作系统和数据库等基本软件。应用系统开发工具供应商提供构件公共设施服务。系统管理员配置硬件、网络和操作系统，监督和维护应用系统者。这六个角色的工作专业性很强，要兼顾成为多面手很不容易。目前已形成构件开放市场，而且还很火红。这也是当今软件人才大战所遇的一个困惑。因此，在CBSD中，如何组织好开发队伍尤为重要，必须按本企业所具备人才来组织。特别重要的是:开发初期必须选好标准框架，以及统一的开发指导方针，保证在整个开发过程中,各角色能随时互相沟通。一般来说，CBSD的人员素质决定了构件的重用率。五、构造方法传统应用软件的构造是用白盒子方法，应用系统的实现全在代码中，应用逻辑和数据粘结在一起。而CBSD的构造是用白盒子和黑盒子相结合的方法。基于构件的框架是用两个概念来支持演变：第一个概念是构件有很强的性能接口，使构件逻辑功能和构件模型的实现都隐藏起来。这样，只要接口相同，构件就可以被替换。第二个概念是隐式调用，即在基于构件的框架中，从来不直接给构件的接口分配地址，只在识别构件用户后才分配地址。因此，构件用户只要了解接口要求和为构件接口提供的引用后的返回信息(该引用可能是一个构件，也可能是一个构件代理。对构件用户来说，构件代理就是构件，不用区分)。构件接口的信息并不存入构件内，而是存入构件仓库或注册处。这样才能保证构件替换灵活，并很容易利用隐式调用去重新部署构件。由于构件的实现对用户透明，因此也使构件能适应各种不同的个性化要求。为此，构件提供自检和规范化两个机制。自检保证在不了解构件的具体实现时，就能获得构件接口信息。例如，JavaBean提供的自检机制是Reflection和BeanInfo，通过Reflection可直接获得Bean构件的全部方法，通过BeanInfo可直接获得构件的许多复杂信息。规范化允许不访问构件就可以修改它，如JavaBean提供的规范化是property sheet和customizer(定制器)。通过property sheet提供一组简单参数，修改Bean的属性。复杂的修改由用户通过定制器设置参数完成。

转载请注明：片头模版 » 软件模块结构图的改进方法(第三章结构化分析与设计方法3)