数据集成的关键因素及综合集成三维模型

综合集成的目的是协调组成智能控件化虚拟仪器系统的控件之间的合作，协调的手段可分为三个方面：控制、数据和显示，它们构成综合集成的三维模型，如图10-1所示。

（1）控制集成 这种集成方式决定控件之间的通信能力，即控件通过互操作（交换信息和服务）实现协同工作的能力。通信方式、控件粒度和过程是实施控制集成的关键因素。

（2）数据集成 这种集成方式决定控件间共享和理解数据的程度。数据模型、表示收敛、数据粒度和数据模式是数据集成的关键因素。

图10-1 综合集成的三维模型

（3）显示集成 这种集成方式要求由异质控件组成的整个虚拟仪器系统给用户以统一的外部感观。图形界面、用户界面管理和多样性显示则成为实施显示集成的关键因素。

尽管综合集成这三个方面的技术可以独立开发，但综合应用它们会产生更好的效应。下面分别描述控制集成、数据集成和显示集成的技术，然后再讨论基于知识的软件智能化技术在促进综合集成技术的开发中所起的作用。

1.控制集成

控制集成的目的在于经由消息通信机制实现智能虚拟控件的共享，并由此促进控件的复用以及任务的分布和并行处理。经由消息通信而非共享单一的数据库及其模式，使控制集成具有独特的优点：不牺牲各控件自身的独立性，甚至不需要定义用于控制协调的任何中心点。但控制集成也存在以下两个重要的问题：

（1）控件间通信 传统的软件复用技术是简单地将被复用软件的代码连接进整个开发系统，从而产生代码数量庞大的单一可执行程序。保持控件执行的独立性，并提供控件间的互操作机制，以免除庞大可执行程序的缺点，但增加了计算机的工作量和复杂性，而且还必须开发适当的功能去封装、转换和解封控件间交换的信息。

（2）接口/控件描述 每个控件必须在其对外接口中以其他控件可理解的方式定义所提供的服务和被交换信息的数据结构，这导致了互操作协议的开发。这些协议可视为某种接口/控件的描述语言，并满足独立于控件编程语言、表示能力、数据分类、一致性核对、命名和范围定义等要求。

下面从通信方式、控件粒度、过程建模和协作支持方面来系统地解决上述两个问题。

（1）通信方式 通信是控件间实现互操作的基本手段。基于消息总线的通信方式，如图10-2所示，该方式的核心思想是将寻找服务提供者的任务委托给消息服务器，服务请求者只需向消息服务器发出请求消息，不必关心由谁提供服务、服务提供者在网络上何处、如何调用等。这样，新控件只需向消息服务器注册其标识和调用方式，即可自由地插进消息总线。

图10-2 基于层次消息总线的通信方式

（2）控件粒度 控件粒度指控件所提供服务的计算量大小，其选择取决于两个相互制约的因素：通信开销和软件复用。为减少通信开销，应缩小包含于开发系统的控件数量，即增大控件粒度；而要提高控件的可复用性，则应将复杂的任务分解为子任务，再由控件承担，即减少控件粒度。

作为一种权衡，可以遵循以下原则来设立控件。

1）控件提供的计算服务能为多个其他控件所共享。

2）控件的设立可支持任务并发执行。

3）控件的设立引起通信需求（频度、通信量、信息结构的复杂度）适中。

4）控件间几乎不存在相同的代码，或即使有，也可以通过共享其他控件提供的服务来取代。

（3）过程建模 控件间的协同工作需遵从一定的过程模型。过程模型可以只是对复杂任务的执行制定一个抽象的规划，或是相当详细地说明如何控制工作流程，比如，图10-3所示为过程建模频谱。前者面向由人参与的管理任务，控件的启动由人根据其承担的任务来决定，过程模型仅用于监控和指导人完成任务。后者面向管理任务的全自动化，控件在过程模型的直接监控下协同工作，自动完成任务。当然，大多数过程模型处于两者之间，并有从偏向抽象规划的低级自动化朝着详细说明的全自动化方向发展的趋势。

图10-3 过程建模频谱

过程模型的结构如图10-4所示。过程模型分为两级：系统和子系统。前者作为过程监控机监控和协调子系统间协作关系的依据，后者则成为子系统监控和指导控件间协作关系的依据。在过程模型仅提供抽象规划的情况下，由用户手工决定控件的调用，子系统提供决策支持信息和综合解答，并接受过程监控机的调控。在全自动情况下，子系统依据过程模型所作的详细说明自动决定控件的调用，仅在必要时反馈关键信息给用户。用户除了在子系统启动时和发现重大异常时，给予原则性指令外，不干预过程的执行。

图10-4 过程模型的结构

2.数据集成

数据集成的理想方式是所有控件共享统一的环境数据，所有相关的信息均存放在其中，任意一个控件均可从其获取所需的信息以推进工作。然而，建立和维护这样的数据库并不容易。首先，必须给存储于数据库的信息定义成适合于作原子处理的存取方式和能为所有相关控件理解的存储格式，这些定义构成了所谓的数据模型。另外，环境数据库的内容是不断变化的，尤其是各控件数据库的观察点不同，使数据库的一致性维护十分复杂。下面从数据模型、表示收敛、数据粒度和数据模式四个方面，来介绍数据集成涉及的关键因素。

（1）数据模型 建立公用数据模型是控件通过数据集成达到的相互理解的基础。公用模型可以视为各控件所需数据模型的交集，其在概念级和执行级提供了关于数据处理的公共假设。数据模型的定义包括三个部分：

1）对象类型集：构成表示数据时可用的基本控件块。

2）操作集：用于组合对象的操作集。

3）构造规则集：用于约束对象组合的方式。

数据模型不仅从概念上定义了控件的数据集成，而且要求把对象操作部分分离出来作为独立的控件，不必重复设置于各控件中。换而言之，数据模型不仅定义标准化概念，也定义标准化执行。

（2）表示收敛 为实现数据集成，每个控件至少有部分数据遵从公用数据模型。正是由于共享该模型，才使控件更易于集成和协调关系。为此，每个控件应提供内部数据对象类型到公用数据模型的映射，如图10-5所示。

图10-5 内部数据对象类型到公用数据模型的映射(www.xing528.com)

通常，控件只有部分数据类型映射到公用数据模型，而不是全部。公用数据模型的规模可视为控件间数据表示收敛的程度。模型越小，收敛性越好，因为只有较少的数据对象类型需要共同的理解。然而，正因为公用的数据模型小，才易于发生控件数据对象类型映射到公用模型时的语义失配问题。一般来讲，大的公用模型能较好地满足映射的语义配合需求。

为实现好的数据集成性能，应综合考虑表示收敛和语义配合问题。基本原则就是：在建立尽可能小的公用数据模型的同时，不失掉太多的语义配合能力。图10-6描述了这种综合考虑和数据集成的最佳点。

图10-6 表示收敛和语义配合的综合考虑

（C—收敛 M—语义配合 C+M—两者综合）

（3）数据粒度 数据粒度指数据对象类型定义的细化程度。粗粒度的对象只有简单定义，如关系数据模型中的关系表；而细粒度的对象可以有十分复杂的定义，如面向对象的数据模型中的对象类。

数据粒度的概念与表示收敛紧密相关。通常，粗粒度的数据对象更支持表示收敛，而细粒度的数据对象更支持语义配合。换言之，小的简单的公用数据模型应采用粗粒度定义方式，以促进表示收敛；而大的复杂模型宜采用细粒度定义方式，以促进语义配合。

为了综合粗、细粒度数据定义的优势，需建立包含关系数据模型的面向对象的数据模型，如图10-7所示。图中以VC++语言定义的类Dat具有关系数据模型的所有操作功能，如增加、删除、更新、联合、相交等，从而使用数据模型具有粗粒度、表示收敛的优点。而类Dat的多种演化（演化为X-Dat、Y-Dat、Z-Dat）则可在继承所有关系操作的同时，详细定义任意的附加数据结构和特别操作。

图10-7 包含关系数据模型的面向对象数据模型

（4）数据模式 数据模式是在遵从数据模型使用的语法规则（定义数据对象类型的规则）条件下对于数据库内容的语义定义。实际上数据模式就是被定义的面向测试分析仪器领域的具体数据对象类型集合，它清晰地说明了数据库内容的组成，以便于作存取操作和语义检查。每种数据模型都提供数据描述语言来表示数据模式。

数据模式会随系统的进化而改变。为促进系统进化的开放性，应确保数据模式发生较小变化时只要求程序作较小修改。换言之，只要数据模式渐增性地改变，系统就可平稳地进化。

数据模型的不同对数据模式的定义具有较大影响，主要体现在数据对象分类定义的强弱。弱分类定义通常与小而简单的数据模型（如关系模型）相关联，它迫使数据模式的设计者将不同的控件对象表示为同类数据对象。作为对照，强分类定义通常与大而复杂的数据模型相关联，这使得不同的控件实体易于表示为不同类型的数据对象。面向对象的数据模型提供了强分类手段，但也带来了缺点——同一实体可映射到多个不同的数据类型。

与数据模式应用紧密相关的另一个问题是数据对象类型的核对。核对具有动态、静态之分。静态核对指系统程序设计时的类型核对能力，通常由编译器执行，主要优点是能在程序设计时一次性完成核对工作，程序执行时不必再核对；缺点则在于当数据模式修改频繁时，需多次重编译。动态核对将类型核对推迟到程序执行时，可由程序的解释器完成。鉴于每次用到某数据对象时都需作类型核对，其降低运行性能的缺点是显然的；优点则在于适合于数据模式频繁改变的场合。

数据模式的数据对象类型定义、变化的渐增性和类型核对的动态性构成一个三维刻画，如图10-8所示。自然地，弱分类的数据模式适合于类型的动态核对，而强分类模式则适合于静态核对，因为弱分类所需核对工作量较强分类小得多。为获取高性能，数据模式应向着强分类、静态核对和渐增性变化方向发展，目的在于降低因数据模式的改变而修改应用系统的代价。

图10-8 数据模式的三维刻画

3.显示集成

显示集成的目的是使用户和仪器信息的显示有一个统一的感观，这种需求促进了仪器显示器与功能程序分离的研究。开发独立显示器的动机如下：

1）关注分离：使显示器的开发独立于功能程序开发。

2）模块独立性：显示界面改变时不影响系统程序的执行，从而能方便地按用户的喜好设计显示界面。

3）投资共享和标准化：显示器可以公用和复用，用户使用非常方便。

随着多媒体显示处理、计算机视觉等技术的发展，显示界面的设计相对来说容易了许多，但如何将独立的界面显示技术与仪器系统的输入输出需求无缝连接，仍存在着许多需精化的问题。其中最突出的就是这种连接必须由系统程序设计人员来实现。然而，依靠程序设计人员来设计面向各种仪器需求的显示界面，很不方便，也不能适应用户对于瞬息万变的仪器信息的需求。为解决这个问题，需要在显示界面和系统程序间建立一种语义接口。语义接口提供了抽象说明，使最终用户能透明地了解系统程序可提供的服务以及方式，而不必知道程序现实和数据库的细节，进而用户只需遵循抽象的说明提出服务要求，就能在熟悉的界面显示形式下得到所需的结果。

此外，显示集成技术的成功应用还与控制集成和数据集成紧密相关。显示界面只是仪器系统的窗口，界面再好，但仪器系统不提供优良服务也是枉然。所以，要协调好三者间的关系。

4.基于知识的软件智能化技术对综合集成的促进作用

如前所述，综合集成的目的在于：促进虚拟仪器开发系统在其内外环境中实现信息集成、功能集成和过程集成，以快速和高效地响应环境的变化和需求。面向控制、数据和显示的三维综合集成，则为智能控件化虚拟仪器零编程开发系统提供健全的方法论。从以上可以看出，在相互理解的基础上协调控件间行为的配合是综合集成技术成功应用的关键。

显然，理解和协调本身是知识密集型任务，应用基于知识的软件智能化技术可大幅度提高综合集成的性能和效用。下面就从控制集成、数据集成和显示集成三个方面讨论智能化技术的作用。

（1）对控制集成的作用 基于知识的软件智能化技术从理解、协调和配合三个层次提高控制集成的性能和效果。

1）理解。这是独立运行的控件协同工作的基础，经由消息传递进行通信是控件相互理解的手段。理解的关键在于制定控件共享的关于消息内容的本体，并以公用通信语言来定义共享本体和消息表示。公用通信语言和共享本体屏蔽了异质控件间通信时易产生的表示和语义失配问题，从而可确保控件理解相互交换的信息和知识。基于知识通信不仅能较好地支持控件间的通信理解，也提供了必要的翻译机制，使各控件动作时仍能应用其内部的信息和知识的表示方式。

2）协调。理解仅为协调建立了基础，尚需通过制定多种协议来协调控件协同工作时的操作行为。协议又可分为三个层次：消息处理、消息转发和协作商议。消息处理协议规定了消息接收方应如何处理接收到的消息，并通过消息分类来区分消息处理的语义。消息转发由消息路由和消息匹配等通信促进器来实现，从而使得信息和知识的消费者和生产者在不必确切了解对方的情况下协同工作。协作商议是高层协议，主要服务于紧耦合的协作任务。

3）配合。由于易于发生控件调用时的表示和语义失配问题，如输入参数和输出结果的表示和语义失配、控件调用的必要和充分条件的失配、控件调用的后果失配（产生非期望结果和副作用）等。为解决失配问题，必须清晰地定义控件的应用约束，并清晰地描述由控件合成的开发系统体系结构，包括任务归约、控件所起的作用、控件调用的选择和组合，以及表示和语义失配问题的解决。下一节介绍的基于知识的柔性集成系统就提供了有效的途径：清晰地描述控件合成和控件应用约束，以确保控件间的配合。

（2）对数据集成的作用 数据集成的关键在于建立控件公用的数据模型。传统的做法是基于该数据模型建立共享数据库（可以是集中型或分布型数据库），以便各控件经由其共享和交换信息。这种方式的主要缺点是导致公用数据模型的进化和共享数据库的一致性维护十分困难。不建立共享数据库，而是由各控件自行维护本地数据库，其他控件只能经由本地控件间接操作数据库，可以免除这些困难。

以共享本体去定义控件之间交换的信息和知识，等价于建立公用的数据模型，将控件联合起来形成统一的虚拟知识库。在这样的知识库中，取用非本地存入的信息和知识可通过其他控件提供的信息和知识服务来实现，因此可免除多控件直接操作共享数据可能引起的不一致性。此外，由于外部控件不直接操作本地数据库，数据模型的进化对外部控件的影响可以最小化。

（3）对显示集成的作用 基于知识的软件智能化技术从智能助理和语义接口两个层次提高显示集成的性能和效用。

1）智能助理。智能助理具有应用和组合多种显示技术的知识、用户喜好的显示方式的知识，并能通过自适应学习，学会以用户满意的方式智能地提供信息显示服务。用户只需以接近于自然的方式向智能助理发出抽象的往往隐含了某些语义的指令。由此，显示集成不仅给用户统一的信息显示模式，更可使这种统一的模式合理地剪裁到符合用户的兴趣和爱好。

2）语义接口。语义接口使最终用户能透明地了解系统程序可提供的服务和方式，而不必知道程序设计和数据库的细节。