一種自適應數(shù)據(jù)交易軟件模型設(shè)計技術(shù)

湯奇峰， 虞慧群， 范貴生， 邵志清

（1.華東理工大學計算機科學與工程系, 上海 200237；2.上海數(shù)據(jù)交易所有限公司, 上海 200131）

數(shù)字經(jīng)濟是繼農(nóng)業(yè)經(jīng)濟、工業(yè)經(jīng)濟之后的主要經(jīng)濟形態(tài)，是以數(shù)據(jù)資源為關(guān)鍵要素，以現(xiàn)代信息網(wǎng)絡(luò)為主要載體，以信息通信技術(shù)融合應用、全要素數(shù)字化轉(zhuǎn)型為重要推動力，促進公平與效率更加統(tǒng)一的新經(jīng)濟形態(tài)[1]。數(shù)字經(jīng)濟正以前所未有的力量推動生產(chǎn)方式、生活方式和治理方式深刻變革。充分發(fā)揮海量數(shù)據(jù)和豐富應用場景優(yōu)勢，促進數(shù)字技術(shù)與實體經(jīng)濟深度融合，賦能傳統(tǒng)產(chǎn)業(yè)轉(zhuǎn)型升級，成為我國社會經(jīng)濟和區(qū)域發(fā)展的重大機遇[2]。

由于數(shù)據(jù)交易是數(shù)據(jù)流通和價值實現(xiàn)的關(guān)鍵環(huán)節(jié)，數(shù)據(jù)交易設(shè)計、實現(xiàn)及驗證技術(shù)研究成為學術(shù)界和工業(yè)界的關(guān)注熱點方向。文獻[3]提出了一種隱私保護的群體感知數(shù)據(jù)交易框架，并給出了參與者的信譽模型，以保障參與者的可信性。文獻[4]提出了一種改進的多目標遺傳算法——協(xié)作式NSGAⅠⅠ，通過數(shù)據(jù)生產(chǎn)者（DP）、數(shù)據(jù)消費者（DC）以及數(shù)據(jù)聚合器(AG)的協(xié)作進行計算。針對當前數(shù)據(jù)交易過程中數(shù)據(jù)容易被拷貝以及數(shù)據(jù)保密的問題，文獻[5]提出一種基于區(qū)塊鏈與可信計算的數(shù)據(jù)交易方案。文獻[6]對基于區(qū)塊鏈技術(shù)的數(shù)據(jù)交易模式進行綜述分析，并討論區(qū)塊鏈和數(shù)據(jù)交易結(jié)合所面臨的挑戰(zhàn)和可能的解決方法。文獻[7]提出了一種基于偏差約減的大數(shù)據(jù)交易模型修復方法，通過過程模型的可達標識圖發(fā)現(xiàn)事件日志與模型之間的偏差關(guān)系，對事件日志與模型之間的偏差進行約減。文獻[8]研究了各種數(shù)據(jù)定價模型，將它們分類為不同的組，并對這些模型的利弊進行了全面的比較。數(shù)據(jù)交易系統(tǒng)涉及多個系統(tǒng)及模塊，通過協(xié)作才能完成數(shù)據(jù)交易。模型驅(qū)動架構(gòu)（Model-Driven Architecture,MDA）關(guān)注系統(tǒng)高層模型，系統(tǒng)模型通過描述系統(tǒng)成分及成分之間的相互關(guān)系，反映設(shè)計者對系統(tǒng)結(jié)構(gòu)和行為的設(shè)計構(gòu)想。然而，數(shù)據(jù)交易在生態(tài)平臺層的理論模型及設(shè)計和分析技術(shù)方面的工作還闕如。如何構(gòu)建數(shù)據(jù)交易的軟件結(jié)構(gòu)模型，對于數(shù)據(jù)交易平臺的功能設(shè)計和性能優(yōu)化至關(guān)重要。

面向方面程序設(shè)計（ Aspect-Oriented Programming，AOP）利用“橫切”的技術(shù)，將那些影響多個類的行為封裝到一個可復用模塊（即方面），降低模塊間的耦合度[9]。為了解決上述數(shù)據(jù)交易模型設(shè)計面臨的問題，本文基于AOP 提出了數(shù)據(jù)交易自適應軟件模型設(shè)計方法。該方法融合了形式化理論、數(shù)據(jù)驅(qū)動軟件工程以及AOP 方法，建立了自適應數(shù)據(jù)交易系統(tǒng)的軟件結(jié)構(gòu)設(shè)計框架。數(shù)據(jù)交易過程的形式化建模由單元模塊通過層次化的組合構(gòu)造而成，包括數(shù)據(jù)交易過程中個體的建模、數(shù)據(jù)交易相關(guān)服務的建模、數(shù)據(jù)各個任務模塊的建模和方面模型構(gòu)建?；赑etri 網(wǎng)形式化方法為數(shù)據(jù)交易模型提供了數(shù)學表達和分析手段。最后，通過仿真實驗說明所提方法的有效性和可行性。

1 數(shù)據(jù)交易軟件結(jié)構(gòu)及需求

自適應數(shù)據(jù)交易系統(tǒng)軟件結(jié)構(gòu)設(shè)計框架采用面向方面編程思想對數(shù)據(jù)交易系統(tǒng)的需求進行解析，分為基本模塊和方面模塊兩部分，如圖1 所示?；灸K主要包括任務和服務，其中任務和服務主要包括數(shù)據(jù)交易過程涉及的相關(guān)任務和服務。方面模塊主要為調(diào)度功能，負責對交易過程進行監(jiān)測和集成，根據(jù)方面所處的層面可分為任務層、交易層和 調(diào)度層3 個方面?；赑etri 網(wǎng)和模型庫方法研究數(shù)據(jù)交易系統(tǒng)的形式化模型和控制策略實施。

該框架構(gòu)建包括需求抽象、模型定義、形式化建模、動態(tài)編織、模型驗證5 個主要步驟：

（1）需求抽象：以數(shù)據(jù)交易系統(tǒng)應用為驅(qū)動，進行需求抽象，提取系統(tǒng)的多維關(guān)注點集、交易場景及其關(guān)系，給出數(shù)據(jù)交易系統(tǒng)需求，包括交易任務、服務、關(guān)注點、場景等。

（2）模型定義：基于Petri 網(wǎng)提出數(shù)據(jù)交易系統(tǒng)的層次形式化描述語言，給出變遷、庫所和個體等模型基本元素的實際映射，探索相應模型執(zhí)行語義以描述系統(tǒng)的動態(tài)和靜態(tài)特性等；

（3）形式化建模：對關(guān)注點集、關(guān)注點之間關(guān)系和控制策略進行建模以形成一個通用的模型庫；

（4）動態(tài)編織：根據(jù)系統(tǒng)基礎(chǔ)元素及其關(guān)系構(gòu)建數(shù)據(jù)交易系統(tǒng)的基礎(chǔ)網(wǎng)模型，并根據(jù)編制規(guī)則在基礎(chǔ)網(wǎng)上動態(tài)織入控制策略橫切關(guān)注點以形成不同場景下的形式化模型；

（5）模型驗證：基于模型執(zhí)行語義構(gòu)造模型的狀態(tài)空間，利用Petri 相關(guān)理論分析模型的一致性、執(zhí)行正確性等。

由于數(shù)據(jù)交易系統(tǒng)的功能是由多個獨立運行的組件構(gòu)成，根據(jù)AOP 思想可知數(shù)據(jù)交易系統(tǒng)的執(zhí)行流程為核心關(guān)注點，而橫切關(guān)注點是指系統(tǒng)的非功能需求，本文主要指組件的屬性和一些控制措施[10]。如無特殊說明，后面所涉及的關(guān)注點均指橫切關(guān)注點。

定義1 數(shù)據(jù)交易系統(tǒng)的軟件結(jié)構(gòu)設(shè)計需求是Γ={ DP, DC, PW, WS, TK, Rq, YW}：

（1）DP 是數(shù)據(jù)提供方集合，二元組（pid，cr）分別表示提供方標識符和信譽等級，本文假設(shè)標識符唯一。

（2）DC 是有限數(shù)據(jù)產(chǎn)品集合， PW 表示其屬性函數(shù)，包括數(shù)據(jù)產(chǎn)品提供方、價格、數(shù)據(jù)量、測試數(shù)據(jù)集、數(shù)據(jù)規(guī)模、產(chǎn)生時間等。

（3）WS 為數(shù)據(jù)交易服務集, TK 為有限的任務集。

（4）Rq 是數(shù)據(jù)需求集合，YW 是有限的業(yè)務流程集合，每個業(yè)務流程對應一個數(shù)據(jù)交易需求，其中每個業(yè)務流程YW=（subT，RL），其中：subT 是有限任務集，標記TKi,j表示業(yè)務流程YWi的第j個任務；RL:subT× subT→{＞,||,+,?}，＞,||,+,?分別表示順序、并行、選擇和互斥關(guān)系。

數(shù)據(jù)交易中服務類型包括數(shù)據(jù)合規(guī)評估、質(zhì)量評估、資產(chǎn)評估、掛牌審核、數(shù)據(jù)測試、概念驗證（Proof of Concept，POC）、數(shù)據(jù)交付[11]。

（1）數(shù)據(jù)合規(guī)評估服務主要由合規(guī)安全評估商提供，服務流程包括明確評估范圍、制定評估計劃、開展合規(guī)性評估、選取合規(guī)評估手段、數(shù)據(jù)安全風險分析、編制數(shù)據(jù)安全評估報告、評估交付。

（2）數(shù)據(jù)質(zhì)量評估服務由數(shù)據(jù)質(zhì)量評估商提供，使用質(zhì)量評估模型、產(chǎn)品，提供質(zhì)量評估服務，對數(shù)據(jù)產(chǎn)品的質(zhì)量進行各種緯度的評估，采用某種評估模型進行評估。

（3）數(shù)據(jù)資產(chǎn)評估服務由數(shù)據(jù)資產(chǎn)評估商提供，幫助數(shù)據(jù)產(chǎn)品提供方進行數(shù)據(jù)資產(chǎn)的梳理、分析、評估。具體流程主要包括質(zhì)量價值和應用價值計算、案例對比分析、數(shù)據(jù)讀取、選擇評估方法、構(gòu)建評估模型、價值評估等。

（4）掛牌審核服務由數(shù)據(jù)交易所提供，主要依據(jù)《數(shù)據(jù)交易所掛牌規(guī)范》 所描述的審核要求，對掛牌主體、數(shù)據(jù)產(chǎn)品與限制描述依據(jù)不同板塊要求進行一一審核。數(shù)據(jù)交易所會對供方交易資格進行審核，對可交易數(shù)據(jù)產(chǎn)品的合規(guī)性、可交易數(shù)據(jù)產(chǎn)品質(zhì)量、數(shù)據(jù)密級程度進行評估。單項要求均需達到交易要求方可審核通過。

（5）數(shù)據(jù)測試服務由數(shù)據(jù)交易所提供，在數(shù)據(jù)使用上以Notebook 方式提供給用戶進行Python編程，對數(shù)據(jù)集進行交互式分析體驗。交易所從數(shù)據(jù)產(chǎn)品使用形態(tài)分類提供APⅠ形式數(shù)據(jù)在線調(diào)用體驗、數(shù)據(jù)集實行數(shù)據(jù)產(chǎn)品在線編程體驗兩種體驗。被動體驗包括數(shù)據(jù)統(tǒng)計學分布報告和基于應用場景的數(shù)據(jù)畫像。

（6）POC 測試服務由交易所提供，是針對數(shù)據(jù)具體應用的驗證性測試，根據(jù)用戶的性能要求和擴展需求指標，在服務器上進行真實數(shù)據(jù)的運行和實際測算。主要包括環(huán)境搭建、測試案例設(shè)計、腳本編寫調(diào)試、功能測試、組件測試、性能測試、可靠性測試等。

（7）數(shù)據(jù)交付服務由數(shù)據(jù)交付生態(tài)服務商提供，利用服務商自身數(shù)據(jù)交付產(chǎn)品對數(shù)據(jù)交易的甲乙兩方進行數(shù)據(jù)交付服務。主要流程有交付請求、調(diào)用APⅠ接口、容器操作、交付?？刹扇〉慕桓斗绞街饕谢A(chǔ)數(shù)據(jù)包、應用程序編程接口和分析產(chǎn)品。

數(shù)據(jù)交易中任務類型包括數(shù)據(jù)登記、數(shù)據(jù)掛牌、數(shù)據(jù)交易、數(shù)據(jù)交付、資金清算。

（1）數(shù)據(jù)登記任務是指數(shù)據(jù)供方完成數(shù)據(jù)產(chǎn)品的登記，登記的內(nèi)容主要包括登記主體、數(shù)據(jù)產(chǎn)品描述、數(shù)據(jù)產(chǎn)品來源證明等。

（2）數(shù)據(jù)掛牌任務是指數(shù)據(jù)供方完成數(shù)據(jù)產(chǎn)品的發(fā)布。被授權(quán)或擁有已登記的數(shù)據(jù)產(chǎn)品的供方才可成為掛牌主體。

（3）數(shù)據(jù)交易是指供需雙方對可交易數(shù)據(jù)產(chǎn)品依照既定交易過程進行的活動，涉及到數(shù)據(jù)供方、數(shù)據(jù)需方和數(shù)據(jù)交易所，按照流程完成交易，形成交易合約。

（4）數(shù)據(jù)交付任務主要完成數(shù)據(jù)交易過程中的數(shù)據(jù)交付（數(shù)據(jù)交割）行為，是交付方從數(shù)據(jù)交易所接收交易相關(guān)信息，幫助數(shù)據(jù)產(chǎn)品使用方和數(shù)據(jù)產(chǎn)品提供方進行數(shù)據(jù)交付。

（5）資金清算任務主要完成費用清結(jié)算行為。數(shù)據(jù)交付完成后，由數(shù)據(jù)交易所對數(shù)據(jù)交付服務機構(gòu)傳入的結(jié)果（含交易量和交易金額）進行審計、清結(jié)算。

2 數(shù)據(jù)交易過程的形式化建模

Petri 網(wǎng)既有嚴格數(shù)學和直觀圖形的表述方式，又有豐富系統(tǒng)描述手段和行為分析技術(shù)，可以廣泛應用于描述和分析系統(tǒng)中控制流和信息流。因此，Petri 非常適合描述數(shù)據(jù)交易系統(tǒng)及生態(tài)這種松耦合的分布式系統(tǒng)。根據(jù)數(shù)據(jù)交易系統(tǒng)建模需求對Petri 網(wǎng)進行擴展，采用文獻[12]所提出的模型對數(shù)據(jù)交易過程進行建模。

2.1 數(shù)據(jù)交易過程中個體的建模

將所有數(shù)據(jù)產(chǎn)品都抽象為個體。數(shù)據(jù)DCi建模為個體dDCi=（DC,i, RW（DC,i））,個體屬性RW（DC,i）表示數(shù)據(jù)產(chǎn)品DCi的數(shù)據(jù)產(chǎn)品提供方、價格、數(shù)據(jù)量、測試數(shù)據(jù)集、數(shù)據(jù)規(guī)模、產(chǎn)生時間等屬性。同理可以將數(shù)據(jù)提供方、數(shù)據(jù)需求方、交易過程涉及的服務、資源等都建模為個體。

2.2 數(shù)據(jù)交易相關(guān)服務的建模

根據(jù)服務內(nèi)在的執(zhí)行流程，對服務進行建模。下面以數(shù)據(jù)合規(guī)評估、數(shù)據(jù)測試、數(shù)據(jù)交付服務為例給出服務形式化模型及其映射。

2.2.1 數(shù)據(jù)合規(guī)評估服務 數(shù)據(jù)合規(guī)評估服務主要由合規(guī)安全評估商提供，其建模如圖2 所示，具體數(shù)據(jù)合規(guī)評估服務執(zhí)行流程如下：

圖2 數(shù)據(jù)合規(guī)評估服務的建模Fig.2 Modeling of Data Compliance Assessment Service

2.2.2 數(shù)據(jù)測試服務 數(shù)據(jù)測試服務的建模如圖3所示。具體執(zhí)行流程如下：若≠ ? ，即存在用戶調(diào)用數(shù)據(jù)測試服務，則觸發(fā)變遷tst執(zhí)行服務開始操作，同時服務進入等待主動體驗位置pwzdt和等待被動體驗位置pwbdt；對于主動體驗模式，選擇觸發(fā)變遷tbxzd執(zhí)行放棄主動體驗操作，則服務進入放棄主動體驗位置；觸發(fā)變遷txzA執(zhí)行選擇APP 調(diào)用體驗操作，則服務進入等待APP 調(diào)用體驗位置pwzA；對于被動體驗模式，觸發(fā)變遷tsbdt執(zhí)行開始被動體驗操作，則服務可同步進入等待統(tǒng)計位置pwtj和等待數(shù)據(jù)畫像開始位置pwhx；若主動和被動都體驗結(jié)束，則觸發(fā)變遷tecs執(zhí)行數(shù)據(jù)測試結(jié)束操作，輸出審核結(jié)果到服務的輸出接口，同時將結(jié)果備份到數(shù)據(jù)測試結(jié)果備份位置pcsb。

圖3 數(shù)據(jù)測試服務的建模Fig.3 Modeling of data test service

2.2.3 數(shù)據(jù)交付服務的建模 數(shù)據(jù)交付服務的建模如圖4 所示。具體執(zhí)行流程如下：若≠ ? ，即存在用戶調(diào)用數(shù)據(jù)交付服務，則觸發(fā)變遷tst執(zhí)行服務開始操作，同時服務進入等待數(shù)據(jù)交付方式選擇位置pwxjf；變遷txsb、txAPⅠ、txfx分別執(zhí)行數(shù)據(jù)包、APⅠ程序編程接口、數(shù)據(jù)分析報告3 種交付方式的選擇操作；引入變遷ttm、tab、tcs、tbs分別描述數(shù)據(jù)包交付方式的數(shù)據(jù)脫敏、安全保護、傳輸、部署操作。其中數(shù)據(jù)安全保護和傳輸是同步運行；若交付結(jié)束（即庫所pejf不為空），則觸發(fā)tejf執(zhí)行數(shù)據(jù)交付結(jié)束操作，輸出審核結(jié)果到，同時將結(jié)果和日志備份到庫所pjfb。

圖4 數(shù)據(jù)交付服務的建模Fig.4 Modeling of data delivery service

2.3 數(shù)據(jù)各個任務模塊的建模

根據(jù)任務的內(nèi)在邏輯，對數(shù)據(jù)交易相關(guān)任務進行建模。下面以數(shù)據(jù)登記、數(shù)據(jù)交易任務為例，給出任務形式化模型及其映射。

2.3.1 數(shù)據(jù)登記任務模塊的建模 數(shù)據(jù)登記任務是指數(shù)據(jù)供方完成數(shù)據(jù)產(chǎn)品的登記。數(shù)據(jù)登記任務模塊的建模如圖5 所示，具體執(zhí)行流程如下：若≠?，存在數(shù)據(jù)產(chǎn)品輸入到數(shù)據(jù)登記任務模塊，即有數(shù)據(jù)產(chǎn)品需要登記。若任務初始位置ps，則觸發(fā)變遷tst開始數(shù)據(jù)登記操作。數(shù)據(jù)產(chǎn)品分別進入等待數(shù)據(jù)合規(guī)檢查、數(shù)據(jù)質(zhì)量評估、數(shù)據(jù)資產(chǎn)評估3 個位置等待數(shù)據(jù)產(chǎn)品評估機構(gòu)提供相關(guān)服務。變遷tshg，tszp，tszc并行執(zhí)行，用于啟動數(shù)據(jù)合規(guī)檢查、數(shù)據(jù)質(zhì)量評估和數(shù)據(jù)資產(chǎn)評估3 個服務，初始化各個服務的輸入信息到對應的輸入接口庫所pshg，pszp，pszc。變遷thgfw,tzlpg,tzcpg分別表示數(shù)據(jù)合規(guī)檢查、數(shù)據(jù)質(zhì)量評估和數(shù)據(jù)資產(chǎn)評估服務的替代節(jié)點。引入庫所phgjg，pzlpg，pzcpg分別用于存放可以提供數(shù)據(jù)合規(guī)檢查、數(shù)據(jù)質(zhì)量評估和數(shù)據(jù)資產(chǎn)評估服務的機構(gòu)個體（每個機構(gòu)建模為一個個體）。觸發(fā)變遷tsht完成數(shù)據(jù)產(chǎn)品登記審核通過操作，輸出登記結(jié)果到數(shù)據(jù)產(chǎn)品登記結(jié)束輸出位置，同時在數(shù)據(jù)登記結(jié)束備案庫所pdjb存檔。

圖5 數(shù)據(jù)登記任務模塊建模Fig.5 Modeling of data registration task module

2.3.2 數(shù)據(jù)交易任務模塊的建模 數(shù)據(jù)交易是指供需雙方對可交易數(shù)據(jù)產(chǎn)品依照既定交易過程進行的活動。數(shù)據(jù)交易任務模塊的建模如圖6 所示：若任務初始位置pssj，則觸發(fā)變遷tsj開始數(shù)據(jù)交易操作；觸發(fā)變遷tssfx啟動數(shù)據(jù)發(fā)現(xiàn)操作，通過交易所交易大廳中的數(shù)據(jù)產(chǎn)品目錄查看數(shù)據(jù)產(chǎn)品說明書，發(fā)現(xiàn)所需數(shù)據(jù)的數(shù)據(jù)產(chǎn)品，同時任務進入數(shù)據(jù)發(fā)現(xiàn)位置pssfx。后面觸發(fā)變遷tfxcp啟動數(shù)據(jù)產(chǎn)品存放操作，任務進入等待數(shù)據(jù)交易位置pdjy；引入變遷txscs，txPcs，txzcg選擇執(zhí)行，分別用于觸發(fā)任務進入數(shù)據(jù)測試、POC 測試和數(shù)據(jù)交付3 個服務等待啟動位置pwscs，pwPcs，pwzcg。其中數(shù)據(jù)測試和POC 測試服務是可選的功能模塊。若任務處于服務等待啟動位置pwscs，pwPcs，pwzcg，則可以分別觸發(fā)變遷tsscs，tsPcs，tszcg初始化各個服務的輸入信息到對應的輸入接口庫所pscs，psPcs，pszcg。變遷tscs,tPcs,tzcg分別表示數(shù)據(jù)測試、POC 測試和數(shù)據(jù)交付服務的替代節(jié)點。引入庫所pcssj，pPcsg分別用于存放的數(shù)據(jù)測試集。最后觸發(fā)變遷tsjyj完成數(shù)據(jù)交易結(jié)束操作，輸出交易結(jié)果到數(shù)據(jù)交易結(jié)束位置pjyb存檔，同時在數(shù)據(jù)交易結(jié)束輸出位置。

圖6 數(shù)據(jù)交易任務模塊建模Fig.6 Modeling of data transaction task module

2.4 面向方面的模型構(gòu)建

方面模型對交易狀態(tài)進行監(jiān)測和交易決策。將交易調(diào)度的描述按照切入的對象和目的不同，分為任務-服務調(diào)度、請求-任務調(diào)度和調(diào)度處理3 個方面模塊。模型集成由基本模塊和方面模塊通過AOP 編織機制實現(xiàn)。

2.4.1 調(diào)度方面模型

調(diào)度元對象根據(jù)交易流程提交的任務集計算具體的可用數(shù)據(jù)產(chǎn)品集，并及時通知服務執(zhí)行。最后將服務執(zhí)行的結(jié)構(gòu)反饋給用戶。

（1）任務-服務調(diào)度方面模塊

在數(shù)據(jù)交易執(zhí)行過程，任務需要調(diào)用一些服務來完成對應功能。所以方面模型需要對任務與服務間調(diào)用關(guān)系進行建模，并將其抽象為任務-服務調(diào)度方面模塊。

其次，任務層TKi如果收到服務執(zhí)行結(jié)果（≠ ? ），則觸發(fā)變遷ttew根據(jù)服務類型將服務結(jié)果轉(zhuǎn)發(fā)到對應服務結(jié)束庫所。

（2）數(shù)據(jù)需求-任務的調(diào)度方面模塊

每個數(shù)據(jù)交易需求完成是根據(jù)業(yè)務流程調(diào)度對應的任務執(zhí)行完成。將需求和任務間的調(diào)度過程建模抽象為需求-任務調(diào)度方面模塊。

首先，對于每個任務輸出的調(diào)度集，引入庫所pdwj表示任務TKj的調(diào)度輸出接口。通過觸發(fā)變遷tdwj將任務TKj的調(diào)度方案存到請求層輸出接口。

其次，若交易請求Rqi∈ Rq 收到服務執(zhí)行結(jié)果（≠ ? ），則觸發(fā)變遷tqew根據(jù)服務所執(zhí)行的任務將服務結(jié)果轉(zhuǎn)發(fā)到任務的服務結(jié)果輸入接口。引入庫所pwt1，pwt2，…，pwt|TKi|分別表示各個任務的服務執(zhí)行結(jié)果輸入接口。

（3）調(diào)度處理方面模塊

對于整個數(shù)據(jù)交易模型，將如何根據(jù)調(diào)度方案觸發(fā)相關(guān)服務并反饋結(jié)果至請求過程抽象為調(diào)度處理方面模塊。

首先，對于每個交易請求輸出的調(diào)度方案集合，引入庫所pwi表示交易請求Rqi的調(diào)度輸出接口。通過觸發(fā)變遷twi將請求Rqi的調(diào)度方案存到等待庫所paw。

其次，調(diào)度層通過觸發(fā)變遷tsw根據(jù)paw庫所收到的服務調(diào)度方案，將任務基本信息輸出到對應不同服務類型的調(diào)用庫所。如庫所pswhg、pswjf分別表示數(shù)據(jù)合規(guī)服務和數(shù)據(jù)交付服務的調(diào)度用庫所。通過觸發(fā)變遷tswhg從庫所ppwhg中選擇數(shù)據(jù)合規(guī)服務提供商，并進入數(shù)據(jù)合規(guī)服務執(zhí)行階段，即輸入個體到數(shù)據(jù)合規(guī)服務的輸入接口pshg。同理，可以通過觸發(fā)變遷tswjf從庫所ppwjf中選擇數(shù)據(jù)交付服務提供商，并進入數(shù)據(jù)交付服務執(zhí)行階段。

若調(diào)度層收到服務結(jié)果，則觸發(fā)對應變遷匯總所有服務結(jié)果到庫所pew，然后根據(jù)服務所執(zhí)行的任務，將其結(jié)果通過觸發(fā)變遷tew轉(zhuǎn)發(fā)到相關(guān)用戶請求接口。引入庫所phgtg、pezp、pezcp、pegsp、pecsg、pePcg、pejfp分別表示數(shù)據(jù)合規(guī)審核服務、數(shù)據(jù)質(zhì)量評估服務、數(shù)據(jù)資產(chǎn)評估服務、數(shù)據(jù)測試服務、POC 測試服務和數(shù)據(jù)交付服務的輸出接口，每個接口都引入對應的變遷執(zhí)行結(jié)果匯總。引入庫所pew1，pew2，...，pew|Rq|分別表示各個交易請求的服務執(zhí)行結(jié)果輸入接口。

2.4.2 模型集成 設(shè)數(shù)據(jù)交易調(diào)度需求Ξ的模型Ω構(gòu)造步驟如下：

（1）根據(jù)交易請求流程中任務的屬性及其關(guān)系(參照文獻[12])。構(gòu)造系統(tǒng)中所有任務、數(shù)據(jù)請求的數(shù)據(jù)交易模型。由于模型主要考慮交易任務的執(zhí)行流程，引入ps、ts表示數(shù)據(jù)請求的初始位置和初始化操作，設(shè)置所有請求的M0(ps)=φ，即所有的交易流程處于等待開始。pinj表示任務TKi,j的輸入接口。

（2）根據(jù)數(shù)據(jù)服務的屬性，構(gòu)造所有數(shù)據(jù)服務的模型，并設(shè)置相應的初始資源分布。

（3）根據(jù)方面模塊的定義、服務、任務、請求的關(guān)系，構(gòu)造自適應數(shù)據(jù)交易模型，將具有相同含義的庫所和變遷合并。

3 數(shù)據(jù)交易模型的正確性分析

通過建模，數(shù)據(jù)交易的執(zhí)行流程映射到模型上是一組由變遷集組成的觸發(fā)序列。因此，通過分析模型的可達狀態(tài)屬性可以對數(shù)據(jù)交易執(zhí)行過程進行動態(tài)分析和驗證。為了區(qū)別不同層面或者模塊的變遷和庫所，在變遷或庫所前引入所屬對象進行區(qū)別，如TKi,j·tkqjf表示任務TKi,j模型中的變遷tkqjf。如無特殊標記，則說明該變遷或庫所處于頂層。

數(shù)據(jù)交易流程的正確建模體現(xiàn)為任務是否可以得到執(zhí)行、服務是否可調(diào)用、用戶請求是否會到達結(jié)束狀態(tài)。下面從以下幾個方面展開驗證。

定理1：設(shè)S0是數(shù)據(jù)交易模型Ω的初始狀態(tài)，R(Ω)是對應的可達狀態(tài)集，則有：

證明： (1)數(shù)學歸納法， ?TKi,j∈YWi, 設(shè)Fork(TKi,j)={ TKi,f| RL(TKi,f, TKi,j)=＞, TKi,f∈ Rqi}為任務TKi,j的前向任務集。根據(jù)TKi,j在執(zhí)行過程中與其余任務的關(guān)系可分為兩種情形。

情形(a) Fork(TKi,j)= ? ：即TKi,j不需要其他任務的運行結(jié)果，系統(tǒng)可以直接執(zhí)行。根據(jù)用戶請求的數(shù)據(jù)交易模型構(gòu)造過程可知，因M0(Rqi·ps)≠ ? ∧ ·ts=Rqi·ps，所以ts∈FT(S0) 。所以存在S1∈R(Ω)使得|M1(Rqi·pinj) |= 1。因為Rqi·pinj和TKi,j·pin是等價的，表示任務的輸入接口。即|M1(TKi,j·pin) |= 1，令S’=S1,可得?TKi,j∈YWi，?S∈R(Ω)，M(TKi,j·pin)≠ ? 。

情形(b) Fork(TKi,j)≠ ? ，設(shè)?TKi,f∈ Fork(TKi,j)，?S’∈R(Ω)，使得M’(TKi,j·pin)≠ ? ，證明TKi,j滿足子命題（1）：不妨設(shè)Fork(TKi,j)={TKi,f,TKi,g,…,TKi,k}, 根據(jù)命題前提可知TKi,j的所有前向任務都有可能執(zhí)行。所以存在S1∈R(Ω)，使得|M1(TKi,f·)|= |M1(TKi,g·)|=…=|M1(TKi,k·)|=1。因為RL(TKi,f, TKi,j)= RL(TKi,g,TKi,j)=…=RL(TKi,k, TKi,j)=＞,根據(jù)任務間關(guān)系的建?？芍Ｐ椭写嬖趯淖冞w將TKi,f, TKi,g,…, TKi,k的運行結(jié)果匯總給TKi,j。即存在S2∈R(S1)使得|M2(TKi,j·pin) |≠0。

綜上所述，子命題（1）得證，?TKi,j∈TK，Ω,S0|=AG?1，其中?1為TKi,j·ts∈FT(S)。

同理可證子命題（2）～（3）也成立。

定理1 說明，在數(shù)據(jù)交易模型中任意一個任務都可以被執(zhí)行，任意一個用戶請求都有可能執(zhí)行完成，任意一個服務都能觸發(fā)。據(jù)交易模型中可以正確刻畫數(shù)據(jù)交易中任務間關(guān)系、用戶請求流程、服務執(zhí)行等過程。因此利用數(shù)據(jù)交易模型可以有效描述數(shù)據(jù)交易系統(tǒng)的執(zhí)行邏輯。

4 數(shù)據(jù)交易調(diào)度策略的性能分析

針對數(shù)據(jù)交易流程、數(shù)據(jù)特征及其約束，隨機生成500 個用戶請求，每個用戶請求的任務數(shù)及其關(guān)系可以隨機設(shè)置。每個用戶請求的業(yè)務流程可以包含數(shù)據(jù)登記、數(shù)據(jù)掛牌、數(shù)據(jù)交易、數(shù)據(jù)交付、資金清算任務。隨機生成500 個可用服務（設(shè)每類服務至少具有20 個以上可用服務），隨機生成任務與可用服務之間的映射關(guān)系。以下通過兩個實驗分析數(shù)據(jù)交易模型對于不同規(guī)模業(yè)務需求及可用服務的適應性。

實驗1：目的是分析數(shù)據(jù)交易模型狀態(tài)空間與用戶請求數(shù)的關(guān)系，具體實驗步驟如下：

(1) 分別取50、100、150、200、250、300、350、400、450、500 個用戶請求作為整個數(shù)據(jù)交易的需求。取500 個可用服務作為需求的總可用服務集，要求每類服務至少有50 個可用服務。

(2) 將500 個用戶請求分為10 組數(shù)據(jù)交易的需求。取100 個可用服務作為可用服務集，每類服務至少有10 個可用服務。

(3) 構(gòu)造數(shù)據(jù)交易的模型，分別計算每個模型的狀態(tài)空間大小，如圖7 所示。

圖7 模型狀態(tài)空間與用戶請求數(shù)的關(guān)系Fig.7 Relationship between model state space and user requests

分析圖7（a）可知，當用戶請求個數(shù)逐漸增加時，數(shù)據(jù)交易模型的狀態(tài)空間整體上呈增加趨勢。分析其原因是因為新增加的請求使得服務上處理的任務數(shù)發(fā)生增加。此外，任務的屬性也是不一樣的，所以請求個數(shù)的增加也會使得系統(tǒng)需要更多的任務異步完成，從而導致模型的狀態(tài)空間增加，但是增加的比例不是固定的。隨著用戶數(shù)的增加，后面狀態(tài)數(shù)逐漸趨于穩(wěn)定。

分析圖7（b）可知，當用戶請求個數(shù)一樣時，每個需求的模型狀態(tài)空間大小也會有波動。分析其原因是因為雖然用戶請求數(shù)一樣，但是用戶所包含的任務數(shù)不一樣，進而導致完成所有請求所需要總的可達狀態(tài)數(shù)不一樣。

實驗2：目的是分析數(shù)據(jù)交易模型狀態(tài)空間與服務數(shù)的關(guān)系，具體實驗步驟如下：

(1) 隨機取100 個請求作為數(shù)據(jù)交易需求，每個請求的任務數(shù)是不確定的。

(2) 隨機取30、50、80、100、130、150、180、200 個可用服務作為需求的可用服務集，要求每類服務至少有1 個可用服務。

(3) 分別根據(jù)任務、用戶請求、服務的屬性，構(gòu)建每個需求的數(shù)據(jù)交易模型，分別計算每個需求模型的狀態(tài)空間大小。

實驗2 的仿真結(jié)果如圖8 所示。分析可知：雖然用戶請求數(shù)一樣，但是隨著服務數(shù)的增加，數(shù)據(jù)交易模型的狀態(tài)空間呈下降趨勢。分析其原因主要為（1）服務數(shù)的增加，導致任務可調(diào)用的可用服務增加，進而引起越來越多的變遷可以并發(fā)運行，所以可達狀態(tài)數(shù)呈下降趨勢。（2）隨著總服務數(shù)增加，狀態(tài)空間不是遞減的。分析其原因是因為增加的可用服務類型不一樣。如增加急需服務，則狀態(tài)空間出現(xiàn)明顯減少；若增加已經(jīng)滿足調(diào)用需求的可用服務，則狀態(tài)空間變化較小。

圖8 模型狀態(tài)空間與可用服務數(shù)的關(guān)系Fig.8 Relationship between model state space and services

根據(jù)實驗1 和2 的結(jié)果可知，數(shù)據(jù)交易模型狀態(tài)空間與用戶數(shù)、需求業(yè)務流程和可用服務數(shù)均相關(guān)，且整體上可達狀態(tài)數(shù)是有限的。所以可以利用數(shù)據(jù)交易模型對數(shù)據(jù)交易流程等進行驗證和分析。

5 結(jié)束語

數(shù)據(jù)交易是數(shù)據(jù)流通的核心環(huán)節(jié)，數(shù)據(jù)交易系統(tǒng)的正確性、可維護性和高效性是數(shù)據(jù)要素市場有效運行的重要支撐。本文提出了一種數(shù)據(jù)交易自適應軟件模型構(gòu)建及驗證方法，該方法中數(shù)據(jù)交易模型由各個模塊通過層次化的組合構(gòu)造而成。通過面向方面建模方法實現(xiàn) 數(shù)據(jù)交易過程的自適應演化，并對方面模型與基礎(chǔ)模型進行編織得到綜合的數(shù)據(jù)交易模型。基于 Petri 網(wǎng)的形式化方法為數(shù)據(jù)交易模型提供了數(shù)學表達和分析手段。最后通過理論分析和實驗表明，該設(shè)計方法具有可行性和高效性。進一步的研究方向包括基于模型的數(shù)據(jù)交易安全設(shè)計和應用。