這將我們帶入到模型驅動開發的另一個主要用途，把系統和軟件開發更多地納入到系統和軟件工程規則中。模型驅動開發是關于開發和維護系統的，系統并不只是由應用程序組成，還包括其他的部分，使得人們可以理解這個應用程序。一個模型可以包含明顯可執行的部分，但它幾乎總是還有其他部分，并不能被運行，比如需求，系統的粗略框架，商業模型和分析模型。在項目開發時，所有這些都應該被創建出來并保持最新，它們對于將來的維護非常重要。
模型驅動開發的現代工具提供了運行一個（或部分）模型的能力，這使得可以更早得到確認，系統能按預定方式工作。換句話說，這意味著項目風險被極大地降低。在模型驅動開發中，測試也變得更加重要，因為能夠被更早和更頻繁地進行。這種方式，會使你對在項目后期，應用程序的各部分能夠統一合作具有更多地信心。直觀地，你可能以為所有這些額外的工作會延長開發周期，但是經驗顯示，產品上市時間實際上是縮短了。你花費更少的時間用于實現和測試階段，更多的時間用于分析和設計階段，當你迭代重復這些過程時，你會發現，這種方式的好處是實實在在的。
UML 2.0 的作用
無疑，統一建模語言（UML，Unifid Modeling Language）就是設計用來進行模型驅動開發的語言。它第一次標準化是在1997 年，作為當時各種面向對象分析方法之爭的結果。然后它迅速成為最流行的建模語言，用于“可視化、構造和存檔在基于軟件的系統創建過程中的產品”。
我們沿著這條道路已經走了五年，用戶和工具提供商對于UML 語言都有了更多的經驗。我們知道什么很有用處，也知道什么需要被改進。而且，軟件工業在這些年也發生了變化，需要去支持一些新的技術，比如基于構件的開發和可執行的模型。這些需求還不能用現在的UML 合適地處理。為了解決這些問題，對UML 大的修訂工作兩年前由OMG 開始啟動，預計于2002 年底前完成。
在語言中新增加的性能，用于對系統架構建模，都是些很重要的部分，使得更容易創建任何復雜度的實際系統。對這種規�？缮炜s性的關注也擴展到了其他領域，包括對行為進行建模的圖形，比如順序圖和狀態機。既然UML 試圖適合很多參與方的需要，它需要變成一種相當大的語言，但是并不是每一個人都需要知道語言的所有部分。它被有意識地分割成幾種視圖或圖形，允許你關注于只與你相關的專門領域。其他人可能希望工作在其他的視圖上，模型將保持這些視圖間的一致性。
工具的考慮
工具實現模型驅動開發的方式各不相同，給予用戶或多或少的靈活性。雙向工程是一個可憐人的選擇，他不能在模型中捕獲到系統行為，并且他還把自己與某種特定的編程語言綁定在一起，這還是一種以代碼為中心的方法，所有這些都將使你感到難受。在一些緊急的場合，你甚至會忘記模型，比如一個項目就要到達最后期限（看起來在某處總有一個最后期限）了。在項目的最后，你得到了一個可工作的應用程序，還有一個沒有實際用處的模型。這時，你甚至懷疑建模的重要性了。
對雙向工程問題的一個讓步就是在模型中直接插入編程代碼，因此強迫你更新模型以確保最終得到一個可執行的應用程序。這同樣使你感到難受，又被綁定到某種特定編程語言，你還不得不在模型的很多地方插入代碼片斷。這很像在C 程序中插入匯編代碼，盡管有時這是必要的，但是將來維護會是問題并可能傷害你。
考慮直接在模型中提供指定系統行為的能力，上述兩種方法都變得過時。在模型驅動開發中，你只需按一個鍵，在你選擇的平臺上，就能獲得自動生成的任何語言的代碼，這樣在模型這一級上就能實現應用程序的可移植性。你不需要修改代碼，改變你的系統就能直接反應到模型的實現上。當然，目前還有一些路需要走，大部分的工具廠商目前都有他們自己的語言映射，但要實現MDA 的目標，就需要有對不同語言和平臺的標準映射和腳本。好消息就是這種前景正在展現。模型驅動開發確實正在起作用，并必將改變我們開發系統的方式。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
