paradigms - 您是否使用 MDA/MDD/MDSD，任何类型的模型驱动方法？会是 future 吗？

Question

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

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

你怎么想，你的经历告诉你什么？模型驱动开发(或任何您想称之为的)有 future 吗？

更新:对这个话题似乎没有太多兴趣。如果您对模型驱动方法有任何(好的或坏的)经验，或者您认为它根本不有趣的原因，请告诉我。

Answer 1

免责声明:我是业务应用程序的开发人员。以下观点肯定是由我在企业 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

我不认为这可以更简化。此外，任何带有框和线的图形表示都不会简化，也不会提供更多便利(考虑布局、重构、搜索、差异......)。