一種自適應數據交易軟件模型設計技術

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

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

數字經濟是繼農業經濟、工業經濟之后的主要經濟形態，是以數據資源為關鍵要素，以現代信息網絡為主要載體，以信息通信技術融合應用、全要素數字化轉型為重要推動力，促進公平與效率更加統一的新經濟形態[1]。數字經濟正以前所未有的力量推動生產方式、生活方式和治理方式深刻變革。充分發揮海量數據和豐富應用場景優勢，促進數字技術與實體經濟深度融合，賦能傳統產業轉型升級，成為我國社會經濟和區域發展的重大機遇[2]。

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

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

1 數據交易軟件結構及需求

自適應數據交易系統軟件結構設計框架采用面向方面編程思想對數據交易系統的需求進行解析，分為基本模塊和方面模塊兩部分，如圖1 所示。基本模塊主要包括任務和服務，其中任務和服務主要包括數據交易過程涉及的相關任務和服務。方面模塊主要為調度功能，負責對交易過程進行監測和集成，根據方面所處的層面可分為任務層、交易層和 調度層3 個方面。基于Petri 網和模型庫方法研究數據交易系統的形式化模型和控制策略實施。

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

（1）需求抽象：以數據交易系統應用為驅動，進行需求抽象，提取系統的多維關注點集、交易場景及其關系，給出數據交易系統需求，包括交易任務、服務、關注點、場景等。

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

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

（4）動態編織：根據系統基礎元素及其關系構建數據交易系統的基礎網模型，并根據編制規則在基礎網上動態織入控制策略橫切關注點以形成不同場景下的形式化模型；

（5）模型驗證：基于模型執行語義構造模型的狀態空間，利用Petri 相關理論分析模型的一致性、執行正確性等。

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

定義1 數據交易系統的軟件結構設計需求是Γ={ DP, DC, PW, WS, TK, Rq, YW}：

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

（2）DC 是有限數據產品集合， PW 表示其屬性函數，包括數據產品提供方、價格、數據量、測試數據集、數據規模、產生時間等。

（3）WS 為數據交易服務集, TK 為有限的任務集。

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

數據交易中服務類型包括數據合規評估、質量評估、資產評估、掛牌審核、數據測試、概念驗證（Proof of Concept，POC）、數據交付[11]。

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

（2）數據質量評估服務由數據質量評估商提供，使用質量評估模型、產品，提供質量評估服務，對數據產品的質量進行各種緯度的評估，采用某種評估模型進行評估。

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

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

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

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

（7）數據交付服務由數據交付生態服務商提供，利用服務商自身數據交付產品對數據交易的甲乙兩方進行數據交付服務。主要流程有交付請求、調用APⅠ接口、容器操作、交付。可采取的交付方式主要有基礎數據包、應用程序編程接口和分析產品。

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

（1）數據登記任務是指數據供方完成數據產品的登記，登記的內容主要包括登記主體、數據產品描述、數據產品來源證明等。

（2）數據掛牌任務是指數據供方完成數據產品的發布。被授權或擁有已登記的數據產品的供方才可成為掛牌主體。

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

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

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

2 數據交易過程的形式化建模

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

2.1 數據交易過程中個體的建模

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

2.2 數據交易相關服務的建模

根據服務內在的執行流程，對服務進行建模。下面以數據合規評估、數據測試、數據交付服務為例給出服務形式化模型及其映射。

2.2.1 數據合規評估服務 數據合規評估服務主要由合規安全評估商提供，其建模如圖2 所示，具體數據合規評估服務執行流程如下：

圖2 數據合規評估服務的建模Fig.2 Modeling of Data Compliance Assessment Service

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

圖3 數據測試服務的建模Fig.3 Modeling of data test service

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

圖4 數據交付服務的建模Fig.4 Modeling of data delivery service

2.3 數據各個任務模塊的建模

根據任務的內在邏輯，對數據交易相關任務進行建模。下面以數據登記、數據交易任務為例，給出任務形式化模型及其映射。

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

圖5 數據登記任務模塊建模Fig.5 Modeling of data registration task module

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

圖6 數據交易任務模塊建模Fig.6 Modeling of data transaction task module

2.4 面向方面的模型構建

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

2.4.1 調度方面模型

調度元對象根據交易流程提交的任務集計算具體的可用數據產品集，并及時通知服務執行。最后將服務執行的結構反饋給用戶。

（1）任務-服務調度方面模塊

在數據交易執行過程，任務需要調用一些服務來完成對應功能。所以方面模型需要對任務與服務間調用關系進行建模，并將其抽象為任務-服務調度方面模塊。

其次，任務層TKi如果收到服務執行結果（≠ ? ），則觸發變遷ttew根據服務類型將服務結果轉發到對應服務結束庫所。

（2）數據需求-任務的調度方面模塊

每個數據交易需求完成是根據業務流程調度對應的任務執行完成。將需求和任務間的調度過程建模抽象為需求-任務調度方面模塊。

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

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

（3）調度處理方面模塊

對于整個數據交易模型，將如何根據調度方案觸發相關服務并反饋結果至請求過程抽象為調度處理方面模塊。

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

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

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

2.4.2 模型集成 設數據交易調度需求Ξ的模型Ω構造步驟如下：

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

（2）根據數據服務的屬性，構造所有數據服務的模型，并設置相應的初始資源分布。

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

3 數據交易模型的正確性分析

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

數據交易流程的正確建模體現為任務是否可以得到執行、服務是否可調用、用戶請求是否會到達結束狀態。下面從以下幾個方面展開驗證。

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

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

情形(a) Fork(TKi,j)= ? ：即TKi,j不需要其他任務的運行結果，系統可以直接執行。根據用戶請求的數據交易模型構造過程可知，因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)≠ ? ，設?TKi,f∈ Fork(TKi,j)，?S’∈R(Ω)，使得M’(TKi,j·pin)≠ ? ，證明TKi,j滿足子命題（1）：不妨設Fork(TKi,j)={TKi,f,TKi,g,…,TKi,k}, 根據命題前提可知TKi,j的所有前向任務都有可能執行。所以存在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)=＞,根據任務間關系的建模可知，模型中存在對應的變遷將TKi,f, TKi,g,…, TKi,k的運行結果匯總給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 說明，在數據交易模型中任意一個任務都可以被執行，任意一個用戶請求都有可能執行完成，任意一個服務都能觸發。據交易模型中可以正確刻畫數據交易中任務間關系、用戶請求流程、服務執行等過程。因此利用數據交易模型可以有效描述數據交易系統的執行邏輯。

4 數據交易調度策略的性能分析

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

實驗1：目的是分析數據交易模型狀態空間與用戶請求數的關系，具體實驗步驟如下：

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

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

(3) 構造數據交易的模型，分別計算每個模型的狀態空間大小，如圖7 所示。

圖7 模型狀態空間與用戶請求數的關系Fig.7 Relationship between model state space and user requests

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

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

實驗2：目的是分析數據交易模型狀態空間與服務數的關系，具體實驗步驟如下：

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

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

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

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

圖8 模型狀態空間與可用服務數的關系Fig.8 Relationship between model state space and services

根據實驗1 和2 的結果可知，數據交易模型狀態空間與用戶數、需求業務流程和可用服務數均相關，且整體上可達狀態數是有限的。所以可以利用數據交易模型對數據交易流程等進行驗證和分析。

5 結束語

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