我不知道'；我不喜欢MDD，但喜欢UML——如果我认为MDD是无用的，为什么要使用它呢？

我是一名java软件开发人员/架构师，喜欢UML

说我也讨厌java生成的代码

我没有看到任何值试图生成我的应用程序的框架：

• 创建空类非常容易，我不需要工具来实现这一点
• 此外，我不能重用生成的代码，因为生成代码的方式使其无法重用

我面临的困境是，我的需求变化如此之快，以至于我需要能够将新需求立即实现到现有代码中

我的问题是，如果我从模型生成代码，然后在生成的代码库中手动开发，我就无法使用模型再次生成代码，因为我的修改将被删除

除非我来回复制/粘贴更改。这是一个巨大的努力，结果太少。因此，我不使用MDD，但仍然使用大量UML

在没有MDD代码生成的项目中，UML能成功吗？ 我问这个问题是因为我有一个新老板，他想在IBMRSA中引入完整的MDD过程，而今天我更喜欢实时代码和模型同步，或者与Omondo合并

• 为什么要改变一个运行良好且行之有效的系统
• 为什么系统地从模型生成代码，而我可以直接在代码中生成代码，然后将其与模型合并
• 为什么要生成甚至不能部署的垃圾数据库代码，而我可以添加原型以获得java注释并将其与hibernate一起使用来生成我的数据库

boss变更的原因之一是为了获得更好的HTML格式的项目文档。我对此表示高度怀疑，认为他正在寻求更多的交付控制，不知道还能发明什么

其他论证理由：

• 使用大型稳定公司的产品
• 有一个完整的模型，可以在任何其他语言部署
  （这就是为什么MDD对我来说是愚蠢的，因为它不可能仅仅从一个模型部署到任何平台、任何服务器、任何数据库。那么为什么要浪费我的时间呢？）

---

请给我一些论点，以便在下次会议上回来，让这个愚蠢的新MDD粉丝崩溃，他想重新组织我们今天的工作方式

使用MDD，对设计进行更改有望变得更便宜：如果需求发生变化，在您的方法中，您必须更新基于UML的文档和代码。现在，如果代码可以自动生成，那么对代码的更改应该自动跟随对模型的更改，并且您不必手动执行（至少在不添加新内容或不需要更改业务逻辑的地方）

假设MDD可以工作（是的，对；），您能证明维护模型（文档和设计）和代码的双重成本是合理的吗

---

对你有利的一个论点可能是，如果项目不是太大（不管这意味着什么），那么不值得承担所有的开销。

我认为你的帖子中有答案

MDD遇到了两个基本问题：

一种表达能力不足的输入（建模语言），无法捕获整个问题。结果：您需要使用另一种语言（代码）完成规范

生成器（即将模型转换为代码的规则）通常不完整和/或不开放供开发团队修改和/或生成低质量代码

把这两件事放在一起，你就会得到你提到的可怕的混乱。结果：试图将手写代码与生成的低质量代码拼接在一起。结果：不漂亮

不过。请不要从上面推测我是反MDD的。我不是，事实恰恰相反。但是：工具和过程需要解决上述两个基本问题

我遇到过/很少有/很少有这样的人。几年前我使用过RSA，但它肯定不是其中之一。（然而，它已经有了改善的时间，所以它现在可能在那里）

一个简单的“温度检查”问题是询问该工具是否提供完整的动作语言。否则，它将与问题（1）相冲突。如果失败了，你很可能会痛苦

如果您的老板真正想要的只是好的HTML文档，那么只需将其集成到您的构建中即可

因此，要回答您的具体问题：

没有MDD，UML能成功使用吗？对通常有两种方式：

作为白板草图的非正式或半正式符号，同时找出问题和/或解决方案（Martin Fowler称之为）

作为构建过程的一部分，从代码中自动生成文档

您最终将消耗非生产性时间的地方是创建与代码没有直接链接的正式UML图（通常使用昂贵的工具）

---

hth.

如果无法控制生成，则可能使用了错误的工具

生成的内容（骨架或特定于框架的代码）也取决于工具。使用允许您创建自己的模板的工具

认为往返工程将永远起作用是错误的。您不能将不太详细的模型转换为更详细的代码，然后再转换回来而不丢失信息。解决这一问题的一种方法是在模型中使用与代码中相同级别的细节，这不是一件好事

更好的方法是从模型中使用单向生成，并结合一些良好的实践来组合生成的代码和手动编写的代码

您可以对手动编写的代码使用保护区域：

• 您可以在模板中指定位置，例如方法体，在重新生成时不应覆盖这些位置

或者代沟模式：

• 您可以使用具体类的骨架生成抽象类和代码，这些都是由您自己完成的