谈谈UML使用

若是有不了解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还有不少能够用到实际工做中的功能，总之多学多使用必定是×××的，对于这些规范化的模型你固然能够不使用或者用其余的方式取代，可是我想规范化，专业化能更好的提升本身的工做效率和提升团队的协做能力。