軍事物流業務流引擎應用本體研究

齊繼東， 馬 妍 ， 荀 燁 ，陳 建

（1．軍事交通學院，天津 300161；2.62402部隊，天津 300182）

1 問題提出

目前，軍事物流業務MIS功能操作步驟、操作權限等均是編碼固化、高耦合度，嚴重制約了系統信息流程的可修改性，無法適應物資保障中數據的采集、傳輸、存儲、處理和使用等事務或功能點的改變。比如，某物資調撥信息流，傳統模式是物資主管部門將出庫憑證直接下達至任務倉庫，但如果改變為物資主管部門將出庫憑證下達至聯勤分部，再由聯勤分部下達至任務倉庫，使數據操作權限、事務鏈、功能點關系發生改變，嚴重時將導致相關業務MIS重構。

為改變現役業務MIS的編碼固化、高耦合度問題，論文[1]提出了基于軍事物流業務流引擎開發業務MIS的技術架構，分析設計了業務流程 （Business Process）、功能環節 （Function Tache）、功能點 （Function Node）、元數據 （Meta Data）及數據服務 （Data Service）等5個結構要素的定制模式，但由于對MLBFE的結構要素缺乏統一公認的注釋，流程定制者和使用者對MLBFE結構要素的理解不同，使用過程中必將產生語義 （本文是指MLBFE的結構要素及其關系的解釋）上或結構上的歧義，如果完全靠人力經驗與理論去辨識含義是不現實的，需要提供能夠被計算機自動識別與釋義的符號系統。截至目前本體 （Ontology）是：解決語義、結構歧義的最佳技術手段；不僅能夠解決語義、結構等異構問題，還能夠基于此推導出新的隱藏的新知識[4]；為充分發揮關系數據庫的優勢，還可將構建的本體文件持久化到數據庫[3]；為基于本體庫的MIS具備智能特點奠定了基礎。因此，本文提出研究軍事物流業務流引擎應用本體庫的主題內容。

2 本體理論

本體是共享概念模型的明確的形式化規范說明，它支持語義級信息交換，是實現Semantic Web的關鍵技術。本體是用來描述某個領域的知識的，是實現不同主體之間共享與互操作的語義、結構基礎，利用聲明式語義[4]能夠使計算機真正理解 “符號”的含義并進行推理。但對本體的描述，不同語言具備不同特征，但無論用XML（可擴展性標記語言，一套元標記語言，用于定義與特定領域有關的、結構化標記語言的語法規則，如＜單元＞＜名稱＞炊事掛車＜/名稱＞＜類別＞后勤裝備＜類別＞＜/單元＞）、RDF（一種由資源、屬性、屬性值組成的三元組，如＜rdfs:Class rdfs:label="炊事掛車"/＞＜rdf:Property rdf:about="&rdf_;類別"＞）等何種語言進行描述。本體的典型結構由5個基本要素構成，分別是： （1）類。任何事務，相關概念構成一個概念層次結構； （2）關系。領域中個體之間的交互約束作用； （3）函數。前n-1個元素能夠唯一確定第n個元素； （4）公理。定義在實例和屬性之上的約束與規則，是本體推理的依據； （5）實例。類的具體化，每個類包含多個實例，實例之間存在顯示或隱式關系，實例都是對象，但對象不一定都是實例。

目前，OWL（Web Ontology Language）同XML、RDF一樣，是W3C為Semantic Web定義的本體描述語言。OWL在知識表示 （Knowledge Represenation）、知識庫 （Knowledge Base）、人類語言處理技術 （Human Language Technology）、自然語言處理 （Natural Language Processing）、語義信息處理 （Semantic Information Processing）和數字圖書館 （Digital Library）等領域廣泛應用[2]。從語義上講，OWL提供了類之間、實例之間、類與實例之間的關系[4]，分別代表本體的概念、個體及個體之間的關系。具體是： （1）類 （Class）關系，為本體類推理奠定基礎。語法主要有： 類 （owl:Class）、 子類 （rdf:sub Classof）、 相等類 （owl:Equivalent Class）、 互斥類 （owl:Disjoint With）和合并類 （owl:UnionClass）等。 （2）對象屬性 （Object Property），實例約束主要形式，本體推理中使用最為廣泛的屬性。語法主要有：對象屬性 （owl:Object Property）、反義屬性 （owl:Inverse）、唯一性 （owl:Functional）、對稱性 （owl:ymmetric）、 傳遞性 （owl:Transitive）、 序列性 （owl:Cardinality）。 （3） 數據類型屬性 （Data Type Property），代表實例 （owl:Individual）與基本數據類型的關系，描述主要是自定義的，語法是：數據類型 （owl:Data Type Property）等。 （4）注釋屬性 （comment），本體中Class、Individuals、Property等注釋語句，是不同實例及屬性匹配的基礎，是實現語義層 “對象”的自動識別與映射的手段之一，但對rdfs:comment賦值時，應盡量是領域內公認的描述語言，如國標、軍標或行業標準，以及相關公理或常識等。 （5）類型域、值域關系，針對每個對象屬性定義類型域 （rdf:Domain）、值域 （rdf:Range），即 “類型域＋對象屬性＋值域”構成三元組等。 （6）實例之間約束度，類型域與值域之間關于某對象屬性的可能性。語法主要有：全稱取值約束[4]（owl:all Values From，如?Belong）、受限存在取值約束[4]（owl:some Values From，如?Belong）、基數約束 （owl:cardinality）等。

3 流程分析

根據軍事物流業務流引擎管控技術體系架構[1]，可知業務流引擎的結構要素主要有5個，不同結構要素之間存在嚴格的約束綁定關系。流程定制者根據軍事物流保障業務相關主題，按照約定的 “輸入/輸出”關系綁定相關“結構要素” （見圖1）：按序列為業務主題流程綁定功能環節 （事務）；按序列為功能環節綁定功能點；為功能點綁定數據集；不同功能點的數據元素CRUDT（Create、Read、Update、Delete、Transmit）存在差異，需在功能點綁定數據集時定制各數據元素的 “CRUDT”；等等。本文以某類物資供應主題中某業務功能為例，分析定制MLBFE的結構需求。

其中，BPi表示第i個業務流程，FTij表示BPi中包含的具備嚴格邏輯串聯或并聯的第j個功能環節 （關系見圖1），i、j表示 1、 2、 3、…。

（2）功能環節 （FT）與功能點 （FN）。多個具備嚴格邏輯關系與接口的功能點構成一具備特定行為的功能環節，而功能點是一聚合程度高且具備輸入/輸出功能的系統單元。針對某功能環節，FN序列為：功能環節 “編制/處理/提請物資需求”可分解為編制、處理和提請等功能點；功能環節 “獲取/編制/提交物資需求計劃”可分解為獲取、編制和提交等功能點；功能環節 “開具/提交出庫或入庫憑證”可分解為提交出庫憑證、提交入庫憑證等功

（1）業務流程 （BP）與功能環節 （FT）。多個具備嚴格邏輯關系的功能環節構成一完整業務流程。對于某類物資供應而言，業務FT序列為：第一步，編制/處理/提請物資需求；第二步，獲取/編制/提交物資需求計劃；第三步，開具/提交出庫或入庫憑證；第四步，獲取調撥憑證，制定物資出庫/入庫計劃；第五步，執行物資出庫/入庫計劃；第六步，執行物資運輸/配送；等等。經分析得業務流程與功能環節關系的函數 （3-1）。能點；等等。另，軍事物流保障中每個功能環節或功能點均與機構 ｛ 后勤機關，保障實體，受供單位 ｝ 中部分機構相關，因此設計功能點時需考慮角色與功能關系。經綜合分析得功能環節與功能點關系函數 （3-2）。

其中：FNi表示業務流程中具體功能環節的第i個功能點；MDij表示FNi中包含的第j個數據元素；DFij表示MDij的數據獲取點 （數據元素的唯一采集點）；pj1、pj2、pj3、pj4和pj5分別表示FNi中第j個數據元素MDij的CRUDT，一個數據元素具備1個以上的CRUDT權限；i、j表示1、2、3、…。

（4）數據服務與數據元素?；谝讯ㄖ频臉I務功能點與數據元素綁定關系、CRUDT權限與獲取點，利用定制的服務集成相關業務數據，對具體功能環節或功能點的執行狀態實施監控。服務定制典型函數 （3-4）。

其中，FTi表示某業務流程中第i個功能環節，FNij表示FTi中包含的具備嚴格邏輯串聯或并聯的第j個功能點（關系見圖1）， Rkj表示角色Rk具備 FNij功能，i、 j、k表示1、2、3、…。

（3）數據元素 （CRUDT）與獲取點。數據流是業務流程管控重點，CRUDT是確保數據集機密性與不可抵賴性的手段。各功能點具備 （獲?。┹斎肓?，按約定處理生成輸出量，作為下一環節的輸入量。因此，需要準確定制相鄰功能點的接口。

假設每個功能點對應唯一角色，業務流定制者需為功能點中各數據元素指定CRUDT和獲取點。經分析得功能點內數據元素 （CRUDT）與獲取點關系的函數 （3-3）。

示例如下：

其中：cmd代表SQL的操作命令；fld（..）表示字段集合；frm（..）表示字段所屬數據庫表集 （含表之間約束關系）；val（..）表示字段集合，與fld（..）對應；w表示SQL的Where條件，而conds是查詢條件集；FNi.MDij表示某業務功能環節中第i個功能點所轄第j個數據元素；DFit.table表示與FNi.MDij具備同一 “獲取點”的數據元素的數據表；FNi.MDtp表示DFit.table的關鍵字 （主鍵，可能是復合主鍵）；v×××表示相關字段的數據值；i、j、t、p表示1、2、 3、 …。

（由于篇幅所限，其它分析略）

4 本體建模

根據MLBFE結構要素分析，為流程定制者和使用者提供公認統一的概念描述，如 “提請”、 “上報”、 “提交”的注釋，以及MLBFE的結構關系及其對象或個體關系等。本節利用OWL中Class、Individuals、Property等從語義和語法層次上，借助Protégé設計MLBFE應用本體庫，主要包括術語本體、業務流程本體、功能環節 （事務）本體、功能點本體、業務數據主題本體和數據服務本體等。建模中，用Individuals（實例）描述MLBFE中具體對象或個體；用Class（類）聲明相關對象或個體的共性，統一概念；用Object Property描述Class之間和Individuals之間關系約束、層次結構等；用Datatype Property描述Class的數值類型屬性等。

（1）類 （Class）/實例 （Individuals）設計，OWL編碼見表1。某物資供應業務流程中，功能環節 “編制／處理／提請物資需求”可拆分為3個串聯的功能環節：編制物資需求、處理物資需求、提請物資需求；當功能環節“編制物資需求”綁定到不同種類的物資 （如彈藥物資、裝甲器材、被裝物資等）供應流程中時，其位置、數據集、CRUDT等方面存在差異；等等。對于 “編制物資需求”經分析得：實例有 “編制彈藥需求”、 “編制裝甲器材需求”、 “編制被裝物資需求”等。通過對多個具體化實例形成概念類，即具體功能點本體；而為完成某業務功能環節的任務，需將多個功能點串聯或并聯，按序 “運行” （如 “編制物資需求”功能環節 （事務）需按 “部隊承擔任務”、 “部隊現有物資統計”、 “需求量分析”、 “部隊自籌能力”等步驟實施與提請），即功能環節本體；多個功能環節按邏輯串聯或并聯構成業務流程本體；業務流本體通過綁定業務流程本體、功能環節 （事務）本體和功能點本體等而形成。

（2）對象屬性 （Object Property）設計，定義實例之間約束，OWL編碼見表2。根據業務實例集抽象出相關概念，但現實中概念之間或實例之間存在多樣關系。同時，利用實例之間約束語句 （全稱取值約束、受限存在取值約束、基數約束等）嚴格定義實例之間的類型域與值域等。如，物資提請功能點本體 （Function Node）與申請物資本體 （Applyfor Material）之間存在關系?Belong，即owl:some Values From，又由于實例是類的具體化，實

表1 MLBFE應用本體類/實例OWL片段

例之間也必然存在?Belong關系等。另，為明確定義出：業務流程本體實例綁定的功能環節本體實例序列、功能環節本體實例綁定的功能點本體實例序列，及功能點本體實例接口關系，需要為業務流程本體、功能環節本體設計環節/功能點的起點 （begin Tache/begin Node）與終點 （end Tache/end Node）的對象屬性，為功能環節本體及其內含的功能點本體的邏輯關系設計各自的父節點 （has Front Tache/has FrontNode）與子節點 （has ChildTache/has Child Node）的對象屬性；等等。

表2 MLBFE本體類/實例的對象屬性OWL片段

（3）數據類型屬性 （Datatype Property）設計，OWL編碼見表3。實例的數據語義是對數據的描述。因此，為實例設計的數據類型屬性主要有物資名稱 （Material Name）、數值類型 （Data Value Type）、類型域 （Domain）、值域 （Range）和注釋 （comment）等。

另，通過對業務所涉數據元素對象的分析，參照數據元素采集點和使用周期與范圍，設計數據獲取點。將業務所涉數據元素按業務主題劃分 （OWL語句片段見表4）：物資需求數據主題本體 （Dataof Requirement Material Subject）、物資籌措數據主題本體 （Dataof Rasie Material Subject）、物資儲備數據主題本體 （Dataof Storage Mate-

表3 MLBFE類/實例的數據類型屬性OWL片段

rial Subject）、物資運輸數據主題本體 （Dataof Transportation Route Subject）、物資入庫數據主題本體 （DataofIn-Base Document Subject）和財務審計數據主題本體 （Subjectof Financeand Audit）等。業務數據主題本體不僅包含數據類型屬性，而且還包含數據對象本體，因為不同業務數據主題本體的子本體之間可能存在owl:Equivalent Class、owl:Disjoint With，等。因此，針對數據元素而言，又形成了業務數據主題本體、數據元素本體、CRUD本體及其采集點本體等。

表4 MLBFE主題數據本體OWL片段

最后，利用Protégé中組件onto Graph生成了MLBFE應用本體結構層次圖，由于篇幅所限圖2僅展示了部分結構。

圖2 MLBFE應用本體結構層次示例

5 本文結論

本文針對文獻[1]中軍事物流業務流程管控技術架構的結構定制，分析在業務流引擎結構要素缺乏統一的概念、個體及其關系注釋條件下，產生的語義異構與結構異構問題?；诖耍氡倔w技術，用OWL的類、實例和屬性等對MLBFE的5個結構要素的內容與關系進行定義、規范和注釋，為計算機能夠依據定義的本體庫進行匹配、推理奠定基礎。利用protégé對MLBFE本體進行了建模，形成了包含術語、業務流程、功能環節、功能點、業務數據主題、數據元素和采集點等本體的體系。本文的研究成果具有較高的現實意義和研究前景，屬于應用創新性研究。

[1] 齊繼東,等.軍事物流業務流程管控系統初探[J].物流技術，2012(2):213-215.

[2] 張智雄.從RDF（S）到OWL，什么在改變之中[J].圖書館雜志，2005(1):54-60.

[3] 齊繼東,等.物流本體數據庫的應用研究[J].物流科技，2009(2):63-65.

[4] 林志陽.基于OWL語義本體的推理與存儲研究[EB/OL].(2008-12-21)[2012-08-21].http://wenku.baidu.com.