業務規則挖掘最佳實踐

業務規則挖掘最佳實踐

以下是關於技術規則的語義捕獲及其抽象成業務規則的通用方法。

準備步驟

一系列準備工作有助於避免冗長的規則挖掘過程，確保規則對業務有價值，並加快建立“業務”規則而非僅僅“技術”規則的過程。建議採取這些步驟以建立正確的組織框架，並使規則挖掘與業務優先順序相一致。

1. 專案目標和預期輸出

定義規則挖掘活動的目標和輸出非常重要。這將根據組織的業務優先順序而有所不同。對於一些組織而言，目標可能是解決高度價值且定製化應用的靈活性不足或高停機時間問題。這可能導致將應用遷移到支援 SOA 的打包應用程式的決策。

根據目標，規則挖掘活動可以產生兩種主要結果。

文件在某些情況下，目標可能是開發面向業務的程式程式碼段文件。這種文件對其他分析師和主題專家而言是寶貴的參考，也可以用作現代化、待開發應用程式的高階設計模型的裝飾。它通常不會生成可執行的業務規則，也不會成為開發環境的輸入。

業務規則在其他情況下，需要將應用程式中編輯和計算的確切語義行為捕獲為真正的業務規則。捕獲的語義將用作目標開發環境的基礎，甚至直接輸入到目標開發環境。此步驟的結果將驅動有關技術採用、資源規劃以及應用於兩種規則挖掘型別最佳方法的決策。

2. 規則挖掘技術選擇

主要採用手動方法規則挖掘技術的低成本、低價值應用是在文字處理或電子表格應用程式中記錄規則。這種方法不能幫助解決規則挖掘中最耗費資源的部分，例如分析應用程式行為並在原始碼段中定位規則。

執行時模擬幫助將使用者行為捕獲到流程和規則中的執行時模擬技術，可以從行為方面提供幫助。其主要缺點是，它們僅限於給定時間段內實際執行的測試場景，可能遺漏通常不會執行的關鍵異常。

掃描工具能夠在原始碼中定位模式的文字掃描工具，可以加快基於原始碼中固定模式的規則捕獲（例如，顯示對變數的所有移動）。這些工具通常會生成大量誤報，並且往往導致技術規則而不是業務規則。

基於儲存庫的規則挖掘工具基於儲存庫的技術可以重新編譯原始碼並構建語法解析樹，這可以為規則挖掘提供最高價值。最先進的工具使用語義分析自動檢測規則，例如，從興趣點變數上游的每個語句，以及可能影響其值的語句，都被挖掘為候選規則。

規則挖掘工具還可以提供規則管理和審計功能，便於專案工作流程和評審人員進行規則維護活動。它們還能夠保留規則與原始碼之間的可追溯性，即使原始碼發生變更（在即時環境中經常發生）也是如此。

考慮到以上因素，規則挖掘的低成本方法的權衡將是更高的手動工作量和較低的結果質量。這在一線性、小規模文件場景中可能是可以接受的，但在企業級現代化工作中則不太可能如此。

3. 時間和資源分配

專案目標和技術選擇將影響資源分配。在很多情況下，業務方面的期望是收到從應用程式語義中推匯出的精確建模的業務規則集，而沒有意識到這種努力的複雜性。在 IT 方面，沒有規則挖掘經驗或對應用程式主題不熟悉的從業人員無法提供可靠的估計。

可以採用迭代方法來估計時間和資源。在最初的幾周內，針對應用程式的代表性子集挖掘規則，可以洞悉最適合所選應用程式的方法，以及用於估計總體工作量的標準。

4. 業務流程對映和對齊

挖掘的邏輯很重要，因為它具有業務上下文。畢竟，邏輯是更廣泛的業務流程的子集。只有將挖掘的規則置於相關流程的上下文中，這些規則才有意義。例如，根據客戶的郵政編碼將她分配給收入範圍，在信貸審批和營銷活動流程中可能具有不同的意義（例如，保險公司會宣傳他們只會檢視過去的行為，而不是信用評級來設定保費）。

此外，在業務流程上下文中檢視應用程式對於確定規則挖掘活動的優先順序非常重要。企業通常從其流程的角度看待自己，例如註冊新客戶、承保保單、收款、註冊索賠、將資金存入賬戶等等。其中一些流程對組織至關重要，而另一些則僅僅是商品功能。一些流程可能滿足業務線主管設定的服務水平協議，而另一些則沒有。現代化活動將根據這種計算來確定重點。

一旦業務流程建模完畢，就確定支援所選流程的應用程式元素。從歷史上看，這些應用程式是孤立組織的，這使得高階匹配成為一個簡單的步驟。然而，在更細粒度的層面上，單體訂單管理應用程式可能處理客戶註冊、信貸審批、訂單錄入和訂單履行。如果組織只對客戶註冊和訂單錄入元件的規則挖掘感興趣，那麼在流程及其支援的應用程式組合元素之間進行對映練習將是有益的。

藉助基於儲存庫的軟體，應用程式物件會被註冊，並且會自動捕獲物件之間的語法和語義關係。

記錄重疊情況，即程式或資料儲存服務於多個業務流程的情況。

示例 - 客戶訂單

在下圖 1 中，客戶主資料、訂單主資料和庫存資料儲存都在規則挖掘的範圍內，儘管它們支援範圍之外的其他流程。類似地，客戶處理程式是單體的，並且包括信貸審批的邏輯，而信貸審批超出了此範圍。

圖 1：業務流程對映到應用程式物件

5. 應用程式分析

在之前的步驟中，已經對應用程式進行了清單，並且在較高層面上已經瞭解了目標業務流程在應用程式工件中的位置。下一步將是將應用程式分解為其組成邏輯元素。一個關鍵因素仍然是上下文化。與組織優先順序無關的應用程式元素被排除在外。這種透過上下文的範圍界定使我們能夠看到規則及其相關影響的“邊界”。

應用程式分解

在此步驟中，應用程式將進一步分解為其詳細元件。目標是獲得足夠詳細的工件集合，以便作為規則挖掘步驟的輸入。

同樣，技術可以提供幫助。基於儲存庫的軟體可以建立詳細應用程式物件及其關係的解析樹。然後，此資訊以多種圖形和文字檢視呈現，這些檢視彼此同步，以便於進行上下文敏感分析。

例如，上下文檢視將以壓縮的概述模式顯示程式中的所有資料欄位宣告、過程和過程呼叫。詳細的原始碼檢視將顯示與上下文檢視相對應的程式碼段，允許透過上下文檢視快速瀏覽程式。透過上下文檢視的遍歷，使用者可以快速瞭解程式的結構和複雜性。

其他在詳細程式級別可用的檢視包括段落之間控制流的圖表、段落內的邏輯流程圖、執行路徑和針對所選條件結果的執行時模擬器。這些工具用於在實際開始規則挖掘階段之前深入瞭解應用程式。

在沒有自動解析工具的幫助下，仍然可以透過對應用程式工件進行手動檢查和演練來獲得價值。

排除項識別

在審查和分析應用程式的過程中，出於功能和技術原因，不應包含在規則挖掘範圍內的元素將被標記。這些元素可能包括標準實用程式、報告、系統例程和超出範圍的業務流程。在圖 1 的示例中，這將包括與信用審批和訂單履行相關的工件，由於其作為商品、標準化業務流程的性質，因此超出範圍。

排除項的識別說明了從上述前期業務情境化步驟中獲得的好處。如果這些步驟沒有進行，則“全面掃描”方法會導致在規則挖掘和 SME 審查階段投入更多，因為來自商品業務流程的規則首先會被挖掘，然後會被捨棄，因為它們是無關的。

6. 詞彙表建立

從應用程式中挖掘規則的一個主要挑戰是，在應用程式內部導航各種變數和命名約定可能很困難。這些約定通常與業務術語之間存在著微妙的聯絡，並且可能使從業務角度理解邏輯變得困難。

最佳實踐是改進這些技術術語，以建立一個更以業務為中心的檢視。這可以透過應用程式物件和相關業務術語的詞彙表來實現。物件可以是資料欄位、段落、程式、資料來源以及其他感興趣的應用程式物件。

術語詞彙表的來源可以是業務文件、資料字典、資料庫模式、使用者通知，甚至原始碼註釋。

自動規則挖掘工具提供了一種機制，用於傳播應用程式中重複模式（通常稱為“令牌”）的值。例如，令牌“ACCT-”可以在任何地方被替換為“Account-”。然後，工具將使用詞彙表業務名稱來替換自動構建候選規則中的技術術語。

7. 規則組成和層次結構定義

預先確定所需的規則格式。用於設定訂單折扣的相同規則可以採用不同的形式，例如

(i) 宣告性形式：“每個來自加州的 AAA 高階會員都將獲得 5% 的折扣。”

(ii) 如果-那麼-否則形式：如果申請人是高階會員，那麼如果她是 AAA 會員，那麼如果她居住在加州，則分配 5% 的折扣。

(iii) 作為決策表中的條目

圖 2：決策表中的條目

將其他資訊和工作流屬性附加到挖掘的規則可能很有用，例如

• 審閱者文字註釋
• 規則型別（輸入/輸出、計算、驗證、安全）
• 稽核狀態（已批准、未批准）
• 工作流狀態（提取、工作、接受、拒絕）
• 轉換（有效、需要修改、重複、完成）
• 審閱者身份
• 程式來源
• 程式碼段位置（開始、結束）
• 程式碼段文字
• 輸入和輸出資料元素

規則還將放置在層次結構中。所有代表決策或在給定條件集下執行的規則可以分組到規則集中。規則集將被分組到更高級別的活動節點，反映它們當前參與的業務流程。

如果您計劃填充可執行的業務規則管理系統 (BRMS)，您將希望定義一個易於傳輸到所選特定目標環境的模式。如果目標環境尚未確定，請參考現有的業務規則標準。

8. 規則挖掘工作流

企業規則挖掘通常是一個多步驟過程，涉及具有不同技能集的從業人員，包括顧問、開發人員、架構師、分析師和主題專家。關鍵人員經常會被其他專案分散注意力，因此定義和記錄通用工作流至關重要。

按照本文件中進一步提供的指南，高階工作流可能如下所示

圖 3：示例規則挖掘工作流

每個步驟都應根據採用​​的方法、專案範圍和約束以及規則挖掘技術的使用來詳細定義。前幾個步驟可能會有多次迭代，直到規則處於已批准的最終格式。

規則挖掘步驟

9. 候選規則的挖掘

此時，規則是從對映到先前步驟中確定的業務流程範圍的應用程式工件中挖掘的。規則挖掘工具可幫助您確保排除的工件不包括在範圍內，方法是使應用程式能夠組織成子分組。將針對子分組而不是針對整個應用程式挖掘規則。

採取的具體規則挖掘方法主要由應用程式模式和期望的輸出驅動。

自頂向下方法

自頂向下或面向流程的方法從線上應用程式中使用者介面或批處理應用程式中作業流程的檢查開始。

在線上應用程式中，使用者選擇選單選項或在螢幕上輸入值可以呼叫事務。識別定義從螢幕傳送到介面應用程式的訊息或事件的欄位。觸發訊息中的每個欄位都可以被視為規則挖掘的種子欄位。

以種子欄位作為起點，記錄對該欄位的所有下游資料影響，包括所有條件排列。每個資料轉換（移動到另一個欄位或計算）都表示要捕獲的候選業務規則。

規則挖掘軟體工具透過視覺化每個種子欄位的每個資料影響路徑，直到它被新值填充或透過比較、值傳播和計算用作其他欄位的輸入，從而幫助完成此任務。在每個這樣的點，該工具可用於記錄底層的業務規則。自動規則檢測方法也可以應用於捕獲每個螢幕欄位編輯作為候選規則。

在批處理應用程式中，概念是類似的。識別作業流程的一部分，例如實現業務流程的作業控制語言或其組，並挖掘與該流程相關的單個程式中的所有規則。

圖 4：自頂向下規則挖掘

在上圖 4 中，請注意生成的“派生候選規則”的格式。它們是從 Cobol 程式中自動檢測到的，類似於它的構造，變數名稱被詞彙表定義替換。這些規則將在以後進行審查，並轉換為更符合業務的格式。雖然此示例是針對 Cobol 應用程式展示的，但高階挖掘工具可以應用於從 PL/ 和 Natural 到 Visual Basic 和 Java 的廣泛語言。

自底向上方法

自底向上或面向資料的方法從檢查系統輸出開始 - 傳送到檔案（批處理和線上）、螢幕和輸出訊息（僅限線上）的資料。

遵循這種方法，規則的捕獲是透過從一個有趣的資料點開始，識別影響該點的所有邏輯來實現的。例如，訂單折扣欄位受從其上游計算的折扣的影響，具體取決於客戶的居住地。

圖 5：自底向上規則挖掘

規則挖掘技術特別適合這種方法。透過視覺檢查或儲存庫查詢，可以快速識別出感興趣的資料輸出。然後，自動規則檢測例程能夠為影響感興趣點的每個語句捕獲候選規則。由於先前已組織到上述情境化子分組中，因此搜尋結果將受到被認為與規則挖掘相關的業務流程子集的限制。

檢查相關的 DBMS 表也可能生成嵌入在鍵中的規則，以及用於參照完整性和值約束的任何資料規則。一旦涵蓋了所有感興趣的資料點，面向現有輸出的所有感興趣的應用程式邏輯基本上就已經挖掘完畢。

混合方法

混合方法結合了上述兩種方法

• 第一步是自頂向下捕獲相關事務；
• 對於每個事務，執行自底向上的規則挖掘，僅包括尚未為其他事務挖掘的資料輸出。

這種方法的好處是擴充套件了規則挖掘的覆蓋範圍，同時避免了重複。

與上圖 4 和 5 中所示的示例相關，嚴格遵循自頂向下的方法會導致對數量和價格欄位的重複工作，因為它們都遍歷了相同的下游資料影響。覆蓋範圍也不完整，因為沒有發現客戶折扣的所有規則。

讓我們考慮一個涉及訂單輸入和提案簽發流程的擴充套件案例。採用排他的自底向上方法也會導致重複，挖掘針對多個輸出（例如客戶折扣規則）“命中”的上游資料影響的規則。使用混合方法，我們將首先從所有訂單事務輸出中挖掘規則，然後只從特定於提案事務的輸出中挖掘規則。

圖 6：混合規則挖掘

10. 候選規則驗證

此時，在從應用程式中挖掘出候選規則後，驗證和更正是確保規則的正確性和完整性的必要步驟。

檢查候選規則以確保

準確性 每條規則是否正確反映了底層應用程式行為？如果使用了自動規則檢測技術，則在感興趣點（種子欄位）處的規則將先於來自其上游的規則，可能帶有觸發器、控制條件和自動規則集分組。對它們中的每一個（或選定的子集）進行準確性審查，並在需要時進行更正，直到結果令人滿意。

冗餘 同一條規則或規則集是否在同一應用程式流程中出現兩次？當針對兩個共享上游功能的不同輸出分別挖掘規則時，可能會發生這種情況。或者，它可能是簡單疏忽的結果，例如多個團隊成員無意中從相同的程式碼庫中挖掘規則。規則屬性用於標記重複。

另一種形式的冗餘發生在語義上相同的規則從不同的流程（例如訂單詳細資訊和提案）中分別挖掘出來，並使用不同的名稱時。這將在下一步解決，您將在下一步將候選規則轉換為業務規則格式。

完整性 除了預定義的例外情況外，所有應用程式功能是否都已涵蓋？匹配挖掘的規則來源與總體來源的規則覆蓋率報告可以提供答案。

相關性 每個挖掘出來的規則都可以被視為候選業務規則嗎？雖然這還沒有進入 SME 審查階段，但可能存在某些結構，經檢查後，顯然無關緊要，不應包含在要審查的規則範圍內。安全驗證規則、維護例程和超出範圍的操作都可能屬於此類。在規則屬性之一上指示相關性。

11. 候選規則轉換為業務規則格式

在前面的步驟中，候選規則已經過挖掘和審查，反映了遺留應用程式的行為。這些規則嚴格遵循應用程式的流程流程和操作。

現在需要一個轉換步驟，將候選規則轉換為可供審查的實際業務規則。此步驟由應用程式專家、規則架構師或主題專家執行。在審查和轉換後，捕獲的業務規則反映了當前的現狀，作為目標環境的基線或比較。

重新格式化為業務規則表示法

如果候選規則是手動構建的，它們可能已經採用所選的業務規則格式。在其他情況下，它們可能以技術格式捕獲（例如從原始碼中剪下和貼上），並將需要一些修改和重新分組。

如果使用了自動規則檢測工具，則生成的候選規則可能會有點類似於業務規則，透過使用詞彙表定義將業務名稱放在規則名稱、資料元素和控制條件中。但是，即使在規則驗證步驟之後，大多數批准的候選規則也需要進行調整以符合所選的業務規則表示法。

圖 7：業務規則轉換

事實建模和規則規範化 由於其程式性，遺留應用程式往往將業務邏輯鎖定在特定於流程的孤島中。但是，真正的業務規則獨立於流程，應該如此維護。

在我們的示例中，訂單詳細資訊條目和建議條目事件的規則已分別挖掘並放置在規則集中。它們都是獨一無二的嗎？經過進一步檢查，它們中的大多數邏輯在設計上是相同的。從業務的角度分析結果，任何客戶文件（無論是訂單還是建議）的各個部分之間都存在共性。

從工具的角度來看，此時可能更有意義地切換到業務規則管理系統，將從規則挖掘工具中挖掘出來的規則匯入，如下面的整合部分所述。

使用 BRMS 或視覺化建模工具，構建一個事實模型，反映在現有應用程式中發現的重要業務實體及其相互關係。這些將連結到挖掘出來的業務規則，並作為目標規則模型的基線。

在我們的示例中，事實模型的一部分將是

完成此操作後，將業務規則規範化為表示所需的業務級別語義

…從而使客戶文件處理規則適用於訂單和建議。

分組和排序

此時，將考慮生成的規則分組和排序。一個關注點是規則與其他規則和規則集之間的觸發關係。由於候選規則通常是從第三代語言應用程式（如 Cobol 或 PL/I）派生的，因此它們以程式方式自動排序。轉換為宣告性模式將消除本質上非業務的程式元素。

如下圖 8 所示，反映真實業務需求的宣告性關係將被建模為規則與其他規則或規則集之間的觸發器。在大多數 BRMS 環境中，單個規則可能會觸發多個規則和規則集，其中每個觸發規則或規則集的排序僅在執行時預編譯或解析。

圖 8：現狀業務規則模型（事件驅動）

主題專家審查和批准

一旦挖掘出來的規則被轉換為業務規則，它們就會被交給主題專家 (SME) 和/或業務分析師進行審查和批准。

通常，SME 此時不會對規則進行重大更改。規則挖掘工具可能包括規則歸屬功能，以幫助 SME 並使他們能夠將業務規則標記為

• 已批准或拒絕；
• 重新分類到其他類別；
• 使用文字描述屬性新增其他資訊。

規則挖掘工具通常還提供以預定義的 SME 活動為中心的 Web 門戶。這可以大大加快審查和批准流程。

12. 報告製作

業務規則報告以硬複製或數字格式建立。規則挖掘工具會生成報告和圖表，以在您選擇的上下文中描述詳細或摘要規則資訊：層次結構級別、分組、搜尋結果。這些報告既作為審查步驟中的參考，也作為記錄的文件。

13. 與目標環境整合

根據所採用的現代化策略，與其他環境的整合需求將有所不同。

業務規則開發

採用業務規則方法的重新開發通常會利用 BRMS 創作環境。這些工具通常包括 XML 匯入功能，用於定義“現狀”業務規則空間，允許規則開發人員有選擇地重新使用被認為與目標環境相關的候選規則。這將提供從新部署的規則到其遺留來源的寶貴（有時是至關重要的）可追溯性。

傳統開發

這種方法通常涉及使用全面的開發工具包構建 Java 和 .NET 應用程式。通常，UML 模型將用於在實際程式碼生成之前定義邏輯應用程式檢視。

在這些環境中，挖掘出來的業務規則可以作為 UML 類中的行為附加，以利用它們。例如，包含 Order_Discount 作為屬性的 Order_Invoice 類，還可以包含 Calculate_Order_Discount 作為類行為。此行為可以從執行相同功能的挖掘出來的業務規則中派生（並可能匯入）。

BPM

流程管理 業務流程管理 (BPM) 工具促進流程模型建立以及與底層規則和可執行服務的連結。它們還包括定義工作流規則（使用 BPEL）的能力，以管理活動節點之間的手動和自動轉換。

在這種情況下，每個活動節點都可以由業務規則實現。規則集和支援的活動之間可能存在多對多關係。使用相關的挖掘出來的“現狀”業務規則填充 BPM 流程可以“閉環”業務分析師，並顯著推動 IT/業務對齊目標。

需求管理

供應商產品還包括需求工具，這些工具可以定義高階用例、詳細流程圖和活動，以實現有效的應用程式開發和管理。在這些環境中，可以匯入挖掘出來的業務規則，並將其附加為核心需求或活動節點的文字註釋。

SOA 使能

現有應用程式的服務使能涉及程式碼重構和作為服務封裝部署。規則挖掘步驟在原始碼中查詢細粒度服務並提供所需的服務元件方面非常寶貴。例如，計算訂單折扣的自動規則檢測結果將包括所有導致最終計算的程式碼段。透過僅使用該程式碼（及其依賴項）建立元件切片，可以將訂單折扣計算重新部署為服務。

14. 主動規則管理

我們預計大多數應用程式將在未來幾年內繼續維護和維護。從它們中挖掘出規則後，至關重要的是要繼續更新它們，並使其與未來的應用程式更改保持同步。規則挖掘工具提供維護和管理功能，包括

• 即使規則已因整體原始碼更改而移動，也要自動將規則與原始程式碼段對齊；
• 手動規則更改的審計跟蹤；
• 允許在規則挖掘後進行單個或批次更改的“更改器”例程。

結論

對業務規則挖掘的定義明確的方法將使業務上下文化能夠儘早地在流程中進行。上下文化步驟不僅有助於正確地構建挖掘出來的規則，而且還將減少規則挖掘投資，使其只專注於感興趣的關鍵和動態業務流程。無論採用哪種應用程式現代化策略，本文介紹的最佳實踐和工具輔助方法將幫助您以更低的成本、更少的重複和更高的質量結果實現您的目標。

註釋和參考文獻

1. NEUER，Mannes。 語境為王：規則挖掘的實用方法