您认为模型驱动的软件开发怎么样?

我在使用IBM Rational Rhapsody为C++的项目中使用MDSD。该模型非常接近UML,因此我们没有真正的领域特定语言。但我还是会声称使用MDSD。根据我的经验,MDSD有很多好处:

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

b)软件的大图文档往往更适合MDSD。当然,还有一些工具可以从代码中自动生成类图。但是这些图由1000个类组成,您看不到感兴趣的方面。使用MDSD,您可以专门绘制系统的一个方面,同样的图也用于生成代码的一部分。

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

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

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

e)建模工具可能会遇到使用版本控制工具的问题。源代码合并通常比模型图简单。这将强制团队从复制编辑合并移到锁定编辑合并工作流。

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

我见过一些看起来很像域驱动设计的东西被称为mda,如果你是说我完全赞成的话:—)

嗡嗡声。

我相信的是,Otoh,在运行时建模。不要生成代码,而是让模型在运行时保持活动,让您的应用程序成为这些模型的运行时解释程序。

我不知道这是否已经为Java完成了。关于smalltalk,请参见 Magritte 在海边使用。

我觉得更好。这就是我想暗示的 this question 关于MVC-ARS而不是MVC。ARS(操作/表示/状态)通过设计包含在模型中,并防止控制器或视图过载。

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

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

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

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

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

正如上面所述,我只想写两本书来理解MDA,这是一个广泛的主题。

• MDA提炼了模型驱动架构的原理。(梅洛)
• 现实生活中的MDA:使用模型驱动架构(Guttman)解决业务问题

当案例研究变得枯燥时,你不需要阅读所有的《古特曼》来获得这个想法,但是导言读起来很愉快。

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

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

针对三层MDA方法的实际应用程序存在的问题是,这些方法很难设置并适应特定的需求。想想ABAP和SAP的价格