你真的知道UML是做什么用的吗？
优秀的UML有什么特征？
什么时候该用UML？或者说，什么时候不该用UML？
学了一学期的软件工程，自己捣鼓了一个小系统，对UML这个东西有了一点感悟。个人觉得，UML是一个“貌似”能描述系统构架的东东，有很多人热衷于画这个东东，甚至热衷于画异常复杂的UML图，并以此为炫耀的资本。我一度很纳闷，好像画了这个东西，面子上就能过得去，就表示你的这个系统是符合软件工程规范的。真的是这样吗？
区区一个图而已，能成为衡量软件质量的标准吗？
我很怀疑。但在用UML图这件事上，我的经验太少，不知道什么是对，什么不对。
我的感觉是：
1、图是给人看的，图不能太复杂，否则看图还不如看代码。
2、并不是所有的程序都要用UML图表示，或者说并不是所有的程序都适合用UML图来表示的。
在学校的图书馆瞎逛，偶然遇见了《UML FOR JAVA PROGRAMMERS》一书，我惊讶地发现了书中阐述了许多我困惑的问题。书中的许多警句训诫更是让我醍醐灌顶，摘录如下，以之为后事之师：
UML适合做什么？不适合做什么？
1、UML非常方便于软件开发者之间沟通设计思想。UML特别适用于就关键设计思想进行沟通。另一方面，UML不是特别适合交流算法的细节。
2、UML适用于创建大型软件结构的路线图，这种图帮助开发者看清楚类与类之间的关系。
图应该画成什么样？
图尤其适合于他人交流思想，有助于解决设计问题。细节不要多，只要能使你实现目标。
何时绘图？
1、当若干人需要同时进行开发时，这些人都需要理解一个系统的某个部分的设计结构时，应该绘图。当所有的人都达成一致的时候，停止画图。
2、当两个人或更多的人对一个特定的元素如何设计持不同意见，你需要你的团队协商时，应该绘图。将讨论限定在一个范围内，确定决策的方法，比如投票制公正裁决制。时间一到或已得出结论，就停止绘图。然后擦掉图。
3、当你需要探讨一个设计思路时，况且画图能够帮你更好的地思考时，应该绘图。一旦得出结论，结束思考，就停止绘图，然后扔掉这些图。
4、要向别人或者自己解释代码中某些部分的结构时，应该绘图。如果进一步的解释需要借助代码，就停止绘图。
5、项目接近尾声，客户要求将图纳入文档以转交给另一方时，应该绘图。
何时不要绘图？
1、不要因为流程的规定而绘图。
2、不要因为这两个原因——不绘图会让自己内疚，或认为优秀的设计者都绘图——而绘图。优秀的设计者写代码，只是在必要的时候才绘图。
3、在编码前的设计阶段，不要为了创建详尽的文档而绘图。这样的文档几乎一文不值，还浪费了大量的时间。
4、不要为写代码的人绘图。真正的软件架构师应当参与编码，以实现自己的设计。
关于文档
良好的文档是任何一个项目的根本。没有它，团队将在代码的汪洋大海中迷失方向。但另一方面，过多不恰当的文档反而适得其反：因为团队不仅要看所有这些杂乱的、容易误导人的文档，还要面对代码的汪洋大海。
文档是必须写的，但是要谨慎。很多情况下，决定不编写哪些文档与决定编写哪些文档同样重要。
复杂的通信协议需要用文档描述。
复杂的关系模式需要用文档描述。
复杂的可重用框架需要用文档描述。
但是，它们都不需要成百页的UML。软件文档应该言简意赅。软件文档的价值与它的大小成反比。
顺序图的应用场合
1、需要立即向某人描述一组对象之间的协作方式时；
2、想把这种协作关系形象化以便于自己思考时。
顺序图只是偶尔为之以锻炼分析能力的工具，而并不是必不可少的文档。
偶尔在白板上绘制顺序图是很有价值的。在一张小卡片上绘制5、6个顺序图，描述了子系统中最常用的交互场景，这样的纸“价值千金”。相反，一个充斥了上千个顺序图的文档，其价值还不如打印它们所用的纸。
上个世纪90年代，软件开发的最大谬论之一是，开发人员在编写代码之前应该为所有的方法绘制顺序图。事实证明，这极大地浪费了时间。千万不要这样做。
我认为，一切的关键是，画图是为了帮助我们思考、交流和编程，不要为了画图而画图。