语言工作台和模型驱动架构

三大 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，因为它缺少编辑器和生成器部分。尽管如此，在我看来，它比臃肿的 UML 更适合语言工作台的 MDA 标准世界。

MDA 和标准化

围绕语言工作台的一场小规模的争论是，人们批评微软在软件工厂工作中忽略了 MDA。许多人认为这是邪恶的微软为了专有解决方案而无视社区标准的又一个例子。

您可能已经注意到，Intentional Software 和 MPS 也忽略了 MDA，他们都认为各种 MDA 标准对于他们正在做的事情并不真正有用。微软对 MDA 的了解比大多数人要好，软件工厂团队的许多成员都是 UML 社区的长期成员。他们得出了相同的结论 - MDA 标准并不适合他们想要做的事情。

我认为这种态度有非常合理的理由。MDA 的 UML PIM 和 MOF 派别只能声称支持标准化 DSL 模式，而同样重要的编辑器和生成器元素却被完全忽略了。此外，整个事情都是倒退的。在我看来，您只有在弄清楚工作技术的共同元素之后才能定义标准。语言工作台还太不成熟，还没有准备好标准化。我怀疑 DSL 模式的标准可以建立在 MOF 上，或者至少看起来像 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 用于模式浮现在脑海中）。但现在语言工作台生命周期的早期，还无法确定。