如果有不了解UML的，请先看一下IBM developerworks这篇讲解UML的简短但是高质量的文章
http://www.ibm.com/developerworks/cn/rational/r-uml/
在之前的工作中，我了解UML，会简单使用UML，但是有一种观点，UML只是一个建模方法，目的主要是为了向人们阐述清楚工程的设计目的，工程的基本流程......，应用的场合也只在面向对象的程序设计。个人感觉用不用都可以，因为其他的方法比如书面的解释，简单的图形讲解......也能完成使用UML同样的功能。
但是在慢慢地实践和与人的交流中我才感受到了UML思想的强大，（要感谢Chuanyi Zheng让我真正了解UML）。
UML系统开发中的三个主要模型：
功能模型：从用户的角度展示系统的功能，包括用例图。
对象模型：采用对象，属性，操作，关联等概念展示系统的结构和基础，包括类图。
动态模型：展现系统的内部行为。包括序列图，活动图，状态图。
我先抛开对象模型不谈，因为他仿佛只适用于面向对象的设计。
先看看功能模型中的用例图。用例图主要目的是帮助开发团队以一种可视化的方式理解系统的功能需求。有很多方式可以让团队理解系统的功能需求，文档解释，ppt， office visio图形。但是对于团队来说，不同的人有不同的喜好，肯定有某些人不爱读通篇的文字（比如我），ppt的绘制关系图效果太差，visio太麻烦。但是我觉得UML的用例图不但方便绘制，在功能关系体现上更加直观，简单。而且通常能得到大家一致的认可。
对于动态模型，我觉得更有必要去了解使用它，记得我在之前《怎样写好一个方法》这篇文章中对自己写好一个方法进行了经验总结，首先在这个方法内把这个方法要处理的流程写下来，比如1.做容错（校验参数有效性），2.如有需要申请资源......5.释放资源，然后再去实现代码编写。也许会有人认为这是多此一举，但是往往我们在工作中却容易把某些流程忽略掉导致低质量的程序实现甚至错误的逻辑。在进行一个业务或者程序设计时如果我们以序列图或者状态图的方式把我们的设计逻辑和程序调用逻辑”跃然纸上“，等梳理好这些逻辑后再去做代码实现我敢说一定会降低很多逻辑或者流程方面的错误发生率，而且有利于团队的交流，你想想看，你是愿意看密密麻麻的代码来分析对方的逻辑还是更愿意看清晰的时序图或者状态图？对于TCP协议的理解，一个状态图一定胜于千言万语......
其实UML还有很多可以用到实际工作中的功能，总之多学多使用一定是多多益善的，对于这些规范化的模型你当然可以不使用或者用其他的方式取代，但是我想规范化，专业化能更好的提高自己的工作效率和提高团队的协作能力。
本文转自永远的朋友博客51CTO博客，原文链接http://blog.51cto.com/yaocoder/828298如需转载请自行联系原作者
yaocoder
