【发布时间】：2010-06-03 12:45:19
【问题描述】：
UML 为我们提供了许多不同类型的图表。但在许多情况下，真正需要的只是其中的一小部分，您如何看待最有用的 UML 图，即使对于非常小的项目也是如此？
【问题讨论】：
【发布时间】：2010-06-03 12:45:19
【问题描述】：
嗯，这真的取决于项目。我认为只创建任何 UML 图而不评估它是否真的有用是错误的。
但是有一些明显的情况是有用的：
如果您的项目在 OO 结构方面非常大，那么创建类图通常很有用。这样你就可以处理抽象，直到需要深入细节。
如果您的项目主要由 UI 驱动，那么创建用例图作为定义需求的一种方式会非常有用。如果您可以让您的客户接受这种方法，这将特别有用。
如果看起来您的系统将在对象之间进行许多交互，那么创建序列图对于理解交互很有用。此外，我认为序列图对开发人员来说是最直观的，因为我注意到许多开发人员本能地在简单的 powerpoint\visio 图中绘制这样的交互 - 即使他们不熟悉 UML。
如果您的系统将使用许多技术并需要大量硬件，那么部署图显然很有用。
我认为关键是只有在软件变得复杂到我们需要抽象思考的程度时才使用 UML - UML 有助于可视化和记录这些抽象。
【讨论】：
-
同意，我要补充一点，任何流程都必须适应项目。在开发过程中没有万能的解决方案
无论我们谈论的是大项目还是小项目，我都不认为 UML 图是项目文档的重要组成部分。
优秀的 cmets 比复杂的图表提供更多的价值。
我个人的印象是 UML 是学术界的玩具。这是我唯一听到和看到人们使用 UML、SOA 等的地方。
在我的工作实践中，我几乎没有见过 UML。好吧，也许有一次在我的学期项目和我目前的工作中，我们在内部 FTP 服务器的某个地方有几个 8 年前的（并且只是相同的已弃用）图表。
【讨论】：
-
+1 声明它们不是必需的，但我不同意 cmets - 具有描述性、可读代码的良好结构比 cmets 有用得多。另外，我认为说 UML 是学术界的玩具有点过分——他们肯定过于相信 UML 代码生成可以拯救我们所有人——但 UML 仍然有实际用途——视情况而定。
-
@David Relihan：我并不是说 UML 完全没用。我只是觉得它有点被高估了。使用 UML 不会自动产生高质量的软件。如果它适合您的需要，只需将其用作一种文档形式。
通常正式的 UML 对于小型项目来说太多了。只需坚持基本的类图和简单的用例图即可。
小型项目（根据我的经验）更容易发生变化，因此您的图表经常会过时。与重做所有花哨的 UML 内容相比，您更有可能使不太正式的图表保持最新。
【讨论】：
UML 已死，没有人使用它。
唯一使用 UML 的人是顾问类型，他们撰写文章并试图正式、花哨且缺乏实质内容。
如果 UML 如此出色，为什么我找不到 Google 在 googlecode 上发布的任何项目？
Ruby 或 Python 或 DOT NET 或 Java 的 UML 在哪里？
【讨论】：
-
这不是有点极端吗？ UML 是一个与其他任何工具一样的工具。我同意过去非常重视它，但它肯定仍然有用。
-
你说UML已经死了，那么当我们要设计一个大项目时，你推荐使用什么？
-
我认为 MS 和 Sun 在内部使用 UML 或至少可比较的图表。 Ruby 和 Python 是社区项目（公平），它们不像商业软件那样计划，而是不断发展。开源经常会遇到高复杂度项目的问题，这些问题会变成一大堆泥巴（这并不意味着项目很糟糕，只是他们应该计划更多）。另外：尝试区分真正使用的内容和允许看到的内容。也许谷歌使用图表但不发布它们？
-
许多 OSS 项目的设计也比使用 UML 的架构师创建的项目要精彩得多。
-
如果 MS 或 Sun 真的认为 UML 很有价值，为什么不将其与其他文档一起发布。 Java 有 javadoc，但从未尝试发布随附的 UML 图，让我们假装它不凌乱。
UML 已经死了，因为使用了开源的垃圾工具！许多公司使用免费工具，只创建一些图表，根本没有培训，然后他们说这没有用。 这是非专业的，并且非常有限地使用 UML 对项目来说是一场真正的灾难！
【讨论】：
-
有趣的是，UML 背后的公司为什么不能使用 RUP/UML 来设计和构建高质量的产品。人们会认为他们的工具将是对他们的过程的验证......也许是......也许这就是工具很糟糕的原因，因为 UML 很糟糕。