模型驱动架构的概念是，您创建的模型表达您需要以不含任何（或至少大多数）实现技术的方式解决的问题，然后为一个或多个特定平台生成实现。声称在更高层次的抽象工作更有力和更有成效。此外，您的模型比技术更长（当您的第一语言/平台变得过时时，您仍然可以使用它来为您的下一代解决方案使用）。另一个声称受益的关键是可以生成很多样板和“笨拙的工作”。一旦计算机理解了您的情况的语义，它可以帮助您更多。
有人声称这种方法的效率提高了10倍，并且 我们将在10年内构建软件。
但是，这只是理论。我想知道当橡胶遇到道路时会有什么结果。此外，MDA的“官方”版本来自OMG，看起来非常沉重。它主要基于UML，根据你的要求（我倾向于“坏”）可能会被视为好或坏。
但是，尽管存在这些问题，但很难与更高层次的抽象和“教导”计算机来理解问题和解决方案的语义的想法争论。设想一系列简单表达真理的ER模型，然后想象使用它们来生成解决方案的重要部分，首先是一组技术，然后是另一组技术。
所以，我很想听听那些现在正在做MDA的人（“官方”与否）。你用的是什么工具？它是如何运作的？您能够捕获多少理论承诺？你看到真正的10倍效率提升吗？
答案 0 :(得分：6)
对这个问题缺乏回应有点不祥......也许我会让Dijkstra反对它。
...因为计算机出现在十年之内 当信念进步和 科学和健康的健康 它几乎是无限的技术 或许明智地回想一下 它的最初目标，人类的 科学的努力，比方说， 过去五个世纪以来一直是 壮观的失败。
大家都记得，第一个和第一个 最重要的目标是发展 Elixir将给予一个 喝它永恒的青春。但是由于 永恒没有多大意义 贫穷，科学世界很快 开始了第二个项目，即。 那将是哲学家的石头 让你赚到尽可能多的黄金 需要。
...
寻求理想的编程 语言和理想的人机 可以制作软件的界面 危机像阳光下的雪一样融化了 - 还有！ - 所有的 寻找的特点 长生不老药和石头。这个搜索 得到两个人的大力支持 双方，首先来自事实 奇迹的运作是至少 你可以期待的电脑， 其次来自财务和财务 一个社会的政治支持 一直要求Elixir和 石头在第一位。
两个主流可以 尊贵，追求石头 和对Elixir的追求。
对石头的追求是基于 假设我们的“编程 工具“太弱了。一个例子是 相信当前的节目 语言缺乏我们需要的“功能”。 PL / I是比较壮观的一个 将要生产的石头。我仍然 记住广告 数据化，1968年，其中一个微笑 Susie Mayer宣布全彩 她已经解决了她的一切 通过切换到编程问题 PL / I。这太可预见了 那几年后，可怜的苏茜 梅尔不再笑了。不必要 要说，这个任务还在继续 时间是下一个可能的石头了 以Ada的形式出现（后面 铁幕被明智地提到了 作为PL / II）。即使是最基本的 初学者的占星术就足够了 预测阿达不会是最后一个 这种石头。
...
形式上的另一系列宝石 制作“编程工具” 在“软件”的旗帜下 工程“，随着时间的推移， 一直试图取代知识分子 管理学科的纪律 它现在已被接受的程度 它的章程“如果你如何编程 不能“。
答案 1 :(得分：4)
我从1999年开始在模型驱动软件开发领域进行自己的独立研究。我最终在2006年开发了一种通用建模方法，我将其标记为ABSE（基于Atom的软件工程）。
因此，ABSE建立在两个基本方面：
一些ABSE功能：
它可以支持传统的所有其他形式的软件工程 面向文件的方法，基于组件的开发，面向方面的编程，特定于域的建模，软件产品线和软件工厂。
它足够通用，可以应用于企业软件，嵌入式，游戏，航空电子，互联网，任何领域。
如果有效的话，你不需要成为一名火箭科学家。 “纯粹的开发者凡人”可以访问ABSE。没有像oAW / MDA / XMI / GMF / etc工具链中那样复杂的复杂性。
它的元元模型旨在支持从模型中生成100％的代码。不需要往返。元模型直接支持自定义/生成的代码组合。
可以同时操作模型。可以应用工作流程和版本控制（需要工具支持）。
这可能听起来像是在乌托邦方面，但实际上我离开了研究阶段，我现在处于IDE的实施阶段，将所有这些都付诸实践。我想我将在几周内（4月底左右）准备好基本原型。 IDE（名为AtomWeaver）正在通过ABSE构建，因此AtomWeaver将成为ABSE方法的第一个概念验证。
所以，这不是MDA（谢天谢地！），但至少是一种非常易于管理的方法。作为ABSE的发明者，我对此感到兴奋，但我确信模型驱动的软件开发将在2009年得到推动！
敬请关注......
答案 2 :(得分：4)
模型驱动的软件开发仍然是一个利基领域，但已发布的案例研究和越来越多的其他文献显示手工编码方法的成功。
OMG的MDA只是一种方法，其他人使用特定于域的语言（不使用UML进行建模）显示成功。
关键是从模型生成代码并更新您的生成器，如果它没有生成您想要的 - 而不是修改您的代码。帮助您实现这一目标的专家工具已经存在多年了，但由于微软进入这一领域并通过Eclipse世界中的openArchitectureWare等开源项目，这种方法的兴趣在过去五年左右的时间里有所增长。
我运行了几个网站：www.modeldrivensoftware.net和www.codegeneration.net，您可以在这些网站上获得有关这些主题的更多讨论，访谈，文章和工具选项。
答案 3 :(得分：0)
我试了一次。大约在整个项目的一半时间，我意识到我的模型在我的代码中已经过时了，并且非常复杂，以至于让它们保持最新状态是令人望而却步的，并使我放慢脚步。
问题是软件充满了边缘情况。模型非常适合捕获更大的图片，但是一旦你开始实际编写实现代码，你就会发现所有这些边缘情况，并且在很长时间之前你会注意到模型太过细化而你必须在维护模型或获取模型之间做出选择。写了一些代码。也许样板生成对于启动是有利的，但之后好处很快消失，我发现生产率大幅下降。这些模型最终从该项目中消失了。
答案 4 :(得分：0)
我在1997年开始使用模型驱动技术和DSL，我对MDE越来越热衷。
我可以证明，在某些情况下，达到10倍以上的生产力（甚至更多;-)是可能的。我已经实现了许多模型驱动的软件工厂，这些工厂能够使用非常简单的模型生成可执行软件，从持久层到UI层，与生成的技术文档相关联。
但出于几个原因，我不遵守MDA标准。 MDA承诺是在PIM模型中表达您的软件，并且有能力将其自动转换为一个或多个技术堆栈（PSM）。
但是：
我提倡MDE策略，其中PIM是一个谈论您的逻辑架构的DSL（独立于任何技术堆栈），并使用自定义和特定的代码生成器从此PIM生成代码。
优点：
缺点：
这种特殊方法可以在具有UML配置文件的可扩展UML建模器之上实现，也可以在特定模型编辑器（文本或图形）上实现。
MDA和MDE之间的巨大差异可归纳为：
这两种方法之间存在一种利益冲突。一方提倡重复使用现成的预先资本化的模型驱动组件，另一方面，您可以通过定义DSL和相关工具来实现自己的大写。
答案 5 :(得分：0)
我们确实使用MDA和EMF作为工具。通过代码生成而不是手动编码，它为我们节省了很多工时。它确实需要高素质的分析能力，但这就是IT的意义所在。因此，我们主要关注问题本身，以及关注代码生成和所生成代码的运行时支持的工具/框架。 最后，我可以确认，使用MDA确实可以使生产率提高10倍。