我不喜欢MDD，但喜欢UML --如果我认为MDD没用，为什么要使用MDD呢？

Question

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

说我也讨厌java生成的代码。

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

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

对我来说，两难的是，我的需求变化太快了，所以我需要能够立即将新的需求实现到现有的代码中。

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

除非我来回复制/粘贴更改。这是一项巨大的努力，但收效甚微。因此，我不使用MDD，但仍然使用大量的UML。

UML在没有MDD代码生成的项目中能够成功吗？

我之所以问这个问题，是因为我有一个新老板，他希望在IBM中引入完整的MDD流程，而今天我更喜欢使用实时代码和模型同步，或者与Omondo合并。

• 为什么要改变一个运行的、经过验证的系统？
• 为什么要系统地从模型中生成代码，而我可以直接在代码中这样做，然后稍后才与模型合并呢？
• 为什么要获得垃圾数据库代码生成，即使我可以添加构造型来获得java注释并与hibernate一起使用它们来生成我的数据库，也不能部署这些代码呢？

老板更改的原因之一是要获得更好的HTML格式的项目文档。我非常怀疑这一点，并认为他正在寻找更多的控制交付，不知道还能发明什么！

其他辩论理由：

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

请给我一些论据，以便回来，在下次会议，并崩溃了这个愚蠢的新MDD风扇谁想重组我们今天的工作方式！

Answer 1

我想你的帖子里有答案。

MDD一直受到两个基本问题的困扰：

1. 一种不足以表达整个问题的输入(建模语言)。结果:您需要用另一种语言(代码)来完成规范。
2. 生成器--即将模型转换为代码的规则--通常是不完整的，并且/或不开放供开发团队修改和/或生成质量较差的代码。

把这两件事放在一起，你就会得到你提到的可怕的烂摊子。结果:试图将手工编写的代码与劣质生成的代码拼接在一起.结果:不漂亮。

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

我遇到过/很少有这样的情况。几年前我用过RSA，但它肯定不是其中之一。(不过，它还有时间改善，所以现在可能就在那里)。

一个简单的“温度检查”问题是询问该工具是否提供了完整的Action语言。如果它不这样做，它就会与问题相抵触。如果失败了，你很有可能会感到痛苦。

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

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

如果没有MDD，UML能成功地使用吗？是。一般有两种方式：

1. 作为白板草图的非正式或半正式符号，同时解决问题和/或解决方案( Martin称之为UML作为素描)
2. 作为构建过程的一部分从代码中自动生成文档。

最后，您将消耗非生产性的时间，就是创建没有直接链接到代码的正式UML图(通常使用昂贵的工具)。

hth。

Answer 2

如果你不能控制这一代，你可能使用了错误的工具。

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

假定往返工程将永远有效是错误的。您不能将较少详细的模型转换为更详细的代码，然后在不丢失信息的情况下返回。解决这一问题的一种方法是在模型中包含与代码中相同的详细信息，这不是一件了不起的事情。

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

您可以在手动编写代码时使用受保护区域：

• 在模板位置指定-例如，方法体，在重新生成时不应覆盖。

或者代沟模式：

• 使用具体类的框架生成抽象类和代码，这是手动完成的)。

还有一种方法可以实现这一点--完整的代码生成。

它看起来可能类似于使用模型编写代码的糟糕做法，但重点是专门用于生成特定类型的应用程序-- web应用程序、嵌入式应用程序。您生成的基本上是一个特定于框架的代码，这些代码通常可以使用模型来表示和维护。

不要忘记，建模不仅仅是关系图，您也可以使用文本DSL。

对于您的问题- UML最初并不适用于MDD (许多MDD实践者根本不使用UML .)，所以您可以随意使用它来进行OO分析和设计。

当涉及到你的老板和RSA，试着找出你的老板真正需要和想要什么，然后尝试为他提供一些更好的工具或实践。

正如在另一个答案中提到的，有许多用于文档的工具。

Answer 3

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

假设MDD可以工作(是的，对吧;)，您能证明维护模型(文档和设计)和代码的双重成本吗？

对您有利的一个论点可能是，如果项目不是太大(不管这意味着什么)，那么它就不值得拥有所有的开销。