引 言
在协同产品开发过程中，存在着许多约束关系，如技术水平、人员素质和各种资源的限制；客户的要求；设计规范、设计对象的垂本规律以及各种一致性要求等等。而且在协同产品开发中，根据并行工程的思想，应尽可能早地、全面地考虑产品开发过程下游对设计阶段的要求，以避免或减少那些在开发过程晚期才发现的而又必须使开发过程返回到设计初期才能弥补的设计错误。产品开发有关人员被划分为数个多功能小组，每个小组包括总体设计、功能分析、工艺制造等部门的有关人员。这样，设计人员与下游有关人员的交流必然增多，设计时考虑下游问题的种类和数量明显增加，表现为设计时必须处理多功能小组间及成员间存在的大量约束关系。为使产品开发过程顺利进行，充分体现并行工程的效益，必须建立一种约束管理系统来表示约束及约束间的层次关系，并将其应用于协同产品开发过程，以便及时判断约束各方的相互影响清况，减少违约次数，及时通报违约信息，必要时提供有效的冲突仲裁方案。
目前，对约束管理的研究，大多集中在约束满足间题的求解方法上，研究者提出一系列约束的求解策略，依赖现有的系统进行约束管理，是一种集中式的约束管理方法。本文根据协同产品开发的分布式特点，开发了一种分布式约束管理系统，为协同产品开发提供了支持。
1 分布式约束管理系统的体系结构
约束管理系统构成方式有两种：集中式和分布式。
在集中式结构中，所有约束管理功能位于服务器上，当客户站点需要进行约束满足检查时，向服务器发出请求，这种系统的优点在于简单、易于实现，适合于约束关系不是很复杂的情况，缺点在于不适合大规模的协作。已有的大量约束管理系统属于这种结构。
本系统中采用了分布式结构，分布式结构根据设计任务将约束分布在各个站点，各站点的地位是平等的，分别对本站点的约束进行管理。这种结构符合设计人员在产品协同设计过程中，总是先针对自己的任务进行设计，在设计过程到一定阶段上与其他人员进行交流的实际情况。它的适应性广，能够适合于大范围分布的群组工作方式。由于产品设计的零部件间的装配、功能间的相互关系以及同一结构不同领域的要求，使得一些约束成为多个人员所必须关心和处理的内容。设计者必须在满足本身约束的同时又满足所有与其相关的外部约束，因而，对一些涉及多个人员的约束进行集中管理可以提高协同效率。如图1所示，系统根据设计任务把约束分成：领域约束、小组约束和全局约束，相应地分布在领域站点和服务器上，其中服务器中存放了小组约束和全局约束。领域约束指仅与某独立领域有关的约束，小组约束指与几个领域有关的约束，全局约束则指与几个小组有关的约束。
为了高效的进行约束管理，在本系统中，将约束管理功能包装成约束Agent。Agent是一个计算机系统，具有自治性，能够感知环境发生的变化并对之作出反应，Agent还具有信念、意向等精神方面的概念，约束Agent是具有约束管理能力的软件系统，它能够感知系统中相关约束的变化情况并采取适当的措施进行处理。
2 分布约束管理系统的功能
约束由相关的变量和一定的约束关系组成，系统功能可分成变量管理、约束管理和约束检查。
2.1 变量管理
零部件的所有特性和参数，例如重量、尺寸、材料等都可以通过变量来描述。仅与一个设计小组有关的变量称为独立变量，与几个小组有关的变量称为小组公共变量。在一个设计小组中，仅与一个领域有关的变量称为独立变量，与几个领域有关的变量称为领域公共变量。要对约束进行有效的管理，首先要对变量进行管理，变量的管理包括变量的添加、删除和修改。
(1)变量的添加在任一客户站点进行变量添加时，首先判断该变量是否与其他客户站点有关，为真时，除了将其存放在本地库外，还将其作为公共变量存放在对应的服务器中；为假时，作为独立变量独立存放在本地库。任一服务器进行变量添加时，将其作为公共变量存放在该服务器中，并将其存放在相关站点的本地库中。
(2)变量的删除公共变量删除时，要通知与此变量有关的各个站点，并达成协议。如果同意剔除，首先根据约束变量关系表删除与变量有关的约束，再删除变量；独立变量删除时，先删除与变量有关的约束，然后删除变量。
(3)变量的修改公共变量修改时，首先对公共变量表进行修改，然后通知与该变量有关的各个客户站点做出相应的动作；独立变量进行修改时，仅对本地库修改即可。
2.2 约束管理
约束的管理包括约束的添加、删除和修改。
(1)约束添加约束添加的同时，建立了动态约束变量关系表，约束与变量建立了多对多的网状关系。在这里，我们所指的约束包括了约束关系本身以及约束变量关系表。约束添加时，首先进行判断，为领域约束的存放在对应领域的本地库，为小组约束和全局约束的放在服务器上。
(2)约束删除服务器的约束进行删除时，必须通知所有与其相关的客户约束Agent删除相关的约束，再删除本约束；客户领域站点进行约束删除时，仅需删除本约束。
(3)约束修改服务器上的约束进行修改时，同时还修改相关客户站点的约束；客户领域站点进行约束修改时，仅需修改本约束。
2.3 约束检查
2.3.1 单个站点的约束检查
对每个具体的站点，根据设计人员的工作方式，有两种约束检查方式：
(1)在线检查每当设计人员给出零部件的某一特性或参数，即对某一变量进行赋值时，立即对与该变量有关的约束进行约束检查，调整变量值，以求得该变量一开始就获得局部约束满足。
(2)阶段检查每当设计人员的活动进行到一定阶段，对现阶段设计的所有约束进行全面检查。
在线检查，每给一个变量赋值，就必须进行一次检查，这样能保证在设计的早期，变量能满足局部约束要求，而不需要在后期进行大量的修改。阶段检查能保证某一阶段的所有约束都为能得到满足。在本系统，同时采用了这两种方法。设计人员仅想对某一变量进行检查时，采用在线检查；设计工作进行到一定阶段，想对整体工作进行检查时，采用阶段检查。
2.3.2 整体约束检查
在本系统中，利用约束Agent进行整体约束检查。约束Agent分为：领域约束Agent，小组约束Agent和全局约束Agent。他们一方面处理本范围的约束，另一方面又与其他的约束Agent发生关系。约束检查过程具体如下：
各客户站点利用约束Agent对本站点的约束进行求解，找出约束满足值。然后通过通讯Agent阶段性地把约束满足值向上提交到小组服务器，进行小组约束检查，若发生冲突，通讯Agent向有关的客户站点发出通知，进行协调，找出约束满足值。最后，通讯Agent阶段性地把小组约束满足值提交给总服务器，进行全局约束检查，若产生冲突，通知相关小组进行协调，直至达到整个产品的一致性。
3 实现系统的关链技术
3.1 用Microsoft Excel辅助约束检查
约束满足检查的关键技术之一是如何计算约束表达式。约束表达式的大部分形式都是方程型：等式方程或不等式方程。一条约束由若干个变量，运算符{＋，－*，/，()}，数学函数{cos()，sin()，abs()……}和不等式狩号{＜，＞，≤，≥，＝}组成。按普通的方法计算，就要把表达式的字符一个个提取出来，分门别类进行判别，这种方法计算量非常的大，可以说是行不通的.为了简化计算，我们在这个项目中采用在VB中用OLE控件定制Microsoft’s Excel，利用Excel来计算表达式的方案，Excel具有强大的计算功能，它包括数学函数与三角函数、逻辑函数、统计函数、信息函数、财务函数等。下面来讨论具体的实现方法：
进行约束表达式计算时，利用约束变量关系表，其结构如表3所示，取出约束所包含的变量，再根据变量表(如表2所示)查出变量的值。然后，把约束表达式的形式转化成Excel所能识别的格式，利用Excel进行约束计算。例如：
要检查约束表达式a1＋b1＋3＞0，第一步，在约束表(如表1所示)查出该约束的Orderid；第二步，根据Orderid在约束变量网络表中找出对应的变量a1，b1；第三步，在变量表中，取出变量a1的值为a1.value，b1的值为b1.value；第四步，把a1的值赋给Excel单元格R1C1，b11的值赋给单元格R1C2；第五步，把表达式a1＋b1＋3＞0转化成Excel格式formulate＝“＝R1C1＋R1C2＋3＞0”，把临时变量Formulate的值赋给单元格R1C3，这样，Excel就会自动进行计算；第六步，根据单元格R1C3的返回值进行判断，为真时，表示约束满足，为假时，表示产生冲突，这时，发布给相关的站点，进行协调。
3.2 约束Agent结构
约束Agent结构主要包括接C3模块、消息处理器、约束求解器本地数据库DB和本地知识库KB等。接口模块负责处理本约束Agent与其他Agent交互数据；消息处理器负责建立消息队列，等待处理；约束求解器负责对约束进行检查；DB中存放着变量表、约束表和约束变量表；KB中存放着处理约束的各种知识库和规则库。不同约束Agent含有不同内容的DB。领域约束Agent的DB包含领域变量表、领域约束表和约束变量关系表；小组约束Agent包含公共变量表、小组约束表和约束变量关系表；全局约束包括小组公共变量表、全局约束表和约束变量关系表。
表格1 约束表
表格2 变量表
表格3 约束变量网络表
4 结 论
本文根据CSCW系统中协同设计的分布式特点，开发了一套C/S和对等式相结合的分布式约束管理系统，提出了用约束Agent来进行约束管理，将领域约束，小组约束和全局约束合理地分布在领域站点，小组服务器和全局服务器中，对整R.束进行有效的管理，为整个协同设计提供了支持。
