问我们什么时候使用UML，什么时候不使用？

EN

UML首先是一种交流工具，它帮助你与团队中的其他人(或三个月后的你自己)交流想法，因此，应该根据它表达你脑海中的任何东西的难易程度来进行评估。

由于与语言无关，UML不能用来表达预期的、惯用的方式来使用给定的API或模块，但这是设计的重要部分:忽略它通常会导致代码准确地建模底层问题，但需要数十行样板代码进行交互。

此外，UML不能很容易地捕获算法所依赖的数据结构的一些特定属性。例如，与相应的UML类图相比，红黑树更容易由带有“这是一棵红黑树”或“这不是一棵红黑树”描述的小树状草图来表示。

最后，语言可能具有根本没有在UML中优雅地表示的特性-例如，Objective Caml模块函数器，或者任何具有它们的语言中的闭包。

UML是独立于语言的，因此您可以对任何支持对象和类的语言进行建模。例如，用汇编语言编写的应用程序很难建模，因为这种语言不对对象进行操作。

不要死守UML标准符号。UML是为您创建的，而不是为遵循UML参考指南而创建的。它的目的是帮助你展示你的系统概念，所以如果你(和你的团队)接受不同的符号也没问题。

另一件事是，并不是每个创建的应用程序(即使是大型应用程序)都需要UML。所以许多开源项目都没有它，因为对于一个庞大的社区正在开发的软件来说，维护实际的UML图是不可能的。

从敏捷的角度来看，您不应该创建大量的UML文档，因为它很快就会成为负担，而不是帮助。明智地使用它，最好是在黑板上，只为了向你的团队展示你的意思。你的目标是创建应用程序，所以不要把时间浪费在同步图表和不断变化的代码上。

UML/OMT和其他建模语言被设计用来帮助你做两件事--在你实现之前对你的设计进行建模，第二，与其他开发人员交流你的设计。首先，您确实可以使用任何您喜欢的符号，但是UML为您提供了一个几乎被大多数开发人员普遍理解的标准。和代码一样-糟糕的，不必要的复杂代码需要大量的注释，结构糟糕的设计的UML图看起来很糟糕，暴露了丑陋。

尽管如此，一些人说，尽可能多地坚持标准，甚至是小细节。例如，静态类图中指定不正确的基数可能看起来不是什么大问题，但这是一个大问题，因为如果你在代码中犯了这样的错误，它就不会工作。UML图通常是出于错误的原因在事后创建的-例如，为了给你的经理留下深刻的印象。在这种情况下，这通常是一个无用的练习。

我经常使用UML。我不使用任何UML编辑工具。在项目开始时，在创建任何新代码之前，我会拿出一张用于工程图纸的大纸，并开始添加类或模块，从中心开始添加数据结构。将整个图表保持在相同的细节级别是很重要的。我用铅笔和橡皮擦来画整个图。尽可能避免自己建模的编码设计--将其委托给其他开发人员，并在必要时交换角色。如果实现者因为设计难以理解或难以实现而表现出误解和抵制-这是一个好兆头，你必须改变你的设计-但首先在纸上做所有的改变，与团队中的其他开发人员交谈，并询问他们为了实现该代码他们将进行哪些改变。用序列图补充静态图--最好的做法是每张纸保持一个交互序列。添加数据流图，状态转换图等。这种纸笔方法有一些奇怪的效果，对你的设计产生了非常积极的影响。我认为这是因为它倾向于提出所有不完美的地方，并将它们置于清晰的视野中。在某些情况下，您必须重新绘制中心图，因此将其稳定的部分复制到UML编辑工具中是一个好主意，这样就可以打印它们，而不是手动重新绘制它们。把那张纸放在你的“作战室”的中心，你会注意到，如果他们想要添加或更改某些东西，每个人都会来到那张桌子前-就这样，你开始真正使用UML并从中受益。