基本介紹,定義,背景,現存問題,解決方法,特點及價值,
基本介紹
定義
Visual Rules可以在程式外部對軟體項目中所設計的業務邏輯進行單獨管理，並且提供多種語言的API藉口供外部程式調用，不限於JAVA。
Visual Rules可以集成到現有的軟體項目中，將軟體中經常容易發生變化的部分，獨立出來由規則庫進行管理，也可以用於直接開發web項目，Visual Rules可以為軟體項目生成90%以上的程式代碼，節約50%以上的軟體開發時間以及減少80%以上的軟體維護工作量。
Visual Rules是開發B/S結構軟體項目的利器，特別適用於快速開發基於J2EE結構的軟體項目。對於J2EE項目，一般其架構分為界面層、業務邏輯層、數據層。而Visual Rules提供了
● 資料庫管理器，可以生成幾乎全部的數據層代碼
● 規則編輯器，可以可視化快速開發業務邏輯
● 規則引擎，可以動態載入和執行業務規則
● 頁面模版編輯器及生成器，可以生成絕大部分界面層代碼
● 線上的業務規則管理平台，可以直接供客戶(包括非技術人員)直接修改軟體項目中實現的業務邏輯
Visual Rules解決了軟體開發中一直以來業務了邏輯層只能手工書寫代碼的問題，為業務邏輯層的實現童工了採用類自然語言(業務人員可以理解的語言)的可視化開發工具以及線上方式的業務邏輯編輯工具直接供業務人員修改相關邏輯。
背景
當前社會已經開始進入資訊時代，越來越多的企業和單位開始套用各種信息化系統來進行公司管理。包括財務系統、業務系統、辦公自動化等等，這些信息化系統對提高企業的競爭力發揮著越來越重要的作用。
同時，當前社會也是一個驚蟄鞥日趨加劇的社會，各行各業都面臨這殘酷的競爭，要求企業不斷地提高產品質量、服務質量並降低企業成本，從而要求企業不斷地改進業務流程、改善商業模式。使得為企業服務的信息化系統也必須根據企業的變化而不斷地變化以滿足企業新的要求。同時，信息化系統也要求其變化能夠快速、安全、穩定。
現存問題
商業需求的不斷變化，是目前軟體行業面臨的最大挑戰。據統計，80%的軟體項目最後都面臨失敗，其主要原因就是因為商業需求的變化造成軟體不斷地被修改，導致軟體問題隱患的持續增加，最終導致失敗。因此軟體項目的成敗關鍵看其能否滿足客戶需求的不斷變化。
客戶需求的變化主要表現在業務邏輯方面，目前已經普遍採用的三層架構技術就是希望解決業務邏輯不斷變化的問題。三層架構技術是將軟體分為界面層、業務邏輯層和數據層，將界面、邏輯、數據分離，其目的就是為了當業務邏輯變化時，只需修改業務邏輯層的代碼而無需改動界面和數據層的代碼。減少了因修改代碼而產生的問題。
但是僅僅採用三層架構技術在解決客戶需求不斷變化的問題方面仍然具有很大的局限性。
首先業務邏輯層採用編碼來實現，當業務邏輯變化時，需要軟體工程師修改程式代碼才能實現新的業務邏輯，一般需要經過需求變更、重新設計、編碼、調試、測試、發布等階段，周期往往在一周以上。這樣就導致不能快速滿足客戶的需求，同時手工修改代碼也增加了軟體不穩定性方面的風險，也大大增加了軟體的後期維護成本。
其次，客戶需求的變化在某些情況下不僅僅表現在業務邏輯上，有可能會變化數據結構。這樣勢必刀子劃修改資料庫層甚至界面層的代碼，改動可能會涉及到一些公共的程式代碼。手工修改的工作量很大，而且也增加了項目失敗的風險。
解決方法
Visual Rules採用規則引擎技術，將業務邏輯層的業務邏輯進一步分離出來，存儲在XML格式保存的規則檔案中，由規則引擎解析執行。同時提供一個可視化的操作界面可供客戶直接修改業務邏輯，無須採用程式設計師編碼的方式來實現。
同時，Visual Rules為基於web的開發提供了一套完整的web框架以及大量的公共控制項，將界面層、業務邏輯層和資料庫層徹底分離。同時其提供資料庫管理器滿足了數據結構的變化時，可以快速生成全部資料庫層代碼；提供頁面模版編輯器以及頁面生成器滿足了數據結構變化時，可以快速生成幾乎全部界面層。無須再採用手工編碼的方式來滿足數據結構的變化。
特點及價值
Visual Rules是在規則引擎基礎上發展出來的一款產品，其秉承了規則引擎可以使業務邏輯的變化可以獨立於程式之外的特點，同時結合國內軟體項目的特點，為資料庫層和界面層也提供了獨立於程式之外配置的特點，因此本產品不光是一個業務規則管理系統，還是一個基於規則引擎的web快速開發平台。與國際上其他的業務規則管理系統相比，本產品具有以下特點：
順序執行的規則引擎算法
傳統的業務規則管理系統，其規則引擎的算法基本上會採用reta算法，其基本原理是運行階段判斷哪些規則符合條件，然後去決定其執行軌跡，這類似於人工智慧的思想，當然其最初出發點也是為了人工智慧判斷。由於業務系統業務邏輯的頻繁變動，因此希望可以利用規則引擎來實現業務規則的配置，因此也就自然將reta算法作為業務系統中業務邏輯的執行算法。但是這兩者其實是不一致的，業務系統中的邏輯一般是確定的，有著明確指定的執行先後順序的。而reta算法是動態決定順序的，因此在用reta算法描述業務邏輯時，往往顯得非常瑣碎，並且其速度也比純粹用程式描述要慢很多。Visual Rules不再採用難以描述業務邏輯的reta算法，而採用順序執行的算法來描述業務邏輯。這樣描述業務邏輯和並平時用流程圖和文本來描述業務邏輯就沒有多少區別。可以最簡單話的配置業務邏輯，同時其速度和手寫程式的速度是一致的。Visual Rules是真正的為業務系統中業務邏輯的實現而設計的，是軟體項目業務邏輯實現的最佳選擇。
公共規則、循環規則、關聯決策表
由於規則執行算法基於順序執行的算法，因此在描述業務邏輯上比reta算法有更多的展現形式，特別是可以通過規則集來定義多個規則的共同條件以形成執行的分支，或者用來描述循環運行的一組規則。另外在決策表的支持方面也有三種方式，二維決策表、多維決策表以及關聯決策表，以更方便的形式來描述邏輯。同時規則還支持否則如果(else if)方式的條件，進一步增強了規則描述業務邏輯的能力。
動態的參數接口、資料庫接口和Excel接口
傳統的規則引擎如JSR94描述的規則引擎調用接口採用Java類來傳遞值，這種方式使得接口的數據結構不能像規則一樣變動。Visual Rules通過Map來傳遞值，因此其接口的數據結構是可變的。同時傳統的規則引擎一般可以通過設定來直接調用Hibernate等外部資料庫對象，這樣其實就是通過類和XML來定義了資料庫的調用接口，這種方式就不能使資料庫對象不能像規則一樣靈活變動。因此VisualRules採用List來定義資料庫對象接口，這種方式使得資料庫對象也是可變的。傳統的規則引擎一般不能直接操作Excel數據，但是在實際的業務邏輯的套用中，部分數據並沒有存儲在資料庫中，或者需要用Excel來展現數據。Visual Rules可以直接來操作Excel檔案。
記憶體表格
業務系統的業務邏輯實現有個特點，就是基本都是批量處理的處理，並且很多數據存儲在資料庫中。但是如果在實現業務邏輯時，頻繁的去訪問資料庫，會使得整個業務邏輯的實現效率很低。因此VisualRules設計了記憶體表，可以將資料庫中的數據先取出後放到記憶體表中，然後通過記憶體表相互之間做匹配或匯總處理。這樣極大的提高了執行效率，而且也增強了業務邏輯層實現的功能。
最小化規則引擎
做開發平台最關鍵是運行時的穩定和性能。因此VisualRules採用最小化的規則引擎，規則引擎只處理規則包的載入和調用，不處理規則語法以及規則解析工作。在開發規則時，開發平台根據規則語法將規則包靜態編譯成可執行的java代碼，這樣最大限度的保證的規則運行平台的穩定。同時將規則的開發平台和運行平台分離，使得運行平台不會隨著規則語法以及功能的增強而變化。
基於模板的頁面配置開發
在頁面表現層的實現上，當前最流行的技術就是採用Ajax來實現界面的表現。但是在表現邏輯的實現上，一般情況下，我們會基於一套框架（比如Ext、Dojo、JQuery等），然後再通過javascript來編寫具體的邏輯代碼。但是這些表現邏輯代碼其實是非常晦澀難寫的，而且也不能體現所見即所得的效果。Visual Rules將基於框架的組件配置信息單獨提出來，通過圖形化界面來設定所需要的參數，然後根據模板生成對應的代碼。這種方式類似於代碼生成器方式來生成界面層的代碼，其開發工作量是最小的。
Visual Rules可以取代當前業務邏輯層和數據層所有的操作代碼，準確的說，可以取代從Struts、Spring、Hibernate這些相關的代碼。Ajax直接通過通用的Servlet來訪問規則包。這種取代方式，極大的簡化了後台代碼的開發，同時也使得業務邏輯層更加快速適應業務需求的變化。規則引擎可以有效的和當前主流的Ajax框架進行互動，也可以在Jsp中，通過java代碼來訪問。頁面層代碼可以通過頁面配置器來根據模板生成，也可以手工編寫。
基於以上這些特點，使用Visual Rules可以為用戶帶來一些這些價值：
軟體系統隨需而變
軟體系統最大的價值就是體現在系統運行的過程中，隨著用戶業務的變化，軟體能夠快速的加以適應，而不是成為業務發展的障礙。因此軟體變更的回響時間以及影響，是衡量軟體價值的關鍵。Visual Rules使得軟體系統可以“零時間”回響用戶需求的變化，真正的做到了軟體系統隨需而變。
降低軟體成本
採用Visual Rules開發軟體系統，可以減少項目開發所需要的人員數量，同時也減少了每個人的工作量，使得項目的周期縮短。因此visual Rules可以減少軟體開發的成本和縮短軟體開發的時間。同時由於Visual Rules提供了方便的配置工具，可以在軟體項目後期維護階段快速適應需求的變化，因此軟體的維護階段，當有需求變更時，不再需要安排程式設計師去維護。而是一般的技術支持人員甚至客戶本身就可以實現變更工作。這使得安排一個技術支持人員就可以同時支持多個項目的維護工作。而不像原先那樣，當維護時需要安排原先的程式設計師來進行對應。因此使得軟體項目整個成本屬於完全可控的範圍以內。
提高軟體復用
