可以看到1990年的早期版本已經對對象模式和相關技術有著濃厚的興趣?;谶@個模式的新的編程語言(比如Smalltalk, Eiffel, C++, 和Java)已經被設計并投入使用。伴隨著這些語言出現的還有令人驚嘆和難以理解的面向對象(object-oriented(OO))軟件設計方法和建模符號。因而在徹底的縱覽了有關OO分析和設計方法后(包含800頁以上),Graham列舉了50種以上的有相當大影響力的方法(Graham01)??紤]到對象模式包含了基本概念的相對較小的子集(包括封裝、繼承和多態),很明顯,在這些方法中存在非常多的重疊和概念上的結合--大多數情況下是由于符號性的和其他并不重要的差異而使其變得很模糊不好理解。這樣就導致了令人難以理解以及不必要的市場分歧—反過來也阻礙了有實用價值的新模式的采用。軟件開發者很難在這些相互矛盾的語言,工具,方法和供應商中做出選擇。
由于這個原因,當Rational 軟件隨后提出了統一建模語言(UML)的初始版時--在Grady Booch,Ivar Jacobson和Jim Rumbaugh的領導下--得到了快速和積極的反響。其目的并不是為了提出任何新的內容,而是—--通過高級領域思想領導者們的協作—--把各種各樣的OO方法的最好特性添加到一個單獨的和與供應商無關的模型化語言和注釋中。正因為如此,UML很快地成為了一個廣泛的實踐標準。隨著1996年對象管理組織(Object Management Group)對它的采用,UML成為了一個廣泛被接受的工業標準[OMG03a] [OMG04] [RJB05]。
從那以后,UML:
被絕大多數的模型工具開發商所采用和支持
成為全世界大學和各種各樣的專業培訓項目中計算機科學和工程課程中必不可少的一部分。
開始被學術和其他研究者所使用,并作為很便利的公共語言。
在處理復雜軟件時,UML同樣能夠幫助增強對模建模價值的普遍的認識。盡管這種非常實用的技術幾乎和軟件本身一樣歷史悠久—――像很早以前的例子那樣它們都帶有數據流圖(flowcharts)和有限狀態機—――大多數開發人員慢慢地才接受它,如同接受其他工具一樣,而不是像接受一個有用的小工具那樣迅速??陀^的說,這種對新事物的態度仍舊是一個占有主導性地位的,這就是為什么模型驅動方法在這一領域中受到很大的阻力的原因。
之所以會存在上述情形是有一些原因的(當然也有些不是那么有根據的原因,比如:通常人們并不相信創新)。主要原因是軟件模式經常會導致不可預知的嚴重性錯誤:我們都清楚,任何一個模式的實際價值與它的正確性直接成比例。如果一個模式不能把它所表示的軟件系統向你準確的表現出來,那么還不如不用模式,因為它可能會導致錯誤的結論。那么提高軟件價值的關鍵在于縮小這些模式和它們所模式化的系統之間的差距。然而,正如這篇文章后面所論述的,在軟件中減小這種差距比在其他任何的工程學科中要容易的多。
某些錯誤的軟件模式歸咎于當前編程語言的過多的細節和敏感的本質。一些較小的失誤和幾乎不被發覺的編碼錯誤――比如指針偏差或者變量未初始化――可能會帶來嚴重的后果。舉一個實例來說,在一個有相關文檔記錄的案例中記載,由于一個嵌套的switch語句中的某個case中少了一個break,結果導致美國的大部分地區失去了長途電話服務,以致帶來了巨大的經濟損失【lee92】。如果這些看似微小的細節會帶來如此可怕的后果,那么我們又如何相信模式的正確性(因為從定義上來看,模式應該用來隱藏或是去掉這些細節)?
模型驅動開發
解決這一難題的方法是通過一個或多個自動的模型轉換器將一個模型與它相應的軟件實現從形式上連接起來。也許這方面最好和最成功的例子就是編譯器,它能夠將一個高級語言程序解釋成一個與之相當的機器語言的執行程序。這種情況下,模式就是這個高級語言程序,它就像所有有用的模式那樣,隱藏了潛在的計算技術特性上的相關細節(比如內存字符大小,累加器的個數,索引寄存器,ALU算術邏輯單元類型等等)。
有趣的是,幾乎沒有任何其他的工程媒介能夠為一個模型和它相應的工程工具提供如此緊密的連接。這是因為你所模式化的工具是軟件而不是硬件。任何一種物理工具的模式(比如:一輛汽車,一座建筑物,一架橋等等)不可避免地包含了一些步驟,它會將物理特性抽象成一個相應的模型(就像數學或幾何模型一樣)。同樣,使用物理原料實現一個抽象的模型包含了從抽象到具體的非正式轉換。這一非正式步驟的本質會導致一些錯誤,正如上面所提到的,會導致模型效率低下或是甚至達不到預期目的。然而,對軟件來說,原則上,這種轉換可以從各個角度的形式上的執行。
在抽象性和自動化抽象性與自動化操作強有力的結合后,所產生的潛能已經導致新的建模技術和相關發展方法的出現,正如所提及的模型驅動開發MDD) [Brown04] [Booch04]。MDD的定義特征是,此模型已經成為軟件設計的主要工具,它把許多注意力從相關的程序代碼上轉移開。它們為不同的自動化和半自動化的方法提供服務,這種方法源于代碼和相關的模型。與傳統的編碼相比較,目前在MDD中使用自動化操作的程度不同于從簡單框架代碼到完全自動的產生代碼。很明顯地,自動化程度越高,模型越精確,MDD的優越性就更突出。
軟件發展的模型驅動方法不是一種獨特地新式方法,在過去就已經被使用并獲得了不同程度地成功。他們之所以愈來愈受重視的原因是,其支持性技術已經愈來愈成熟,成熟點在于比起過去的情況來看在實踐上更加自動化。這不僅僅在效率方面,而且在可測量性方面,同樣這種工具所具有的能力是與繼承性工具和方法相結合的。這種成熟技術所反應的MDD標準的出現,使得使用相關的工具時更加便利舒適,給使用者帶來顯而易見的好處。其標準之一是統一建模語言的修訂版。
原文轉自:http://www.anti-gravitydesign.com