用于配置由多个组元组成的组件的虚拟表示的方法、计算机系统和计算机程序产品

摘要

本发明提供了一种用于配置由多个组元组成的组件的虚拟表示的方法，包括以下步骤：I)存储表示组元的多个类别的第一组数据，并且存储对于每一个类别表示定义了对每个组元的配置的限制的约束和参数，II)产生和存储表示多个组元组成的组件的第二组数据，同时遵守与每个组元相关的约束以及对组件的约束，产生表示当前配置的第三组数据，III)通过以下的方法重复步骤II)：a)将表示一个组元的数据以及来自第一组数据的数据加入到第二组和第三组数据中，或者b)删除表示第二组和第三组数据的组元的数据，或者c)修改表示第二组和第三组数据的先前加入的组元的数据，同时遵守与每个组元相关的约束以及对组件的约束，以得到第二组和第三组数据的更新版本。

说明书

技术领域

本发明涉及对系统的配置，其目的是支持复杂产品的配置问题的实时可视化。本发明提出了一种通过使用抽象的组元(component)来表述一个产品模型的通用方法。本发明在实时运行环境中是有用的，例如电子销售，用于以实时可视反馈的形式来完成产品的可视化配置。

背景技术

产品的配置可以看作是对参数空间进行导航(navigating)以得到(产品的)一个配置的过程，通常称之为产品的变体或者定制产品。

在本文中，参数应该理解为一个或多个属性，通常被保存在计算机程序中的组元的变量中。例如，一个组元可以具有被赋予不同值的材料参数，例如橡木、山毛榉树、桃花心木、柚木等，一种颜色参数，例如绿色、蓝色、黄色等，一种尺寸参数：小尺寸、中等尺寸或大尺寸，一种光反射参数，例如明亮的或者无光泽的等。

例如一个小轿车有有限个状态空间。它的合法解系可以被有限个参数限定，配置该轿车的过程等同于通过选择有限个参数中的每个参数的值，在有限的状态空间中导航的过程。反之，建造一个厨房间需要选择数目不同的橱柜和一些附件，因此根据橱柜的数量具有不同的、可能是无限的参数空间，厨房中每增加一个新的橱柜，厨房的参数空间将发生改变。

一个更普通的例子是可建造的产品。一个可建造的产品是由许多子产品组成的，可以将它们装配在一起(在某种意义上)而形成一个整体。在某种意义上来说绝大多数的产品可以被看成是可以建造的。但是，如果产品不严格局限于特定数目的组成项，则这个产品通常被称为可以被建造的。这可能被视为不同产品，其具有组装在一起的不同数量的子产品和/或不同数量的子产品组合。例如，一辆轿车通常会有相同数量的类似的主要部件，如四个车轮和一个引擎，然而，一个厨房的主要部分包括不同数量的橱柜。这些组成模块可能本身有很好的可配置性或可建造性。

通常，对大部分可以建造的产品中而言，很难建立一个满意的产品模型。一个问题在于获得变量的数目，因为每一个形成模块是可以配置的，但是它们的配置依赖于其他部件。解决此问题的一种方法是固定子产品的数量和组合，然后描述所有的相互关系。

此外，对于许多可以建造的产品，子产品间的连接通常可以作为一个很基本的物理属性，这种属性很难甚至不可能用产品模型的逻辑项来描述。例如在一个厨房中，柜子上的抽屉和它所在的柜子有很明显的逻辑(或者结构)关系；例如根据柜子的大小可能有3、5或7个抽屉。但是，没有必要知道在两个不同连接组中的两个柜子之间的关系。

因此存在许多问题。第一，一个可以建造的产品的组合的整体逻辑规则不能很好地描述典型的产品。第二，用逻辑约束的项不容易描述可建造的产品中的相互关系。

已知有两类基于规则的配置器(configurator)；搜索算法(例如使用树状结构)或者基于逻辑关系将所有的有效组合都存储在一个数据库中。这些技术均没有解决以上提到的问题。而且，许多明显、简单的规则是几何属性，或者涉及到了产品的几何属性。它们很难用逻辑语言来表达。因此，本发明的一个目标是基于组元原理，便于产品的构建，并能够生成一个产品模型。

发明内容

第一方面，本发明提供了一种用于在计算机系统的存储器中配置由多个组元组成的组件的虚拟表示的方法，该方法包括以下步骤：

-将表示组元的多个类别的第一组数据存储在计算机系统的一个数据库中，并且对于每个类别，存储定义了对于每个类别中的每个组元的配置的限制的参数和约束，由此在一个类别中的所有组元具有共同的参数和约束；

-产生或者定义表示由多个组元组成的组件以及表示所述多个组元的配置空间的第二组数据，将所述第二组数据储存在计算机系统的存储器中，执行产生第二组数据的步骤，同时遵守与每个组元相关的约束以及组件的约束，并且生成表示在配置空间中的当前配置的第三组数据，

-通过如下方式重复执行产生或者定义步骤：

-将表示所提供的组元之一、并且由第一组数据导出的数据加入到第二和第三组数据中，或者

-删除表示第二组和第三组数据的组元的数据，或者

-修改表示第二组和第三组数据的先前加入的组元的数据，

同时遵守与每一个组元相关的约束以及组件的约束，以得到第二组数据的更新版本并得到第三组数据的更新版本。

第二组和第三组数据的重复产生可以实现不被有限数量个组元或有边界的空间所限定的产品模型。此外，通过定义了对于存储在数据库中的每个元件的配置的限制的约束，并通过在产生第二组数据时遵守这些约束，就不需要存储所有可能的组元组合。类似地，通过自动产生和优选存储表示组件的约束的数据，可以灵活的、对于存储器和数据处理有效的方式建立产品模型。

可以理解，所述第二组数据的更新版本可以作为第三组数据的改变的结果而获得，这样，当产生的步骤被重复执行时，第三组数据被更新，例如响应用户输入，第二组数据可以自动地更新。

在产生第三组数据的步骤中，该方法还包括提供多个组元或者组元类别，以及重复提供的步骤，这样，当重复提供的步骤的时候，只提供选定的组元或者组元类别。因此，计算机系统的用户在配置产品的时候可以节省时间，同时防止产生非法的或者不允许的组元的组合。

表示组元的数据可以包括表示组元参数的数据，在这种情况下，该方法还包括在产生第三组数据的步骤中提供组元的多个参数，由此只提供被选定的参数，根据组元的约束这样来选择被选定的参数，使得可以仅获得有可能的和/或合法的组元和参数的组合。

此外，在提供组元和/或参数值的步骤中，可以只提供那些遵守与每个组元相关的约束以及遵守组件的约束的组元和/或参数值。

在本发明中，组元不但可以解释为一个物理组元，并且或者可选地，也可以解释为在计算机系统的存储器中的其数据的表示，可能包括组元的参数和/或特性。

该方法还可以包括在与计算机系统相关的显示装置或打印机上可视化显示由第二组数据所表示的配置空间的至少一部分和/或由第三组数据所表示的配置的至少一部分的图像或者物理表示。计算机系统可以被连接到通信网络，这时该方法还包括：

-将第二组和/或第三组数据通过通信网络发送到另一个计算机系统，以及

-在所述另一个计算机系统或者其他装置的显示器上进行可视化显示，以显示用于显示由第二组数据所表示的配置空间的一个图形图像和/或由第三组数据所表示的配置的图形图像。

因此，通过通信网络，例如因特网或者局部网(LAN)可以传输数据，使得产品，例如厨房，的用户或者潜在的购买者，可以从远离计算机系统的位置配置产品。

第二组数据还可以包括表示相关组元之间的关系以及组元之间关系类型的数据，这样第二组数据也可以表示组元之间的连接。

在产生的步骤中，加入步骤可以包括连接组件中的组元和/或将组元加入组件中。同样，删除步骤可以包括将组件中的两个组元的连接断开和/或将组元从组件中去除。最后，修改的步骤可以包括以下步骤中的至少一项：

-修改表示组件中的至少一个组元的数据；

-将组件中的两个组元相连接，以及

-使组件中的两个组元断开连接。

在本发明的一个实施例中，产生步骤包括生成一组群集(cluster)，每一个群集包括表示单个组元以及可选性地与所述单个组元相关联的至少一个另外的组元的数据，这样，这组群集包括了表示包含在虚拟表示中的所有组元的数据。组元之间的关系可以是物理的或者逻辑的关系，物理关系例如可以包括两个组元之间的物理连接，而逻辑关系例如限制了可赋给组元的可能的参数或者参数值，例如，用于制造厨房门的木材限于橡树或者山毛榉树，而其他厨房组成部分也可以由柚木或者桃花心木制造。第二组数据可以包括表示相关组元之间的关系类型的数据。

第二组数据还可以包括独立的数据结构或者一组独立的数据结构，其定义了组元和/或参数值的可能的或允许的组合，独立的数据结构或者一组独立的数据结构以这样的方式包括在第二组数据中，使得每一个独立的数据结构与一个特定的组元相关联，该特定组元中的至少一个约束可以反映所述组元和/参数值的可能的或者允许的组合。

因此，与单个组元相关联的独立的数据结构可以限定对应于单个组元的群集中的组元的、和/或对应于单个组元的群集中的组元的参数值的可能的或者允许的组合。

独立的组元结构可以优选地构成一个配置数据库，在该数据库中存储了表示可能的或者允许的组元和/或参数值的组合的数据。

产生第二组数据的步骤还可以包括：

-对于每个群集执行一个检查，检查是否表示该群集的组元的数据与在该群集中相互连接的组元所定义的约束是兼容的，并且，如果检查结果表现为不兼容：

-则修改第二组数据和/或表示发现问题的那个组元的数据，同时遵守所有相互连接的组元所商定的约束。

第二组数据还可以包括表示组件的至少一部分的几何形状的数据，这样，在组件的这个部分中的组元的约束将对于几何特性的约束限定到组元的参数上。

此外，第三组数据可以表示当前配置的状态，该方法还包括，在重复的步骤中，响应第三组数据的变化，自动更新第二组数据。第三组的这种变化例如可以是改变一个或者多个参数的值。如果一个参数表示一个组元，这种参数的改变可以使该组元被插入到该组件中/从该组件中去除，和/或插入/去除与该组元相关的连接。因此，当前的配置可以从第一组数据和第三组数据中重现。

在第二个方面，本发明涉及一种用于在计算机系统的存储器中配置由多个组元组成的组件的虚拟表示的计算机系统，所述计算机系统包括：

-存储表示组元的多个类别的第一组数据的数据库，并且对于每个类别，存储定义了对于每个类别中的每个组元的配置的限制的约束和参数，由此在一个类别中的所有的组元具有共同的参数和约束，

-处理器，被编程为产生表示由多个组元组成的组件以及表示所述多个组元的配置空间的第二组数据，并且将所述第二组数据存储在计算机系统的存储器中，所述处理器被编程为产生所述第二组数据，同时遵守与每一个组元相关联的约束以及组件的约束；所述处理器还被编程为产生表示在配置空间中的当前设置的第三组数据；

-所述处理器还被编程为通过以下方式重复产生所述第二组数据的步骤：

-将表示所提供的组元之一、并从第一组数据导出的数据加入到第二和第三组数据中，或者

-删除表示第二组和第三组数据的组元的数据，或者

-修改表示第二组和第三组数据的先前加入的组元的数据；

同时遵守与每个组元相关的约束以及组件的约束，以得到第二组数据的更新版本并得到第三组数据的更新版本。

所述计算机系统可以被编程以执行上面所描述的与本发明的第一个方面相关的方法的步骤。

本发明的第三个方面涉及一种用于在计算机系统的存储器中配置由多个组元组成的组件的虚拟表示的计算机程序产品，所述计算机程序产品包括用于执行以下步骤的装置：

-将表示组元的多个类别的第一组数据存储在计算机系统的一个数据库中，并且对于每个类别，存储定义了对于每个类别中的每个元件的配置的限制的参数和约束，由此在一个类别中的所有组元具有共同的参数和约束；

-产生表示由多个组元组成的组件以及表示所述多个组元的配置空间的第二组数据，将所述第二组数据储存在计算机系统的存储器中，执行产生第二组数据的步骤，同时遵守与每个组元相关的约束以及组件的约束，并且生成表示在配置空间中的当前配置的第三组数据，

-通过如下方式重复执行产生步骤：

-将表示所提供的组元之一、并且由第一组数据导出的数据加入到第二和第三组数据中，或者

-删除表示第二组和第三组数据的组元的数据，或者

-修改表示第二组和第三组数据的先前加入的组元的数据，

同时遵守与每一个组元相关的约束以及组件的约束，以得到第二组数据的更新版本并得到第三组数据的更新版本。

本发明还涉及装载有所述计算机程序产品的计算机可读数据载体，包含由所述计算机程序产品所产生的数据的计算机可读数据信号，还涉及包括装载有所述计算机程序产品的存储器或者存储装置的计算机系统。所述计算机程序产品可以包括用于执行上述及后面将描述的与本发明的方法相关的步骤中的全部或者一些步骤的装置。

发明的具体说明

在配置技术中所要解决的科学问题是构建并在给定系统的合法解的动态状态空间中导航。抽象而言，配置(产品)是在参数空间中导航以获得(产品的)配置的过程。

产品是某个系统、物理对象或者对象组，它们共同形成了某种整体。可建造的产品是这样的产品，其由多个子产品构成，这些子产品可以(以某种方式)组装在一起以得到一个整体。

在配置的术语中，产品模型(PM)描述了一个完整系统中的所有参数，并且描述了哪些参数值组合是合法的，这些表示了在配置器中的合法的(或者有效的)产品。在这个术语中，配置过程包括在由参数所限定的参数空间中的导航，同时遵守产生了产品的合法配置的产品模型的规则。

从数学上讲，产品模型描述了具有M^N*P个值的参数空间，每个值对应于产品的一种可能的配置。这里，假设系统包括P个子系统，每一个子系统具有N个参数，这N个参数中的每一个又具有M个可能的值。如果P个子系统是非连接的，那么参数空间只有(M^N)*P个值。但是，子系统具有一些子空间，在这些子空间中它们是相连接的。因此，参数空间具有(M^(N+O))*P个值，它并不是很复杂，因为对于很小的数目O有系统M^N*P，即子系统有很小的重合。换句话说，通过将描述连接的一些额外的参数加入到每个子产品中，确定了一个不是很复杂的系统，这一点当起初不知道子系统的数目P时有很大的优点。

本发明中，发明了组元化的产品模型以用于描述原则上为无限的(或者不受限制的)参数空间(即参数的数量)，其中每一个组元(上述的P)具有有限数量的参数(上述的N)，每一个参数具有一个域值(上述的M)，而完整的系统可以包括一个起初不知道的不受限制的单元，它可以由任意数量的组元组成。这些组元是数据结构的一部分，每一个组元与多个状态变量相关。

在特殊的情况下，组元直接与一个具有几何表示的对象相关。该对象通常是产品的一个物理对象，它的几何形状可以在任何设备上的相关可视化系统中进行可视显示，作为PM变化的结果。任何可以显示几何形状的电子设备都可以用于进行可视化显示。

典型的假设，即所有的参数都是所有组元的所有参数的总和，是难以通过定义来描述的，这是因为使用的产品模型通过形成新的组元(模型合并)扩展到已经存在的组元化产品模型中，以得到产品的新的配置。

本发明的重要一个概念是基于状态的配置，其包括表示参数空间的一个特定的数据结构，以及在参数空间(也称为状态空间)中进行导航的相关方法。

在该方法中，所有的参数通过状态变量来表示，所有状态变量在任何时刻均恰好具有一个值。所有状态变量的值的集合被称为“状态”，并恰好表示产品的一个配置。同样重要的是，通过每次改变一个(或多个)变量可以在参数空间中进行导航，直到达到一个满意的配置。在某种意义上，这类配置器可以使用户在参数空间中随处移动。可选的是，可以缩小参数空间的一些可接受的子集，并只有在最后获得产品的特定配置。

考虑一下在某种意义上是有形的产品，例如脚手架(scaffold)。状态表示的一个好处在于它可以在配置过程中将配置以可视化的方式呈现给用户。通过将产品的虚拟表示进行可视化，意味着产品的可视化，而不是参数空间的抽象显示。配置产品并同时显示结果的问题是在配置技术领域中已知的问题。请注意，基于状态的配置是这种类型的配置如何工作的核心，并且其含义和好处并不完全局限于可视化。

本方面的核心部分是具有组元化的产品模型(组元化的PM)的概念，组元化的PM包括两个PM相关的部分。一部分是PM的静态描述，另一部分是动态的。这对于从PM中的各个组元形成产品的应用是必需的，并且整个产品动态地变化，因此模型的描述(必须是静态的)必须从模型自动分离。

静态的描述被称为片断化的产品模型，它由有限数量的PM片断组成，PM片断是PM的构成模块。每个PM片断包含一组产品参数。

PM片断是关于PM的构成模块，而组元是关于产品的构成模块。但是，PM片断经常直接与组元或者组元组相关联。

动态的描述称为瞬时产品模型，它包括一组组合起来的PM片断。换句话说，瞬时PM是彼此唯一组合的PM片断总和。注意，瞬时PM通常包括同一类别的许多PM片断，其中同一类别的PM片断定义为具有相同参数组的PM片断，但是其中参数也可以具有不同的值。

总之，组元化的PM由片断化的PM和瞬时PM组成，如图1所示。

在利用组元化的PM的运行环境中，第一个例子是PM片断，它使瞬时PM初始化。然后，组元化的PM的改变通过瞬时PM的模型改变来完成，每一个改变通常产生瞬时PM和/或其PM片断的新的结构。

能够实现这些的整个基础依赖于局部组合，该种组合产生了所谓的PM群集，其中所有的PM片断都置于这个范围中。这意味着特定组元的影响，或者确切的说是它的状态，仅仅是局部的。至少只有局部的直接影响，这是因为它自己的群集(范围)的变化可以通过群集的重叠传播到其他的群集。

本发明还涉及配置复杂的系统，该系统可以由多个系统组元(简称为组元)组成。为了区别，整个系统被称为“场景(scene)”。

配置基于状态的系统意味着改变状态，同时遵守产品模型的规则。配置器中的(系统的)产品模型包括对所有可用参数的描述，以及它们必须遵守的规则。在数学上，它包括一个参数空间，该参数空间是各个域的所有相关参数的笛卡尔乘积(Cartesian product)以及一组规则，主要描述了被称为合法参数空间的参数空间的子集。

关于配置器，参数空间中的每个点被称为所要考虑的系统的配置，如果这个点在有效的子集中，则这个配置就是合法的(或者有效的)。配置(系统)包括产生表示一个(或者也可能是多个)配置。注意，配置(参数空间中的点)恰好包括每个参数的一个值。

获得配置的基于状态的过程的含义是，配置过程通过一次改变一个或者多个表示各参数的状态变量，基本上由从一种配置(称为状态)到另一种配置的导航来组成，这些参数始终位于合法的子集中。

在整个系统的给定状态中，在合法参数空间和参数域之间的交集被称为参数的合法值。这些值会被分配给一个变量，而不会引起与另外一个变量的冲突，即破坏一个规则。

基本上，本方法中涉及到三种独立的数据结构。

第一组数据：一种片断化产品模型，它是一组组元类别(模型片断)的定义，每一个均包括定义了该组元类别的参数数量和参数分类以及定义了这种组元的行为的数据。

第二组数据：一种瞬时的产品模型，它是当前组件系统的产品模型，包括该场景中组元的所有参数的表示以及当前合法的参数空间的子集。

第三组数据：一种状态，其指出了参数空间当前的点(表示当前的配置)。

附图说明

图1示出了组元化产品模型的概念图，

图2示出了设置值的过程中的步骤总示意图，

图3示出了设置值的过程中的值的传递步骤，

图4示出了设置值的过程中的处理值步骤，

图5示出了通过独立的数据结构的组元之间的约束，

图6示出了设置值的过程中的检查值步骤，

图7示出了在设置值的过程中被分为不同状态的基于状态的方法，

图8示出了组元与其具有状态变量的状态向量，

图9示出了包括C2和C4的C3的群集，

图10示出了一组重叠的群集，其中群集C1只包括两个组元，

图11示出了具有子组元的更为复杂的群集的示例，

图12示出了添加延伸到参数空间中的组元(组元5)，

图13示出了将组元加入到瞬时产品模型的过程，

图14示出了连接组元的过程，

图15示出了由于在两个组元之间的连接引起的模块链，

图16示出了基于组元的可视配制器的体系结构，

图17示出了管理器、世界(world)、组元等的数据结构图，

图18示出了组元1的逻辑群集，

图19示出了在配置脚手架系统时的可视化步骤，

图20示出了包括一些相关变量的平台4的群集，

图21示出了在配置步骤10之后出现的组件图(或者组元层次)，

图22示出了配置后的脚手架系统的参数空间。

具体实施方式

状态变量恰好表示PM中的一个参数，它是来自PM的数据和规则直接与配置过程相关的点。

状态变量与一个域相关联，该域表示了所有对于该参数可用的值。将该域以外的任何值赋给一个变量是毫无意义的。

在某个给定的时刻，该域内的值的子集，也可能是该域内的所有值，都被认为是合法的，而其他都是非法的。与静态的域不同，这可以动态地变化。需要注意的是，哪些在给定时刻为合法的值反映了PM对于当前状态的反应，也就是说，如果给定了整个系统的状态，哪些值可以赋给这个变量，而不会使整个系统进入非法状态。因此，它间接地反映了一个变量与其他变量的交互作用。

正如所述那样，一个状态值在任意时刻恰好具有一个值，使用赋予了该值的变量。这个值是该域中许多值中的一个，只有设置值的过程可以改变它。图2示出了设置值的过程当中每个步骤的示意图。如果设置值的过程导致了非法状态，该过程就被认为发生了冲突，如图3中传递值步骤所示。根据系统的明确的设置，这个问题可以采用不同的方法来解决。一个例子是利用相关变量简单的返回(rollback)，另一个例子是将整个状态认为是瞬态的，开发出非常先进的瞬态解决机制，以识别出哪些其他的变量值应当调整到合法的状态。

状态变量可以被赋予许多约束，这些约束可以动态地限制域内的哪些值是非法的。换句话说，这些约束控制了哪些值是合法的。此外，状态变量可以被赋予多种结果(consequence)或者影响(effect)，如图4所示，其在处理值过程期间的设置值过程中被触发。

确定了参数空间的合法部分的规则是通过将约束赋给每一个状态变量而进行建模的。一个约束可以看成与独立的数据结构或者甚至是外部数据结构的链接，在这个链接中当前系统的一些特殊方面的信息被收集并进行处理，如图5所示。每一个约束就是这个信息的特定解释，这些信息与特定的状态参数相关。例如，具有表示对象的系统的纯几何信息的数据结构，允许使用表示系统的几何属性的约束。另一个例子是在独立的外部结构中进行一些计算，相应地会通过状态变量影响到参数空间。独立的数据结构的第三个例子是一个数据库，具有变量的给定(局部)系统的所有合法的组合，即系统的逻辑配置器。

这里重要的一点是约束只赋给一个状态变量，然后它间接地链接到它的数据结构，但是数据结构可以并且常常具有链接到它的多个状态变量。状态变量之间是这样相互作用的：并非直接地，而是通过它们各自对于这样的数据结构的变化的反应来相互作用。

除了约束状态变量的合法值之外，所有的约束对它的数据结构具有结果或者影响，这意味着，当一个状态的变量被设置为与一个约束相关时，数据结构会发生变化。这就是将结果或者影响赋给状态变量的机制。

实际应用中，如果可以检查一个值的合法性，而不需要考虑其结果，约束是可以模拟的，这通常是特殊应用的执行性能的问题，因此并不是真正与抽象的过程相关。值得指出的是它对于方法的实际应用具有非常重要的意义。参见图6所示的检查值的步骤的流程图。

因此，如果一个约束是不可模拟的，那么在触发某些效果之前，它是不能被检查的。如果在这种情况下发现某个值是非法的，这个状态值就发生了冲突，并执行返回机制。最普通的返回机制是返回到设置程序；但是，在特定的情形下这并非始终是可能的和/或所期望的；另外一个返回的机制是利用影响的加权方案(scheme)，其中根据该方案中的加重的不同，影响(effect)具有不同的优先级。

在设置值的过程中，基于状态的方法被划分为不同的状态，如图7中所示。

当这样的数据结构被改变之后，其他与该数据结构相关的变量可以使它们的状态发生改变，因此应当特别注意。这也可以通过约束来进行处理。因此，通过改变相应的数据结构，约束可以被改变，并且该约束能够表明这些变化的状态变量。对于这些变化的反应可以是不同类型，但是仍然存在一些值得注意的基础。在第一个例子中，它使当前的合法值进行了更新，但是，它也可以实际上使对该变量的值进行设置。

设置单独的变量可以通过约束一影响的关系，引起其他变量的设置，反过来也可以引起其他变量的设置，因此使结果传递。这个过程就叫做影响级联(或者级联)，注意这并不限于一个PM片断中，它可以传递到整个瞬时PM中，尽管实际中很少发生，这是因为它会非常聪明地加入传播中断(命令)控制这个过程。

组元是数据结构(PM片断)的一部分，每一个组元与状态向量相关联，该状态向量包括每一个组元参数的一个状态变量，如图8所示。对于组元的影响通过这些状态变量来控制。例如，如果一个特定的状态变量设置在一个组元上，那么就会有一个可视效果。

回忆一下，一个组元代表一个产品形成模块，一个完整的(完整或部分的)产品是由多个这样的模块组成，而这些模块是由许多组元来表示的。产品可以通过成对地连接子产品来组成。采用可形成的产品概念，组元可以成对地连接，产生一个称之为组元层次(或者组件)的数据结构，这在数学上称之为组元表(component graph)。

每一个组元可以具有与其他组元的多个(动态变化的)连接(或者结构连接)。连接可以是自反的(reflexive)，因此这些连接是双向的，换句话说，如果一个组元与另外一个组元相连，那么另外一个也与第一个组元相连。如前所述，组元的PM的一部分是组元与其他组元的关系，这可能会影响特定的组元，通常可以通过一个特定的状态变量来对其进行建模(modeling)，该状态变量具有的值与另外一个组元一样。这个特定状态变量称之为组元变量。实际的值是对应PM片断的组元类别，同时它仍然是组元类别的特定例子，它是组元。需要说明的是，如果组元(C2)是另外一个组元(C1)中的组元变量的值(称为Neighbor1)，那么C2起到Neighbor1在C1的PM中的作用。

在组元的PM中，组元变量就是状态变量。但是，(部分)组元变量的影响(设置)是建立其组元和值组元之间的连接，需要注意的是，这可能包括在具有该组元变量的其他组元中设置一个变量。

PM片断是系统的所有PM形成模块。每一个PM片断包括系统的一组参数，PM片段是PM概念下的形成模块，在许多情况下PM片断等同于组元或组元组。

模型链(model chaining)是将许多PM片断合并为瞬时PM片断的抽象过程，实际上，模型链可以形成在结构连接(组元之间)上，并且是使两个PM片断相互通信的方法。它同时也是一种使片断形成为完全瞬时PM的一部分的方法(如图1和图15所示)。

在组元的水平上，组元层次中的组元之间可以通过使用链产生所有的相互作用，链通常在群集中发生。这基本上就是群集的定义。

如果将两个组元连接，就可以在两个状态变量间形成链，这样的链形成了一个状态变量值和另一个状态变量之间的联系，该联系可以是不同类型，如单向镜像、共用、在逻辑应用中的约束转移。抽象地说，总体上其构成了常说的两个组元的局部PM的模型链。

简单的情形是当PM片断相互独立。通常PM片断相互之间以关系复杂，强烈的依存。为了控制这种状态，采用了群集。

在运行环境下，所有的PM片断至少原则上合并为瞬时PM。这仅限于“原则上”，这是由于能够实现的整个基础取决于局部的合并，产生我们所称的PM群集，其中所有的PM片断置入它们的范围中。

群集的概念是组元化PM和模型链的不可分割的部分。所有组元均与PM片段相联系。当组元的行为取决它的邻近组元的状态变量时，模型链就开始起作用了。一个组元行为的完整PM片段就称之为局部(组元化)产品模型。它基本上可以取决于它所临近大量的组元的状态变量，或者它达到多个的临近组元的临近组元的水平。这种不同局部模型中的状态变量中的重叠，使它们相互之间相互依赖，就是模型链。包含在一个局部组元化产品模型中的组元的集合，就叫做群集。

因此，属于全部的组元化的产品模型的瞬时PM，包括局部模型，该局部模型具有重叠的群集，产生所有组元的完整覆盖。多群集中的组元是包括在模型链中的组元。

例如，假设一个具有两个相邻组元的组元类别，假设它们中的5个连接为一个链。一个组元的局部模型依靠于它的相邻组元，而不是其他的。因此C3的群集包括C2和C4，如图9所示。为了说明全部产品模型如何包括重叠的群集，如图10所示，图中产品模型具有5个组元。注意，C1和C5仅具有一个相邻组元，因此，它们的群集中仅有两个组元。

群集会通常会更加复杂，它包括不同的组元类别，这些组元并不都是链接模型。作为前面例子的简单扩展，考虑如果上面的组元具有两个子组元，每个具有一个子组元。母组元模型取决于它的所有的子组元，但是，没有一个子组元取决于C2和C4的群集中的任何一个。

瞬时产品模型包括动态产品模型，包括一组形成在一起的PM片断。换句话说，瞬时PM是PM片断的相互依赖的唯一组合的总和。

需要注意，瞬时PM通常包括许多同类型的PM片断，其中同类型的PM片断定义为具有同一组参数的PM片断，但是，参数具有不同的值。

通过将新的PM片断加入到特定的瞬时PM或者当将两个或者更多组元连接起来时，瞬时PM动态地改变，发生模型合并。在第一种情形下，当前的瞬时PM拓展了一个新的片断。在另外一种情形下，将每一个组元的瞬时PM合并。但是，实际上过程在局部上是相同的，因此统一了用语。

模型合并可以通过两种方式进行，一种方式是在群集中连接PM片断，但是，这仅是将一个完整的局部PM组合，例如一个群集中的新的PM片断。另外一种方式是在群集之间，从一般配置的角度看，其是真正的模型链。

一种好的方法是将瞬时PM的方法看作许多(无限的)重叠的标准(典型)产品模型，其中每一个可以半独立地配置，除了当它们通过模型合影响它们的重叠时。

单独的组元可以被看作组元类别的一个例子，当创建一个组元的时候，形成所有参数的新的复制。当将该组元加入到场景(scene)的时候，所有这些参数被加入到所有瞬时PM的所有瞬时参数空间中，应用那些仅涉及该组元的约束。

当连接两个组元时，每一个对对方都起着特定的作用。这些作用(行为和所有作用)被预先定义在组元类别中，行为是产品模型的一部分。

行为可以看作为包括两部分。第一部分是描述可以提供那些作用，那些组元类别可以实现它们，组元变量表示可供组元的每一个作用。然后，域和可选择的约束赋给该变量。第二部分描述了与这些组元相联系的两个局部PM如何相互影响。它们通过将约束放到对方的状态变量中相互影响，例如，它们不影响在组元中实际上哪些变量是可用的，而它们的确影响在那些变量中哪些值是合法的。

在这种背景下，瞬时PM包括：

·参数空间，它是相关于各自参数(状态变量)的域的笛卡尔乘积。

·参数空间的合法子集，它定义了参数值之间的关系。

一个同样有效的看待这些的方法在于瞬时PM包括这些参数值之间的关系，限定了参数空间的子集，参数空间的子集称为合法的。这样的关系也可以叫做约束。

瞬时PM可以以如下的方式动态的变化，可以改变的是：

·参数，包括在参数空间中，需要指出的是特定参数的域不改变。

·参数空间的子集，称为合法的，通过定义可以使子集属于超集(superset)，因此，改变参数空间，之前提供的子集失效。但是，如果通过加入合法子集来定义超集的扩展，以及将约束定义为子集的明显约束(restriction)时，这仍然应当被很好的定义。

当修改组元时，当加入或者去除一个PM片断(或者组元)时，当重新设置在相应的组元层次中PM片断之间的联系时，瞬时PM(在配置器中)大体上发生了改变。它可以通过以下5种方式进行变化，

·修改组元，

·加入新组元，

·去除组元，

·连接两个组元，

·使两个组元之间的连接断开。

正如下面所解释的，修改组元的操作仅对于组元参数产生局部影响。通过加入新组元的参数，加入一个新的组元的操作可以拓展参数空间，如图12所示。此外，子集可以被内部约束，但是在这些新的参数和旧的参数之间可没有关联。将新的组元加入到瞬时PM中的过程如图13所示。

去除组元的操作仅是将相关于这个组元的参数从瞬时PM的参数空间中去除，预请求是使要去除的组元失去连接，例如，已经断开了与所有其他的组元的连接。

两个组元连接的操作可以改变合法的子集。直接地，可通过在属于两个组元中的一个的参数之间建立新的联系。间接地，这还对于已经建立的关系的那些参数产生影响。具体而言，这个过程包括建立在两个组元的局部PM之间的模型链。这个模型链取决于组元相互之间扮演的何种特定角色，被描述为PM片断的部分(组元类别)，如图14所示。

一种实施连接两个组元的过程的方法是，使每一个组元相对于另外一个起到特定的作用，建立两个组元之间的模型链。这种模型链包括属于组元的两个局部PM片断之间的组元之间建立一个或者多个链，(如图15所示)这些链与特定的作用相关联，是PM片断的一部分。

显然，使两个组元之间的连接断开需要的条件是这两个组元是已经连接的。这个操作通过使属于这些组元之间的参数的联系去除而改变了合法的子集。

组元化的PM包括两个PM相关部分。一个部分是PM的静态描述，称为片断化的PM，其包括有限的PM片断。另外一个部分是上述的瞬时PM，它可以在运行环境下动态地变化。

这两个部分重要的是分离，这是由于在它们形成一起之前，片断化的PM用于得到产品或者系统组成块的结构，而瞬时PM用于形成过程，其中每一个片断化的PM用于产生瞬时PM.。

连接两个组元以及形成如上所述的模型链的重要影响在于合并了两个PM，因此在模型合并过程中这两个PM在模型中都有改变。原则上，如果被看作一个标准的配置器，那么这提供了全部的配置，该配置使合并之前，瞬时PM无效甚至没有含义。但是，通过基于当前配置的组元居中状态表达的原理的组元化PM，可以确保变量的数量，它们的含义以及相关的域保持不变，以保证重要的特性，即这些因而产生的状态仍然表示在新的合并的组元化PM中的有意义(技术上有效)的设置。

上述的特性是非常重要的特性，但是状态的合法性在此处并没有被保证。由于需要解决非法性这个问题，这个状态是暂时的状态，在这种情况下，完全返回将是不恰当的，这是因为这样会重新破坏连接。这叫做瞬时解，具有几种可能性。需要指出的是，即使原则上所有的变量都可以是非法的，通过合法性原则过程组元-中心(component-centered)的表示(例如几何形状和结构位置)，通常问题将限定到所涉及的组元的邻接组元，经常仅是一些变量(如果有的话)。

解瞬时解的策略基于组元化的PM，是在参数空间内发现可以接收的状态。如何估量附近的项取决于PM，并且实际上可以被认为是组元化的PM的部分。这例如可以将优先级赋给所有的变量，将发生冲突中的最不重要的一个首先改变直到实现合法的状态。也可能是其他的策略。

原则上讲，组元变量仅为普通的变量，它可以具有一般类型的约束。但是，由于设置这样一个变量实际会合并模型，这说明了在值设置过程中规则发生了改变，在合并之前，它必须在两方面在PM中协调，防止采用过于广的瞬时解，而且应用了插件技术(plugtechnology)。插件技术事先确保了连接的PM之间的兼容性。插件，基本表示组元中的连接点，通过与组元变量相关联，如果连接有意义，在PM合并之前，它们进行控制。另外的一个好处在于，这是将具有必要的定位数据提供给几何形状和可视表达的自然方式。

基于组元的可视配置器的例子

本发明提供了一种方法，用于将物理对象的可视表达配置在基于组元的可视配置器中，这种方法基于一种原理，即产品和产品模型可以被无限地由子产品(或者产品零件)形成。组元化的产品模型可以在基于组元的可视配置器-简单而言就是可视配置器中用作基本的机制。之中可视配置器设置用于一种难以处理标准配置器的类型的产品，在另一方面通常发生，从概念上来讲，结合以下5点：

1.应用组元层次，以及

2.状态引擎，是状态表示的特定应用，

3.连接到它的是当前配置的动态的真实的可视表达，

4.满足逻辑约束，

5.满足几何约束。

基于组元的可视配置器的基本结构如图16所示。下面的说明集中于选用的全部数据结构，通过之前所述的数据结构，以及通过状态引擎完成的状态变量过程定时的特定应用选择，以及与状态变量相联系的约束的运转和关联，该数据结构已经得到阐明。

组元的基本结构组连接在图表结构中(不必是单一的结构组)。每一个组元被赋给了一个状态向量，包括用于每一个组元参数的一个状态变量。这构成了(动态)参数空间的完整表示。

通过将一些环境(surroundings)赋给世界(world)(可视世界)，通过将虚拟表示赋给每一个组元，以及通过允许组元的每一个状态变量具有可视效果，通过改变组元的表示(包括它相对于世界或者其他组元的位置)，可以将可视化加入。由于每一个状态变量一直具有一个特定的值，完整的产品的完全可视化就一直显示了当前的配置。

通过将约束分给每一个状态变量，模拟了决定参数空间的合法部分的规则。在这种应用中，采用了这种约束的两种特定的类型。一种是世界和产品的完全几何表示，这允许使用表示产品的组件特性的约束。通过给世界分配某个几何世界，通过允许每一个组元具有几何的表示，以及通过允许每一个状态变量具有一个几何约束，规则如可视化的那样加入。组元结构被反映，这是因为组元之间的每一个连接包括它们之间的相对位置。

第二种类型是普通的逻辑配置器，其收集了产品的完全的逻辑表示。每一个局部PM片断相关联的是这样一种，其与一定组元类别(称为组元逻辑群集所有者)相关，取决于特定的PM，在原理上可以是每一个组元，特别地，通过分配给它们关联于变量间联系的逻辑描述的逻辑约束，状态变量可以结合在一起。

在这样的应用中，每一个组元可以允许与这样一个相联系，每一个状态变量可以被分配一个逻辑约束，该约束将其与另外一个(状态变量)连为一体(详见下述的“这如何与局部产品模型、逻辑群集以及群集所有者相互联系”)。

首先，完整的应用包括了包含了上述(下述)的方法和结构的核心，和3D提供者(任何装置)，图表用户界面，可能是外部的逻辑配置器，以及PM表示。

基本的应用结构是设置多个控制器，基本上说，是将每一个结合起来进行初始化的总的管理器，控制静态的片断化的PM和相关的信息(数据)的数据管理器，控制3D可视化的可视控制器，可视控制器与外部的可视化系统进行交互反应，一个处理几何世界的几何控制器。

总的数据结构(除了上述每一个中的特殊结构)由多个组元形成。存在一个基本反映周围环境的世界，例如，产品形成在场景中。它包括组元，这些组元可以被直接加入到里面，但是不是直接加入到组元层次中。只有一些初始的组元直接加入到世界中，而例如子组元可以与另外一个组元相连接，因此只能间接地加入。这个数据结构在图17中示出。

图16中示出了在状态引擎下的三个部分的三个例子。

可视化部分的例子

为了保持当前(完整)设置的真实可视化(产品的状态)，需要考虑下面的实际方面。

首先，可视场景通过可视控制器与被表示的世界对象相联系，例如，3D场景图像。这也包括产品环境，其可以重新具有自己的参数并且实际上可以单独地配置。区别的产生是由于它通常仅影响产品或者PM(规则)，而实际上不是产品的一个部分。有时它甚至从可视上进行改变，而只是为了显示实际的配置在真实的或者正确的环境。

第二，每一个组元可以分配一个虚拟表示，非可视组元是指幻象组元或者抽象的组元，并且通常具有某些收集(collection)作用。

第三，每一个状态变量可以具有可视效果，它影响了那个表示的特定方面。它事实上也可以根据可视化系统的灵活性将整个表示与另外一个(表示)相交换。

可视化系统的一种可能的类型是表示是形成在场景表上或者甚至是3D场景图表(scene graph)。在这样的系统中，组元的一种变量的可视效果将改变为特定的可视模式。例如，改变材料节点的颜色域(color field)可以改变一个项的颜色，而改变形状模式可以改变它的实际形状。改变变形节点的平移(translation)或者转动范围将改变制品的位置，例如，移动组元。

分级表示尤其适合于开发使用中的组元化表示的好处。它使得可以自然，容易地将局部的视觉变化包括如在组元中或者在两个连接的组元之间。例如，两个组元可以在视觉上相互连接，独立于其他的组元，而不影响与其他组元的连接。基于组元的可视设置的重要之处为可以局部地实现结果(以及效果)。换句话说，在组元自己的虚拟表示和连接到其他组元的位置。

组件配置中的约束的例子

描述物理对象的可视配置器中的重要部分在于描述产品的组件和物理方面的能力，将这些信息传递到配置器中，例如状态变量。

与可视化相似，思路基本上在于保持当前(完全)设置的几何表示。因此，可以将约束赋给状态变量，该状态变量可以查询当前的几何表示，也可以改变它，而它通常意味着一个效果。

而且，当组元加入到当前的配置中的时候，每一个组元可以被赋给被确定的几何表示(它的形状)，该形状被加入到几何世界中。每一个变量都可以分配一个几何约束，它例如可以防止组元移动到另外的组元上，例如，防止冲突，或者可以防止任何东西进入到与该组元相关的特定的区域中。这个区域的例子是安全区域或者工作区域。它可以具有一些空位，这些空位可以被占或者不被占，因此，防止或者允许需要特定缝隙的组元被加入或者被连接。

几何约束的定义尤其对于配置器是非常重要的，在于，通过几何世界，可以产生诸如在组元之间的距离的概念，它可以实际被测定以及应用于其他的规则，例如逻辑的规则。这不是通常典型的配置器使用的数据，它可以很难表达特定类型的规则。而且，它给出了局部影响(位置或者接近)的自然概念，完全远离结构性的一个(组元结构和组元分级系统)，其例如在子产品已经被添加和/或形成相遇时可以允许简单的注意或者感知的方式。这种指定几何规则的方法是表达组元化的PM的关键机制。

需要指出的是，所有几何约束与相同的几何世界相联系，这意味着它们各自的状态变量此处相互影响，完全不取决于它们是否能够获得同样的状态向量，例如，局部组元结构的。如果是几何特性，组元上的约束仅被其他的物理上接近于组元的其他(组元)而影响。因此，此处具有不同的几何位置的概念，它完好地补充了结构性的整体。

在组元化的配置器中的逻辑约束的例子

在将逻辑设置和组元化的配置结合的时候，解决了大量的问题，因此，在组元化的环境中开发了逻辑配置器的能力。换句话说，这个环境提高了逻辑配置器，反之亦然，如果正确使用的话。

基本上讲，通过被允许将逻辑配置器(逻辑数据库)与每一个组元(实际上是状态向量)相联系，数据结构得到了扩展，包括逻辑规则，以及包括将这种数据库的逻辑约束分配到组元的状态变量中。这允许这些变量以非常复杂的方式成为相互依赖的(依赖于逻辑数据库中允许的复杂程度)。

通过使用链机制，连接后的组元的状态变量也可以分配相同的逻辑数据库中的逻辑约束，因此，将它们包括在相应的局部产品模型中，在这种情况下，已经从数据库中分配了逻辑约束的大量变量就叫做具有相关逻辑数据库的组元的逻辑群集。这个组元就叫做逻辑群集所有者(见图18)。需要注意的是，这个结构允许配置器开发出任何逻辑配置器的能力(strength)。在组元化的配置器中，局部产品模型描述了预定数量的参数，而整个瞬时产品模型也可以包括许多的局部产品模型和许多参数。

脚手架系统的可视配置器的例子

该例子的目的在于解释采用根据本发明的方法的配置过程。强调了用于配置器中的输入数据的组元结构和数据结构，输出模型(PM)的组元化如何抓住所述可建造产品的可扩展特性。

这个例子是脚手架系统。观察了两个方面，换句话说模拟化的过程以及配置过程，其中，模拟化的过程抓住了系统的结构，参数和规则，配置过程中配置了特定的脚手架，开发和考虑了脚手架系统的约束。

脚手架配置器例如可以由脚手架系统制造商提供，用于脚手架操作者，该操作者可以使用系统准确地配置它们用来完成特定任务的脚手架，而同时保证了制造商可以实际上交付这样的系统(定制系统)。利用相关于配置器的可视化系统例如可视化的配置器，脚手架操作者可以方便地正确地组装脚手架。

产品包括用于建筑脚手架的整个系统。它包括多个子脚手架部件，例如地板组件、扶手、梯子等。这些就是产品模型中的组元和(物理)子产品范围内的对象所示出的产品。可以回想起产品模型也可以包括抽象的组元，并且这些组元并不必一一对应于物理对象。

更仔细地说，脚手架系统是一种沿着建筑物的侧面的用于建立工作平台的系统，。一般而言，它包括多层平台，设置在钢管的框架结构上。为了能够方便地上下，一些层可以具有用于安装梯子的洞。为了防止工人掉下来，钢管的扶手也可以被安装到框架上。最后，(没有模拟出)框架可以与建筑物的墙体连接，进行固定。

脚手架基本上由多层组件构成，包括平台和必要的框架。共有两种平台，一种标准的，另外一种具有一个洞和安装的梯子。平台是具有短侧和宽侧的矩形，通过将其他层的组件和每一侧(需要等长)或者顶部或者底部连接，脚手架可以从层组件上增建。

通常，模块的两个宽侧中的一侧将是墙安装部分，称为内侧。在组件下面，或者有地面或者另外一个组件。从地面组件到下一层上面的距离可以是低，中，高(可能存在的梯子到洞的距离必须遵守这个高度)。特定的脚手架(一种配置)分为多层，因此，相邻的平台具有同样的高度。

共有两种扶手，一种短的，一种宽的，与层组件的侧面相配合。为了允许将扶手加到最高的层，可以允许加一个顶层，基本包括一些更长的管。

脚手架的特定系统具有一个包括如下组元的PM：平台、标准扶手、完整扶手、顶部和梯子，具有前述关系。如下是每一种组元的特定的参数以及根据组元化的PM将其表示为变量。此外，生成了不同连接之间的相关链。第三，简单描述了涉及的定义为与规则数据库相关的约束(此处命名为rules.logicdb)，以及涉及的类型。

共有两种地板模型，一种标准的，一种是具有一个洞和安装的梯子。这些对应于PM中的一个组元(平台)，其在层的每一侧有/或没有洞。需要注意的是，是否它仅具有定向物(orientation)的一端的洞。另一方面，不可能有两个洞。平台组元是这个产品模型中的关键组元，它集中了脚手架的规则和参数。

<Component(组元)id＝platform(平台)..

<variables(变量)>

<var id＝neighbor_left domain(域)＝modules(模块) valuetype(值的类型)＝component(组元) type(类型)＝link(链接)..

<var id＝neighbor_right..

<var id＝neighbor_outside domain＝modules type＝link..

<var id＝inside_neighbor..

<var id＝above(上方) domain＝modules_and_top type＝link..

..如果模块(module)包括不同的模块“形状”，例如宽和窄，

..则这里应为一个链(chain)

<var id＝below(下方)..

<var id＝ladder(梯子) valuetype＝component(组元) type＝sub..

<chain(链) id＝resize(调整大小) direction(方向)＝outconstraint(约束)＝ladder(梯子) chained＝length(长度)..

</var>

<var id＝rail_left domain＝rails type＝sub

<chain                id＝“length”             direction＝“out”constraint＝“rail_left_length”chained＝“length”/>

</var>

<var id＝rail_right domain＝rails type＝sub..

..

<var id＝rail_outside domain＝rails type＝sub..

..

<var id＝raii_inside domain＝rails type＝sub..

..

<var id＝wall_inside valuetype＝boolean(布尔)default(缺省值)＝true

<var      id＝height(高度) valuetype＝integer(整数)domain＝module_heights default＝medium

<var   id＝hole(孔) valuetype＝boolean visualeffect(视觉效果)＝switch

  </variables>

  <logic>

  .. 

  </logic>

  <geometry(几何形状)>

  ..

  </geometry>

  </Component>

表1：平台组元

<Component id＝rail_standard

<var id＝length domain＝side_lengths

</Component>

表2：标准扶手组元

<Component id＝rail_full

<var id＝length domain＝side_lengths

</Component>

表3：完整扶手组元

<Component id＝top..

<var id＝rail_left domain＝rails type＝sub..

<var id＝rail_right domain＝rails type＝sub..

<var  id＝rail_outside domain＝rails type＝sub..

<var  id＝rail_inside domain＝rails type＝sub..

<var  id＝wall_inside valuetype＝boolean

</Component>

表4：顶部组元

<Component id＝ladder

<var id＝length domain＝module_heigths effect＝switch

</Component>

表5：梯子组元

<domain id＝modules         list(列表)＝(platform，none)/>

<domain id＝modules_and_top list＝(platform，top_module，none/>

<domain id＝modules         list＝(rail_standard，rail_full，none/>

<domain id＝modules_heights list＝(low，medium，high)/>

<domain id＝side_lengths    list＝(short，wide)/>

表6变量的域

下面的规则用于描述产品模型：

规则1：两个组件的连接部分必须是相同长度的，例如，如果C1具有C2作为left_neighbor(左侧邻接)，那么C2具有C1作为right_neighbor(右侧邻接)或者left_neighbor(左侧邻接)，此外，它必须是右侧的，否则内侧就不符合要求。

规则2：如果有墙(wall)，就可以没有内侧邻接(inside neighbor)。

规则3：如果层(floor)不在地面上，那么，在它的下方还会有一层。

规则4：如果有一个孔(hole)的话，只能有梯子(ladder)。

规则5：如果层不在地面上，那么就必须在层的侧面具有扶手(rail)，如果没有邻接的话(或者墙，如果在内侧)。

规则6：作为规则5的结果，在每一层的组元的上方会存在某些东西(调用从平台下去的管子)

规则7：与规则1相似，扶手的变量长度需要对应于层侧面的长度。

规则8：梯子的长度必须与组件的高度相配合。

规则9：所有相邻层(上方或者下方)的高度必须相同。

规则10：没有与对象或者环境的冲突，例如与建筑物的一部分。

规则11：梯子和扶手的几何形状必须与长度相配合(如果没有冲突的话)。

规则1基本上是结构约束，协调了连接中的两个组元中的每一个起到的作用。利用插件(plug)使约束隐含应用。

<var id＝neighbor_left plug id＝neighbor_left..

<plug id＝neighbor_left type＝floor_short..

..

表7：利用插件约束连接组件

规则2、3、4是标准的逻辑类约束，它将变量一个组元内的变量连接起来。每个变量都和约束相关，这样将变量连接到一个逻辑数据结构(rules.logicdb)，其可以单独地进行形成。

<var  id＝neighbor_inside logicconstraint(逻辑约束)＝neighbor_inside..

<var id＝wall logicconstraint＝wall..

..

<logic database(逻辑数据库)＝rules.logicdb..

<constraint(约束)id＝neighbor_inside

<constraint id＝ladder(梯子)

<constraint id＝wall(墙)

<constraint id＝below

</logic>

表8：与称为rules.logicdb的规则数据库相关的逻辑类型约束

在独立的数据结构rules.logicdb中，所述规则按照如下逻辑设计：

wall＝true->inside＝none

hole＝false->ladder＝none

onground＝false->below＝floor_module

表9：逻辑规则，其中->表示说明的意思

规则5和6类似于规则2，3，4，除了在建造过程中，实施这些规则并不现实。例如，空的一侧是加入另外一个层组件的必要的前-状态。这种类型的规则叫做完整规则或者最终定则，仅当要求完成的时候由系统实施。当实施的时候，配置器产生一个最终的正确的脚手架。

in_complete->(neighbor_left＝none and ！groung)->rail_left！＝none

in_complete->(neighbor_outside＝none and ！groung)->rail_outside！＝none

in_complete->above！＝none

表10：逻辑规则，其中！意味着否

规则7和规则8也可以是标准逻辑类约束，除了它们包括不同连接组元中的变量。由于逻辑约束由一个组元持有，必须通过链机制将约束从层模块推到各自的扶手和梯子的变量上。

<Component id＝floor_module

<var id＝rail_outside

.<chain id＝length constraint＝rail_outside.length

</var>

<logic database＝rules.logicdb>

<constraint id＝rail_outside.length..

</logic>

</Component>

<Component id＝parent

<chain chaintype＝constraint

<var id＝lenght

..以及在‘rules.logicdb’

rail_outside！＝none->rail_outside.length＝wide

rail_left！＝none->rail_left.length＝narrow

..

ladder.length＝platform.height

表11：链、逻辑和组元之间的关系

规则9是在连接组元之间的同类型约束。这可以通过链机制直接处理。

<var_id＝neighbor_left domain＝modules valuetype＝componenttype＝link..

<chain    id＝n_height   direction＝in    chained＝myheightconstraint＝neighbor_left.height

<chain    id＝myheight   direction＝out   chained＝n_heightrefvar＝height

..或者..

<chain id＝myheight direction＝out chained＝n_height constraint＝height

</var>

<logic database＝rules.logicdb>

<constraint id＝neighbor_left.height

并且在‘rules.logicdb’中加入

platform.height＝neighbor_left.height

platform.height＝neighbor_outside.height

..

表12：链机制

规则10和11是典型的冲突类型约束。规则10通过将几何形状赋给组元，在所有组元上形成。例如

<Component id＝rail..

<geometry>

<box size(盒子大小)＝...position(位置)＝...

</geometry>

表13：组元上的冲突几何形状

规则11说明几何的数据结构即组元的几何形状改变(检查是否允许)。这是典型的几何约束。

<Component id＝rail..

<var id＝height geometricconstraint＝length..

..

<geometry>

<constraint id＝length type＝geometrychange..

</geometry>

.. 

</Component>

表14：组元的几何约束

如下给出了如何利用上述定义的组元化的产品模型在组元化配置系统中配置脚手架的例子。重点是两部分的；第一部分是示出过程，以及一个用户如何开发配置产品的这个方法的好处。第二，示出了在配置过程中，在配置器中实际发生了什么。

目标的配置是两层的脚手架，例如到达需要一些外部修缮的特定的窗户，一侧具有梯子，给出了2×2的脚手架，在两层脚手架上具有顶层组件。用户可以采用以下步骤和观察每一个步骤的相应图像，如图19所示：

步骤1：能够直接插入到世界中的唯一的组元是平台(platform)，因此，用户可以选择并且插入平台。缺省的高度为中(medium)。自动命名为平台1。

步骤2：用户选择平台1的左侧，获得两个变量neighbor_left以及rail_left。可以加入平台或者扶手。用户加入了平台，称为平台2。

步骤3：用户选择了平台2，将变量孔设置为真(true)。配置系统自动地在孔的位置(向下)加入梯子(梯子1)，将梯子的长度设置为中。

步骤4：选择平台的顶部。可以将平台或者顶层组件加入。用户加入平台(也就是平台3)。

步骤5：用户将平台3的变量孔设置为真，自动加入梯子2。

步骤6：选择顶部，加入顶部(顶部1)。

步骤7：注意，顶层不够高，不能够到达窗户，以及用户选择平台3，将变量高度调整高。梯子2的长度自动设置到高值。

步骤8：选择平台1的顶部，用户可以将另外一个平台(平台4)加入。这通过几何世界说明，系统自动地将平台4作为neighbor_right设置到平台3。接着调整它的高度变量到高值。

步骤9：为了最佳地保护工人爬上梯子，用户选择了平台的外侧，将outside_rail设置到全值。这样，长度变量就与值的宽度相等。

步骤10：最后，为了确保到达所有必须的位置，该过程完全由用户实施。配置系统通过状态变量rail_left将单个的扶手加入到平台3，通过状态变量rail_right和rail_outside加入平台4，通过状态变量rail_left和rail_outside加入顶部1，将顶部2加入，通过rail_right和rail_outside将单个扶手加入到顶部2。需要指出，由于平台和顶部的内部的缺省值为沿着墙，因此，无需加任何东西。

实际在配置器中在配置过程中发生的是在下面的集中于瞬时PM、状态、群集概念以及返回机制的讨论中。

可以记得瞬时PM是组元的当前组合配置的模型，表示了一个人在状态上操作时的所有可能的改变。它包括当前的组元层次，说明了组元如何组合，它包括描述组元如何组合的当前组元层次，以及描述所有状态变量和其所有可能的值的当前状态空间。在图21中，是完整的在完成步骤10之后的组元层次。此外，可以记得，状态表示唯一地当前配置，它只表示一个在当前状态空间的点，当前瞬时PM和静态片断化的PM一起从状态中是可以重复的。

状态是所有状态变量的值的集合，其中，一些变量(组元变量)起到两个作用，因为它们的值与另外一个组元是相关的，并定义了与另外一个组元的连接，而且它们的集合状态定义了组元层次。它们的值在这个方面不是状态值，而是实际的组元。这就叫做连接值。图22示出了在步骤9完成之后状态空间的概况，以及当时的状态(如图12所示)。注意，所有的变量具有一个缺省值，因此，它们不可能没有值。没有特定缺省值的变量自动选择一个值作为缺省值，特别地，组元变量选择“none”作为缺省值。

如前述，(逻辑)群集是瞬时PM的一部分，其直接由一个逻辑结构约束。在该例当中，只有平台具有连接的逻辑结构(规则)，因此，在所有步骤完成之后，共有四个(逻辑)群集；每一个平台一个。如图20所示，图20示出了在完成了步骤10之后的平台4的群集。图中说明了连接到平台4的(平台4是群集所有者)逻辑结构所约束的变量。注意，它包括其他变量中的一些变量，其因此链入平台4群集。图20中，这些在不同的方框中示出，线连接到变量，通过该变量链入。还要注意，变量“neighbor_left.height”来自于平台3，该平台3具有自己的群集。这是群集重叠的例子，其中这个信息在两处均需要。

接下来，考虑给变量设置值的过程。在步骤3中，平台2中的变量“hole”设置为“true”。通常，按照如下步骤进行：

1)用户界面访问平台2，获得“hole”。

2)寻找合法值列表，此处为true、false。

3)用户调用“hole”的设置值过程，值为true。

4)首先检查、验证合法性。

其次，处理值。该步骤包括更新虚拟世界，以显示该值，传递逻辑数据结构的新值。

第三，传递值。此处包括在逻辑数据结构中发现可能的结果。

发现了简单的冲突，也就是与其他的变量“ladder”的冲突，它的当前值“none”不在当前合法值“ladder”中间。

状态引擎(state engine)进入解决冲突状态。

为了解决冲突，状态引擎调用了设置值过程，将值“ladder”设置到变量上。

当梯子变量已经成功设置之后，不再有冲突，因此，状态引擎开始做好准备。

设置值过程成功结束，通知用户(界面)新值。

现在考虑设置一个组元变量，例如，创建一个新的连接。上述步骤9中，变量集(variable set)是组元变量，因此，设置它实际对创建新组元(梯子1)具有负面影响，其已经加入到瞬时PM中并且与平台2连接。通常，按照如下步骤进行：

设置变量“ladder”为值“ladder”。

检查是否是合法的。是

处理值。这启动了组元变量的特殊效果(effect)。

创建“ladder”类型的新组元。这成为梯子1。

初始化梯子1的状态。这包括将单独变量长度设置到缺省值(medium)。

将其连接到世界(取决于虚拟配置器的准确设置)

通过组元平台2中的连接器-变量“ladder”，将链大小连接到变量长度。

检查梯子组元中是否有冲突。此时没有发现。

从连接过程返回，继续传递平台2中的梯子变量的值，检查是否有冲突，没有发现，因此状态引擎做好准备，返回。

最后，考虑解决冲突。注意，在步骤7中，配置器有目的地改变了平台2的高度，产生了与梯子1的长度的冲突，该冲突然后被解决。这种状况同样发生在步骤3和5中，按照如下步骤进行：

首先，检查合法性，判断值是否是不合法的。用户可以无需考虑它(通过听变量的放弃-状态，取消它)。这种情况下，用户-界面将自动地进行。

其次，返回程序应当允许其继续。这样在传递值过程中，开始了求解程序。

通过传递值，逻辑-群集中将出现冲突。发现了变量“height”和“ladder.height”发生了冲突，也将发现所有可能的解，最后比较它们。在这个例子中，状态引擎选择了改变“ladder.height”超过“height”，这是因为，“height”的约束已经被用户忽略了。通过设置“height”的优先级比“ladder.height”的高已经实现了这一点。在其他的例子中，可以询问用户或者环境的请求。