您是否使用mda/mdd/mdsd,任何类型的模型驱动方法?这将是未来吗?

我认为,这需要时间,直到工具变得更精致,更多的人获得MDD的经验。目前,如果你想从MDD中得到一些东西,你必须投资很多,所以它的使用仍然有限。

例如,看看OpenArchitectureWare:虽然它非常健壮,并且存在基本的文档,但是内部工作的文档丢失了,并且仍然存在可伸缩性问题,这些问题是未记录的-当xtextext和xpand被重写时,可能会更好。

但是,尽管有这些限制,OAW的生成本身是非常容易的,您可以像xtend和xpand中的魅力一样导航您的模型,通过将几个工作流组合到更大的工作流中,您还可以做非常复杂的事情。如果需要的话,你可以求助于Java,这样你就可以非常灵活地使用你的模型。用OAW中的xtext编写自己的DSL也很快完成,但是基本上你可以免费获得元模型、解析器和一个非常好的编辑器。此外,您还可以从任何地方获得您的模型,例如,可以将数据库转换为元模型的组件,并且可以不费力地编写相应的模型。

所以我想说,随着工具和经验的增加,MDD仍在发展。如果你有必要的专业知识并准备好在你的公司内推广它,那么它已经可以成功使用了。最后,我认为这是一件非常好的事情,因为可以并且应该生成大量的粘合代码(又称复制粘贴)。在我看来,使用MDD实现这一点是一种非常好的、结构化的方法,这有助于重用。

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

我认为这不能再简单了。此外,任何带有方框和线条的图形表示都不会简化,也不会提供任何便利(考虑布局、重构、搜索、差异化…)。

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

最成功的早期尝试是詹姆斯马丁斯综合工程设施,这是仍然存在,并由加州营销严重不酷的“柯尔根”品牌名称。

那么,如果它是如此的好,为什么它不接管世界呢?

好吧,这些工具擅长使简单的东西变得简单,但是,它们不会使困难的东西变得更容易,而且在许多情况下会使困难的东西变得更难!

当你知道在爪哇/C/SQL中编码正确的东西或任何琐碎的事情时,你可以花几个小时试图说服一个图形化的4GL建模语言来“做正确的事情”。

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

但我个人对丙二醛有着丰富的经验。唯一的一次很好的体验是使用伟大的工具-我曾经使用togethersoft(我相信他们最终以某种方式在Borland结束)-他们是第一批引入编辑的人之一,这不是“代码生成”,而是直接编辑代码/模型(这样你就可以编辑代码或模型,这是唯一的事情)。他们还进行了重构(这是我在Smalltalk环境之后第一次记得)。

从那时起,我就没有看到丙二醛在流行,至少在主流中是如此,所以从流行的角度来看,它似乎不再是未来(这样的回答)。

当然,流行并不是所有的事情,而且事情有一个趋势会回来,但就目前而言,我认为MDA+工具被许多人视为“基于向导的代码生成”工具(不管它实际上是什么),所以我认为它将是一段时间,或者可能永远不会真正起飞。

MDD的一个问题是,因为它在更高的抽象级别上工作,所以它需要开发人员也可以在抽象级别上工作。这大大减少了能够理解和使用这种方法论的开发人员的范围。

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

我认为这里的贡献者是“无银弹”阵营的一部分(我是绝对的)。如果MDA起作用(相当于“巨大的节省”),我们就会知道,这是肯定的。问题是:在保持系统的可管理性的同时,您可以走多远?这是UML2.0的转折点,当时他们引入了一个更正式的元模型。到目前为止,我还没有看到uml 2.0建模能力的实际应用(但我的世界相当有限)。此外,对于模型驱动的方法,您只有两个选择:生成代码,或者让运行时利用您的模型。终极的无约束代码生成器被称为“人类”,而在4GL中找到的终极运行时(现在的数字是多少?)或许这可以解释为什么缺乏热情。

我们在itemis(www.itemis.com)使用模型驱动的软件开发。到目前为止,我们有很好的经验。舒尔这不是一个银弹,但它有助于提高软件质量,从而为我们的客户提供更多的用途。

如果并且只有当它使用的模型能够像编写它应该生成的代码一样灵活时,模型驱动的开发才是未来。我认为它现在做得不好的原因是,你很难像基于文本的编程语言几十年来做的那样做“往返”。

对于基于文本的编程语言,更改模型就像更改几行代码一样简单。使用图形编程语言(也称为MDD图,如UML),您必须找到一种方法将该模型转换回它的基于文本的等价物(这在一开始就已经非常有效了),而且它可能非常非常混乱。

imho,如果MDD是从一开始就构建起来的,并且像它的基于文本的对应物一样具有表现力和灵活性,那么MDD就永远是有用的。试图使用现有的自上而下的图形设计语言(如UML)来处理使用分层抽象(如编程语言)自下而上构建的工具,会造成巨大的阻抗不匹配。我不能完全相信它,但MDD中仍然有一些东西丢失了,这将使它像人们声称的那样有用…

这是一个非常晚的回复,但我目前正在寻找MDD工具来取代RoseRT,不幸的是,它被Rhapsody所取代。我们在实时、嵌入式和分布式C++空间中,我们从MDD中得到了很多。我们正在努力开发一种更好的工具,并在我们的大公司中得到更广泛的使用。这是一场艰苦的战斗,因为这里提到了一些很好的理由。

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

确实,您可以对代码执行任何操作,但我将大致总结MDD的好处,如下所示:

1. 少数人制作应用程序框架、中间件适配器,并将其粘附到MDD工具上。他们建造了“房子”。
2. 其他人创建完整的类、图表和状态机转换代码。这让他们专注于应用而不是“房子”。
3. 很容易看出什么时候人们有了wierd设计,因为图表就是代码。我们没有所有的专业开发人员,用这种方式培养年轻人是件好事。
4. 大多数情况下,这是一个令人讨厌的状态机代码,可以发生在移动机器人项目中。我想让人们制作状态图,我可以理解、批评和使用它们。
5. 您还可以进行很好的重构,比如将操作和属性拖到继承链上或其他类上,等等。我更喜欢这样做,而不是挖掘文件。

当我输入这个代码时,我意识到你可以用代码做任何事情。我喜欢在代码之上使用一个精简的JSUT工具来强制实现一致性、记录设计并允许更容易的重构。

我遇到的主要问题是,我没有一个很好的答案,因为对于此类模型,没有标准的功能集和文件格式。人们担心卖主会离开然后被卡住。(我们基本上是用Rose RT实现的)源代码没有。但是,您将拥有该工具的最新版本和上次生成的课程代码:)。我敢打赌,利益大于风险。

我还没有找到这样的工具,但我正试图让一些供应商听我的,也许接受钱来实现这一点。