面向對象的下一代開發工具

介紹
過去的30年，文檔是軟件開發過程中的重要容器。所有項目的結構和邏輯最終都是生成了文檔和目錄。圍繞著軟件開發的許多工具也是基于這樣的概念構建的；編譯器、連接器、甚至機器代碼都是以代碼文檔作為輸入的。版本控制系統反映出了文檔系統結構，保存了每項文檔每個版本的一個副本。近十年來，這已經被人們接受，并且已經成為標準。諸如C之類的語言在源代碼中通過包含指令被構建與文件參考之上。

問題
在二十世紀九十年代中期，面向對象的軟件開發開始成為主導觀念。從前很少研究的諸如C＋＋之類的語言， 現在成為主流。隨著這個基本原則的變化，基于文檔系統的開發最為遺留被延續下來。C＋＋像它的前輩一樣，用文件包含解決從屬問題。盡管有了諸如UML之類用于建模和設計的新技術、新語言，但最終源文件還是需要被創建并彼此連接。

這種聯接導致了一個努力方向：模型必須能被翻譯成文檔和源代碼。復雜構造的原稿必須被寫為確保能構造正確的應用的形式。模型發生變化，源代碼也必須能被更新反應這種變化；反過來，源代碼發生變化，模型也要被更新。

許多各異的軟件解決方案用于同步這些各異的文檔，但是他們始終都是基于這樣的基礎觀念的：文檔是輸出產品的重要單元。這也證明了在一個小組環境中文檔管理是一個挑戰。如果許多開發者從源碼控制器中將一個文件遷出，那么版本控制系統必須要確保不發生更改沖突。如果沖突發生，就需要手動干涉解決分歧。由于源碼控制系統以文件作為單元控制系統，因此受到了限制。源碼控制系統對于包含在文件中語言結構一無所知。

很顯然，對軟件開發來說，文檔是一個超過其用途的遺留物。

模型驅動架構
在2001年末，一個軟件開發的新的方法學開始嶄露頭角，那就是：模型驅動架構（MDA）。MDA的基本原理是：模型并非代碼成為中心焦點。

與平臺無關的模型由UML構建，然后經過各種各樣的轉化，最終成為某種特定平臺的源代碼。很顯然，模型而不是文檔成為輸出產品的重要單元。一種模型對于不同水平的提取有著不同的觀點。在最高水平上，與平臺無關的組件能夠被解析成不同規格；在最低水平上，存在一個依賴于特定平臺的執行，它由一系列代碼類組成的。

可用的模型符號涉及到了所有能夠代替文件的必要特征的定義。具體來說，類間的依賴被容易的通過關聯箭頭來標記。創建模型的支持工具在理想情況下應該為每個模型元素考慮版本控制問題。每個元素應該有被從庫中遷入或遷出的能力。

同樣的，模型工具應該和庫一起提供元素級別的分支和合并功能支持。例如：開發者應該能夠聯接庫獲得一個能迎合需求的元素列表。接著，開發者能夠把庫中元素分離將其包含在一個新模型中。最后，另一些開發者能夠調整不同模型中分支元素的差異。開發環境應該支持這些。

一個普通例子對于這種功能用于Bug的修正。如果在一個項目中，模型元素的bug被修正，那么運用相同模型元素的另一個項目也要反映這種變化。完成這個任務非常簡單。 

解決方案
這些問題的解決方案可以說是一個完全的范例變化。開發工具必須支持在代碼已經產生情況下的變化，并且必須完全支持MDA開發。

顯然，代碼實際上就是另外一種模型。這種觀點以一種與語言無關的代碼文檔對象模型（CodeDOM）的存在為例證。當你基于這種觀點考慮，源代碼和UML類只不過是對于相同基礎數據的不同視圖。他們之間的所有區別都是需要被排除的人為的構造。開發者應該能夠用UML創建類及類的屬性方法，并能將UML和源代碼緊密結合。源代碼應該可以同時被多種語言實現。

如今通過CodeDOM使得這些成為可能，CodeDOM本質上是一個易于映射為UML的面向對象的模型。代碼結構在大多.NET支持的語言中移植，工具本身就支持這種移植。一個必須被排除的人造物品就是源代碼文件。這成為MDA的一項功能，并且沒有比MDA更好的方法了。

為了代替源文件，IDE可以直接與項目庫聯接。項目將直接列出對象，符合文檔需求。這種新功能與目前Visual Studio中的類視圖一樣，視圖可以被嵌套的命名空間而不是命名目錄所組織，也可以被類、structs、資源而不是文件所組織。當開發者雙擊這個類時，代碼在編輯器中打開。

類視圖還包含了UML圖。圖可以以一定的層次在任何地方創建，開發者可以將類拖拽到設計表面。每個命名空間都有一個默認的圖形和若干個附加圖形，用于顯示系統各個不同的部分。除了代碼視圖外，工具還應該有類和類關聯的繪制視圖。理想情況下，代碼不應該以任何特定語言的形式存儲，而應該存儲為附加的CodeDOM結構模型。

對CodeDOM 類較為次要的一點是：它能夠用各種語言表達，除去一些對語言細節代碼片斷的需求。模型中的每種方法都包含語言獨立的CodeDOM構造，為了易于編輯，這種構造可以被轉化為任何一種支持的語言。正如在FrontPage中存在設計分割視圖和HTML視圖，開發環境也應該提供一個模型和代碼的分割視圖。

當基于文件的開發被基于模型的開發所代替，一個新世界被開辟。與其說直接通過創建Web頁設計Web站點，還不如說通過構建行為圖模仿用戶與站點的交互。除編輯之外，工具因該能夠產生必要的輸出文件以支持這些圖形。圖中的每個行為都需要一個用戶接口，因此包含一個UI設計。例如：對于一些給定的行為，一個Web UI設計和Windows UI設計成為行為的一部分。工具能夠允許HTML文件的導入/導出，并給予設計者用自己的工具而不是默認IDE的能力。當設計完成后，HTML文件被導回變成行為。

這個整體觀念符合一種新的被稱之為"Whitehorse"的技術，Microsoft正將此技術包含在Visual Studio 2005中。Visual Studio 2005還包含對Microsoft的Dynamic Systems Initiative（DSI）的支持，這將通過一個能創建System Definition Model (SDM) 硬件聯接組件的工具來實現。Whitehorse包括一系列的新設計，它支持被稱之為軟件工廠[JG04]的MDA。一個UML類設計器可用于源代碼、邏輯應用和基礎構造設計，并允許開發者在早期的設計過程中聲明應用組件的結構、構造和配置。正如現在的代碼文件，這些模型在目前的解決方案中被存儲為文件。所有的模型因該存儲在庫中，并直接通過APIs從庫中訪問模型。

源碼控制系統因該能識別模型和代碼中呈現的內部結構，也應該能支持功能級模型元素的遷入和遷出。這種方式下，兩個開發者能夠工作在一個類的不同部分，并且不存在事后還需協調兩部分的潛在問題。建造工具同時也需要支持這種新環境。與其說是文件的編譯，還不如說其真正的工作是模型編譯。通過一個配置模型，類可以被聯接，集成并執行。編譯器因該兼顧配置模型，以決定企業類和資源的物理分割，同時也要兼顧類間的依賴，以分解符號。構建過程將輸出多種不同的基于需求的文件。對于一個Web項目，ASPX或ASMX頁面將隨著二進制匯編被創建。

構建過程讀取SDM并產生相應的設置文件，并為引入到開發工具中導出SDM。為了達到兼容性目的，工具允許以任何支持的語言抽取并導入源代碼文件。開發者可以選擇一系列的類，并將其導出，同時工具可以產生必要的文件。然后開發者可以修改這些文件，并把這些文件導回項目中。工具可以自動產生模型元素，如果需要還將提示調整變化。

結論
模型開發環境并沒有充分迎合面向對象的變化。所有工具還是依靠文件作為源代碼的容器。與一些容納模型的能力一樣，對于文檔和代碼來說，模型作為不同的實體而存在。

這些工具需要繼續發展，以支持模型軟件開發；它們需要將模型視圖和代碼視圖融合成一個單一的實體。這聽上去像一個根本的改變，但是實際上，新工具對于開發者是自然的結果。

開發者期望他們的類被命名空間組織。他們不用擔心哪個文件哪個目錄包含哪些代碼。如果開發者改變一個方法，他希望能找到所有的該方法的參數，并改變它們。架構師已經構建了軟件和系統的模型。因此開發者可以理解這些模型。

原文轉自：http://www.kjueaiud.com