李 陽 毛世峰 葉民友

(中國科學技術大學工程與應用物理系 安徽 合肥 230026)

0 引 言

中國聚變工程實驗堆CFETR[1]是我國正在研究設計的新型超導托卡馬克裝置，旨在彌補ITER[2]和DEMO之間的差距并開展聚變堆關鍵技術的測試，對未來實現(xiàn)商用聚變堆的設計和建造有重要意義。作為一個復雜的工程系統(tǒng)，CFETR需要經(jīng)歷漫長且復雜的設計過程，設計過程中將產(chǎn)生大量的設計文件。為了提高CFETR的設計效率，對這些設計文件進行有效管理是一個關鍵的問題。

隨著計算機軟件技術的進步，文檔管理系統(tǒng)被廣泛地應用在工程領域。位于法國的國際熱核聚變實驗堆ITER開發(fā)了一套文檔管理系統(tǒng)IDM[3]。這套系統(tǒng)基于開源框架Zope開發(fā)，具有易用性、安全性的特點，且具備強大的搜索功能。國內(nèi)的全超導托卡馬克實驗裝置EAST為了應對爆炸式增長的項目文檔，開發(fā)了基于LDAP和RBAC的文檔管理系統(tǒng)[4-5]，具備文檔管理、在線查看、用戶管理以及權限控制的功能。從功能上看，這些管理系統(tǒng)都提供了優(yōu)良的文檔管理功能，但缺乏對設計文件之間依賴關系管理的功能。

依賴關系在CFETR設計過程中起到重要的作用。CFETR包含13個子系統(tǒng)，各子系統(tǒng)之間存在復雜的約束關系，即某個子系統(tǒng)的設計往往依賴于其他子系統(tǒng)。如果子系統(tǒng)設計之間發(fā)生依賴沖突，這樣的設計必然是錯誤的。傳統(tǒng)設計過程中，設計間的依賴關系通過設計人員閱讀設計文檔來保障。這種方式缺乏對依賴關系的系統(tǒng)管理，設計人員的失誤會帶來嚴重的后果。

考慮到設計文件是對物理部件的直接體現(xiàn)，其與物理部件具有一一對應的關系，因此物理部件之間的依賴關系也自然地對應在設計文件上。通過管理設計文件的依賴關系，可以巧妙地解決物理部件之間的依賴問題。本文針對CFETR的設計需求，在CFETR集成設計平臺[6-7]上設計并實現(xiàn)了一套具備依賴管理功能的文檔管理系統(tǒng)。該系統(tǒng)首先基于達索公司的ENOVIA系統(tǒng)，搭建了安全、穩(wěn)定、可靠的文檔管理服務，用以存儲原始設計文件。在此基礎上，通過開發(fā)設計包管理服務，封裝了設計文檔、管理了設計文件的依賴關系，并能全局地查看設計文件間的依賴關系。

1 概要設計

1.1 系統(tǒng)架構

CFETR設計文檔管理系統(tǒng)架構如圖1所示。該系統(tǒng)由兩部分組成：用于管理原始數(shù)據(jù)的基礎文檔管理模塊和用于管理設計依賴關系的設計包管理模塊。

圖1 CFETR設計文檔管理系統(tǒng)架構

數(shù)據(jù)文件是文檔管理系統(tǒng)的核心，任何一個文檔管理系統(tǒng)必須能保證數(shù)據(jù)的安全性?？紤]到開發(fā)周期、人力成本以及可靠性要求，選擇經(jīng)過市場檢驗的商業(yè)軟件能帶來穩(wěn)定性和數(shù)據(jù)安全性的優(yōu)勢。CFETR文檔管理系統(tǒng)引入ENOVIA來存儲和管理原始數(shù)據(jù)。ENOVIA具有用戶友好的交互界面，同時還能夠和設計開發(fā)環(huán)境CATIA有機結合，用戶可以在瀏覽器端上傳、下載模型文件，也可以在CATIA軟件中直接傳輸、查看模型。

雖然ENOVIA具備優(yōu)良的文檔管理功能，但是不具備管理文檔依賴關系的功能。為了解決文檔依賴管理，CFETR設計文檔管理系統(tǒng)引入了“設計包”的概念。設計包是滿足某個特定設計要求的完整文件集合，其封裝了設計需求文檔、設計模型文件以及設計開發(fā)文檔等必要文件，并具有描述依賴關系的屬性。設計包是一個邏輯上不可拆分的實體，一旦生成就不能新增或刪除文件，這就保證了設計文檔的完整性和一致性。

在設計包的基礎上，開發(fā)了設計包管理模塊。設計包管理模塊由設計包數(shù)據(jù)庫、設計包管理程序和依賴沖突檢測程序組成。設計包數(shù)據(jù)庫記錄了系統(tǒng)中的數(shù)據(jù)包信息、系統(tǒng)中用戶信息以及數(shù)據(jù)包的依賴關系。設計包管理程序是用戶創(chuàng)建、查看、審批和銷毀設計包的程序。依賴沖突檢測程序實現(xiàn)了依賴沖突檢測算法，能在引入依賴關系時檢測是否存在沖突。

1.2 技術選擇

C/S結構和B/S結構是常用的應用系統(tǒng)軟件結構。B/S結構采用瀏覽器作為客戶端，無需部署客戶端程序，具有天然的跨平臺屬性。C/S結構需要專門編寫客戶端程序，能充分發(fā)揮客戶端PC的處理能力，并能帶來更好的人機交互體驗和更靈活的操作流程。在CFETR設計文檔管理系統(tǒng)中，設計包管理程序采用了C/S架構，而原始數(shù)據(jù)存儲、管理所依賴的ENOVIA系統(tǒng)則采用了B/S架構。

ENOVIA是達索公司開發(fā)的產(chǎn)品生命周期管理程序，兼具優(yōu)良的文檔管理功能。相較于其他文檔管理軟件，ENOVIA的優(yōu)勢在于其和三維建模軟件CATIA深度結合[8]。ENOVIA提供了豐富的配置工具，可以自由地配置軟件功能。同時，它也提供了可供二次開發(fā)的接口。在CFETR設計文檔管理系統(tǒng)中，設計包管理模塊就充分利用了ENOVIA的接口，實現(xiàn)了從ENOVIA中讀取、寫入數(shù)據(jù)的功能。

CFETR設計文檔管理系統(tǒng)采用Java語言和JavaFX技術開發(fā)了設計包管理程序，可以運行在Windows和Linux終端上。Java作為一門廣泛使用的計算機編程語言，擁有跨平臺、面向對象、泛型編程的特性，并且具有豐富的開源庫，適合開發(fā)大型項目[9]。JavaFX是由甲骨文公司推出的和Java語言無縫結合的圖形界面技術，擁有豐富的圖形API，相較于AWT、SWING等舊有的圖形庫，更容易地創(chuàng)建具有現(xiàn)代風格的程序。JavaFX在語言層面實現(xiàn)了邏輯和界面的分離，其在控制器內(nèi)編寫邏輯代碼，在FXML文件內(nèi)構建圖形化界面，因而易于編寫符合MVC框架的代碼[10]。CFETR文檔管理系統(tǒng)使用關系型數(shù)據(jù)庫MySQL管理數(shù)據(jù)，具有性能高、成本低和可靠性好的特點。

2 詳細設計

2.1 設計包的數(shù)據(jù)結構定義

由于原始數(shù)據(jù)存放在ENOVIA系統(tǒng)中，設計包無需再次存儲這些數(shù)據(jù)。在設計包管理系統(tǒng)中，使用文件指針的方式表明設計包數(shù)據(jù)文件的地址。此外，設計包還要有標志符、名稱、審核狀態(tài)、版本、所有者、創(chuàng)建時間、依賴關系等屬性，其中依賴關系是用分號分隔開的一系列設計包標志符，表明該設計包所依賴的設計包。設計包的數(shù)據(jù)結構如圖2所示。

圖2 設計包的數(shù)據(jù)結構

2.2 設計包數(shù)據(jù)庫的設計

CFETR文檔管理系統(tǒng)在數(shù)據(jù)庫中創(chuàng)建了三張表，分別是設計包表、用戶表和依賴關系表。

2.2.1 設計包表

設計包表記錄了系統(tǒng)中的設計包信息，其表結構如表1所示。

表1 design_package表結構

2.2.2 用戶表

用戶數(shù)據(jù)表存儲了用戶信息，包括用戶名、密碼、郵箱以及用戶角色信息，其表結構如表2所示。

表2 user表結構

2.2.3 依賴關系表

依賴關系表存儲了設計包之間的依賴關系，每一條記錄對應一個依賴關系,其表結構如表3所示。

表3 依賴關系表

2.3 設計包管理程序的設計

設計包的生命周期可分為三個階段：設計人員的創(chuàng)建階段，審核人員的審批階段以及設計作廢時的銷毀階段。

設計包管理程序客戶端基于Java和JavaFX技術開發(fā)，針對設計包的生命周期，提供了可視化的操作界面。設計包管理程序通過WebService技術實現(xiàn)了和ENOVIA之間的文件傳輸，可以直接讀取存儲在ENOVIA中的文件。

設計包管理程序服務器端使用Socket編程處理客戶端發(fā)送的請求，通過調用依賴沖突檢查程序檢查依賴沖突，并能操作數(shù)據(jù)庫來實現(xiàn)數(shù)據(jù)的增刪改查。

2.3.1 設計包的創(chuàng)建

用戶將原始設計數(shù)據(jù)上傳到ENOVIA后，就可以在設計包管理程序中創(chuàng)建新的設計包，如圖3所示。用戶在該界面中填入設計包的名稱，指定設計包所屬的子系統(tǒng)，并從左側的ENOVIA文件瀏覽器中選擇文件(設計需求文檔，設計文件，設計報告等)到右側的文件列表中，最后添加設計所依賴的設計包。

圖3 創(chuàng)建設計包的界面

用戶點擊保存按鈕后，數(shù)據(jù)將被提交給服務器端程序。服務器端程序在后臺創(chuàng)建設計包，其流程如圖4所示。用戶提交的設計包將首先進行依賴沖突檢測，若檢測存在沖突，系統(tǒng)終止該設計包的創(chuàng)建過程，并返回錯誤信息給客戶端；若不存在沖突，系統(tǒng)將在數(shù)據(jù)庫中新增記錄，并通過和ENOVIA開發(fā)的接口鎖定原始數(shù)據(jù)，保證數(shù)據(jù)不會被刪除或修改。

圖4 創(chuàng)建設計包時服務器端程序的流程

2.3.2 設計包的審批

審批是設計過程中的重要環(huán)節(jié)，任何設計人員創(chuàng)建的數(shù)據(jù)包在經(jīng)過項目主管的審核后方能被其他設計包依賴。設計包管理程序的審批界面如圖5所示。項目主管登錄進入該界面后，可以點選列出的設計包，并查看設計包對應的文件。點擊“通過審核”按鈕后，程序將提交該請求給服務器端程序。服務器端程序在數(shù)據(jù)庫中修改該設計包為“已審核”狀態(tài)，并分配版本號給該設計包，這個版本號將比同模塊設計包的最大版本號大1。

圖5 審核設計包的界面

2.3.3 設計包的查看

為了能全局地查看系統(tǒng)中所有的設計包，設計包管理程序提供了設計包查看界面。利用JavaFX豐富的繪圖功能，在設計包界面中有層次地展示了系統(tǒng)中通過審核的設計包。

2.3.4 設計包的銷毀

對于過時且不再會被使用的設計包，系統(tǒng)允許管理員對其進行刪除操作。刪除設計包可能會帶來依賴關系的破壞，因而系統(tǒng)會列出所有直接或間接依賴該設計包的其他設計包，并要求同時刪除這些依賴。

2.4 依賴沖突檢測程序的設計

設計包管理程序在處理新增、修改設計包任務時，需要調用依賴沖突檢測程序。依賴檢測程序是一個使用Java編寫的獨立程序，其使用mybatis框架對數(shù)據(jù)庫進行讀寫操作，并實現(xiàn)了依賴沖突檢測算法。

2.4.1 設計包和依賴關系的形式化表示

設計包及其依賴關系可視為一個有向圖[11]，記為G=(V,E)，其中：V是圖G的頂點集；E是圖G的邊集。圖中的頂點對應設計包，有向邊E對應設計包的依賴關系。頂點可由一個二元組表示，其中：m為設計包所屬模塊；v為設計包的版本號。

對于設計包來說，存在兩種依賴沖突：版本沖突和循環(huán)引用沖突。

存在版本沖突的充分必要條件是?w∈V??x,y∈w的連通分量，使得x.m=y.m且x.v≠y.v。其意義是系統(tǒng)中某個設計包同時依賴了兩個相同模塊的不同版本設計包。

存在循環(huán)引用沖突的充分必要條件是圖中存在環(huán)，其意義是系統(tǒng)中某個設計包依賴了自身。

圖6和圖7分別為版本沖突和循環(huán)引用沖突的示意圖。

圖6 版本沖突示意圖

圖7 循環(huán)引用沖突

2.4.2 依賴沖突檢測算法

本節(jié)將介紹版本沖突檢測算法和循環(huán)引用檢測算法。由于系統(tǒng)需要保持無沖突出現(xiàn)，因此算法只需考慮在一個沒有依賴沖突的系統(tǒng)中，檢測新增、修改或刪除單個設計包時引發(fā)的沖突。

對于一個沒有依賴沖突的系統(tǒng)，增加一個設計包，可能產(chǎn)生版本沖突，例如圖6在新增頂點前不存在依賴沖突，但新增頂點D引發(fā)了版本沖突。由于新增的設計包不可能被系統(tǒng)中已有的設計包依賴，即新增頂點的入度一定為0，因而新增設計包不會帶來循環(huán)引用沖突。

對于一個沒有依賴沖突的系統(tǒng)，修改一個設計包的依賴關系，意味著該頂點關聯(lián)的邊可以任意調整，則可能產(chǎn)生版本沖突和循環(huán)引用沖突。

對于一個沒有依賴沖突的系統(tǒng)，刪除一個設計包，即刪除一個設計包及它所有的依賴關系。依賴關系的減少必然不會導致依賴沖突，但可能會導致其他設計包的依賴關系無法滿足，不在本節(jié)的討論范圍。

經(jīng)過以上分析，本文設計了版本沖突檢測算法和循環(huán)引用檢測算法，如算法1和算法2所示。

算法1版本沖突檢測算法

Step 1 使用深度優(yōu)先搜索算法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循環(huán)引用檢測算法

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

Step 2 將頂點N加入集合S中

Step 3 對頂點N使用深度優(yōu)先搜索算法DFS，在遍歷過程中，將遍歷到的頂點嘗試添加到集合S中;若該頂點已在S中，則返回有循環(huán)引用沖突的結果，算法結束

Step 4 返回無循環(huán)引用沖突的結果，算法結束

3 系統(tǒng)測試

3.1 測試環(huán)境配置

CFETR設計文檔管理系統(tǒng)的測試環(huán)境如表4所示。在應用服務器上部署了ENOVIA以及設計包管理程序的服務器端。數(shù)據(jù)庫服務器上安裝了MySQL服務器，并建立了數(shù)據(jù)庫。在客戶端上部署了設計包管理程序的客戶端。

表4 測試環(huán)境

3.2 軟件功能測試

引入一個CFETR設計的實際場景，涉及到CFETR中三個子系統(tǒng)：真空室(VV)、環(huán)向場線圈(TF)和極向場線圈(PF)。

首先，在三維建模軟件CATIA中完成模型的繪制并將模型文件上傳到ENOVIA中。隨后，使用設計人員測試賬號登錄進入設計包管理系統(tǒng)，創(chuàng)建VV、TF和PF的設計包。創(chuàng)建設計包時，通過ENOVIA文件瀏覽器添加必要的文件，并設定好依賴關系。表5列出了測試中部分設計包所包含的文件和依賴的設計包。

表5 算法性能測試

使用審核人員測試賬號登錄系統(tǒng)，系統(tǒng)中列出了所有的設計包；逐個選擇并通過設計包；通過的設計包得到了一個版本號；進入設計包查看界面，可以查看所有的設計包信息以及依賴關系，如圖8所示。

3.3 依賴沖突檢測程序測試

3.3.1 正確性驗證

由于依賴檢測算法是基于已有的設計包無依賴沖突而設計的，為了測試依賴沖突檢測程序的正確性、健壯性及時間效率，需要生成一個無依賴沖突的設計包數(shù)據(jù)表。本文構造了一個由5個模塊、15個設計包、14條依賴關系組成的設計包數(shù)據(jù)庫，如圖9所示。

圖9 測試數(shù)據(jù)表

本文測試了典型的依賴關系并獲得通過：

測試1：嘗試插入依賴于和，系統(tǒng)提示存在版本沖突。

測試2：嘗試插入依賴于和，系統(tǒng)提示創(chuàng)建成功。

測試3：嘗試修改的依賴，使其依賴于，系統(tǒng)提示存在循環(huán)依賴。

接下來，構造了具有30個設計包，60條依賴關系的數(shù)據(jù)庫，并設計了20個測試樣例。算法準確識別了所有的依賴沖突。由于測試原理相同，在此不再贅述。

3.3.2 算法性能測試

為了測試算法的效率，需要構造一張具有相當數(shù)據(jù)量的設計包數(shù)據(jù)表。為此實現(xiàn)了自動生成無依賴沖突數(shù)據(jù)表的算法，如算法3所示。

算法3生成無依賴沖突數(shù)據(jù)表算法

輸入：生成設計包個數(shù)N，依賴數(shù)量參數(shù)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。

本文測試了在不同規(guī)模的模塊數(shù)、設計包數(shù)和依賴數(shù)下的算法效率。測試方法為：將一個隨機生成設計包加入到系統(tǒng)中，記錄依賴沖突算法的執(zhí)行時間。每種情況進行了三次測試并取平均耗時，如表6所示。

從表6可以看出，算法的時間開銷在可接受范圍內(nèi)，并且其性能在不同規(guī)模下是穩(wěn)定的。

表6 算法性能測試

4 結 語

本文分析了國內(nèi)外工程設計中文檔管理系統(tǒng)的現(xiàn)狀，提出了一套基于依賴管理的CFETR文檔管理系統(tǒng)。通過管理設計文件的依賴關系，體現(xiàn)了設計部件之間的約束關系，提高了設計效率。本文首先給出了系統(tǒng)的總體架構，并提出了設計包的概念以及依賴檢測算法，說明了設計包管理依賴關系的過程。其次，給出了系統(tǒng)的技術方案：基礎文檔管理模塊基于成熟的商業(yè)軟件ENOVIA開發(fā)，設計包管理模塊基于C/S架構，使用Java語言開發(fā)，實現(xiàn)了設計包的創(chuàng)建、審批、銷毀功能，并能調用依賴沖突檢測程序。最后本文測試了系統(tǒng)的各項功能，并對依賴檢測算法進行了正確性和性能測試。