Defining Languages andInterchanging Models
在OMG的MDA旗幟下還有另一個重要的技術：MOF。MOF是一個比UML更加抽象和難以理解的技術。理解了這個還有更難理解的術語，象metamodel（元模型）和meta-metamodel（元－元模型），感謝還沒有出現(xiàn)meta-meta-meta-model，我們也會盡力阻止出現(xiàn)。
MOF主要作兩個工作。第一，它是一個被設計成定義建模語言的領域定義建模語言：一個MOF模型是一個MDA建模語言的定義。第二，它是一種計算一個MDA模型如何被序列化到一個XML文檔或Java API的機制。
一個領域的建模語言包含很多方面，它必須定義領域中的概念，必須把概念表示為圖形或文本，必須定義用戶如何與語言交互，必須定義一個模型是否合法，必須定義模型間如何交互。但是MOF僅僅定義了語言的基本概念，以及概念的模型如何存儲和交互。一種語言的MOF說明并沒有提供多少用戶真正關心的東西：語言所包含的模型是什么，它看起來象什么，用戶如何和模型交互。
在微軟，我們希望我們的語言能夠整合到Visual Studio包括IntelliSense®，工具欄，菜單，屬性欄，和對Debug的支持，我們發(fā)現(xiàn)定義如何對概念建模在整個工作中只是一個次要的方面，而且我們的語言定義工具要整合到Visual Studio中要比MOF好。
事實上，盡管這是語言定義技術的通常的地位，MOF仍然是一個存儲概念模型，并且使用XMI（XML Metadata Interchange）在模型和CORBA和Java API之間轉換的主要技術。如果使用MOF來定義一種語言的概念，接下來就可以使用XMI的方法來進行對語言的基于XML的自動生成。
從這個方面看，這似乎是挺吸引人的，但是，還是有一些問題。首先，XML的生成基于語言的定義，這也就意味著使用UML1.4標準進行的XMI序列化將無法被基于UML2.0的實現(xiàn)所理解，除非用戶在這些概念的觀點能夠保持前后一致。再者，XMI本身就在變化，也就是說可能會出現(xiàn)對與同一個模型的不同XMI序列化版本。第三，MOF的定義也在變化，它會為了對付不同的組合而不斷加入新的元素，這將導致MOF的版本具有不同的取向，而且無法完全一致。所以，雖然XMI宣稱為建模工具提供互操作性，但是實際情況是，除非每個工具都能夠支持MOF，XMI，UML標準下的所有可能的組合，工具之間的交互才是沒問題的。XMI的更深層次問題是，特別是對于舊版本，由機器生成的XML架構常常冗長且難以閱讀，這就迫使開發(fā)者們?nèi)で罂梢暬潭雀叩?，可轉換的技術來維護XML文檔。來源：www.examda.com
我們不認為XMI對于模型的序列化來說是正確的方法。XML正在變的成熟，市場上有大量的模式和工具。我們認為正確的方法是，對特定的建模語言有他自己特定的XML架構，并且提供工具來管理語言和序列化格式間如何自動解釋和映射。如果對一個特定領域進行標準化，XML架構就可以是標準的，這是業(yè)界廣泛存在的觀點。之后，如果語言的定義發(fā)展了，可以在舊的XML架構上擴充，進行移植。XMI有效地阻止了這個清晰的思路發(fā)展，并導致了大量不兼容的XML架構標準，和它的互操作的目的完全背離了。
簡而言之，微軟不支持MOF是因為下面的原因：
1. 它還不是個穩(wěn)定的標準
2. 使用它來作為設計我們的工具的語言會產(chǎn)生我們不愿看到的結果。
3. 支持MOF所沒有提供的元素需要商業(yè)級的實現(xiàn)，我們會繼續(xù)引入MOF定義的改動。
4. MOF沒有實現(xiàn)自己的目標。
結論：本文討論了模型在軟件開發(fā)中的角色，特別是domain-specific languages的定義和使用，以及在產(chǎn)品線中的使用，同時對OMG的MDA作了總體的評價。我們確信在敏捷軟件開發(fā)過程中模型會得到更多的使用，我們正在構筑工具和技術來支持這些開發(fā)。我們看到UML作為重要的一步，它的未來是基于圖釋的開發(fā)者間的約定，而且可以作為面向特定問題領域的領域定義語言的靈感。也看到XML是模型的表現(xiàn)和交互的關鍵技術，我們期望對領域內(nèi)容的標準化能盡早開始。
在OMG的MDA旗幟下還有另一個重要的技術：MOF。MOF是一個比UML更加抽象和難以理解的技術。理解了這個還有更難理解的術語，象metamodel（元模型）和meta-metamodel（元－元模型），感謝還沒有出現(xiàn)meta-meta-meta-model，我們也會盡力阻止出現(xiàn)。
MOF主要作兩個工作。第一，它是一個被設計成定義建模語言的領域定義建模語言：一個MOF模型是一個MDA建模語言的定義。第二，它是一種計算一個MDA模型如何被序列化到一個XML文檔或Java API的機制。
一個領域的建模語言包含很多方面，它必須定義領域中的概念，必須把概念表示為圖形或文本，必須定義用戶如何與語言交互，必須定義一個模型是否合法，必須定義模型間如何交互。但是MOF僅僅定義了語言的基本概念，以及概念的模型如何存儲和交互。一種語言的MOF說明并沒有提供多少用戶真正關心的東西：語言所包含的模型是什么，它看起來象什么，用戶如何和模型交互。
在微軟，我們希望我們的語言能夠整合到Visual Studio包括IntelliSense®，工具欄，菜單，屬性欄，和對Debug的支持，我們發(fā)現(xiàn)定義如何對概念建模在整個工作中只是一個次要的方面，而且我們的語言定義工具要整合到Visual Studio中要比MOF好。
事實上，盡管這是語言定義技術的通常的地位，MOF仍然是一個存儲概念模型，并且使用XMI（XML Metadata Interchange）在模型和CORBA和Java API之間轉換的主要技術。如果使用MOF來定義一種語言的概念，接下來就可以使用XMI的方法來進行對語言的基于XML的自動生成。
從這個方面看，這似乎是挺吸引人的，但是，還是有一些問題。首先，XML的生成基于語言的定義，這也就意味著使用UML1.4標準進行的XMI序列化將無法被基于UML2.0的實現(xiàn)所理解，除非用戶在這些概念的觀點能夠保持前后一致。再者，XMI本身就在變化，也就是說可能會出現(xiàn)對與同一個模型的不同XMI序列化版本。第三，MOF的定義也在變化，它會為了對付不同的組合而不斷加入新的元素，這將導致MOF的版本具有不同的取向，而且無法完全一致。所以，雖然XMI宣稱為建模工具提供互操作性，但是實際情況是，除非每個工具都能夠支持MOF，XMI，UML標準下的所有可能的組合，工具之間的交互才是沒問題的。XMI的更深層次問題是，特別是對于舊版本，由機器生成的XML架構常常冗長且難以閱讀，這就迫使開發(fā)者們?nèi)で罂梢暬潭雀叩?，可轉換的技術來維護XML文檔。來源：www.examda.com
我們不認為XMI對于模型的序列化來說是正確的方法。XML正在變的成熟，市場上有大量的模式和工具。我們認為正確的方法是，對特定的建模語言有他自己特定的XML架構，并且提供工具來管理語言和序列化格式間如何自動解釋和映射。如果對一個特定領域進行標準化，XML架構就可以是標準的，這是業(yè)界廣泛存在的觀點。之后，如果語言的定義發(fā)展了，可以在舊的XML架構上擴充，進行移植。XMI有效地阻止了這個清晰的思路發(fā)展，并導致了大量不兼容的XML架構標準，和它的互操作的目的完全背離了。
簡而言之，微軟不支持MOF是因為下面的原因：
1. 它還不是個穩(wěn)定的標準
2. 使用它來作為設計我們的工具的語言會產(chǎn)生我們不愿看到的結果。
3. 支持MOF所沒有提供的元素需要商業(yè)級的實現(xiàn)，我們會繼續(xù)引入MOF定義的改動。
4. MOF沒有實現(xiàn)自己的目標。
結論：本文討論了模型在軟件開發(fā)中的角色，特別是domain-specific languages的定義和使用，以及在產(chǎn)品線中的使用，同時對OMG的MDA作了總體的評價。我們確信在敏捷軟件開發(fā)過程中模型會得到更多的使用，我們正在構筑工具和技術來支持這些開發(fā)。我們看到UML作為重要的一步，它的未來是基于圖釋的開發(fā)者間的約定，而且可以作為面向特定問題領域的領域定義語言的靈感。也看到XML是模型的表現(xiàn)和交互的關鍵技術，我們期望對領域內(nèi)容的標準化能盡早開始。