業務架構平台 livebos 與輔助開發平台之他見 (引用)

業務架構平台與輔助開發平台之我見   引用 http://www.itpub.net/thread-1005375-1-1.html hiraymail@126.com    QQ:20709610    一、業務架構中介軟體 livebos 與輔助開發平台的系統實現方法的差異     在整個軟體開發項目的過程中，都要經曆在軟體需求分析、系統設計、系統實現的過程，即使我們採用了組件化的開發、物件導向的設計，還是會發現，分析設計人員、程式員和使用者之間，仍然無法溝通的很好，應用系統在交付使用者使用時，仍然離使用者的真實意圖比較遠。這是因為，提出需求的使用者和系統設計的技術人員看問題的角度不同。     使用者是從業務的角度，提出應用軟體是哪個職能範圍的、有哪些應用模組、每個模組又有哪些子模組，這是一種基於“業務對象”的描述方法。而開發人員則是從技術的角度，架構是什嗎？資料庫的結構是什麼樣的？表間關係是什嗎？商務邏輯如何編寫？頁面展現如何設計？這是傳統的“組件”或“構件”思路。所以，使用者和開發人員之間溝通起來仍然很難，業務實現及業務調整都依然為軟體開發項目帶來很大的難度和不可控因素。     而對應與應用系統實現，軟體開發平台為瞭解決這些問題，經曆了語言級開發到輔助開發平台的升級，直到我們所提供的面向業務架構的中介軟體平台。     而輔助開發平台源自與語言級軟體開發環境，是從軟體項目架構和程式開發過程各環節的開發效率上增加了許多特色的工具，從而為Team Dev、開發人員提供了更為高效的開發工具和項目控制與組織管理的手段，最終為整個項目降低了開發成本，提高了開發效率，但這並未真正意義上解決上面的問題。     例如：基於軟體輔助開發平台，我們依然遵循需求分析，資料庫建模，商務邏輯建模，頁面設計，調試跟蹤，測試，發布等過程，但是在每個節點上輔助開發工具都會提供相應廠商所特有的“視覺化檢視”以減低過程的操作難度，提升開發效率。     我們從軟體系統開發實現的過程來看，開發人員會按照調研的需求分析報告，按照資料庫建模，商務邏輯建模，頁面設計的過程對業務需求進行分層的電腦語言轉化，然後再將商務邏輯與物理資料庫、展現頁面與商務邏輯之間建立映射關係，之後在開始跟蹤調試，最終發布應用程式。在這整個過程中程式員會利用輔助開發平台的“視覺化檢視”進行配置和關聯，去自動產生系統的70%-80%的代碼，複雜商務邏輯仍需手工代碼編寫實現。這對開發人員來說確實減低了很大的開發工作量，具體體現在開發過程中的普遍性及通用性的工作量，細節性的複雜商務邏輯處理難度和工作量並沒有得到改善，這大概會佔20%-30%的代碼量。     但是軟體系統的並不是一成不變的，隨著業務需求的升級，軟體系統功能及業務處理必須進行同步的更新，例如資料結構上需要增加一個欄位，這時就會涉及物理資料庫的調整，也會涉及商務邏輯的調整和頁面展現的調整等等，當然也包括各層面的映射關係的調整。這時不管是哪個方面的調整都會影響其他層面的設計，而且既可能是通過“視覺化檢視”自動產生的程式碼部分，也可能是自訂的代碼部分，而這種雖然只是系統從1.0到1.01的升級，都需要我們調整這0.1的升級部分所涉及的三層調整，以此看來並不是20%和80%的關係了，而是100%的調整。     而面向業務結構的中介軟體平台又是如何解決上述問題的呢？     業務架構平台是以業務對象建模為核心的業務中介軟體及其整合開發工具。在它的支援下，應用軟體徹底實現“業務驅動導向”的軟體開發模式，並實現“應您所需，隨時而變”的應用系統。基於業務中介軟體平台，開發人員只需要基於業務和管理的層面，而非技術的層面來理解、設計、構架和整合企業的資訊系統（基於業務層面是指開發人員只需描述企業的組織機構、商務程序、商務資訊、業務資源、商務邏輯、業務事件等業務內容，而不考慮技術層面的東西），就可以實現各類基於WEB的高層次的資訊化應用。而且，使用者可以隨時在運行中重新定義或調整業務模型，從而達到使自己的資訊系統完全貼近不斷變化的業務需求，這也是“靈動”的價值體現。     在這樣的平台裡，開發人員所關注的就是“業務模型”，在整合式開發環境中通過對“業務對象（BO）”的分析來設計描述模型，而“業務模型”的處理流程通過“商務程序（BP）”來描述業務對象的邏輯關係，業務模型提交至中介軟體伺服器後自動會產生標準應用程式系統的三層架構，自動建立關聯映射關係。當業務對象調整時，只需要修正業務模型重新提交至伺服器，伺服器又自動修正應用系統中的每個層面，關聯映射關係會自動關聯。     通過以上我們可以看出，隨著兩大主流語言開發工具的發展，輔助開發平台的生存空間將會不斷縮小，這主要源自各種輔助開發平台的初衷只是語言級開發工具的補充，事實上這是一廂情願的做法，從電腦語言的發展趨勢來看，它將是主流的語言開發工具的過度品，這種現象在微軟.net架構的VS上已經有了較大的體現。而且我們通過對各種輔助開發平台的對比可以看出，其核心的差異主要體現為：一方面商務邏輯分解上的顆粒度粗細不同，組件、構件、服務……；另一方面所提供的工具的便捷性不同，可視化、圖形化、嚮導模式、拖拽模式……；而這些“差異特色”都將會在主流語言的開發工具的逐步體現。     而業務架構平台則是在開發工具之上的業務模型描述工具，它與開發工具之間是分工關係，可以基於.net也可以基於J2EE，而且他會隨著開發語言的發展而越來越強大，畢竟業務模型的建立永遠是在系統開發設計實現之前。 二、業務架構中介軟體平台的特性       1、業務模型的重用：通過業務架構中介軟體開發的各種業務系統都是以物件模型的形式存在，每個物件模型都是依據“業務對象”而建立，對與程式的二次使用者來說，這樣的模型較三層結構設計的系統更易解讀，同時當系統需要進行重用時，只需要複製所需的模型檔案即可，因為模型檔案包含了整個業務對象的所有資訊，複製後，重新提交至伺服器即可再次產生系統的各個層面。由此看來這種意義上的重用與組件、構件、類的重用完全不同，這是基於業務層面的，是包含著三層體系的業務模型。       2、團隊的協同開發與版本控制：由於平台系統協同開發人員都在針對不同的業務對象進行建模，開發環境與伺服器互動的是xml檔案，所以平台不但提供的CVS控制，還提供了基於http協議的SVN控制，這使得協同開發人員之間在地理空間的局限。可以通過互連網直接連接伺服器提交業務模型或者修改業務模型。       3、業務模型的反向工程：平台的物件模型特性還使得我們能夠實現物件模型與業務系統之間的相互轉換。       4、平台的應用難度：平台的物件模型建立均以參數化或者圖形化的方式實現，使得平台對開發人員的技術要求降至最低，而只注重於開發人員對系統需求的理解和對物件模型工具的使用熟練程度。       5、系統的技術架構與技術路線：平台完全基於J2EE架構設計，標準的多層分布式應用程式，符合業界的技術發展趨勢。同時平台的系統設計實現方法已申請商業方法專利（Business Method Patent,BMP）。      6、系統的開發性與擴充性：            WebService支援：平台是一個面向服務的的架構體系(SOA),通過系統服務或自訂方法很方便的調用第三方的Webservice,同時也可以將對象與操作以webservice方式供第三方調用。            HTML擴充支援：利用平台的建模工具可以不用任何代碼產生美觀的操作介面,但為了滿足使用者的不同需求，平台同樣支援以HTML代碼為基礎的自訂頁面,使用者可以利用頁面編輯器產生各種格式的操作介面.同時平台提供了一個“JSP資源”類型的系統對象來方便掛接應用開發人員定製的JSP或者是html檔案，當加入JSP資源，平台可以統一對其進行許可權控制。可以將這些JSP掛入系統功能表，也可與其他對象進行整合。       流程擴充支援：平台流程引擎中流程有活動，動作及轉向等元素，並對這些元素提供了事件支援，可以在進入某個活動，觸發某個動作，或具體到轉向上進行事件處理。在事件處理上，使用者可以調用Message Service，執行表單操作或直接的資料庫SQL操作。此外，平台還提供了流程的相應編程介面，可支援在流程外啟動或辦理任務。       資料提供者：平台具有有很強的整合能力，有多種資料訪問能力來擷取第三方軟體的資料，支援異構資料庫訪問，支援直接tcp/ip資料訪問，支援FIX通訊協議，支援基於webservice的資料來源。同時平台也能輸出excle,csv,xml等多種格式的資料。       深度開發支援：系統整個體系有很好的可擴充性。提供了豐富的Java介面。如介面模式介面，操作驗證介面，操作介面，操作攔截器。使用者可以自行實現這些Java介面並加入相應配置中，系統即可按這些介面進行介面或操作處理。平台在系統每個層面、使用者方法、計算資料行公式、流程條件及事件處理中都提供了SQL語句與指令碼語言支援。在運算式指令碼中，平台也提供了直接載入JavaBean的函數。JavaBean載入後，使用者即可在指令碼中設定javabean屬性及調用javabean方法。

__________________msn:hiraymail@126.com QQ:20709610