model-driven-development - 您如何看待模型驱动的软件开发？

Question

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

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

score 8 · Accepted Answer

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

我已经看到一些看起来很像域驱动设计的东西被称为 MDA，如果你的意思是我完全赞成 :-)

score 8 · Accepted Answer

我在 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) 建模工具可能会遇到使用版本控制工具的问题。源代码通常比模型图更容易合并。这迫使团队从复制-编辑-合并转向锁定-编辑-合并工作流程。

score 2 · Accepted Answer

嗡嗡声。

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

我不知道这是否已为 Java 完成。对于 Smalltalk，请参见Seaside 中使用的Magritte 。

score 1 · Accepted Answer

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

score 1 · Accepted Answer

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

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

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

score 0 · Accepted Answer

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

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

score 0 · Accepted Answer

仅举两本书，我发现上面提到的 MDA 对理解 MDA 很有帮助，这是一个广泛的主题。

由于案例研究变得乏味，您无需阅读所有 Guttman 的文章即可获得想法，但介绍读起来很愉快。

score -1 · Accepted Answer

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

我仍然没有看到像 Forté（或 UDS，现已死）+ Express 那样强大的 MDA 工具。我想具有 Forté 功能的 MDA 加上更好的模式来实现独立的服务层（如 ActiveRecord 或 EntityTransactionManager 模式）将成为任何平台的杀手级应用程序。

针对三层 MDA 方法的实际应用问题在于，这些方法非常难以设置和适应特定要求。想想 ABAP 和 SAP 费率

8 回答 8