具備一致性維護功能的業務規則系統研究

摘 要：對現有蘊涵業務規則的商業應用系統的應用現狀和程序特點進行了深入分析，并對業務規則系統中存在的一致性沖突及其相應對策進行了闡述，最后提出了基于本體的面向業務規則的商業應用系統開發流程，并且成功應用于指導公眾城市一卡通系統開發。結果表明，用該開發流程指導系統開發，能夠有效地解決業務規則系統的一致性問題，從而降低面向業務規則的商業系統開發和維護的難度。

關鍵詞：業務規則； 業務規則系統； 一致性維護； 本體； 業務規則本體

中圖分類號：TP18文獻標志碼：A

文章編號：1001-3695(2009)06-2291-04

doi:10.3969/j.issn.1001-3695.2009.06.089

Research of business rule system with consistency-maintaining function

WANG Cheng-liang1a，1b， LI Jian-wei1a ， CHEN Juan-juan 2

(1.a.College of Computer Science Engineering， b. College of Electrical Engineering， Chongqing University， Chongqing 400044 China;2. College of Physics Information Technology， Chongqing Normal University， Chongqing 400047 China)

Abstract:

This article carried a deep analysis for present development and characteristics for commercial application systems based on business rules， also elaborated the consistency conflict and the relevant countermeasures. Finally presented the onto-logy-based business-rule-oriented business application system， which was then utilized in the development of the public one-card system. The whole process and outcome proved that it was very useful to solve former problem of consistency conflict and hence could reduce the difficulty of development and maintenance for business rule-based systems.

Key words：business rules; business rules system; consistency maintaining; ontology; business rules ontology

業務規則是企業業務運作和管理決策所依賴的重要資源，它反映了企業業務策略，控制并影響各個系統的運作和企業員工的行為。業務規則隨企業的客戶服務和市場競爭的需要而頻繁地變化，因此，業務規則是否被有效管理以及是否能夠達到正確性、一致性和完備性，一直是困擾企業的問題。同時，由于面向業務規則系統開發應用的復雜性以及開發代價和學習成本令大多數企業望而卻步，影響了業務規則系統的普及應用。為了打破這種局限，使更多的企業能夠從業務規則系統的應用中受益，同時解決困擾企業業務規則一致性難以維護的問題，本文設計了一套對于商業應用系統（如銀行交易系統、小額消費系統等）切實可行的總體框架和開發流程——基于本體的面向業務規則開發的商業應用系統開發流程。

1 業務規則系統

1.1 內嵌業務規則的商業應用系統的應用現狀及原因分析

面向業務規則的商業應用系統開發的概念已經被提出多年，但卻沒有很好的實際應用，尤其是沒有一套能夠實際指導開發的流程、規范來引導和確保開發的質量。在對現有蘊涵業務規則的商業應用系統深入分析后發現，主要有以下三個原因：

a）對于以交易為主的商業應用系統開發的特點，尤其是程序代碼的特點沒有詳細的分析和總結。因為，如何在實際開發中將符合業務規則開發流程的工作介入進來，需要盡量與大多數的開發習慣保持一致，否則，面向業務規則的商業應用系統開發只是一種理念，或者實際應用時學習成本和開發代價都超出企業的承受力。

b）目前的業務規則系統大多是支持前向推理的專家系統，著名的業務規則系統或支持環境有Haley、ILOGT和Jess 等。而它們大多以腳本語言(LISP、CLIPS 等)為基礎，這些語言的表達方式與傳統的開發語言（C++、Java）不同，設計、開發人員的接受難度抵消了業務規則能夠為整個應用系統開發帶來的優點。

c）業務規則系統產生于知識系統，具備許多知識系統的特征，但業務規則系統同時具有自身的一些特性。例如，商業應用系統中由于效率需要、多團隊介入開發的事實、開發模式多樣化的內在要求等，業務規則往往分散在代碼、存儲過程和數據庫的表單中，因而容易發生規則不一致的情況，而且不一致主要表現為規則冗余、規則沖突，知識系統中存在的規則循環的問題在業務規則系統中基本可以忽略。

1.2 內嵌業務規則的商業應用系統的程序開發特點

1.2.1 非面向業務規則開發的商業應用系統

在傳統的非面向業務規則開發的商業應用系統開發中^[1]，系統開發階段極易產生規則表達的不一致，為便于對此階段展開描述，定義以下四元組：{role，ruleConception，ruleModel，ruleCode}。其中:role是參與系統分析階段的角色，如業務經理、業務員、系統分析員、程序員等；ruleConception是角色對業務規則的概念性定義；ruleModel是角色對業務規則的形式化定義；ruleCode是角色對業務規則的程序編碼。

傳統的程序開發過程是由系統分析員與業務經理及業務員通過交談、問卷等方式進行溝通，形成初步的業務規則的概念定義及描述文檔，即ruleConception，然后由系統分析員與程序員共同進行業務規則的模型化定義及描述，形成結論性文檔，即ruleModel，最后由程序員編碼實現，即ruleCode。在此過程中，業務員role1對業務規則有自己理解的業務規則概念ruleConception1，系統分析員role 2在與role 1交流的過程中形成業務規則概念ruleConception2，程序員role 3與role 2基于ruleConception2抽象出業務規則模型ruleModel，程序員基于ruleModel形成業務規則編碼ruleCode。ruleConception1是否等價于ruleConception2，ruleModel又在多大程度上反映了ruleConception2，ruleCode是否能夠執行業務模型描述的流程，這些都是開發出的業務規則系統能否產生實際應用的關鍵，也是產生業務規則不一致的原因所在。

1.2.2 面向業務規則開發的商業應用系統

面向業務規則的開發是商業應用系統中實現動態可變業務邏輯的模塊，其理念就在于用管理數據的方式來管理業務規則。它將業務邏輯以業務規則的形式抽取出來，形成業務規則庫。業務規則系統依據這些規則對傳入的業務數據進行處理，實現企業業務的流動。它為企業人員和業務分析人員等非技術人員設計了業務規則語言，提供了規則開發環境，使得他們能夠直接依據業務需要制訂、修改規則，有效地解決了系統分析過程中產生的規則表達不一致問題。同時，當企業業務的發展需要變更規則時，用戶可以隨時在規則庫中修改、創建規則，無須重新開發企業的應用系統，從而達到靈活配置與變更企業的業務處理過程的目的。但在系統開發及規則變更維護的過程中，極易產生業務規則的冗余、沖突^[2]等不一致性。

2 基于本體的商業應用系統的業務規則一致性維護

基于以上對業務規則系統的分析和總結，為了能夠降低面向業務規則的商業系統開發和使用的難度，解決規則表達不一致問題，擴大其應用范圍，筆者提出了一種基于本體的面向業務規則開發的商業應用系統的開發流程來解決業務規則一致性維護的問題。隨著業務規則方法應用的不斷深入，其應用范圍從原來的數據庫應用領域（定義數據庫中的完整性約束及觸發規則）擴展到企業建模乃至整個企業業務系統的開發方法中^[3]。要利用業務規則對業務系統進行分析和建模，規則本身的一致性與完整性分析就顯得非常重要，現有的規則描述方法很難對此進行分析并提供完整的理論指導，因此，有必要對業務規則的一致性維護方法進行研究。在對大量商業應用系統的業務規則類型及表達等諸多方面分析的基礎上，提出在系統開發的各個階段維護業務規則一致性的方法：

a）業務規則自身的一致性。自然語言描述的業務規則如下：

IF the card’s spend-money is greater than minimum integration

then card’s integration plus card’s spend-money.

類自然語言描述的業務規則如下：

if (card.spendMoney) > MININTEGRATION

then card.integration+card.spendMoney

如果卡、消費金額大于計提積分最小限額，則卡、積分額度+卡、消費金額

基于對以上兩種業務規則的表達形式的分析，業務規則描述中不一致產生的原因主要是規則概念的冗余和沖突，即同一自然語言描述的業務規則在轉換成對應的類自然語言描述時可能會產生不同的概念表達。因此，本系統在設計時基于本體來抽取業務規則的概念，采用OWL語言來建立業務規則本體，對于規則屬性限制的一些OWL公理^[4]本身就能夠保證規則表達式中規則屬性的一致性，消除冗余，防止沖突。通過本體中概念相似度的計算^[2]來找出和解決概念沖突，從而保證業務規則本體概念的一致性。

b）類自然語言描述的業務規則和程序語言實現的業務規則之間的一致性。

(a)通過限制來保證一致性。使用UML-OCL^[5]描述業務本體時，確保關聯兩端的實體必須具有不同的名字；任意屬性都不能與類具有相同的名字。

(b)通過制訂一致性規則保證一致性。

規則1 類自然語言描述的業務規則所引用的業務規則術語必須在業務規則本體庫中已經定義。

規則2 程序語言中實現的類及其屬性必須與業務規則本體庫中已經定義的本體類及屬性一一對應。

規則3 一條類自然語言描述的業務規則至多有一個實現類與其對應。

（c）業務規則庫和運行系統中業務規則的一致性。

通過使用設計模式來保證一致性。設計模式在業務規則系統的設計和實現中的使用，意義重大。設計模式捕獲了隨時間進化與發展的問題的求解方法，反映了不為人知的重新設計和編碼的成果。較好地運用設計模式來實現業務規則，可以減少程序代碼對業務規則庫的關聯和依賴性，實現業務規則庫和運行系統中業務規則的松耦合，從而可以很好地適應業務規則對時間和環境敏感并不斷進化的特點^[5]，滿足新的業務需求。例如：會話設計模式是一個對象結構模式，用來為子系統提供訪問界面以方便對子系統的訪問。正如人們所看到的，將一個系統分割成一系列相互協作的類需要維護相關對象間的一致性，使用此模式可以使類之間解除耦合，可以減少規則運行系統對業務規則庫的關聯和依賴性，縮減整個系統的復雜性，從而降低了由于業務規則庫編輯產生不一致的可能性。

模式比較如圖1所示。



3 基于本體的面向業務規則開發的商業應用系統

應用以上提出的針對業務規則的一致性維護方法，筆者設計了一種總體框架來指導實際的業務規則商業應用系統的開發，如圖2所示。

3.1 內嵌業務規則的商業應用系統的總體框架描述

1)位于最底層的數據庫層 該層主要包含了業務本體庫、業務規則本體庫、業務規則庫以及含有業務規則腳本的腳本文件庫。其中，業務本體庫和業務規則本體庫主要是存儲靜態的業務本體和業務規則本體以及動態的操作本體。業務規則庫主要是用于存放原子級的表述業務規則的源碼的數據庫，是規則執行時的數據源，其中包含業務和業務規則本體schema的鏡像及其實例信息。含有業務規則引用的腳本文件庫主要是調用和解釋業務規則，并將其用腳本模板中定義的參數來表達，供程序調用執行。



2）位于中心的業務平臺層 一共包含了以下三個部分：

a)業務本體編輯系統。其主要功能是建立商業企業的業務本體庫以及對業務本體的增加、刪除、更改的操作。

b）業務規則編輯系統。其主要功能是根據業務本體庫建立業務規則本體庫以及對業務規則本體的增加、刪除、更改的操作，并且利用已經建立的業務規則本體構建企業原子級的業務規則庫，另一重要功能是對業務規則本體庫和業務規則類庫中的業務規則本體的一致性維護。

c）程序代碼編輯系統。其主要功能是將業務規則類庫中的原子級業務規則嵌入到業務過程處理代碼中，并且進行編譯產生可以運行的程序，此處產生的運行程序共有兩類：（a）經過完整代碼編譯過程產生的運行程序，稱之為運行程序組A；(b)保留完整的業務過程但僅含有業務規則腳本的代碼編譯后產生的運行程序，稱之為運行程序組B。其中，在后面的分析中，會對運行程序組B的工作過程進行詳細介紹。

3)最上層即運行層 主要包含運行程序組A、B及規則報告。其中，運行程序組A是完整編譯后的業務流程執行程序，任何時候試圖應用最新修改的業務規則，都要全部重新編譯產生新的運行程序組；運行程序組B是編譯后帶有規則腳本引用的業務流程執行程序，與運行程序組A區別的是，B是在程序執行過程中通過規則腳本動態調用編譯并執行業務規則；規則報告是由業務規則編輯系統將業務規則以類自然語言^[3]的形式表達并將結果輸出到報告文件（如xml、pdf、word等）。

報告文件中的內容格式示例如下：

如果卡、消費金額大于計提積分最小限額，則卡、積分額度+卡、消費金額

其中：卡消費金額、計提積分最小限額和卡積分額度均來自于業務及業務規則本體庫中的描述。

4）數據準備引擎 它是在運行程序組B執行業務流程的過程中提供其所需的事實數據。有必要對參與一個具體業務過程的業務規則的數據類型進行詳細的說明如下：

a）業務過程中的數據，對應于程序開發時業務規則類中的局部變量。在業務過程表達中采用［業務規則類名］×［成員變量名］的方式來訪問。

b)業務過程外但在業務流程中的數據，對應于程序開發時業務過程中的全局變量。

業務操作算子產生的數據，如定義的各種函數方法（max、min、count等）。

3.2 業務及業務規則本體詳細描述

對于以上描述的內嵌業務規則的商業應用系統開發流程，數據庫層的設計與表達極為關鍵，業務及業務規則本體庫的建立能夠有效地避免業務規則的冗余、沖突等不一致性，其詳細描述如下：

a）業務及業務規則本體的表達。本文以大多數商業企業都包含的金融資源本體為例來說明業務及業務規則本體的表達形式，如圖3所示。



資源^[6]是參與企業業務或為業務所用的對象，它們在業務過程中被使用、消耗、產出或轉換。而金融資源（如資金、等價券、積分等）是資源的一個子類，是商業企業的生命線。金融資源本體^[7]的OWL形式化描述（部分）如下：



〈?xm lversion=\"1.0\" encoding=GB\"2312\"?〉

〈!DOCTYPE rdf:RDF[

〈!ENTITY rdf′http://www.w3.org/1999/02/22-rdf-syntax-ns#′〉

〈!ENTITY CARDBUSI′http://127.0.0.1/CARDBUSI#′〉

〈!ENTITY rdfs ′http://www.w3.org/2000/01/rdf-schema#\"〉

]〉

〈rdf:RDF xmlns:rdf=\"rdf;\"〉

xmlns:CARDBUSI=\"CARDBUSI;\"

〈xmlns:rdfs=\"rdfs;\"〉

〈--class tree--〉!

〈rdfs:Class rdf:about=\"CARDBUSI;finance_resource\"rdfs:label=\"金融資源\"〉

〈rdfsaubClassOf rdf:resource=\"CARDBUSI;resource\"/〉

〈/rdfs:Class〉

〈rdfs:Class rdf:about=\"CARDBUSI:funds\"rdfs:label=\"資金\"〉

〈rdfs:subClassOf rdf:resource=\"CARDBUSI; finance_resource\"/〉

〈/rdfs:Class〉

〈rdfs:Class rdf:about=\"CARDBUSI;equivalent\"rdfs:label=\"等價券\"〉

〈rdfs:subClassOf rdf:resource=\"CARDBUSI:finance_resource\"/〉

〈/rdfs:Class〉

〈rdfs:Class rdf:about=\"CARDBUSI;card\"rdfs:label=\"儲值卡\"〉

〈rdfs:subClassOf rdf:resource=\"CARDBUSI;finance_resource\"/〉

〈/rdfs:Class〉

〈rdfs:Class rdf:about=\"CARDBUSI;integration\"rdfs:label=\"積分\"〉

〈rdfs:subClassOf rdf:resource=\"CARDBUSI;finance_resource\"/〉

〈/rdfs:Class〉

〈!--Properly--〉

〈rdf:Property rdf:about=\"CARDBUSI;transform\"rdfs:label=\"轉變\"〉

〈rdfs:domain rdf:resource=\"CARDBUSI;funds\"/〉

〈rdfs:range rdf:resource=\"CARDBUSI;co_financier\"/〉

〈/rdfs:Property〉

〈rdfs:Property rdf:about=\"CARDBUSI;shift\"rdfs:label=\"轉移\"〉

〈rdfs:domain rdf:resource=\"CARDBUSI;card\"/〉

〈rdfs:range rdf:resource=\"CARDBUSI;com_institute\"/〉

〈/rdf:Property〉

〈!--Relation between Concepts--〉

〈rdf:Description rdf:about=\"CARDBUSI;轉變類型\"〉

〈CARDBUSI：instanceOf resource=\"CARDBUSI;Unix\"/〉

〈/rdf:Description〉

〈rdf:Description rdf:about=\"CARDBUSI;轉換類型\"〉

〈CARDBUSI:instanceOf resource=\"CARDBUSI;Sygate\"/〉

〈/rdf:Description〉

〈rdf:Description rdf:about=\"CARDBUSI;資源類型\"〉

〈CARDBUSI;instanceOf resource=\"CARDBUSI;資源\"/〉

〈/rdf:Description〉

〈/rdf:RDF〉

b）業務規則形式化描述。本文將業務規則形式化表達為：業務規則條目=if前置條件then執行操作，即

〈ruleStatement〉=if〈logicExpr〉then〈action〉

其簡單示例如下：

if(card.spendMoney) 〉 MININTEGRATION then card.integration+card.spendMoney

如果卡.消費金額大于計提積分最小限額，則卡.積分額度+卡.消費金額

其中，前置條件（logicExpr）主要包含邏輯運算、算術運算和已經定義的業務操作算子，分列如下：

（a）算術運算：

〈class〉.〈class.attribute〉≥〈value〉

〈class〉.〈class.attribute〉in〈〈valuel〉，〈value2〉〉

〈class〉.〈class.attribute1〉=〈class〉.〈class.Attribute2〉+〈class〉.〈class.attribute3〉

〈class1〉.〈class1.Attribute1〉 ≥ 〈class2〉.〈class2.attribute2〉

（b）已經定義的業務操作算子，一般包括sum、min、max、avg等。它們可以表述為

sum of(〈class〉.〈object〉)≥ (value)

sum of(〈class〉.〈object〉)≥ (value)

（c）邏輯運算（logicExpr為算術運算者已經定義的業務操作算子之間的與、或、非關系）：

〈logicExpr〉=〈logicExpr1〉〈and 〉〈logicExpr2〉|〈logicExpr1〉〈or〉〈logicExpr2〉|

not〈logicExpr1〉

4 實例應用

公眾城市一卡通是重慶市八大民心工程之一，公眾城市一卡通中心承擔著為市民提供便捷的小額消費平臺的重要任務。作為涉及到銀行交易、小額消費等領域的典型商業企業，隨著業務規模的迅速擴大和日交易量的不斷增加，原有的開發模式已無法快速適應不斷變化和迅速增加的業務及業務規則需求。本文在原有系統的基礎上，應用基于本體的面向業務規則的開發流程的指導下^[2，8]，開發了一套完整的能夠適應不斷變化的業務及業務規則需求的商業應用系統。目前該系統已經在公眾城市一卡通中心試運行。表1是三種開發模式的比較。

表1 三種開發模式比較

開發模式程序特點開發難度學習成本維護成本

沒有面向業務規則開發的商業應用系統業務規則采用硬編碼，代碼耦合度高符合大多數開發者的開發習慣，開發迅速，難度較低符合大多數開發者的開發習慣，學習成本低業務規則的任何變化都需要修改源代碼，易對程序結構產生影響，維護成本高

著名的業務規則系統或支持環境如Haley、ILOG、Jess 等動態可變業務規則模塊，代碼耦合度低以腳本語言(LISP、CLIPS等)為基礎，開發者接受難度高與傳統的開發語言不同，學習成本高業務規則模塊獨立，規則變化不會影響程序結構，維護成本低

基于本體的面向業務規則開發的商業應用系統動態可變業務規則模塊，代碼耦合度低，具備規則一致性維護功能符合大多數開發者的開發習慣，開發語言和技術也是常用的符合大多數開發者的開發習慣，學習成本低業務規則模塊獨立，規則變化不會影響程序結構，維護成本低

由于采用了基于本體的面向業務規則的開發思想，在系統開發初期，需要建立相關的企業業務及業務規則本體，耗費的人、月數相對較多，但是有了熟悉本體構建的系統分析人員的參與，構建出系統開發所需的企業業務及業務規則本體庫難度不大，圖4展示了采用三種不同開發模式進行系統開發所耗費的人、月數比較。通過比較，可以清晰地看到，采用基于本體的面向業務規則的系統開發流程來指導商業應用系統的開發，可以有效地降低開發周期，新增業務模塊帶來的成本開銷可以得到有效的控制。

通過使用基于本體的面向業務規則開發流程來指導商業應用系統，可以很好地解決業務規則的不一致性問題，僅以公眾通卡積分規則為例，有以下幾條自然語言規則：

積分價值規則：323積分=1元人民幣

積分獲取規則：刷卡消費1元人民幣獲得1積分



通過業務規則概念提取，本文在業務及業務規則本體庫中添加了卡消費金額、計提積分最小限額和卡積分額度等本體概念及其關聯，根據OWL公理^[4]保證本體概念表達的一致性，通過UML-OCL^[5]描述業務規則本體之間的關聯，根據UML-OCL規則^[5]保證業務規則本體關聯的一致性，如圖5所示。



5 結束語

基于本體的面向業務規則的商業應用系統流程，借助于本體的表達來描述業務規則術語，有效地解決了規則一致性維護問題，同時面向業務規則的系統開發使得應用系統的應用邏輯與業務過程邏輯分開，實現動態可變業務邏輯的模塊，增強了企業業務處理的敏捷性。而且，本套系統完全結合傳統的開發語言的特點以及面向大多數開發者的開發習慣，從而降低了學習和維護的成本，為業務規則系統的普遍應用提供了支撐平臺。

參考文獻：

[1]GUO Pei-jun， ZENG Dao-zhi， SHISHIDO H. Possibilistic conflict analysis for group decision[C]//Proc of IEEE International Conference on Systems， Man， and Cybernetics. 2001:1224 -1228.

[2]楊朝君. 信息系統中業務規則與約束的時態化研究[J]. 計算機應用，2007，27(1):196-198.

[3]徐黎，糜宏斌，馮元勇，等. 基于業務對象模型的業務規則語言的設計及實現[J]. 計算機應用研究，2005，22(1):36-37.

[4]林金嬌，王海洋. 基于業務行為與業務對象約束的業務規則研究[J]. 計算機科學，2006，33(11):256-258.

[5]于淼，王延章，劉繼山. 信息系統業務規則的設計模式[J]. 計算機工程，2004，30(6):27-28.

[6]劉云杰，龔傳信，劉鐵林. 業務本體開發與描述方法[J]. 計算機應用，2007，27(6):1423-1425.

[7]楊明華，錢樂秋，趙文耘，等. 特定領域本體的構造方法[J]. 計算機工程，2006，32（11）：80-82.

[8]ROSS R. Principles of the business rule approach[M]. Boston: Addison-Wesley， 2003.