我目前面临的情况是，我作为测试驱动开发的倡导者必须与模型驱动软件开发（MDSD）/模型驱动架构（MDA）的倡导者竞争。
在我看来，代码生成是我工具箱中的一个有价值的工具，我需要时大量使用模板和自动化。当我认为这有助于理解内部工作或讨论白板上的架构时，我还用UML创建图表。但是，我强烈怀疑通过UML创建软件（创建状态图和序列图以创建工作代码而不仅仅是代码的骨架）对于多层应用程序（数据库层，业务/域层和Gui，甚至可能是分布式的）更有效。在我看来，当谈到MDSD时，CASE工具突然不再仅仅是一个工具了，但它是满足的东西：正如我所看到的，一方面，MDSDevelopers从更高的抽象UML中获益，但是在同时他们正在努力修改代码生成器/模板/引擎以满足他们的需求，如果使用工具箱中的其他工具（VisualStudio，Eclipse，...），可能很容易实现（和测试）。
这一切让我想知道是否有一个成功的故事（产品是在时间上推出的，并且只有很少的错误和软件的一部分在以后被重复使用）是真实的世界应用程序完全填充此creteria并使用严格的模型驱动方法开发：
答案 0 :(得分：3)
模型驱动软件网络上发布了一个关于MDSD使用的微小但有用的见证：
http://www.modeldrivensoftware.net/profiles/blogs/viva-mdd-follow-up-building-a?xg_source=activity
这是一个相对较小的应用程序正在开发中，但仍然是运行中的MDSD的一个很好的例子。
Metacase网站（http://www.metacase.com/cases/index.html）列出了更多成功案例。 Metacase销售MetaEdit +，它实现了DSM（特定领域建模）。 DSM只是MDSD的一种形式。
我也在开发另一种形式的MDSD ABSE（基于Atom的软件工程），非常接近DSM。 ABSE概述于http://www.abse.info。
答案 1 :(得分：3)
我使用通过CAN连接的4个处理器在嵌入式系统项目中使用MDA和代码生成。我们有超过20个运动轴和许多传感器。随着机械部件的评估和修改，该系统具有高度的可靠性和可维护性。
我们在模型中工作并生成代码，因此模型始终是最新的。我们进行了仔细的域分析以实现主题隔离。电机控制需要非常高的性能，因此未进行建模或生成。我们的网络驱动程序也是手工编写的，我们编写了允许桥接服务根据需要将事件发送到系统中任何位置的任何服务的接口（尽管这是严格控制的，以便最大限度地减少处理器间依赖性）。
使用该方法需要一些纪律，但拥有工作模型非常好，因为它们可以通过非软件类型进行审核。
模型的版本控制和差异是一个挑战，但我们有一个小型的本地化团队，因此我们能够避免合并问题。
Pathfinder Solutions（我们的工具供应商）的优秀人才可以帮助指导您完成整个项目。
答案 2 :(得分：2)
您还可以查看以前代码生成会议的幻灯片。其中一些谈话来自成功的案例研究，例如： http://www.codegeneration.net/cg2009/slides.php
答案 3 :(得分：1)
我正在开发遗留现代化项目之一，并使用名为Bluage的MDA工具。它是一个大型医疗保健组织及其生产所以我可以说它的成功。在遗留现代化的情况下，MDA更好，因为它可以从像pacbase这样的某些技术中产生KDM模型，这些技术将会失去支持。
答案 4 :(得分：1)
我参与了一个在Google Closure中生成管理式网络应用的MDSD系统。我相信你的问题很有说服力。太复杂，你的MDSD系统太难用了。太简单了，你不会生成在现实世界中有用的应用程序。 MDSD真正发挥作用的是节省开发人员时间，输入大量的管道样式代码，但MDSD如何在多个版本中保持有效？要求可以在很多方面进行。这是真正的挑战。我最近在该项目上发表了关于MDSD lessons learned的博文。