呂征宇, 周亮, 蘇葉鋒, 吳豪杰

(1.國網(wǎng)上海電力設計有限公司，上海 200002;2.上海金曲信息技術有限公司, 上海 200070)

0 引言

可行性研究、初步設計階段報告協(xié)同編制系統(tǒng)是一種針對項目調研立項、方案設計的報告協(xié)同編制系統(tǒng)，能夠對可行性研究報告與初步設計階段報告進行協(xié)同編制，幫助項目展開基礎工作。可行性研究、初步設計階段報告協(xié)同編制系統(tǒng)的設計背景為在項目的前期準備與實施階段，對項目的初步設計與實施方案進行編制，使項目計劃具備可操作性，幫助項目進行項目監(jiān)理與工程招標[1]。當前國內外都在積極開展可研、初設報告協(xié)同編制系統(tǒng)的研究與設計。國外由于相關研究的開展較早，因此研究開展的較為深入，主要針對可行性研究、初步設計階段報告的智能調研進行研究，有學者提出一種基于Apache POI的可研、初設報告協(xié)同編制系統(tǒng)，主要通過Apache POI這種Java API對可行性研究、初步設計階段報告進行讀取、創(chuàng)建以及跨平臺編制[2]。國內對于可研、初設報告協(xié)同編制系統(tǒng)的研究與設計則起步較晚，因此系統(tǒng)開發(fā)的相關技術仍然不夠成熟，但在可行性研究、初步設計階段報告的協(xié)同方面已經(jīng)取得很大成績，主要通過協(xié)同技術對項目的創(chuàng)建與設計進行協(xié)同[3]。有學者提出一種基于XML技術的可研、初設報告協(xié)同編制系統(tǒng)，主要通過XML技術進行可行性研究、初步設計階段報告的結構化數(shù)據(jù)讀寫從而對其進行協(xié)同編制；還有學者提出一種基于iText技術的可研、初設報告協(xié)同編制系統(tǒng)，主要通過iText技術實現(xiàn)可行性研究、初步設計階段報告的報表處理與pdf公文動態(tài)生成，該系統(tǒng)能夠提供格式化的pdf文件拼接功能從而對可行性研究、初步設計階段報告進行協(xié)同編制[4]。針對以上系統(tǒng)受硬件協(xié)同性較差的影響，存在無法分解的協(xié)同任務，在可研、初設報告項目數(shù)據(jù)為5-20M時存在數(shù)據(jù)錄入速度過低的問題，研究一種新的可研、初設報告協(xié)同編制系統(tǒng)。

1 設計可研及初設報告協(xié)同編制系統(tǒng)

1.1 設計硬件

可研、初設報告協(xié)同編制系統(tǒng)的硬件構成為協(xié)同任務分解模塊。協(xié)同任務分解模塊是基于C/S結構設計的，主要由多個客戶機與服務器構成，模塊能夠將可行性研究、初步設計階段報告分解成多個子任務，由多臺服務器分別對各子任務進行執(zhí)行，實現(xiàn)協(xié)同任務的分解[5]。

協(xié)同任務分解模塊的處理模式為客戶機發(fā)出請求-服務器進行響應，也就是通過客戶機提出可行性研究報告與初步設計階段報告的數(shù)據(jù)或應用處理請求，再由服務器對請求進行處理，并將狀態(tài)信息與處理結果返還至客戶機。在協(xié)同任務分解過程中，負載由服務器與客戶機共同承擔，能夠實現(xiàn)可行性研究報告與初步設計階段報告數(shù)據(jù)的分布式計算[6]。在協(xié)同任務分解模塊中，客戶機的業(yè)務能力是獨立的，當服務器與客戶機的連接斷開后，客戶機仍然可以再離線狀態(tài)下獨立運行，通過單機模式進行子任務的執(zhí)行。

協(xié)同任務分解模塊的架構為集中式架構，數(shù)據(jù)主要在服務器端存放，能夠集中進行可行性研究報告與初步設計階段報告的數(shù)據(jù)共享。在協(xié)同任務分解模塊中，服務器的功能具體如表1所示。

表1 服務器功能

客戶機的功能具體如表2所示。

表2 客戶機功能

1.2 設計軟件

可研、初設報告協(xié)同編制系統(tǒng)的軟件構成包括數(shù)據(jù)交互模塊、數(shù)據(jù)管理模塊、可研、初設報告編制模塊、數(shù)據(jù)庫模塊。

1.2.1 設計數(shù)據(jù)交互模塊

數(shù)據(jù)交互模塊主要通過JSON進行可行性研究、初步設計階段報告數(shù)據(jù)的交互。JSON是一種數(shù)據(jù)交換輕量級格式，具備較少冗余數(shù)據(jù)、易讀的特點。通過JSON進行可行性研究、初步設計階段報告數(shù)據(jù)交互時不需要其他API工具，可以直接對某組可行性研究、初步設計階段報告數(shù)據(jù)進行字符串轉換，并在各函數(shù)之間對轉換的字符串進行輕松的傳遞，以及將轉換的字符串上傳至服務端程序，從而實現(xiàn)可行性研究、初步設計階段報告數(shù)據(jù)的交互[7]。

1.2.2 設計數(shù)據(jù)管理模塊

通過數(shù)據(jù)管理模塊能夠對可行性研究報告與初步設計階段報告的編制數(shù)據(jù)進行管理，模塊的具體構成如圖1所示。

圖1 數(shù)據(jù)管理模塊的具體構成

其中，項目計劃及技術資料管理單元主要負責針對項目的計劃及技術資料進行數(shù)據(jù)庫構建與管理。該單元還可以對相關日志進行保存和備份，以及根據(jù)用途與編制日期對新數(shù)據(jù)進行錄入、對老數(shù)據(jù)進行修改；報告參數(shù)生成單元主要負責根據(jù)項目數(shù)據(jù)收集單元獲取數(shù)據(jù)對可行性研究、初步設計階段報告所需的項目參數(shù)進行計算與生成；項目數(shù)據(jù)收集單元主要負責對于可行性研究、初步設計階段報告所需的項目數(shù)據(jù)進行收集，包括項目的創(chuàng)建與設計數(shù)據(jù)；報告數(shù)據(jù)導出單元主要負責對可行性研究、初步設計階段報告的數(shù)據(jù)進行導出，導出數(shù)據(jù)類型包括Excel、GIS、CAD等；報告數(shù)據(jù)錄入及修改單元主要負責對報告中涉及的項目數(shù)據(jù)進行核實，從而對其進行錄入與修改；數(shù)據(jù)查詢單元主要負責對項目的業(yè)務數(shù)據(jù)、個性化數(shù)據(jù)以及統(tǒng)計數(shù)據(jù)進行查詢；報告數(shù)據(jù)合并及整理單元主要負責進行對報告相關的各種項目數(shù)據(jù)庫進行合并與數(shù)據(jù)更新；項目數(shù)據(jù)分解單元主要負責對報告相關的各種項目數(shù)據(jù)進行細致的分解，包括可行性研究報告的項目數(shù)據(jù)分解與初步設計階段報告的項目數(shù)據(jù)分解[8]。

1.2.3 設計可研及初設報告編制模塊

可研、初設報告編制模塊主要負責根據(jù)其他模塊提供的資料進行可行性研究報告與初步設計階段報告的編制，該模塊的構成為準備項目技術資料單元、可行性研究報告與初步設計階段報告生成單元、可行性研究報告與初步設計階段報告編制單元[9]。

其中，準備項目技術資料單元的功能及內容構成，具體如表3所示。

表3 準備項目技術資料單元的功能及內容構成

可行性研究報告與初步設計階段報告生成單元的功能及內容構成具體如表4所示。

表4 報告生成單元的功能及內容構成

可行性研究報告與初步設計階段報告編制單元的功能及內容構成具體如表5所示。

表5 報告編制單元的功能及內容構成

1.2.4 設計報告項目拓撲排序模塊

在可行性研究報告與初步設計階段報告的編制中，需要對項目的子項目進行拓撲排序，通過報告項目拓撲排序模塊能夠獲取一個開展子項目的拓撲序列，以保障各子項目能夠互不沖突的開展，從而使報告更具合理性[10]。報告項目拓撲排序模塊主要通過拓撲排序算法進行子項目的拓撲排序，算法的排序流程具體如圖2所示。

圖2 算法的排序流程

對于有n個子項目與e對項目關系的大項目而言，其拓撲排序的空間復雜度如式(1)。

P=O(n+e)

(1)

其中，P表示大項目拓撲排序的空間復雜度；O表示先進行某子項目的復雜度。

拓撲排序的時間復雜度則如式(2)。

G=O(nlogn+e)

(2)

數(shù)據(jù)庫模塊的構成為項目資料表、報告資料表、項目預算表。綜上所述，設計的可研、初設報告協(xié)同編制系統(tǒng)硬件組成包括協(xié)同任務分解模塊，軟件構成包括數(shù)據(jù)交互模塊、數(shù)據(jù)管理模塊、可研、初設報告編制模塊、數(shù)據(jù)庫模塊。

2 實驗驗證

2.1 實驗設計

對設計的可研、初設報告協(xié)同編制系統(tǒng)進行實驗驗證。實驗項目為某建筑項目，利用設計的可研、初設報告協(xié)同編制系統(tǒng)對該項目編制。實驗項目的具體數(shù)據(jù)如表6所示。

表6 實驗項目的具體數(shù)據(jù)

項目平面圖如圖3所示。

圖3 建筑項目平面圖

其中，項目資料表具體如表7所示。

表7 項目資料表

報告資料表具體如表8所示。

表8 報告資料表

項目預算表具體如表9所示。

表9 項目預算表

2.2 數(shù)據(jù)錄入速度實驗結果分析

為了避免本次實驗結果過于單一，缺乏對比性，將原有系統(tǒng)作為本次實驗中的對比系統(tǒng)，包括基于Apache POI、基于XML技術、基于iText技術的可研、初設報告協(xié)同編制系統(tǒng)。

對比實驗系統(tǒng)在可研、初設報告項目數(shù)據(jù)為5-10M時的數(shù)據(jù)錄入速度實驗結果具體如圖4所示。

圖4 5-10M時的數(shù)據(jù)錄入速度實驗結果

根據(jù)圖4中可研、初設報告項目數(shù)據(jù)為5-10M時的數(shù)據(jù)錄入速度實驗結果可知，設計的可研、初設報告協(xié)同編制系統(tǒng)的數(shù)據(jù)錄入速度可達230.04 s，在可研、初設報告項目數(shù)據(jù)為5-10M時，設計的可研、初設報告協(xié)同編制系統(tǒng)的數(shù)據(jù)錄入速度在幾種實驗系統(tǒng)中最快。

對比實驗系統(tǒng)在可研、初設報告項目數(shù)據(jù)為10-15M時的數(shù)據(jù)錄入速度，實驗結果如圖5所示。

圖5 10-15M時的數(shù)據(jù)錄入速度實驗結果

根據(jù)圖5中可研、初設報告項目數(shù)據(jù)為10-15M時的數(shù)據(jù)錄入速度實驗結果可知，設計的可研、初設報告協(xié)同編制系統(tǒng)的數(shù)據(jù)錄入速度可達254.69 s，在可研、初設報告項目數(shù)據(jù)為10-15M時，設計的可研、初設報告協(xié)同編制系統(tǒng)的數(shù)據(jù)錄入速度在幾種實驗系統(tǒng)中保持最快。

對比實驗系統(tǒng)在可研、初設報告項目數(shù)據(jù)為15-20M時的數(shù)據(jù)錄入速度實驗結果具體如圖6所示。

根據(jù)圖6中可研、初設報告項目數(shù)據(jù)為15-20M時的數(shù)據(jù)錄入速度實驗結果可知，設計的可研、初設報告協(xié)同編制系統(tǒng)的數(shù)據(jù)錄入速度可達283.68 s，在可研、初設報告項目數(shù)據(jù)為15-20M時，設計的可研、初設報告協(xié)同編制系統(tǒng)的數(shù)據(jù)錄入速度在幾種實驗系統(tǒng)中保持最快。

圖6 15-20M時的數(shù)據(jù)錄入速度實驗結果

綜上所述，不同報告項目數(shù)據(jù)下，本文系統(tǒng)的錄入速度均最快，主要原因在于本系統(tǒng)的硬件構成為協(xié)同任務分解模塊，解決了原有系統(tǒng)受硬件協(xié)同性較差的影響，存在無法分解的協(xié)同任務，導致數(shù)據(jù)錄入速度過低的問題，提高了錄入速度。

在實際的網(wǎng)絡通信和數(shù)字信號處理系統(tǒng)中，由于通信帶寬是有限的，因此，信號在傳輸之前都要經(jīng)過量化，使用量化器對狀態(tài)信號和控制輸入信號進行量化，編制系統(tǒng)穩(wěn)定性曲線如圖7所示。

圖7 系統(tǒng)穩(wěn)定性測試

由圖7可以看出，當網(wǎng)絡加入動態(tài)量化器后，系統(tǒng)的性能有所提高，也說明了本文給出的控制器設計方法的有效性，系統(tǒng)在本文控制器作用下可以保證漸進穩(wěn)定。

為測試系統(tǒng)安全性能，設置已知漏洞，對系統(tǒng)檢測能力進行測試，采用了以Linux-3.1.2內核為基礎的Cent OS 6.4為測試的運行操作系統(tǒng),如圖8所示。

由圖8可以看出，掃描出了8 個已知漏洞，證明系統(tǒng)安全性良好。主要原因在于本文系統(tǒng)硬件構成為協(xié)同任務分解模塊，解決了原有系統(tǒng)受硬件協(xié)同性較差的影響，存在無法分解的協(xié)同任務，導致數(shù)據(jù)錄入速度過低的問題，保證了系統(tǒng)穩(wěn)定性，可及時發(fā)現(xiàn)系統(tǒng)漏洞。

圖8 系統(tǒng)安全性測試

綜上所述，設計的可研、初設報告協(xié)同編制系統(tǒng)在幾種實驗系統(tǒng)中數(shù)據(jù)錄入速度始終保持最快，且系統(tǒng)的穩(wěn)定性與安全性較強。

3 總結

本文提出可研、初設報告協(xié)同編制系統(tǒng)，基于C/S結構設計協(xié)同任務分解模塊，軟件構成包括數(shù)據(jù)交互模塊、數(shù)據(jù)管理模塊、可研、初設報告編制模塊、數(shù)據(jù)庫模塊，通過JSON設計數(shù)據(jù)交互模塊，該系統(tǒng)實現(xiàn)了數(shù)據(jù)錄入速度的提升，對于各種項目的后期展開都有很大意義。