Mar*_*nke 7 paradigms model-driven
编程语言在其历史中有几个(r)进化步骤.有些人认为模型驱动的方法将是"下一件大事".有一些工具,如openArchitectureWare,AndroMDA,Sculptor/Fornax平台等,可以带来令人难以置信的生产力提升.然而,我的经验是,它在开始时要么相当容易,但是当你尝试一些意想不到的东西或者很难找到足够的信息来告诉你如何开始你的项目时,也会陷入困境.可能有很多事情需要考虑.
我认为从模型驱动的东西中获取任何东西的重要见解是理解模型不一定是一组漂亮的图片或树模型或UML,但也可能是文本描述(例如状态机,业务规则)等等.).
您如何看待,您的经历告诉您什么？是否存在模型驱动开发的未来(或者您可能想要称之为的任何东西)？
更新:这个主题似乎没有太多兴趣.如果您对模型驱动方法有任何(好的或坏的)经验,或者您认为它根本没有意义,请告诉我.
免责声明:我是业务应用程序的开发人员.以下观点肯定是由我在企业IT战略中的经验所塑造的.我知道,还有其他软件开发领域.特别是在工业和/或嵌入式系统开发中,世界可能看起来不同.
我认为MDSD仍然与代码生成过于紧密相关.
代码生成仅在您的代码包含大量噪声和/或非常重复时才有用.换句话说,当你的代码不能主要关注基本的复杂性时,却会被意外的复杂性所污染.
在我看来,当前平台和框架的趋势正是为了消除意外的复杂性,让应用程序代码专注于基本的复杂性.
因此,这些新的平台/框架从MDSD运动的风帆中汲取了很多风.
DSL(文本的)是另一种趋势,试图使唯一的重点放在基本的复杂性上.虽然DSL可以用作代码生成的源,但它们并不主要与代码生成相关联.DSL(特别是内部DSL)基本上允许它在运行时被解释/执行.[运行时代码生成介于两者之间].
因此,即使经常与MDSD一起提及DSL,我认为它们实际上是MDSD的替代品.鉴于目前的炒作,他们也从MDSD运动中获取动力.
如果您已达到最终消除代码中的意外复杂性的目标(我知道这是虚构的),那么您已经达到了业务问题的文本模型.这无法进一步简化!
漂亮的盒子和图表不提供抽象级别的另一个简化或提升!它们可能对可视化有益,但即便如此也是值得怀疑的.掌握复杂性的图片并不总是最好的表现形式!
更进一步,参与MDSD的工具的当前状态,增加了意外复杂另一个层面(认为:同步,版本比较/合并,重构......),基本上勾销简化的终极目标!
看看下面的ActiveRecord模型,作为我理论的一个例子:
class Firm < ActiveRecord::Base
has_many :clients
has_one :account
belongs_to :conglomorate
end
我不认为这可以更简化.另外随着框和线的任何图形表示就没有简化,并不会提供任何更多的便利(想想布点,重构,搜索,版本比较......).
模型驱动开发已经存在了很长时间.
早期尝试中最成功的是詹姆斯·马丁斯综合工程设施",它仍然由CA以严重不冷的"Coolgen"品牌名称进行销售.
那么,如果它如此美好,它为什么不接管世界呢？
这些工具很擅长简化这些简单的东西,但是,它们不会让硬件变得更容易,而且在许多情况下会使硬件变得更难!
当您知道在Java/C/SQL中编写正确的东西或其他任何微不足道的东西时,您可以花费数小时试图说服图形4GL建模语言"做正确的事".
小智 3
我认为，工具变得更加完善、更多的人获得 MDD 经验还需要时间。目前，如果你想从 MDD 中获得一些东西，你必须投入大量资金，因此它的用途仍然有限。
以 openArchitectureWare 为例：虽然它非常强大并且存在基本文档，但内部工作的文档缺失，并且在可扩展性方面仍然存在问题，这些问题没有记录 - 也许当 Xtext 和 Xpand 被重写时情况会变得更好。
但忽略这些限制，使用 oAW 生成本身非常容易，您可以像 Xtend 和 Xpand 中的魅力一样导航模型，并且通过将多个工作流程组合成更大的工作流程，您还可以做非常复杂的事情。如果需要，您可以求助于 Java，因此您可以非常灵活地使用模型进行操作。在 oAW 中使用 Xtext 编写您自己的 DSL 也可以很快完成，而且您基本上可以免费获得元模型、解析器和非常好的编辑器。此外，您基本上可以从任何地方获取模型，例如可以将数据库转换为元模型的组件，并且可以轻松编写相应的模型。
所以我想说，随着工具和经验的增加，MDD 仍在不断发展。如果您拥有必要的专业知识并准备好在公司内推广它，那么它已经可以成功使用。最后，我认为这是一件非常好的事情，因为可以而且应该生成很多粘合代码（又名复制粘贴）。在我看来，使用 MDD 来实现这一点是一种非常好的、结构化的方式，它可以促进可重用性。