首页 / 知识

关于mdsd：您如何看待模型驱动的软件开发？

2023-04-15 20:08:00

我真的很想听听您对Java和/或.NET的模型驱动的软件开发的看法。

节省时间吗？它会提高质量吗？

我在带有IBM Rational Rhapsody for C ++的项目中使用MDSD。该模型非常接近UML，因此我们实际上没有特定于域的语言。但是我仍然声称会使用MDSD。根据我的经验，MDSD有很多好处：

a)使用MDSD有助于将SW体系结构提升到复杂的水平。您总是在非常抽象的水平上思考大局。牛仔编码软件通常缺乏良好的体系结构，因为开发人员会陷入细节。使用MDSD，我发现我的工作趋向于用足够大小的类，漂亮的模式或只是更好的代码来解决问题。

b)使用MDSD可以更好地记录SW的大图文档。当然，有些工具可以根据您的代码自动生成类图。但是这些图包含1000个类，您看不到感兴趣的方面。使用MDSD，您可以专门绘制系统的一个方面，并且使用完全相同的图来生成代码的一部分。

c)建模有助于解决固有的系统复杂性。我要说的是，有些系统太复杂而无法在没有计算机辅助设计支持的情况下构建。没有庞大的软件工具的帮助，没有人会设计CPU。使用SW可以帮助您编写甚至更复杂的SW。

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

MDSD当然也有一些缺点：
d)如果您有一个模型，则希望每一行代码都来自该模型。而且可能很难将外部库包含到项目中。因此，要么您忍受这样一个事实，即您的系统基于外部组件，要么重新发明轮子以将其纳入模型。

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

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

我看过一些看起来很像域驱动设计的东西，称为MDA，如果您是说我全力以赴:-)

嗡嗡声。

我所相信的OTOH是在运行时进行建模。无需生成代码，而是在运行时使模型保持活动状态，并使您的应用程序成为这些模型的运行时解释器。

我不知道这是否已经为Java完成。对于Smalltalk，请参阅在海边使用的Magritte。

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

当然，代码是" a"模型，但是在DSL中捕获更高级别的模型是表达相同意图的更为简洁的方法。关键是始终从模型生成代码，而不是允许独立修改生成的代码。

有很多可用的工具，并且有很多公开的材料(包括案例研究)可以告诉您，如果您不愿意购买现成的发电机，则如何构建自己的发电机。可以说，这比使用通用编程语言给您更多的控制权。

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

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

案例研究变得无聊时，您不需要阅读所有Guttman就能理解，但是介绍很容易阅读。

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

我这样认为：代码就是模型。这样，您的模型和代码将始终保持最新：-)

由于模型视图映射由生成的代码处理，并且功能挂钩作为事件响应程序提供，因此MDA通常很难在服务器端层内部集成业务规则。

我仍然没有看到MDA工具像Forté(或UDS，现在已经消失)+ Express一样强大。我认为具有Forté功能以及更好的模式以实现独立服务层(如ActiveRecord或EntityTransactionManager模式)的MDA对于任何平台而言都是杀手级应用。

针对三层MDA方法的实际应用存在的问题是，这些方法很难设置和适应特定需求。只需考虑ABAP和SAP汇率