對模型驅動軟體開發的理解

作為一個物件導向的程式員、習慣於構件開發的程式員，對於模型驅動軟體開發的認識經曆了幾個步驟。

首先我想到的是：為了適應使用者不同的業務組合，很多軟體中都有的運行選項。當我們依據自己的需要對選項進行組合後，將得到不同的介面和商務規則。比較常見的有：報表、對於資料的校正、流程等。

接著WEB頁面進入了我的視野。利用諸如：JSP、PHP、ASP甚至CGI等技術來組建活動的介面。而太多的這些Pages都是用指令碼產生的。當我們改變指令碼的時候，在瀏覽器端的畫面也隨之改變。

XML是一個更加接近於這種思想的東西。簡單的說格式化的資料＋如何顯示，構成了XML。而XML本身只是資料而已，它並不是一個軟體。但你利用它中間的定義就應該得到同樣的顯示。這不能不說是標準的威力。同時我也看到，同樣的資料改變其中的XSL、DTD等，我們看到將是資料的另一種表達形式。作為資料的XSL、DTD等的改變引起了顯示內容和形式的改變。這不也是一種模型嗎？

回頭看看各種指令碼程式。每種指令碼都有自己的解釋程式。把他們當作驅動引擎，指令碼當做自訂的模型。當指令碼（模型）變化的時候，程式的運行也將隨之改變。

這些都屬於樸素的執行個體。再從一個程式員的眼光看看軟體自身的發展曆程。

其實我們現在所進行的軟體開發都可以看做是一種模型。軟體開發經曆了靜態庫à動態庫à構件技術。從其中可以看到的是，軟體的發展是在不斷地提升靈活性和提升系統的延展性。在靜態庫的時代，代碼是在編譯時間被裝載的，動態庫是程式在開始運行時被裝載的。而構件卻是在需要時被載入的，這種載入不一定是由你的程式碼來實現的。

中繼語言成了一種趨勢， Java是先驅者。先將原代碼編譯成中繼語言，然後用解釋引擎（Java虛擬機器）去解釋。中繼語言就是一種動態模型，它在運行期間被解釋引擎解釋。MS.Net步其後塵。所有的.Net語言都被先編譯成一種公用的中繼語言。然後在系統運行期間來解釋中繼語言代碼。這樣做壞處是顯然的：運行速度降低了。這樣的做法又有什麼好處呢？首先想到的應該是平台的跨越。Java就是一個例證。同時讓程式員擺脫了具體平台的束縛，專心於業務的實現。

這隻是對於開發人員的好處。但我們可以看到，模型的不斷提升，其結果是讓開發人員更加接近於想要表達的商務邏輯。而運行期間的動態模型更是增加了其中的靈活性，更少的代碼改變換來更多的對業務的專註。由此，我們設想一下，演化到一定的時期，是不是我們客戶中的業務人員也可以設計軟體了呢？

我認為這是很有可能的。

軟體開發中的原型法和逐步逼近真實的思路是非常有用的。系統分析人員為了得到使用者的真實想法，更符合實際業務的邏輯，首先做出一個原型出來，通過改進這個原型最終達到滿足使用者需要的系統。

雖然物件導向的設計從一開始以對象的方式來思考，但使用者的商務程序卻是需要經過多輪的磨合才能真正去理解的。

如果一開始我們就提供給使用者一個模型定義（或稱建模）工具，讓使用者自己去定義自己的業務。這樣，當使用者可以修改這個模型的時候也就是業務人員真正參與軟體開發時代的到來。那麼建模工具就要符合使用者的思維習慣，用現實世界中的概念去建立軟體。

物件導向、UML建模等能協助我們去理解模型驅動軟體的開發。但模型驅動的軟體開發並不是OOD、OOA。在這個世界裡，我們看到的是實體。實體和對象並不一樣。實體可以是一個對象、一個構件、一個系統。而實體在更多的時候被理解為諸如：報表、物料單、生產計劃、客戶、銷售情況等。

UML是協助我們的系統分析人員進行軟體開發設計的，它更多的是在貼近代碼這個層面。但是複雜的圖形與文字說明並沒有減少使用者對軟體的神秘和抵觸心理。暫且不說使用者需要去學習UML，至少在中國能看懂UML圖的系統分析員就不多。以一個軟體專業人士的眼光去理解使用者的業務需求，這本身是有問題的。而你與使用者去談物料單該如何處理的時候，他會顯示出非常高的積極性。因為在他看來，他的工作就是處理物料單，處理報表等。誰願意去學習一種與自己工作毫不相干的東西的？當然你有特別的興趣除外。

模型就是要協助使用者去設計自己的系統。它是軟體中的虛擬業務與現實業務之間的映射器。模型中通過對實體、規則、業務等的表達實現了以使用者的思維方式去理解軟體中的業務操作。

所以，我認為模型驅動的方法是下一代軟體開發的方法。

它應當將OOA、OOD等方法囊括其中，這一點從OMG（http://www.omg.org）的研究中可以得到體現。OMG目前的研究是建立在UML、MOF、CWM這幾個東西的基礎之上的。雖然OMG的研究，過於技術化，還不是應用程式層面的解決方案，但其中的思想卻是一致的。