基于依赖管理的CFETR文档管理系统的设计与实现

李 阳 毛世峰 叶民友

(中国科学技术大学工程与应用物理系 安徽 合肥 230026)

0 引 言

中国聚变工程实验堆CFETR[1]是我国正在研究设计的新型超导托卡马克装置，旨在弥补ITER[2]和DEMO之间的差距并开展聚变堆关键技术的测试，对未来实现商用聚变堆的设计和建造有重要意义。作为一个复杂的工程系统，CFETR需要经历漫长且复杂的设计过程，设计过程中将产生大量的设计文件。为了提高CFETR的设计效率，对这些设计文件进行有效管理是一个关键的问题。

随着计算机软件技术的进步，文档管理系统被广泛地应用在工程领域。位于法国的国际热核聚变实验堆ITER开发了一套文档管理系统IDM[3]。这套系统基于开源框架Zope开发，具有易用性、安全性的特点，且具备强大的搜索功能。国内的全超导托卡马克实验装置EAST为了应对爆炸式增长的项目文档，开发了基于LDAP和RBAC的文档管理系统[4-5]，具备文档管理、在线查看、用户管理以及权限控制的功能。从功能上看，这些管理系统都提供了优良的文档管理功能，但缺乏对设计文件之间依赖关系管理的功能。

依赖关系在CFETR设计过程中起到重要的作用。CFETR包含13个子系统，各子系统之间存在复杂的约束关系，即某个子系统的设计往往依赖于其他子系统。如果子系统设计之间发生依赖冲突，这样的设计必然是错误的。传统设计过程中，设计间的依赖关系通过设计人员阅读设计文档来保障。这种方式缺乏对依赖关系的系统管理，设计人员的失误会带来严重的后果。

考虑到设计文件是对物理部件的直接体现，其与物理部件具有一一对应的关系，因此物理部件之间的依赖关系也自然地对应在设计文件上。通过管理设计文件的依赖关系，可以巧妙地解决物理部件之间的依赖问题。本文针对CFETR的设计需求，在CFETR集成设计平台[6-7]上设计并实现了一套具备依赖管理功能的文档管理系统。该系统首先基于达索公司的ENOVIA系统，搭建了安全、稳定、可靠的文档管理服务，用以存储原始设计文件。在此基础上，通过开发设计包管理服务，封装了设计文档、管理了设计文件的依赖关系，并能全局地查看设计文件间的依赖关系。

1 概要设计

1.1 系统架构

CFETR设计文档管理系统架构如图1所示。该系统由两部分组成：用于管理原始数据的基础文档管理模块和用于管理设计依赖关系的设计包管理模块。

图1 CFETR设计文档管理系统架构

数据文件是文档管理系统的核心，任何一个文档管理系统必须能保证数据的安全性。考虑到开发周期、人力成本以及可靠性要求，选择经过市场检验的商业软件能带来稳定性和数据安全性的优势。CFETR文档管理系统引入ENOVIA来存储和管理原始数据。ENOVIA具有用户友好的交互界面，同时还能够和设计开发环境CATIA有机结合，用户可以在浏览器端上传、下载模型文件，也可以在CATIA软件中直接传输、查看模型。

虽然ENOVIA具备优良的文档管理功能，但是不具备管理文档依赖关系的功能。为了解决文档依赖管理，CFETR设计文档管理系统引入了“设计包”的概念。设计包是满足某个特定设计要求的完整文件集合，其封装了设计需求文档、设计模型文件以及设计开发文档等必要文件，并具有描述依赖关系的属性。设计包是一个逻辑上不可拆分的实体，一旦生成就不能新增或删除文件，这就保证了设计文档的完整性和一致性。

在设计包的基础上，开发了设计包管理模块。设计包管理模块由设计包数据库、设计包管理程序和依赖冲突检测程序组成。设计包数据库记录了系统中的数据包信息、系统中用户信息以及数据包的依赖关系。设计包管理程序是用户创建、查看、审批和销毁设计包的程序。依赖冲突检测程序实现了依赖冲突检测算法，能在引入依赖关系时检测是否存在冲突。

1.2 技术选择

C/S结构和B/S结构是常用的应用系统软件结构。B/S结构采用浏览器作为客户端，无需部署客户端程序，具有天然的跨平台属性。C/S结构需要专门编写客户端程序，能充分发挥客户端PC的处理能力，并能带来更好的人机交互体验和更灵活的操作流程。在CFETR设计文档管理系统中，设计包管理程序采用了C/S架构，而原始数据存储、管理所依赖的ENOVIA系统则采用了B/S架构。

ENOVIA是达索公司开发的产品生命周期管理程序，兼具优良的文档管理功能。相较于其他文档管理软件，ENOVIA的优势在于其和三维建模软件CATIA深度结合[8]。ENOVIA提供了丰富的配置工具，可以自由地配置软件功能。同时，它也提供了可供二次开发的接口。在CFETR设计文档管理系统中，设计包管理模块就充分利用了ENOVIA的接口，实现了从ENOVIA中读取、写入数据的功能。

CFETR设计文档管理系统采用Java语言和JavaFX技术开发了设计包管理程序，可以运行在Windows和Linux终端上。Java作为一门广泛使用的计算机编程语言，拥有跨平台、面向对象、泛型编程的特性，并且具有丰富的开源库，适合开发大型项目[9]。JavaFX是由甲骨文公司推出的和Java语言无缝结合的图形界面技术，拥有丰富的图形API，相较于AWT、SWING等旧有的图形库，更容易地创建具有现代风格的程序。JavaFX在语言层面实现了逻辑和界面的分离，其在控制器内编写逻辑代码，在FXML文件内构建图形化界面，因而易于编写符合MVC框架的代码[10]。CFETR文档管理系统使用关系型数据库MySQL管理数据，具有性能高、成本低和可靠性好的特点。

2 详细设计

2.1 设计包的数据结构定义

由于原始数据存放在ENOVIA系统中，设计包无需再次存储这些数据。在设计包管理系统中，使用文件指针的方式表明设计包数据文件的地址。此外，设计包还要有标志符、名称、审核状态、版本、所有者、创建时间、依赖关系等属性，其中依赖关系是用分号分隔开的一系列设计包标志符，表明该设计包所依赖的设计包。设计包的数据结构如图2所示。

图2 设计包的数据结构

2.2 设计包数据库的设计

CFETR文档管理系统在数据库中创建了三张表，分别是设计包表、用户表和依赖关系表。

2.2.1 设计包表

设计包表记录了系统中的设计包信息，其表结构如表1所示。

表1 design_package表结构

2.2.2 用户表

用户数据表存储了用户信息，包括用户名、密码、邮箱以及用户角色信息，其表结构如表2所示。

表2 user表结构

2.2.3 依赖关系表

依赖关系表存储了设计包之间的依赖关系，每一条记录对应一个依赖关系,其表结构如表3所示。

表3 依赖关系表

2.3 设计包管理程序的设计

设计包的生命周期可分为三个阶段：设计人员的创建阶段，审核人员的审批阶段以及设计作废时的销毁阶段。

设计包管理程序客户端基于Java和JavaFX技术开发，针对设计包的生命周期，提供了可视化的操作界面。设计包管理程序通过WebService技术实现了和ENOVIA之间的文件传输，可以直接读取存储在ENOVIA中的文件。

设计包管理程序服务器端使用Socket编程处理客户端发送的请求，通过调用依赖冲突检查程序检查依赖冲突，并能操作数据库来实现数据的增删改查。

2.3.1 设计包的创建

用户将原始设计数据上传到ENOVIA后，就可以在设计包管理程序中创建新的设计包，如图3所示。用户在该界面中填入设计包的名称，指定设计包所属的子系统，并从左侧的ENOVIA文件浏览器中选择文件(设计需求文档，设计文件，设计报告等)到右侧的文件列表中，最后添加设计所依赖的设计包。

图3 创建设计包的界面

用户点击保存按钮后，数据将被提交给服务器端程序。服务器端程序在后台创建设计包，其流程如图4所示。用户提交的设计包将首先进行依赖冲突检测，若检测存在冲突，系统终止该设计包的创建过程，并返回错误信息给客户端；若不存在冲突，系统将在数据库中新增记录，并通过和ENOVIA开发的接口锁定原始数据，保证数据不会被删除或修改。

图4 创建设计包时服务器端程序的流程

2.3.2 设计包的审批

审批是设计过程中的重要环节，任何设计人员创建的数据包在经过项目主管的审核后方能被其他设计包依赖。设计包管理程序的审批界面如图5所示。项目主管登录进入该界面后，可以点选列出的设计包，并查看设计包对应的文件。点击“通过审核”按钮后，程序将提交该请求给服务器端程序。服务器端程序在数据库中修改该设计包为“已审核”状态，并分配版本号给该设计包，这个版本号将比同模块设计包的最大版本号大1。

图5 审核设计包的界面

2.3.3 设计包的查看

为了能全局地查看系统中所有的设计包，设计包管理程序提供了设计包查看界面。利用JavaFX丰富的绘图功能，在设计包界面中有层次地展示了系统中通过审核的设计包。

2.3.4 设计包的销毁

对于过时且不再会被使用的设计包，系统允许管理员对其进行删除操作。删除设计包可能会带来依赖关系的破坏，因而系统会列出所有直接或间接依赖该设计包的其他设计包，并要求同时删除这些依赖。

2.4 依赖冲突检测程序的设计

设计包管理程序在处理新增、修改设计包任务时，需要调用依赖冲突检测程序。依赖检测程序是一个使用Java编写的独立程序，其使用mybatis框架对数据库进行读写操作，并实现了依赖冲突检测算法。

2.4.1 设计包和依赖关系的形式化表示

设计包及其依赖关系可视为一个有向图[11]，记为G=(V,E)，其中：V是图G的顶点集；E是图G的边集。图中的顶点对应设计包，有向边E对应设计包的依赖关系。顶点可由一个二元组表示，其中：m为设计包所属模块；v为设计包的版本号。

对于设计包来说，存在两种依赖冲突：版本冲突和循环引用冲突。

存在版本冲突的充分必要条件是∀w∈V⟹∃x,y∈w的连通分量，使得x.m=y.m且x.v≠y.v。其意义是系统中某个设计包同时依赖了两个相同模块的不同版本设计包。

存在循环引用冲突的充分必要条件是图中存在环，其意义是系统中某个设计包依赖了自身。

图6和图7分别为版本冲突和循环引用冲突的示意图。

图6 版本冲突示意图

图7 循环引用冲突

2.4.2 依赖冲突检测算法

本节将介绍版本冲突检测算法和循环引用检测算法。由于系统需要保持无冲突出现，因此算法只需考虑在一个没有依赖冲突的系统中，检测新增、修改或删除单个设计包时引发的冲突。

对于一个没有依赖冲突的系统，增加一个设计包，可能产生版本冲突，例如图6在新增顶点前不存在依赖冲突，但新增顶点D引发了版本冲突。由于新增的设计包不可能被系统中已有的设计包依赖，即新增顶点的入度一定为0，因而新增设计包不会带来循环引用冲突。

对于一个没有依赖冲突的系统，修改一个设计包的依赖关系，意味着该顶点关联的边可以任意调整，则可能产生版本冲突和循环引用冲突。

对于一个没有依赖冲突的系统，删除一个设计包，即删除一个设计包及它所有的依赖关系。依赖关系的减少必然不会导致依赖冲突，但可能会导致其他设计包的依赖关系无法满足，不在本节的讨论范围。

经过以上分析，本文设计了版本冲突检测算法和循环引用检测算法，如算法1和算法2所示。

算法1版本冲突检测算法

Step 1 使用深度优先搜索算法DFS，得到所有和N连通的顶点集合S

Step 2 初始化一个空的映射M

Step 3 若S不为空，取出S中的第一个元素e；否则，返回无版本冲突的结果，算法结束

Step 4 在M中查找是否有键为e.m的键值对，如果存在这样的键值对p，则转向Step 5，否则转向Step 6

Step 5 若p.v≠e.v，则返回有版本冲突的结果，算法结束；否则，转向Step 3

Step 6 在M中插入键值对，转向Step 3

算法2循环引用检测算法

Step 1 初始化一个空的集合S

Step 2 将顶点N加入集合S中

Step 3 对顶点N使用深度优先搜索算法DFS，在遍历过程中，将遍历到的顶点尝试添加到集合S中;若该顶点已在S中，则返回有循环引用冲突的结果，算法结束

Step 4 返回无循环引用冲突的结果，算法结束

3 系统测试

3.1 测试环境配置

CFETR设计文档管理系统的测试环境如表4所示。在应用服务器上部署了ENOVIA以及设计包管理程序的服务器端。数据库服务器上安装了MySQL服务器，并建立了数据库。在客户端上部署了设计包管理程序的客户端。

表4 测试环境

3.2 软件功能测试

引入一个CFETR设计的实际场景，涉及到CFETR中三个子系统：真空室(VV)、环向场线圈(TF)和极向场线圈(PF)。

首先，在三维建模软件CATIA中完成模型的绘制并将模型文件上传到ENOVIA中。随后，使用设计人员测试账号登录进入设计包管理系统，创建VV、TF和PF的设计包。创建设计包时，通过ENOVIA文件浏览器添加必要的文件，并设定好依赖关系。表5列出了测试中部分设计包所包含的文件和依赖的设计包。

表5 算法性能测试

使用审核人员测试账号登录系统，系统中列出了所有的设计包；逐个选择并通过设计包；通过的设计包得到了一个版本号；进入设计包查看界面，可以查看所有的设计包信息以及依赖关系，如图8所示。

3.3 依赖冲突检测程序测试

3.3.1 正确性验证

由于依赖检测算法是基于已有的设计包无依赖冲突而设计的，为了测试依赖冲突检测程序的正确性、健壮性及时间效率，需要生成一个无依赖冲突的设计包数据表。本文构造了一个由5个模块、15个设计包、14条依赖关系组成的设计包数据库，如图9所示。

图9 测试数据表

本文测试了典型的依赖关系并获得通过：

测试1：尝试插入依赖于和，系统提示存在版本冲突。

测试2：尝试插入依赖于和，系统提示创建成功。

测试3：尝试修改的依赖，使其依赖于，系统提示存在循环依赖。

接下来，构造了具有30个设计包，60条依赖关系的数据库，并设计了20个测试样例。算法准确识别了所有的依赖冲突。由于测试原理相同，在此不再赘述。

3.3.2 算法性能测试

为了测试算法的效率，需要构造一张具有相当数据量的设计包数据表。为此实现了自动生成无依赖冲突数据表的算法，如算法3所示。

算法3生成无依赖冲突数据表算法

输入：生成设计包个数N，依赖数量参数K

输出：无依赖冲突的设计包表和依赖关系表

过程：

Step 1 若N>0，随机生成一个设计包A添加到设计包表中，N=N-1；否则算法结束

Step 2 在设计包表中随机选择至多K个设计包，生成集合S

Step 3 若S不为空，取出S中的第一个元素X；否则返回Step 1

Step 4 尝试使A依赖于X，使用依赖冲突检测程序判断是否冲突，若无冲突，添加此依赖关系到依赖关系表中。返回Step 3。

本文测试了在不同规模的模块数、设计包数和依赖数下的算法效率。测试方法为：将一个随机生成设计包加入到系统中，记录依赖冲突算法的执行时间。每种情况进行了三次测试并取平均耗时，如表6所示。

从表6可以看出，算法的时间开销在可接受范围内，并且其性能在不同规模下是稳定的。

表6 算法性能测试

4 结 语

本文分析了国内外工程设计中文档管理系统的现状，提出了一套基于依赖管理的CFETR文档管理系统。通过管理设计文件的依赖关系，体现了设计部件之间的约束关系，提高了设计效率。本文首先给出了系统的总体架构，并提出了设计包的概念以及依赖检测算法，说明了设计包管理依赖关系的过程。其次，给出了系统的技术方案：基础文档管理模块基于成熟的商业软件ENOVIA开发，设计包管理模块基于C/S架构，使用Java语言开发，实现了设计包的创建、审批、销毁功能，并能调用依赖冲突检测程序。最后本文测试了系统的各项功能，并对依赖检测算法进行了正确性和性能测试。