3

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

4

7 回答 7

4

我倾向于对这个主题有点愤世嫉俗......并回答永远不应该使用UML图。

当您必须与不真正了解编程的人交流时，往往会使用 UML 图。漂亮的图形绘图使他们更加轻松舒适，但通常像以前一样毫无头绪。

根据我的经验，UML 会浪费大量时间，并且往往会取代其他更简单、更高效的工具。伪代码就像类图一样容易阅读（对我来说更容易）并且更容易输入；用例的效率不如 scrum 或 XP 中的优秀用户故事；等等。所有图表与代码库和文档一起维护都很麻烦。并且您可以很容易地在绘制它们时犯设计错误（并且当以 UML 形式出现时，设计错误将变得更加难以检测和克服，同意您在考虑绘图时可能会避免最明显的错误）。

我相信我浪费了很多时间来绘制 UML 图，但我仍在寻找一个案例，他们给了我任何好处。

于 2010-03-18T22:18:28.837 回答
4

我会采取一些不同的立场。

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

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

于 2010-03-18T18:52:25.273 回答
2

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

于 2010-03-18T18:50:49.770 回答
2

之前，期间和之后。

您使用它们来描述需求、预期架构、软件设计、实施和部署。

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

于 2010-03-18T18:35:50.313 回答
1

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

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

于 2010-03-18T20:53:46.533 回答
0

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

于 2010-03-18T18:51:44.603 回答
0

根据我使用 DSDM 方法驱动手机应用程序开发的经验，我在功能原型设计阶段（开发开始之前）使用了 UML 图。

我发现他们让我更清楚地了解了应用程序的外观，它如何与人和其他系统交互，并开始向我展示代码的结构。

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

于 2010-03-18T18:43:45.960 回答