UML图。什么时候使用？

好吧，我知道UML图有助于程序的构建，但是什么时候使用它们呢？在开始编码之前需要它们吗？你需要它们吗？这样你就知道你需要编码什么了？还是在编码程序后使用它们？

之前、期间和之后

您可以使用它们来描述需求、预期的体系结构、软件设计、实现和部署

---

甚至使用软件的操作过程也可以用UML图的形式来描述。

根据我使用DSDM方法来驱动移动电话应用程序开发的经验，我在功能原型阶段（开发开始之前）使用了UML图

我发现他们让我更清楚地理解了应用程序应该是什么样子，它是如何与人和其他系统交互的，并开始向我展示代码应该是如何构造的

---

例如，类图将在您开始开发应用程序之前创建，因为它允许您考虑您可能需要哪些类和属性。

UML图只是一个符号，所以真正的问题是您应该在何时使用建模。有许多不同的方法，有不同的方法和态度。统一过程就是其中之一，它是免费的，并且极大地利用了UML，从中您可以了解如何使用UML图以及它们如何有用。但是，您必须决定哪些做法对您有利。我个人认为UML和建模是一种主要用于代码生成的工具，因此这些模型实际上是声明性程序。但是，它们也可以用作文档。另一方面，如果它们是用于需求和动态行为描述的最佳工具，则可能存在疑问。我希望能给你一些线索。

根据我的经验，它们通常在实现之前用于传达组件将如何构建。它们为人们提供了一种以标准格式审查潜在设计的方法（desgin review）。它们还可以向对系统感兴趣的非开发人员提供系统的高级视图（功能审查）。我还看到它们在实现后被用作需要了解系统如何工作的新开发人员的参考。

我将采取一些不同的观点

除了通常处于体系结构/设计阶段的序列图之外，我们不使用严格意义上的UML。我想说，在学术界，当你描述一些精确和理论的东西时，它是最有用的

---

在每天的工作中，一张纸上的任何盒子和箭头都将到期。实际上，一个很好的使用规则是，如果你不能在一张纸上用手画出你的设计，那就太复杂了

我在不同的项目中以几种不同的方式使用了它们。我已经看到类和序列图被用作设计时工件，成为设计文档的一部分，我认为它们在当时非常有用。它们可以帮助沟通类之间的关系以及它们将如何交互。我发现看一眼，知道哪些接口和类是什么，哪些接口和类是相互扩展/实现的很有帮助，特别是当我参加其他人的设计评审时。不过，我发现，如果开发人员不努力使他们的设计文档保持最新，那么这些UML图很快就会过时

---

不过，我们在我当前的项目中大量使用UML，因为我们使用的是一个名为AndroMDA的UML代码生成工具。它肯定有起有落，但我们使用它来生成一些后端类、接口、存根impl、hibernate配置文件和spring配置文件。hibernate和spring配置文件是可能的，因为您向UML添加了额外的注释。无论如何，因为我们正在使用这个工具，每当我们对后端代码进行更改时，我们必须首先更新我们的UML。因此，它确保了我们的UML始终代表我们代码中真正发生的事情。

我倾向于对这个主题有些愤世嫉俗。。。并回答说，永远不要使用UML图

当您必须与不真正理解编程的人交流时，通常会使用UML图。漂亮的图形让他们更加轻松舒适，但通常还是像以前一样不知所措

根据我的经验，UML是一个巨大的时间损失，并且倾向于取代其他更简单、更高效的工具。伪代码和类图一样容易阅读（对我来说更容易），而且更容易键入；用例的效率不如scrum或XP中的好用户故事；所有的图表都需要与代码库和文档一起维护。而且你可以很容易地在绘图时产生设计错误（当以UML的形式出现时，设计错误将变得更难检测和克服，同意你在考虑绘图时可能会避免最明显的错误）

我相信我在绘制UML图上浪费了很多时间，但我仍然在寻找一个案例，在这个案例中，UML图给了我任何好处