编程语言在其历史上有几个（r）进化步骤。有些人认为模型驱动的方法将成为下一件大事。有一些工具，如 openArchitectureWare、AndroMDA、Sculptor/Fornax Platform 等，可以极大地提高生产力。然而，我的经验是，一开始很容易上手，但当你尝试一些意料之外的事情时，或者很难找到足够的信息来告诉你如何开始你的项目时，也会在某个时候卡住，因为可能有很多事情需要考虑。
我认为从模型驱动的东西中获得任何东西的一个重要见解是理解模型不一定是一组漂亮的图片或树模型或 UML，但也可能是文本描述（例如状态机、业务规则等）。
你怎么看？你的经历告诉你什么？模型驱动的开发（或任何您可能想要的名称）是否有未来？
更新：似乎对这个话题没有太多兴趣。如果您对模型驱动方法有任何（好的或坏的）经验，或者您为什么认为它一点都不有趣，请告诉我。
【问题讨论】：
免责声明：我是业务应用程序的开发人员。以下观点肯定是由我在企业 IT 领域的经验所塑造的。我知道，还有其他软件开发领域。尤其是在工业和/或嵌入式系统开发中，世界可能看起来不同。
我认为 MDSD 仍然与代码生成过于紧密。
仅当您的代码包含大量噪音和/或非常重复时，代码生成才有用。换句话说，当你的代码不能主要关注本质的复杂性，而是被偶然的复杂性污染了。
在我看来，当前平台和框架的趋势正是消除偶然的复杂性，让应用程序代码专注于基本的复杂性。
因此，这些新的平台/框架从 MDSD 运动的风帆中汲取了很多动力。
DSL（文本）是另一种趋势，它试图将重点放在基本的复杂性上。虽然 DSL 可以用作代码生成的源代码，但它们并不主要与代码生成相关联。 DSL（尤其是内部 DSL）基本上让它在运行时被解释/执行。 [运行时代码生成介于两者之间]。
因此，即使 DSL 经常与 MDSD 一起被提及，我认为它们确实是 MDSD 的替代品。考虑到当前的炒作，他们也消除了 MDSD 运动的势头。
如果您已达到最终消除代码中意外复杂性的目标（我知道这是虚构的），那么您已经获得了业务问题的文本模型。这不能再简化了！
漂亮的方框和图表不会提供抽象级别的另一种简化或提升！它们可能对可视化有好处，但即使这样也是值得怀疑的。图片并不总是掌握复杂性的最佳表示！
此外，MDSD 中涉及的工具的当前状态增加了另一个级别的意外复杂性（想想：同步、差异/合并、重构......）这基本上使简化的最终目标无效！
看看下面的 ActiveRecord 模型，作为我的理论的说明：
class Firm < ActiveRecord::Base
has_many :clients
has_one :account
belongs_to :conglomorate
end
我认为这不能再简化了。此外，任何带有框和线的图形表示都不会简化，也不会提供更多便利（考虑布局、重构、搜索、差异......）。
【讨论】：
模型驱动开发已经存在了很长时间。
早期尝试中最成功的是“James Martins Integrated Engineering Facility”，它仍然存在并由 CA 以非常不酷的“Coolgen”品牌进行营销。
既然这么好，为什么不接管世界呢？
嗯，这些工具擅长让简单的东西变得更简单，但是，它们不会让困难的东西变得更容易，而且在很多情况下会让困难的东西变得更难！
当您知道用 Java/C/SQL 或其他任何东西编写正确的事情时，您可以花费数小时试图说服图形 4GL 建模语言“做正确的事情”。
【讨论】：
我认为，这需要时间，直到工具变得更加完善，更多的人获得 MDD 的经验。目前，如果您想从 MDD 中获得一些东西，您必须投入大量资金，因此它的使用仍然有限。
以 openArchitectureWare 为例：虽然它非常健壮并且存在基本文档，但缺少有关内部工作的文档，并且仍然存在可伸缩性问题，这些问题未记录 - 也许当 Xtext 和 Xpand 被重写时会变得更好。
但是忽略这些限制，使用 oAW 生成本身非常容易，您可以像 Xtend 和 Xpand 中的魅力一样导航您的模型，并且通过将多个工作流程组合成更大的工作流程，您还可以做非常复杂的事情。如果需要，您可以求助于 Java，因此您可以非常灵活地使用模型进行操作。在 oAW 中使用 Xtext 编写您自己的 DSL 也很快，但您基本上免费获得了元模型、解析器和非常好的编辑器。您也可以基本上从任何地方获取模型，例如一个可以将数据库转换为元模型的组件，并且可以轻松编写相应的模型。
所以我想说，随着工具和使用它的经验的增加，MDD 仍在构建中。如果您拥有必要的专业知识并准备在您的公司内推广它，它已经可以成功使用。最后，我认为这是一件非常好的事情，因为可以而且应该生成很多胶水代码（也就是复制粘贴）。在我看来，使用 MDD 这样做是一种非常好的且结构化的方式，它有助于可重用性。
【讨论】：
我认为也许没有明确的答案 - 因此对这个问题缺乏“兴趣”。
但我个人对 MDA 的体验参差不齐。唯一一次好的体验是使用很棒的工具-我曾经使用过TogetherSoft（我相信他们以某种方式最终进入了borland）-他们是最早引入编辑的人之一，这不是“代码生成”而是实际编辑代码/直接建模（这样您就可以编辑代码或模型，这都是一回事）。他们还进行了重构（这是我记得第一次发布 smalltalk 环境）。
从那时起，我没有看到 MDA 越来越受欢迎，至少在主流中是这样，所以就受欢迎程度而言，它似乎不是未来（所以那种回答）。
当然，流行并不是一切，而且有回归的趋势，但目前我认为 MDA+工具被许多人视为“基于向导的代码生成”工具（不管它到底是什么) 所以我认为它需要一段时间或者永远不会真正起飞。
【讨论】：
MDD 的一个问题是，由于它在更高的抽象级别上工作，因此它要求开发人员也可以达到抽象级别。这大大减少了能够理解和使用此类方法的开发人员的范围。
【讨论】：
如果您对模型驱动方法有任何（好的或坏的）经验，或者您为什么认为它一点都不有趣，请告诉我。
我认为这里的贡献者是“没有银弹”阵营的一部分（我绝对是）。如果 MDA 有效（相当于“节省大量资金”），我们就会知道，这是肯定的。问题是：在保持系统可管理性的同时，你能走多远的“元”？这是 UML 2.0 的转折点，当时他们引入了更正式的元元模型。到目前为止，我还没有看到 UML 2.0 的建模能力在现实世界中的使用（但我的世界相当有限）。此外，对于模型驱动的方法，您只有两种选择：生成代码，或者让运行时利用您的模型。最终的无约束代码生成器被称为“人类”，而最终的运行时在 4GL 中可以找到（现在的数字是多少？）。也许这可以解释缺乏热情。
【讨论】：
我们 itemis (www.itemis.com) 大量使用模型驱动的软件开发。到目前为止，我们有非常好的经验。舒尔它不是灵丹妙药，但它有助于提高软件质量，从而为我们的客户提供更多用途。
【讨论】：
当且仅当它使用的模型可以像编写它应该生成的代码一样灵活时，模型驱动开发才是未来。我认为它现在做得不好的原因是你很难像基于文本的编程语言几十年来所做的那样“往返”。
使用基于文本的编程语言，更改模型就像更改几行代码一样简单。使用图形编程语言（又名 MDD 图，如 UML），您必须找到一种方法将该模型一直翻译回其基于文本的等价物（这首先已经非常有效）并且它可以非常非常混乱。
恕我直言，如果 MDD 从头开始构建，使其像基于文本的对应物一样具有表现力和灵活性，那么它唯一有用的方法。尝试将现有的自顶向下图形设计语言（例如 UML）用于本质上是使用分层抽象（例如编程语言）自底向上构建的工具会造成巨大的阻抗不匹配。我不能完全确定它，但 MDD 中仍然缺少一些东西，使它像人们声称的那样有用......
【讨论】：
这是一个很晚的回复，但我目前正在寻找 MDD 工具来替换 Rose RT，不幸的是，Rhapsody 正在取代它。我们处于实时、嵌入式和分布式 C++ 空间中，我们从 MDD 中获得了很多。我们正在尝试使用更好的工具，并在我们非常大的公司中更广泛地使用该工具。由于这里提到的一些很好的原因，这是一场艰苦的战斗。
我认为 MDD 只是比编译器高一级，就像编译器比汇编高。我想要一个工具，让我作为架构师开发应用程序框架，并广泛编辑代码生成（脚本）以使用该框架和我们用于消息传递的任何中间件。我希望开发人员制作完整的 UML 类和状态图，其中包括生成应用程序和/或库所需的所有代码。
确实可以用代码做任何事情，但我将 MDD 的好处大致总结如下：
即使在我输入此内容时，我也意识到您可以在代码中完成所有操作。我喜欢在代码之上添加一个精简工具来强制统一、记录设计并允许更轻松地重构。
我遇到的主要问题是我没有很好的答案，因为这些模型没有标准的功能和文件格式。人们担心供应商离开然后被卡住。 （我们基本上在 Rose RT 中发生过这种情况。）源代码没有这种情况。但是，您将拥有该工具的最新版本以及您上次生成的课程代码 :)。我愿意打赌，收益大于风险。
我还没有找到这样的工具，但我正在尝试让一些供应商听我的意见，也许会接受资金来实现这一目标。
【讨论】：