您是否使用 MDA/MDD/MDSD 等任何类型的模型驱动方法？ 未来会是这样吗？

Question

编程语言在其历史上经历了几个（或）进化步骤。 有些人认为模型驱动的方法将是下一件大事。 openArchitectureWare、AndroMDA、Sculptor/Fornax Platform 等工具可以带来令人难以置信的生产力提升。 然而，我的经验是，一开始起步相当容易，但当你尝试一些意想不到的事情时，或者很难找到足够的信息来告诉你如何开始你的项目时，也会在某些时候陷入困境，因为可能有很多事情需要考虑。

我认为从模型驱动的东西中获得任何东西的一个重要见解是理解模型不一定是一组漂亮的图片或树模型或 UML，但也可能是文本描述（例如状态机、业务规则） ETC。）。

你怎么看？你的经历告诉你什么？ 模型驱动开发（或者无论你如何称呼它）有未来吗？

更新：似乎对此主题没有太多兴趣。 如果您对模型驱动方法有任何（好的或坏的）经验，或者为什么您认为它一点也不有趣，请告诉我。

Answer 1

免责声明：我是业务应用程序的开发人员。 以下观点无疑是由我在企业 IT 领域的经验所形成的。 我知道软件开发还有其他领域。 特别是在工业和/或嵌入式系统开发中，世界可能看起来有所不同。

我认为 MDSD 仍然与代码生成有太多联系。

只有当您的代码包含大量噪音和/或非常重复时，代码生成才有用。 换句话说，当你的代码不能主要关注本质复杂性，而是被偶然复杂性所污染时。

在我看来，当前平台和框架的趋势正是消除偶然的复杂性，让应用程序代码专注于本质的复杂性。

因此，这些新平台/框架使 MDSD 运动失去了很大的动力。

DSL（文本DSL）是另一种趋势，它试图让人们只关注本质的复杂性。 虽然 DSL 可以用作代码生成的源，但它们主要与代码生成无关。 DSL（尤其是内部 DSL）基本上让它开放以在运行时解释/执行。 [运行时代码生成介于两者之间]。

因此，即使 DSL 经常与 MDSD 一起提及，我认为它们确实是 MDSD 的替代品。 鉴于目前的炒作，他们也削弱了 MDSD 运动的动力。

如果您已经达到了最终消除代码中意外复杂性的目标（我知道这是虚构的），那么您就已经获得了业务问题的文本模型。 这不能再简化了！

漂亮的方框和图表不会提供抽象级别的另一种简化或提升！ 它们可能有利于可视化，但即便如此也是值得怀疑的。 图片并不总是掌握复杂性的最佳表示！

此外，MDSD 中涉及的工具的当前状态增加了另一个级别的意外复杂性（想想：同步、差异/合并、重构......），这基本上使简化的最终目标无效！

看一下下面的 ActiveRecord 模型，作为我的理论的例证：

class Firm < ActiveRecord::Base
   has_many   :clients
   has_one    :account
   belongs_to :conglomorate
end

我认为这不能再简化了。 此外，任何带有方框和线条的图形表示都不会简化，并且不会提供任何更多的便利（考虑布局、重构、搜索、比较......）。

Answer 2

模型驱动开发已经存在很长时间了。

早期尝试中最成功的是“James Martins Integrated Engineering Facility”，它仍然存在，并由 CA 以非常不酷的“Coolgen”品牌进行营销。

那么，如果它这么好，为什么没有占领世界呢？

这些工具是擅长使简单的事情变得更简单，但是，它们不会使困难的事情变得更容易，并且在许多情况下使困难的事情变得更难，

当您尝试说服图形 4GL 建模语言“做正确的事情”时 ！知道用 Java/C/SQL 或其他语言编写正确的代码是微不足道的。

Answer 3

我认为，工具变得更加完善、更多的人获得 MDD 经验还需要时间。 目前，如果你想从 MDD 中获得一些东西，你必须投入大量资金，因此它的用途仍然有限。

以 openArchitectureWare 为例：虽然它非常强大并且存在基本文档，但内部工作的文档缺失，并且在可扩展性方面仍然存在问题，这些问题没有记录 - 也许当 Xtext 和 Xpand 被重写时情况会变得更好。

但忽略这些限制，使用 oAW 生成本身非常容易，您可以像 Xtend 和 Xpand 中的魅力一样导航模型，并且通过将多个工作流程组合成更大的工作流程，您还可以做非常复杂的事情。 如果需要，您可以求助于 Java，因此您可以非常灵活地使用模型进行操作。 在 oAW 中使用 Xtext 编写您自己的 DSL 也可以很快完成，而且您基本上可以免费获得元模型、解析器和非常好的编辑器。 此外，您基本上可以从任何地方获取模型，例如可以将数据库转换为元模型的组件，并且可以轻松编写相应的模型。

所以我想说，随着工具和经验的增加，MDD 仍在不断发展。 如果您拥有必要的专业知识并准备好在公司内推广它，那么它已经可以成功使用。 最后，我认为这是一件非常好的事情，因为可以而且应该生成很多粘合代码（又名复制粘贴）。 在我看来，使用 MDD 来实现这一点是一种非常好的、结构化的方式，它可以促进可重用性。

Answer 4

我认为也许没有明确的答案 - 因此对这个问题缺乏“兴趣”。

但我个人对 MDA 的体验好坏参半。 唯一一次很好的体验是使用很棒的工具——我曾经使用TogetherSoft（我相信他们最终在borland）——他们是第一个引入编辑的人之一，编辑不是“代码生成”，而是实际编辑代码/直接模型（这样你就可以编辑代码或模型，这都是一件事）。 他们还进行了重构（这是我第一次记得它在 Smalltalk 环境中）。

从那时起，我就没有看到 MDA 变得更受欢迎，至少在主流中是这样，所以就受欢迎程度而言，它似乎不是未来（所以这就是答案）。

当然，流行度并不是一切，而且事情有卷土重来的趋势，但目前我认为 MDA+工具被许多人视为“基于向导的代码生成”工具（不管它到底是什么），所以我我认为它需要一段时间或者也许永远不会真正起飞。

Answer 5

MDD 的问题之一是，由于它工作在更高的抽象级别上，因此它要求开发人员也能够上升到抽象级别。 这大大减少了能够理解和使用此类方法的开发人员的范围。

Answer 6

如果您对模型驱动方法有任何（好的或坏的）经验，或者为什么您认为它一点也不有趣，请告诉我。

我认为这里的贡献者是“无银弹”阵营的一部分（我绝对是）。 如果 MDA 有效（等于“节省大量资金”），我们就会知道，这是肯定的。 问题是：在保持系统可管理性的同时，“元”能走多远？ 这是 UML 2.0 的转折点，他们引入了更正式的元元模型。 到目前为止，我还没有看到 UML 2.0 的建模能力在现实世界中的使用（但我的世界相当有限）。 此外，对于模型驱动的方法，您只有两种选择：生成代码，或者让运行时利用您的模型。 最终的无约束代码生成器被称为“人类”，而最终的运行时在 4GL 中找到（现在的当前数字是多少？）。 也许这可以解释缺乏热情的原因。

Answer 7

我们在 itemis (www.itemis.com) 经常使用模型驱动的软件开发。 到目前为止，我们的经历非常好。 舒尔它不是灵丹妙药，但它有助于提高软件质量，从而为我们的客户提供更多使用。

Answer 8

当且仅当它使用的模型可以像编写它应该生成的代码一样灵活时，模型驱动开发才会成为未来。 我认为它现在表现不佳的原因是你很难像基于文本的编程语言几十年来所做的那样进行“往返”。

使用基于文本的编程语言，更改模型就像更改几行代码一样简单。 使用图形编程语言（又名 MDD 图，如 UML），您必须找到一种方法将该模型一直翻译回其基于文本的等效语言（这首先就已经非常高效），并且它可以非常非常混乱。

恕我直言，如果 MDD 是从头开始构建的，并且与基于文本的对应物一样具有表现力和灵活性，那么 MDD 发挥作用的唯一方法就是。 尝试将现有的自上而下的图形设计语言（例如 UML）用于本质上使用分层抽象（例如编程语言）自下而上构建的工具会造成巨大的阻抗失配。 我不太清楚它的具体情况，但是 MDD 中仍然缺少一些东西，无法使它像人们声称的那样有用......

Answer 9

这是一个很晚的回复，但我目前正在寻找 MDD 工具来替换 Rose RT，不幸的是，Rhapsody 正在被 Rhapsody 取代。 我们处于实时、嵌入式和分布式 C++ 领域，我们从 MDD 中获益匪浅。 我们正在努力转向更好的工具，并在我们非常大的公司中更广泛地使用该工具。 由于这里提到的一些很好的原因，这是一场艰苦的战斗。

我认为 MDD 仅比编译器高一级，就像编译器比汇编高一级一样。 我想要一个工具，让我作为架构师开发应用程序框架，并广泛编辑代码生成（脚本）以使用该框架以及我们用于消息传递的任何中间件。 我希望开发人员制作完整的 UML 类和状态图，其中包括生成应用程序和/或库所需的所有代码。

确实，您可以用代码做任何事情，但我粗略地总结 MDD 的好处如下：

1. 少数人制作应用程序框架、中间件适配器并将其粘合到 MDD 工具。 他们建造“房子”。
2. 其他人创建完整的类、图表和状态机转换代码。 这让他们可以专注于应用程序而不是“房子”。
3. 当人们有奇怪的设计时很容易看出，因为图表就是代码。 我们没有所有的专家开发人员，很高兴以这种方式培养初级人员。
4. 主要是在移动机器人项目等中可能发生的令人讨厌的状态机代码。 我希望人们制作出我可以理解、批评和处理的状态图。
5. 您还可以进行很好的重构，例如将操作和属性拖动到继承链或其他类等。我比挖掘文件更喜欢这样做。

即使在我输入此内容时，我也意识到您可以用代码完成所有操作。 我喜欢在代码之上使用一个瘦工具来强制一致性、记录设计并允许更容易的重构。

我遇到的主要问题是，没有针对此类模型的标准功能和文件格式集，但我没有一个好的答案。 人们担心供应商会消失然后陷入困境。 （我们在 Rose RT 中基本上就遇到过这种情况。）源代码中没有这种情况。 但是，您将拥有该工具的最新版本以及您上次生成的课程代码:)。 我愿意打赌，收益大于风险。

我还没有找到这样的工具，但我正在努力让一些供应商听取我的意见，并可能接受金钱来实现这一目标。