基于依賴管理的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語言開發，實現了設計包的創建、審批、銷毀功能，并能調用依賴沖突檢測程序。最后本文測試了系統的各項功能，并對依賴檢測算法進行了正確性和性能測試。