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

領測軟件測試網 作為一個面向對象的程序員、習慣于構件開發的程序員，對于模型驅動軟件開發的認識經歷了幾個步驟。首先我想到的是：為了適應用戶不同的業務組合，很多軟件中都有的運行選項。當我們依據自己的需要對選項進行組合后，將得到不同的界面和業務規則。比較常見的有：報表、對于數據的校驗、流程等。接著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的研究，過于技術化，還不是應用層面的解決方案，但其中的思想卻是一致的。以上權當拋磚引玉，歡迎大家來指正與討論。

文章來源于領測軟件測試網 http://www.kjueaiud.com/

TAG: 模型 驅動 軟件開發