我不喜欢 MDD 但喜欢 UML - 如果我认为 MDD 没用，我为什么要使用它？ [关闭]

Question

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

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

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

• 创建空类真的很容易，我不需要工具来做到这一点
• 我也无法重用生成的代码，因为它的生成方式无法重用

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

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

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

UML 能否在没有 MDD 代码生成的项目中取得成功？

我问这个问题是因为我有一个新老板想用 IBM RSA 引入完整的 MDD 流程，而今天我更喜欢实时代码和模型同步或与 Omondo 合并。

• 为什么要更改一个正在运行且经过验证的系统？
• 为什么要系统地从模型生成代码，而我可以直接在代码中生成代码，然后再将其与模型合并？
• 为什么要生成甚至无法部署的垃圾数据库代码，而我可以添加构造型以获取 java 注释并将它们与 hibernate 一起使用来生成我的数据库？

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

其他争论的原因：

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

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

Answer 1

我认为你的帖子里有答案。

MDD 一直困扰着两个基本问题：

1. 输入（建模语言）表达能力不足，无法捕捉整个问题。结果：您需要使用另一种语言（代码）来完成规范。
2. 生成器（即将模型转换为代码的规则）通常不完整和/或不开放供开发团队修改和/或生成质量较差的代码。

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

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

我遇到过/非常/很少这样做的。几年前我使用过 RSA，它绝对不是其中之一。 （但是它有时间进行改进，所以它现在可能就在那里）。

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

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

所以回答你的具体问题：

UML 可以在没有 MDD 的情况下成功使用吗？是的。一般有两种方式：

1. 作为一种非正式或半正式的符号，用于白板草图，同时找出问题和/或解决方案（Martin Fowler 称之为 UML as Sketch）
2. 作为构建过程的一部分从代码自动生成的文档。

最终会浪费时间的是创建与代码没有直接链接的正式 UML 图（通常使用昂贵的工具）。

第一次。

Answer 2

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

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

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

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

您可以将受保护区域用于手动编写的代码：

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

或者代沟模式：

• 您使用具体类的骨架生成抽象类和代码，这些是您手动完成的）。

还有另一种方法可以解决这个问题 - 完整的代码生成。

这可能看起来类似于使用模型进行编码的不良做法，但重点是专门用于生成特定类型的应用程序 - Web 应用程序、嵌入式应用程序。然后，您生成的基本上是特定于框架的代码，通常可以使用模型来表达和维护。

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

对于您的问题 - UML 最初并不是针对 MDD 的（许多 MDD 实践者根本不使用 UML...），因此您可以随意将其用于 OO 分析和设计。

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

正如另一个答案中提到的，有很多文档工具。

Answer 3

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

假设 MDD 有效（是的，对；），您能否证明维护模型（用于文档和设计）和代码的双重成本是合理的？

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