您如何看待模型驱动的软件开发?[关闭]

我在一个使用IBMRationalRhapsodyforC++的项目中使用MDSD。该模型非常接近UML,因此我们没有真正的领域特定语言。但我仍然会声称使用MDSD。根据我的经验,MDSD有很多好处:

a) 使用MDSD有助于将软件架构提升到一个复杂的水平。你总是在非常抽象的层面上工作,思考大局。牛仔编码软件通常缺乏良好的架构,因为开发人员被困在细节中。使用MDSD,我在工作中看到了一种趋势,即用足够大的类、良好的模式或更好的代码来解决问题。

b) 使用MDSD时,软件的总体文档往往更好。当然,有一些工具可以从代码中自动生成类图。但是这些图表由1000个类组成,你看不到感兴趣的方面。使用MDSD,您可以专门绘制系统的一个方面,并且也可以使用相同的图表来生成部分代码。

c) 建模有助于处理固有的系统复杂性。我想说,有些系统太复杂了,如果没有计算机辅助设计的支持,就无法构建。没有大型软件工具的帮助,没有人会设计CPU。使用软件来帮助您编写更复杂的软件。

d) 使用MDSD有助于遵守编码风格指南。没有比让代码由规则集生成更好的方法来获得连贯的代码风格了。

当然,MDSD也有一些缺点: d) 如果你有一个模型,你希望每一行代码都来自该模型。而且,将外部库包含到项目中可能很困难。所以,要么你接受这样一个事实,即你的系统是基于外部组件的,要么你重新发明轮子,把它放进你的模型中。

e) 使用版本控制工具时,建模工具可能会遇到问题。源代码通常比模型图更容易合并。这将迫使团队从复制-编辑-合并工作流程转移到锁定-编辑合并工作流程。

MDA是一个有点超载的概念。有时这意味着将UML或其他类型的图转换为可执行代码。我从未见过用现在可用的工具很好地解决这个问题。它通常会导致项目很快得到结果,然后导致维护噩梦,因为可用的工具并不能真正支持大型团队在可视化图表上工作,而且人们开始在图表和生成的代码中工作。

我看到一些看起来很像领域驱动设计的东西被称为MDA,如果你的意思是我完全支持它的话:-)

嗡嗡声。

我所相信的OTOH是在运行时建模。与其生成代码,不如让模型在运行时保持活力,让你的应用程序成为这些模型的运行时解释器。

我不知道这是否适用于Java。有关Smalltalk,请参阅 Magritte ,用于海滨。

我认为这更可取。这就是我想暗示的 this question 关于MVC-ARS而不是MVC。ARS(动作/表示/状态)按设计包含在模型中,可防止控制器或视图过载。

模型驱动软件开发不仅仅是MDA,还有一组其他方法,包括可能更流行的领域特定语言方法。

当然,代码是“一个”模型,但在DSL中捕获更高级别的模型是表达相同意图的一种更简洁的方式。关键在于 总是 从模型生成代码,而不是允许对生成的代码进行独立修改。

如果你不喜欢购买现成的发电机,有很多可用的工具和大量已发表的材料,包括案例研究,告诉你如何构建自己的发电机。可以说,这比使用通用编程语言提供了更多的控制权。

这听起来确实不错,但我还没有看到它以实际可行的方式实现。

我这样认为:代码就是模型。这样,你的模型和代码总是最新的:-)

如上所述,我发现两本书对理解MDA很有用,这是一个广泛的主题。

• MDA提炼——模型驱动架构原理。(梅勒)
• 现实MDA:用模型驱动架构解决业务问题(Guttman)

你不需要阅读所有的Guttman来理解这个想法,因为案例研究会变得无聊,但引言读起来很愉快。

MDA通常很难将业务规则集成到服务器端层,因为模型视图映射是由生成的代码处理的,功能挂钩是作为事件响应器提供的。

不过,我还没有看到MDA工具像Fort(或UDS,现已死亡)+Express那样强大。我认为,具有Fort功能的MDA加上实现独立服务层的更好模式(如ActiveRecord或EntityTransactionManager模式)将是任何平台的杀手级应用程序。

针对三层MDA方法的实际应用的问题是,这些方法很难设置和适应特定的需求。想想ABAP和SAP的费率