語言工作台和模型驅動架構

三個 MDA 陣營

討論這一點的第一步是了解 MDA 實際上對不同的人來說代表許多截然不同，甚至不相容的事物。史蒂夫·庫克將這種差異描述為分為 三個相互輕視的陣營

• UML PIM：使用 UML 建立平台無關模型，然後將其轉換（或詳細說明）為平台特定模型，再將其轉換（或詳細說明）為程式碼。
• MOF：完全不使用 UML，而是使用 OMG 的元物件設施 (MOF) 來定義語言和轉換。
• 可執行 UML：為 UML（或延伸子集）建立編譯器，並將 UML 視為程式語言。

在這三個陣營中，UML PIM 和 MOF 陣營在某種程度上從事面向語言的程式設計。可執行 UML 陣營對面向語言的程式設計並不太感興趣。這並不是一件壞事，事實上，一些可執行 UML 人員似乎是各種 UML 倡導者中最明智的，但他們與此處的討論無關。

還有另一個陣營，最好稱為模型驅動開發 (MDD) 陣營。他們根本不是 MDA 的一部分，因為他們不重視 OMG 標準，而 MDA 是 OMG 標準。之所以會產生混淆，是因為人們經常錯誤地將沒有 OMG 的 MDD 工作稱為 MDA。正確來說，最好說 MDA 是使用 OMG 標準的 MDD。（我稍後將討論 MDD。）

所有這些都表示，為了討論 MDA 在語言工作台中扮演的角色，我必須分別檢視 UML PIM 和 MOF 陣營，因為他們思考面向語言程式設計的方式截然不同。

UML PIM 陣營

UML PIM 風格的 MDA 是基於使用 UML 作為「平台無關模型 (PIM)」來開發系統的想法。（儘管 它實際上並非平台無關。）一旦完成，它就會透過平台特定模型 (PSM) 轉換為程式碼。此 PIM 是 UML，就像語言工作台一樣，資訊的主要來源使用 UML 元模型以抽象表示儲存。編輯（通常透過不再敢自稱為 CASE 工具的圖形工具）是透過使用 UML 圖形化標準進行呈現的投影編輯器來完成。

使用持續的抽象表示和投影編輯器當然是語言工作台會做的事，但不足以成為語言工作台。要成為語言工作台，您必須能夠自行定義新語言並將它們整合到其餘部分。UML PIM 的做法是使用內建於 UML 的語言延伸功能，例如立體型和它們的種類。

理論上，沒有理由 UML PIM 系統不能成為語言工作台。問題在於使用 UML PIM 方法是否為建構語言工作台的好方法。由於使用 UML 的方法是透過 UML 定義的方式來擴充 UML，因此使用 UML 的工作 DSL 較像是內部 DSL，而非語言工作台的整合外部 DSL。在這種情況下，您不需要考慮工作台三部曲：架構、編輯器和產生器，而是考慮要如何輕鬆擴充 UML 以滿足您的需求。

這裡的問題在於 UML 是一種極其複雜的語言。擴充機制也很複雜，而且很難看出它們在實際應用中會如何運作。也不清楚工具將如何操作這些擴充。一個特別的灰色地帶是產生。沒有標準產生標準來定義 UML 圖表如何詮釋為程式碼。因此，UML 沒有足夠精確的語意。事實上，我聽過 UML 支持者自豪地說 UML 沒有語意。

您可以使用 UML 元模型來定義 DSL 架構，但這裡的 UML 既太多又太少。UML 包含許多您不需要用於定義架構的元素，而且不清楚它是否提供了您需要的建構。此外，UML 沒有提供任何協助定義編輯器或產生器的內容。對於此目的，UML 元模型是一個龐大、複雜的野獸，它沒有涵蓋語言工作台的核心需求，而且增加了許多不必要的東西。這有點像說我們應該用卡車來建造快艇，因為它們都有方向盤。

儘管我顯然輕視這種方法，但有人在 UML PIM 基礎上進行語言工作台工作。如果您不同意我對 UML 適用於此工作的評估，您絕對應該進一步調查這些人。

MOF 陣營

元物件設施來自 OMG 中與 UML 不同的社群，而 MOF 和 UML 陣營之間的關係常常很冷淡。MOF 的工作與 OMG 的 CORBA 工作關係更密切，而且 MOF 的許多驅動力來自與 CORBA 的合作。

MOF 標準是元模型的元模型標準。因此，您可以使用 MOF 作為定義 UML 元模型的語言。事實上，UML 元模型的 MOF 相容性是 UML 工作中長期存在的問題。在語言工作台方面，MOF 對應於用於定義 DSL 架構的 DSL，類似於 MPS 結構語言。如果您查看 MOF 文件，您會注意到許多與我們看到的 MPS 結構編輯器相似的功能。因此，MOF 本質上是（另一個）資料建模元模型。它的物件歷史也提供了操作，儘管沒有行為建模機制（與 UML 不同）。

MOF 遠比 UML 小，基本上是 UML 類別圖表部分的子集。由於這正是 DSL 架構所需，因此 MOF 比 UML 更適合這項任務。確實有些人提出 MOF 會是抽象表示法或至少語言工作台儲存表示法的良好架構。

然而 MOF 仍不完美，操作定義在遠端物件互通性 (CORBA) 的背景下有意義，但對 DSL 架構來說意義較小。因此，關於使用 MOF 作為 DSL 架構的許多辯論都圍繞著它實際上有多合適的問題。MOF 是否帶有額外的負擔，或是否遺漏了重要元素？我對此沒有強烈的意見，因此對我而言，這是一個開放式問題。

更重要的是，MOF 遺漏了編輯器或產生器定義。由於這兩個語言工作台的關鍵元素，因此從語言工作台的角度來看，這些都是 MOF 中的重大缺陷。OMG 正在準備一個標準來解決其中一些問題，稱為 QVT（查詢、檢視、轉換）。原則上，QVT 可以填補產生器缺口，但其開發仍處於早期階段。

MOF 可能有用的地方是作為 DSL 架構語言工作台之間的交換機制。因此，它可以在該背景下發揮作用，但由於缺乏編輯器和產生器部分，因此不足以完全交換 DSL。儘管如此，我認為它對語言工作台來說，是 MDA 標準世界中比臃腫的 UML 更實用的部分。

MDA 和標準化

語言工作台周圍的小型筆戰之一，就是批評微軟在軟體工廠計畫中忽視 MDA。許多人將此視為邪惡的微軟再次忽視社群標準，而偏好專有解決方案的案例。

您可能會注意到 Intentional Software 和 MPS 也忽視 MDA，兩者都認為各種 MDA 標準對他們正在做的事情沒有實際幫助。微軟對 MDA 的了解比大多數人都好，軟體工廠團隊的許多成員長期以來都是 UML 社群的成員。他們得出了相同的結論，即 MDA 標準不適合他們想做的事情。

我認為這種態度有非常正當的理由。MDA 的 UML PIM 和 MOF 陣營只能聲稱支援標準化 DSL 架構，而編輯器和產生器這兩個同樣重要的元素卻完全被忽視。此外，整件事都是倒退的。在我看來，您在找出運作技術的共同元素後，才定義標準。語言工作台還不成熟，還沒有準備好標準。我懷疑可以用 MOF 建立 DSL 架構的標準，或至少看起來像 MOF，僅僅是因為這些架構是資料模型，而 MOF 的大部分都是資料建模標準。但是語言工作台工具仍在嘗試找出他們需要什麼，因此現在嘗試制定標準有過早標準化的風險。

有人在某種 MDA 旗幟下建構工具，可以視為語言工作台。我尚未深入檢視任何這些工具。此類工具應與任何工具一樣有機會派上用場，但 UML 或 MOF 似乎只對此類工具的一部分功能有幫助，而且 UML 由於其複雜性，實際上可能是有害的。

所有這些並非表示 UML 標示法對語言工作台沒有用。事實上，我認為在這裡批評軟體工廠是有道理的，因為它們的圖形標準可以更接近 UML。對於某些類型的圖表，類似 UML 的標示法非常有意義。UML（至少在草圖模式中）已變得相當知名。我預期工具會在有意義時使用類似 UML 的圖表，儘管它們可能不會完全遵循 UML 標準，也不會將 UML 元模型用作其抽象表示。

模型驅動開發

正如我在上面提到的，有一群人喜歡使用（主要是）圖形模型來推動軟體開發的許多想法，但對 OMG 標準堆疊並不那麼熱衷。這個社群最適合稱為模型驅動開發（MDD）社群。

他們與 MDA 社群有許多共同點。他們許多人來自 80 年代和 90 年代的 CASE 工具工作。他們傾向於偏好圖形模型而非文字模型。他們喜歡透過投影編輯器編輯抽象表示的想法。他們許多人支持讓人們定義自己的圖形語言的想法。

在這些意義上，MDD 和語言工作台有很多哲學上的共識。事實上，可以合理地說，語言工作台的興趣來自兩個背景：程式語言人員和建模人員。軟體工廠團隊有更多的建模背景。

並非所有 MDD 追隨者都認為讓人們輕鬆定義和整合自己的語言很重要。對 MDD 世界中的許多人來說，重要的是根據一組模型定義系統，而想出定義和整合多個 DSL 的方法優先順序較低。雖然大多數只是強調的不同，但它仍然是 MDD 和許多面向語言的程式設計工作之間的重要區別。

MDD 社群的努力無法產生語言工作台並非沒有特別的原因。的確，除了 MDD 和語言導向程式設計之間（對我而言不相關的）圖形語言和文字語言論點外，它們共享了大部分內容。然而，我注意到一個趨勢，MDD 人員通常不會認真注意產生器。建模人員經常抱持一種態度，認為產生程式碼是一個微不足道的實作問題 - 一旦建模完成，所有艱難的工作就完成了。然而，整理產生器是讓語言導向程式設計運作的關鍵，因為產生器有效地定義了 DSL 的語意。淡化產生器的趨勢是許多程式設計師不重視建模人員的主要原因。UML 社群對以任何形式（除了揮手之外）提供 UML 和常見目標語言之間的任何對應關係不感興趣，就是這個差距的一個好例子。

結語

我以對 MDA 持有相當懷疑的觀點而聞名。這種負面情緒大多針對 UML PIM 陣營 - 我認為 UML 太過複雜，語意上也不夠連貫，無法作為未來工作的嚴肅基礎。然而，本文的問題是 MDA 應該在語言工作台中扮演什麼角色？

我的答案是「沒什麼」。當然，有必要定義語言工作台之間有效的交換表示法。沒有它，就有供應商鎖定的風險，這將阻止許多使用者，並可能阻礙語言工作台的使用。然而，我並不相信 OMG 標準就是答案，主要是因為它們是為不同的目的而設計的。我的觀點是，首先你需要找出如何做某事，然後你應該找出什麼以及如何標準化。OMG 標準可能適用於圖片的某些部分（MOF 用於模式）。但現在判斷語言工作台生命週期還為時過早。