答案 0 :(得分：3)
天儿真好，
我发现我倾向于使用完整UML标准的子集。
类图：，用于说明如何构建类的组件以及它们包含的成员和函数。特别有用的是显示“isa”和“有一个”关系，甚至聚合与组合的“有”关系反映了组件的生命周期。
序列图：显示类如何相互交互，并在消息使用顺序中显示类之间的消息流。
偶尔：
活动图：显示并行处理。
如果您想使用UML，那么我不能高度推荐Martin Fowler的书“UML Distilled”（sanitised Amazon link）。说真的，忘记所有其他UML书！恕我直言自然
HTH
欢呼声，
答案 1 :(得分：2)
如果您在正确的背景下使用它，我认为它非常有用 在大型项目中，构建一个关于系统外观的整体计划是一个非常好的主意。
所有这些都可以帮助您节省时间和金钱。
答案 2 :(得分：2)
UML可能是好的还是坏的......太多的东西都可能是坏的。
UML是一个很好的工具，可以帮助您理解概念以及您工作的域。它可以成为与领域专家和功能专家沟通的非常有用的工具。它还可以帮助您可视化您的解决方案，并大大减少您在构建解决方案时遇到的麻烦。
过多的UML也可能是一件坏事，最好的方法是对解决方案的部分进行建模，这些部分很难掌握或有些复杂。对一般解决方案进行建模将有助于提供鸟瞰图并更好地理解整个解决方案。然后创建需要更深入理解的区域模型。 小项目并不一定需要建模。另一方面，较大的项目可能需要建模，以便能够将正确的信息传达给其他人。
非常完整的模型通常被认为是坏的，因为它们在很短的时间内有效。对于有价值的模型，他们需要与代码保持同步。在许多情况下，这成为一项没有人希望实现的额外任务。解决此问题的一个好方法是使用将模型与代码同步的工具。
从最小的年龄开始，我们非常善于通过绘制它们来描述事物。我们中的许多人在学习阅读和写作时都失去了这种能力，但在内心深处，我们往往非常直观。事实是，当我们说当我们遇到困难时，找到解决方案的最佳方法是暂时不管它，或者将问题与其他人讨论。向某人解释它的简单事实通常会给你答案，因为要解释你需要理解它的东西。一旦理解了某些东西并且你已经掌握了细微之处，解决方案就显得简单了。通过帮助您理清想法和概念，可以使用建模来实现相同的结果。一旦它在纸上，它就会变得更加简单。
纸，白板和餐巾通常是你最好的朋友！它们将帮助您记住并深入了解您的想法和概念。
答案 3 :(得分：0)
让我详细说明一下。 UML应该将设计思想传达给项目中的其他人。我们在重大的开发工作中认真使用它。事实证明，唯一一个能够理解图表和笔记的人就是创造它们的人。我发现良好的屏幕模型和模式描述在沟通设计意图方面比UML建模做得好得多。
答案 4 :(得分：0)
我个人认为UML只应该在从代码生成的情况下使用，以使程序员能够获得实际系统的概述。在编码之前使用它总是一个错误，因为那时代码不是系统的优先级。