姚經(jīng)緯　冷文浩

摘要摘要：飛行器總體設(shè)計是多學(xué)科相互協(xié)作、反復(fù)迭代的動態(tài)過程，現(xiàn)今很多軟件和系統(tǒng)在多專業(yè)協(xié)同以及設(shè)計過程動態(tài)表達上還有所欠缺。為此，設(shè)計并開發(fā)了一套全新的主模型管理系統(tǒng)，該系統(tǒng)實現(xiàn)了對設(shè)計過程中與主模型相關(guān)的數(shù)據(jù)、版本、譜系等要素的管理功能，通過版本和技術(shù)狀態(tài)的變化，追蹤并反饋整個設(shè)計過程中的各種動態(tài)變化。系統(tǒng)采用Redis內(nèi)存數(shù)據(jù)庫實現(xiàn)數(shù)據(jù)的存儲，具有存儲簡便、效率高等優(yōu)點；在復(fù)雜業(yè)務(wù)的處理上探索了使用事件的方式實現(xiàn)各子模塊的解耦。詳細探討了系統(tǒng)總體設(shè)計思路和過程，同時對系統(tǒng)的實現(xiàn)進行了簡要闡述，為類似系統(tǒng)的設(shè)計提供參考與借鑒作用。

關(guān)鍵詞關(guān)鍵詞：主模型；版本管理；數(shù)據(jù)譜系；Redis

DOIDOI：10.11907/rjdk.171033

中圖分類號：TP319

文獻標識碼：A文章編號文章編號：16727800（2017）005007505

0引言

飛行器總體設(shè)計綜合了總體、氣動、飛行力學(xué)、推進、控制及結(jié)構(gòu)等子系統(tǒng)專業(yè)的知識與成果，是一個按照特定程序交叉、反復(fù)迭代的過程。為了使型號的整體性能最優(yōu)、成本最低、研制周期最短，總體集成化設(shè)計模式是其發(fā)展的必然趨勢和迫切需求。總體集成設(shè)計對提高飛行器設(shè)計質(zhì)量、降低研制成本、縮短研制周期具有重要意義[1]。

早期型號設(shè)計軟件大都針對某特定的型號，采用結(jié)構(gòu)化形式組織學(xué)科執(zhí)行模塊，以固化的數(shù)據(jù)結(jié)構(gòu)表達總體方案，因而設(shè)計流程和數(shù)據(jù)接口基本固定，擴展性較差，僅適用于少量方案的參數(shù)設(shè)計和對比評估[2]。近年來，隨著飛行器領(lǐng)域信息化的不斷發(fā)展，出現(xiàn)了基于高擬真度模型的軟件工具，如Sim SAC開發(fā)的基于物理分析的設(shè)計平臺CEASIOM，以及NASA開發(fā)的高擬真度MDO設(shè)計與優(yōu)化工具Open MDAO等[34]。這類軟件具有一定的多學(xué)科集成、數(shù)據(jù)管理和分析優(yōu)化功能，但是仍然無法表達由于多種方案設(shè)計需求引起的設(shè)計過程動態(tài)性。為此，急需建立一套完整的總體協(xié)同設(shè)計環(huán)境，具備多種方案設(shè)計和選型的能力，能夠較好地反映設(shè)計過程中的動態(tài)變化，從而提高總體設(shè)計的效率和質(zhì)量。

基于飛行器總體設(shè)計智能主模型的研究成果和標準規(guī)范，結(jié)合當前飛行器總體設(shè)計過程中工具軟件的使用情況及存在的不足，針對總體設(shè)計對模型及數(shù)據(jù)管理方面的需求，設(shè)計并開發(fā)了一套更加符合總體設(shè)計過程的主模型管理系統(tǒng)，實現(xiàn)了設(shè)計過程中對與主模型相關(guān)的數(shù)據(jù)、版本、譜系等進行管理的功能。該系統(tǒng)能夠在整個設(shè)計過程中將各種動態(tài)變化及時反饋到各子系統(tǒng)的設(shè)計修改過程之中，為多領(lǐng)域、多專業(yè)的協(xié)同設(shè)計過程提供支撐。

1相關(guān)技術(shù)

1.1數(shù)據(jù)處理

協(xié)同數(shù)據(jù)區(qū)：協(xié)同數(shù)據(jù)區(qū)對應(yīng)一個型號項目，內(nèi)容包括型號的基本信息、項目團隊、下級目錄，一個數(shù)據(jù)區(qū)一般包含不同設(shè)計階段的多個主模型。

主模型：主模型對應(yīng)一個型號方案，內(nèi)容包括基本信息、下級目錄、譜系關(guān)系、專業(yè)角色，一個主模型一般包含多個數(shù)據(jù)包。

專業(yè)數(shù)據(jù)包：專業(yè)數(shù)據(jù)包對應(yīng)一套相關(guān)專業(yè)數(shù)據(jù)文件，內(nèi)容包括目錄、文件、所屬專業(yè)。一個專業(yè)有多個數(shù)據(jù)包，數(shù)據(jù)包不允許跨專業(yè)。

數(shù)據(jù)項：數(shù)據(jù)包中的一項數(shù)據(jù)內(nèi)容，是版本管理的最小粒度，一個數(shù)據(jù)項對應(yīng)一個數(shù)據(jù)文件，文件類型可以是文本、圖片、報告、表格等。

譜系關(guān)系：譜系關(guān)系是指專業(yè)數(shù)據(jù)包的上下游關(guān)系，其是協(xié)同設(shè)計的依據(jù)，主模型通過譜系關(guān)系驅(qū)動設(shè)計活動。一個主模型對應(yīng)一套譜系關(guān)系，譜系不允許跨主模型。

1.2Redis內(nèi)存數(shù)據(jù)庫

Redis是一種基于內(nèi)存的NoSQL數(shù)據(jù)庫產(chǎn)品，由遠程字典服務(wù)（REmote DIctionary Server）取名而來。它支持多種數(shù)據(jù)類型的存儲：字符串（string）、鏈表（list）、集合（set）、有序集合（zset）和哈希類型（hash），并且各種類型都支持豐富的操作，其中大多都支持原子操作。為了保證數(shù)據(jù)存取的效率，數(shù)據(jù)都是保存在內(nèi)存中；Redis還提供了對持久化的支持，可以定期將更新的數(shù)據(jù)異步寫入磁盤，同時不影響繼續(xù)提供服務(wù)；此外，還可以使用集群的形式對Redis進行水平擴容，實現(xiàn)大規(guī)模數(shù)據(jù)存儲[5]。根據(jù)Redis官方測試數(shù)據(jù)，Redis寫入速率為198 412.69條/s，讀速率為198 019.80條/s[6]。Redis具有如此之多的優(yōu)秀特性，這使得它從一開始就受到了廣泛關(guān)注，Redis可以適用于多種不同的應(yīng)用場景，很多大型互聯(lián)網(wǎng)企業(yè)的后臺服務(wù)中都在使用Redis，有不少成功應(yīng)用的范例。

1.3Spring與事件模型

Spring是Web開發(fā)中常用的一個開源框架，它采用分層的架構(gòu)形式，使得開發(fā)者可以根據(jù)需要選擇使用哪些組件。它所具備的控制反轉(zhuǎn)技術(shù)促進了應(yīng)用的低耦合，而面向切面的編程方式則能通過分離業(yè)務(wù)邏輯與事務(wù)從而實現(xiàn)內(nèi)聚性開發(fā)。Spring的使用大大簡化了企業(yè)應(yīng)用的開發(fā)，降低了成本，因此在現(xiàn)今的Web開發(fā)中得到了廣泛應(yīng)用[7]。

Spring中的ApplicationContext提供了容器內(nèi)部事件的發(fā)布功能，它基于觀察者模式實現(xiàn)，當某事件觸發(fā)時，所有注冊了該事件的監(jiān)聽器將收到消息并進行事件處理。事件模型通過ApplicationEvent類和ApplicationListener接口提供編程接口。使用事件模型時，首先通過繼承ApplicationEvent定義事件；然后定義事件相關(guān)的事件參數(shù)；最后通過實現(xiàn)ApplicationListener接口定義相關(guān)的監(jiān)聽器，完成后即可使用ApplicationContext中的publishEvent方法發(fā)布事件并進行事件的相關(guān)處理[8]。

2系統(tǒng)總體設(shè)計

系統(tǒng)與外部的交互如圖2所示，主模型管理系統(tǒng)在整個系統(tǒng)中處于核心地位，它配合主模型建模工具、專業(yè)客戶端等工具，為設(shè)計師提供一個基于主模型的高效協(xié)同工作環(huán)境。系統(tǒng)采用B/S和C/S模式相結(jié)合的形式，這樣可以取長補短，充分發(fā)揮兩者各自的優(yōu)勢[9]。服務(wù)器端采用Web應(yīng)用中最流行的三層架構(gòu)形式實現(xiàn)，使用了Redis、Spring、Activiti等技術(shù)，為瀏覽器端、主模型建模工具和專業(yè)客戶端提供數(shù)據(jù)的存儲和訪問等相關(guān)服務(wù)。瀏覽器端使用ExtJS開發(fā)，具有除數(shù)據(jù)包同步、提交功能外的系統(tǒng)的大部分功能，可以滿足專業(yè)設(shè)計人員日常數(shù)據(jù)瀏覽、審批等各項需求。主模型建模工具和專業(yè)客戶端均使用C/S架構(gòu)的形式實現(xiàn)，主模型建模工具負責(zé)主模型結(jié)構(gòu)的設(shè)計和主模型的導(dǎo)入；專業(yè)客戶端主要負責(zé)主模型的訪問和數(shù)據(jù)包的同步，兩者均通過WebService接口與系統(tǒng)交互。

主模型管理系統(tǒng)模塊設(shè)計圖如圖3所示，包括七大功能模塊：①數(shù)據(jù)區(qū)管理：提供對協(xié)同數(shù)據(jù)區(qū)的管理和控制功能；②版本管理：提供基礎(chǔ)文件、目錄的存儲和版本管理功能；③主模型管理：提供針對主模型、數(shù)據(jù)包和譜系的管理功能；④數(shù)據(jù)譜系管理：提供譜系追蹤、技術(shù)狀態(tài)變更通知和一致性檢查等功能；⑤數(shù)據(jù)應(yīng)用：提供基本的數(shù)據(jù)查詢、瀏覽和統(tǒng)計功能；⑥系統(tǒng)管理：提供基本的用戶、權(quán)限、日志、備份、恢復(fù)等功能；⑦開放式數(shù)據(jù)接口：基于WebService接口提供對數(shù)據(jù)區(qū)和主模型數(shù)據(jù)的訪問功能。

其中，版本管理和數(shù)據(jù)譜系管理是系統(tǒng)中最重要也是最復(fù)雜的兩個功能模塊，故下面的章節(jié)將詳細介紹這兩個功能的設(shè)計。

3版本管理模塊設(shè)計

版本控制是系統(tǒng)的關(guān)鍵功能，為了滿足主模型版本管理和譜系追蹤的要求，參考了SVN版本控制的概念和原理，實現(xiàn)了版本信息的存儲和記錄、本地數(shù)據(jù)與遠程數(shù)據(jù)的同步、歷史版本的追溯等功能[1011]。

在設(shè)計版本管理模塊時，通過抽象的節(jié)點建立數(shù)據(jù)之間的邏輯結(jié)構(gòu)，并基于節(jié)點實現(xiàn)通用的版本控制功能，節(jié)點可以關(guān)聯(lián)目錄和文件。在主模型模式下，還可以擴展為數(shù)據(jù)區(qū)、主模型、數(shù)據(jù)包、數(shù)據(jù)項。即使主模型的結(jié)構(gòu)發(fā)生變化，通過抽象的節(jié)點也能夠靈活適應(yīng)。

數(shù)據(jù)庫結(jié)構(gòu)設(shè)計是Web開發(fā)中的重要環(huán)節(jié)，數(shù)據(jù)庫結(jié)構(gòu)設(shè)計的好壞會直接影響到后續(xù)設(shè)計和開發(fā)工作。因為系統(tǒng)中存在較多樹狀和圖狀結(jié)構(gòu)，如版本控制中的目錄結(jié)構(gòu)、數(shù)據(jù)譜系中的譜系結(jié)構(gòu)；對于這些結(jié)構(gòu)的存儲，如果采用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫按行存儲，并使用外鍵的方式形式表示結(jié)構(gòu)中的前驅(qū)和后繼關(guān)系，那么在整個結(jié)構(gòu)展現(xiàn)時就需要對結(jié)構(gòu)進行遞歸遍歷，從而導(dǎo)致過多的數(shù)據(jù)庫查詢操作，而傳統(tǒng)關(guān)系型數(shù)據(jù)庫的查詢效率普遍較低，因此會拖慢系統(tǒng)的整體響應(yīng)速度，影響用戶體驗[12]。因此，采用當下比較流行的NoSQL數(shù)據(jù)庫——Redis進行應(yīng)用數(shù)據(jù)的存儲，它不僅可以實現(xiàn)對數(shù)據(jù)的快速存取操作，而且比關(guān)系型數(shù)據(jù)庫更加適合樹狀和圖狀結(jié)構(gòu)數(shù)據(jù)的存儲。

在版本管理相關(guān)的庫結(jié)構(gòu)設(shè)計中，采用鍵值對的形式將數(shù)據(jù)保存在Redis中，主要結(jié)構(gòu)及描述如表1所示，為了簡單起見，表中屬性只保留與版本相關(guān)部分，其它與業(yè)務(wù)相關(guān)的屬性不再列出。

基于以上的庫結(jié)構(gòu)設(shè)計，抽象出一個節(jié)點類Node，它包含id、name、version、type、children等基本屬性，文件夾、文件、數(shù)據(jù)區(qū)、主模型、數(shù)據(jù)包等類型則繼承Node類，其他屬性可以根據(jù)需要進行擴展。為了簡化Redis中的存儲、讀取和轉(zhuǎn)換等操作，引入了Spring Data Redis實現(xiàn)對Redis中的JSON數(shù)據(jù)和Java Bean之間的序列化和反序列化[13]。

版本庫的基本操作有提交、合并、回滾等，這些操作的邏輯均較復(fù)雜，若采用通常使用的基于方法調(diào)用的形式實現(xiàn)這些基本操作，則勢必使得各子方法間耦合性較強，因此采用基于Spring事件模型的方式實現(xiàn)這些基本操作。本文以提交操作為例，簡單介紹如何使用事件模型的形式實現(xiàn)版本提交功能。

提交操作包括文件夾、文件、數(shù)據(jù)區(qū)、主模型、數(shù)據(jù)包等多種類型的新增、修改、刪除的混合操作，因此提交操作中相關(guān)事件監(jiān)聽器按照初始化、節(jié)點變更、擴展類型操作、保存操作歷史、事件后處理這5種類型進行組織。

（1）初始化：對事件初始化參數(shù)進行配置，包括版本號生成，新增節(jié)點ID分配以及節(jié)點增刪改的具體配置；

（2）節(jié)點變更：對通用節(jié)點類型進行變更操作，包括總體結(jié)構(gòu)變更，節(jié)點增刪改的處理，父節(jié)點版本提升等操作；

（3）擴展類型操作：對增刪改具體類型的操作，包括新版本詳細信息的創(chuàng)建與屬性設(shè)置，比如對文件來說，需要保存文件的實際路徑和計算文件的MD5值；

（4）保存操作歷史：保存用戶本次提交操作的詳細信息，包括備注和本次有改變的節(jié)點信息；

（5）事件后處理：提交操作完成之后的后處理，包括消息的發(fā)送，送審等操作。

以上5種類型的監(jiān)聽器可以根據(jù)需要分解成更為具體的監(jiān)聽器，以進一步細化各步操作。

4數(shù)據(jù)譜系管理模塊設(shè)計

數(shù)據(jù)譜系定義了數(shù)據(jù)包間的依賴關(guān)系，在飛行器總體設(shè)計過程中，各專業(yè)間的協(xié)作關(guān)系可以通過該專業(yè)數(shù)據(jù)包與其它專業(yè)數(shù)據(jù)包間的數(shù)據(jù)依賴關(guān)系所確定；因為依賴關(guān)系中不可能出現(xiàn)循環(huán)依賴，所以數(shù)據(jù)譜系的關(guān)系實際上就是一個有向無環(huán)圖模型；根據(jù)專業(yè)協(xié)作關(guān)系，當一個專業(yè)數(shù)據(jù)包所依賴的上游數(shù)據(jù)包工作全部完成時，它才可以開展它自身的工作。因此可以通過數(shù)據(jù)流的狀態(tài)反映協(xié)同工作的完成情況，并以此為基礎(chǔ)實現(xiàn)譜系的追蹤和技術(shù)狀態(tài)的變更。

為了表示設(shè)計過程中數(shù)據(jù)包節(jié)點的工作狀態(tài)，定義了最新、待更新、已過時3種技術(shù)狀態(tài)，它們依次表示工作完成、工作進行中和工作未開始這3種工作狀態(tài)；依據(jù)這3種技術(shù)狀態(tài)，可以對設(shè)計的總體過程進行追蹤。技術(shù)狀態(tài)的更新由系統(tǒng)根據(jù)譜系關(guān)系和數(shù)據(jù)包的依賴關(guān)系進行技術(shù)狀態(tài)分析以確定數(shù)據(jù)包的技術(shù)狀態(tài)，技術(shù)狀態(tài)分析規(guī)則如下：

最新：上游數(shù)據(jù)都為最新，并且當前依賴的上游版本也是最新有效的。

待更新：上游數(shù)據(jù)包都為最新，但當前依賴的上游版本不是最新有效。

已過時：上游數(shù)據(jù)包中存在已過時或待更新的數(shù)據(jù)包。

在設(shè)計數(shù)據(jù)譜系管理模塊時，考慮到要能夠?qū)Ω鲾?shù)據(jù)包技術(shù)狀態(tài)的變化進行追蹤，因此在每次技術(shù)狀態(tài)分析時需要記錄當前主模型下所有數(shù)據(jù)包的技術(shù)狀態(tài)；同時考慮到可能的數(shù)據(jù)譜系關(guān)系變更，需要在每次譜系關(guān)系變更時記錄當前主模型的數(shù)據(jù)譜系關(guān)系。設(shè)計時，將譜系管理、技術(shù)狀態(tài)分析模塊從版本管理模塊中獨立出來，這樣既減小了兩相關(guān)模塊間的耦合，同時也減少了技術(shù)狀態(tài)分析過程中不必要的版本比較，從而減小了技術(shù)狀態(tài)分析的時間復(fù)雜度。為了便于譜系的展現(xiàn)和技術(shù)狀態(tài)的分析，采用如下的庫結(jié)構(gòu)設(shè)計，具體結(jié)構(gòu)和描述如表2所示。

基于以上庫結(jié)構(gòu)設(shè)計，使用master_model_info和data_pack_info分別記錄主模型譜系關(guān)系和數(shù)據(jù)包狀態(tài)信息。在進行技術(shù)狀態(tài)分析時，首先從master_model_info中獲取對應(yīng)版本主模型中數(shù)據(jù)包的譜系關(guān)系，然后獲取需要分析的數(shù)據(jù)包的狀態(tài)信息，按照以下規(guī)則對該數(shù)據(jù)包的技術(shù)狀態(tài)進行分析：

（1）上游已完成數(shù)據(jù)包數(shù)小于入度（precursor_newest < in_degree）時，表明該數(shù)據(jù)包上游數(shù)據(jù)包不全是最新狀態(tài)，故該數(shù)據(jù)包的技術(shù)狀態(tài)應(yīng)為已過時；

（2）上游已完成數(shù)據(jù)包數(shù)等于入度（precursor_newest = in_degree）時，表明該數(shù)據(jù)包上游數(shù)據(jù)包已全部是最新狀態(tài)，此時若有：①數(shù)據(jù)包依賴的上游數(shù)據(jù)包不全是最新的，表明該數(shù)據(jù)包在當前主模型中沒有進行提交操作，故其技術(shù)狀態(tài)應(yīng)為待更新；②數(shù)據(jù)包依賴的上游數(shù)據(jù)包均為最新，表明該數(shù)據(jù)包在當前主模型中進行了提交操作，故其技術(shù)狀態(tài)應(yīng)為最新。

（3）按上述規(guī)則對當前數(shù)據(jù)包進行分析后，若當前數(shù)據(jù)包技術(shù)狀態(tài)有改變，則按如下規(guī)則對其直接下游狀態(tài)信息進行變更：①當前數(shù)據(jù)包節(jié)點技術(shù)狀態(tài)由其他狀態(tài)變?yōu)樽钚拢瑒t其直接下游屬性precursor_newest進行加一操作；②當前數(shù)據(jù)包節(jié)點技術(shù)狀態(tài)由最新變?yōu)槠渌麪顟B(tài)，則其直接下游屬性precursor_newest進行減一操作。

（4）按上述規(guī)則遞歸地對當前數(shù)據(jù)包的下游數(shù)據(jù)包進行技術(shù)狀態(tài)分析。

從上述分析規(guī)則中可以看出，在數(shù)據(jù)包狀態(tài)信息中增加屬性precursor_newest的意義所在。對當前數(shù)據(jù)包進行技術(shù)狀態(tài)分析時，可以直接根據(jù)in_degree與precursor_newest的關(guān)系確定所有上游數(shù)據(jù)包的完成狀態(tài)；而不需要對所有上游數(shù)據(jù)包進行遍歷再得出所有上游數(shù)據(jù)包的完成狀態(tài)。因此，該方法可以在很大程度上減少對上游節(jié)點的重復(fù)遍歷，降低技術(shù)狀態(tài)分析的時間復(fù)雜度。

5應(yīng)用架構(gòu)及分析

主模型管理系統(tǒng)的應(yīng)用架構(gòu)如圖4所示，系統(tǒng)總體上采用三層架構(gòu)的形式實現(xiàn)。請求控制層用來處理用戶的請求，包括瀏覽器發(fā)出的Http請求和客戶端發(fā)出的Web Service請求；業(yè)務(wù)邏輯層用來對簡單業(yè)務(wù)進行處理，同時也對相關(guān)事務(wù)進行的控制；數(shù)據(jù)訪問層實現(xiàn)對數(shù)據(jù)存儲和訪問，包括存儲在Redis中的數(shù)據(jù)和存儲在文件服務(wù)器中的文件。由于版本管理模塊和數(shù)據(jù)譜系管理模塊的業(yè)務(wù)邏輯都比較復(fù)雜，如果直接在業(yè)務(wù)邏輯層實現(xiàn)則會導(dǎo)致模塊的耦合性較強，代碼不易維護等缺點；故將這兩個復(fù)雜模塊分解成多個小模塊，各小模塊邏輯在業(yè)務(wù)邏輯層實現(xiàn)，再使用事件模型的方式將這些小的模塊整合到一起，使得系統(tǒng)的耦合性有所降低。

6結(jié)語

為解決飛行器總體設(shè)計過程中多專業(yè)協(xié)同以及過程的動態(tài)性表達問題，設(shè)計并開發(fā)了一套基于Redis的主模型管理系統(tǒng)，系統(tǒng)使用簡單高效的Redis內(nèi)存數(shù)據(jù)庫進行數(shù)據(jù)存儲，并對使用事件的方式降低各子模塊的耦合性進行了探索。本文對系統(tǒng)設(shè)計與開發(fā)過程中的關(guān)鍵技術(shù)進行了介紹和討論，并分別就版本管理和數(shù)據(jù)譜系管理這兩大功能模塊的設(shè)計過程進行了詳細介紹，為今后類似系統(tǒng)的設(shè)計提供參考與借鑒作用。

參考文獻參考文獻：

[1]孫建勛，張立強等.飛行器總體多學(xué)科集成設(shè)計平臺[J].計算機集成制造系統(tǒng)，2012，18（1）： 18.

[2]梅小寧，楊樹興.復(fù)雜系統(tǒng)的多學(xué)科設(shè)計優(yōu)化綜述[J].工程設(shè)計學(xué)報，2010，17（3）： 173185.

[3]PESTER M.Multidisciplinary conceptual aircraft design using CEASIOM[D].Hamburg： Hochschule für Angewandte Wissenschaften Hamburg，2010.

[4]CHRISTOPHER M， HEATH，JUSTIN S GRAY.OpenMDAO： framework for flexible multidisciplinary design，analysis and optimization methods[C].Reston，Va.，USA： AIAA，2012.

[5]Redis[EB/OL].http：//redis.io.

[6]How fast is Redis[EB/OL].http：//redis.io/topics/benchmarks.

[7]翟劍錕.Spring框架技術(shù)分析及應(yīng)用研究[D].北京： 中國科學(xué)院大學(xué)，2013.

[8]Spring framework reference documentation[EB/OL].http：//docs.spring.io/spring/docs/4.3.6.BUILDSNAPSHOT/springframeworkreference/htmlsingle.

[9]孫達凱，鮑勁松.大型企業(yè)中B/S構(gòu)架和C/S構(gòu)架平臺的研究[J].科學(xué)家，2015（11）：3339.

[10]Apache Subversion[EB/OL].http：//subversion.apache.org.

[11]侯秋菊.開源軟件SVN庫中提交行為的特性研究[D].武漢：武漢科技大學(xué)，2015.

[12]權(quán)治，宋晶晶.基于NoSQL的數(shù)據(jù)庫技術(shù)分析[J].無線電工程，2013，43（9）： 427.

[13]Spring data redis[EB/OL].http：//projects.spring.io/springdataredis.

責(zé)任編輯（責(zé)任編輯：陳福時）