您应该在实现之前还是之后创建类图？

如果您在获得以下优势之前创建一个，我的看法：

• 提前计划
• 项目概况

但你输了：

• 时间（做工作时，您可能会在编写代码时最终重复出现）

另一方面，我可以在编写代码后就全部创建它们，以供将来开发人员参考。

哪一个服务于类图的目的，哪个更有利？

如果您之前创建过它们，它们将成为设计阶段的一部分。

如果您在之后创建它们，则可以仅将它们用作文档。但是，如果在设计和编码过程中进行记录，则记录会更好，更快。

顺便说一句，您不会浪费时间进行设计！编码部分将更快。而且更好。

毕竟，您认为设计摩天大楼或桥梁是浪费时间，而不仅仅是开始建造？

一种折衷方案是在设计阶段开始创建一些伪代码（只是类/函数的原型），并使用此代码框架来构建类图。

当我在编码之前创建它们时，我们将它们视为“临时”文档。就是说，我们创建了图表并把想法写到了纸上。我们从这些类图开始编码。然后我们将它们丢弃。一旦编码开始，花时间去维护它们是不值得的。而且，如果您需要最新的类模型，请使用工具从代码中创建它们。

无论哪种情况，它们都将作为文档的一部分保留下来。更改实现后，没有人会更新它们。图表上没有日期，因此您甚至都不知道它们所引用的代码的版本。当一个新人被添加到项目中时，您将给他或她一个图表，说：“这是在设计或实现过程中的某个时刻创建的一些图表。我们不知道它们是最新的。”

这是设计的一部分，因此应在实施之前创建。这并不是说无法在实施期间/之后对其进行完善以反映当前实施状态。

在实施后提供设计就是我所说的“牛仔编码”，并确保您可以在狂野的西部繁荣发展，但请记住，牛仔通常会在某个时候死掉。

这取决于设计的深度。有些人甚至坚持为最琐碎的类编写类图，因为“这是一种很好的做法”。我认为当您已经确切地知道如何实现时，画一些东西是浪费时间。在创建新设计时，有些陌生的事情，首先绘制一些图表绝对有用。

不过，我从未使用过UML工具，因为设计通常会在实现过程中发生很大变化，以至于我不得不重绘该图。我想一个好的双向工具可以处理这些更改，但是我从未使用过一个好的工具（不过，我只使用了免费的工具）。相反，我在纸上或白板上绘画以帮助我对设计进行排序。在实现它并合理确定它的声音之后，我将做一个更正式的图表。

另外，我们不要忘记其他类型的图。我一直发现序列图是最有用的，并且在组件之间进行大量通信时，我经常使用它们。

实施之前。正如我的一位前同事曾经说过的：“我喜欢在开始编码之前尽可能多地进行编程”，我认为这是一种很好的方法。

我发现绘制图表的行为通常会提醒我缺少信息。如果我只是在代码编辑器中输入但未绘制图表，也会发生这种情况，但是实例之间的距离会更远（因为我将花时间编写算法，计算和测试等），因此我可能会花更多时间在获得我丢失的信息之前先经过。

另外，如果您隐约发现的设计真是令人讨厌，那么如果您先进行图解设计，就会更快地注意到这一点。因此，我至少要快速而非正式地画些东西。它是否变成其他人可以参考的电子图，将取决于项目。

类模型的创建应该在模型创建期间，之后进行，因为模型应该与代码交互并修改需求。首先，您需要创建一个类图来启动您的项目。这将有助于在更高级别的对象上可视化对象。您将能够创建稳定且智能的软件体系结构。然后，您需要编写代码，有时您会注意到，在代码中实际上不可能实现在UML中看起来不错的体系结构。然后，您更改代码和体系结构。最后，通过代码修改来更新模型并生成文档。

在我的上一个项目中，决策者在去年对我的要求进行了50多次更改。这真的很痛苦，UML帮助我保持更改的可追溯性以及原因。UML应该允许模型和代码在任何时候以迭代的方式合并（例如，从代码到模型，从模型到代码，从两者，从重构后的代码等等）。我为Helios使用了Omondo EclipseUML，我真的很满意这个工具。我最喜欢的功能是模型合并，它使我可以随时更新模型而不会丢失模型信息。我也喜欢直接在类图中建模的实体，并使用构造型和休眠方式创建数据库。从对象到数据库，真正强大而完整！

之前：它将帮助您整理思想并传达您的意图。不要在这里详细介绍。

之后：很明显，它是在构建过程中从代码自动生成的（希望您不太喜欢uml）

两者都很有用，但是之前的东西一旦实现就可以扔掉……无论如何现在它已经过时了。

使用Topcased，我在设计阶段创建了类图。然后，我单击“生成代码”按钮以生成我的实现的画布。然后，用代码填充占位符。

我要投票给答案（C）不要打扰。

它们在很大程度上是不必要的。就我个人而言，提供它们时，我从不费心去看它们。

在开发之前就不需要它们了，因为设计还是会改变的。而且，如果您不认为班级的设计会发生变化，那么您就已经束手无策了，并阻止了将来的自己正确解决问题。如果您认为必须遵守一些先前存在的类图，那么您要么在NASA工作，要么就自己开枪。

之后，它们就是不必要的文档。如果仅通过一点代码检查就无法弄清这些类在做什么，或者它们之间是如何关联的，那么您在软件开发人员方面的技能就有空子。

当然，这个答案听起来确实很自大和固执。那好吧。

使用Eiffel和相关工具，这只是观点不同，它们都指向相同的基础文件。