大话UML
作者：
张传波
软件知识原创基地 首席专家
UML的信任危机
有一次我在做这个课程培训时，有位同学跟我说，他曾经听过不少UML培训，以为UML培训就是这个样子，没想到我的课程让他大开眼界，重新认识了UML！他对课程的赞美让我非常高兴，但目前业内UML面临着比较普遍的信任危机，批评UML、认为UML用处不大的文章随处可见，这让我十分担忧。
我读书时从来没有听说过UML这回事，仅是在工作后才开始学习。很多书籍将UML讲得过于复杂、过于理论化，其实完全没有必要，学以致用才是学习的最终目的。在实际工作中我不断地体会UML的魅力，逐步形成了自己的一套理解，我在大量的项目中使用UML了，并且将我的经验传授给同事。UML在很多公司没有能用好，在业内有严重的信任危机，我觉得是以下的原因导致的：
原因一：合适的UML学习资料不多。
市面上的资料、书籍主要是两类，一类是国外骨灰级高手写的，一类是国内的UML理论家写的。
国外高手的书籍，很多写得过于高深抽象，又加上翻译后影响了原意，这些书籍一般都难以让我们理解。
国内理论家写的书籍，内容确实很丰富，部分书让人读了还会觉得很兴奋，问题是没有能处于“学以致用”的目标来编写，我甚至怀疑有些作者基本上没有实际在项目中使用UML的经验。
UML大师 Martin Fowler 编著的《UML Distilled》（中文译名：UML精炼），我觉得是难得的一本UML好书，推荐大家阅读。
原因二：有实战经验的UML讲师太少。
不少UML讲师是来自某某大学、学院或者是研究所的，很少见到来自企业的。如果不能处于实战的角度讲授UML，UML的威力就会大打折扣，这样的培训训练出来的学生，实战水平不会得到很大提升。
原因三：对学习UML普遍存在严重误解。
我觉得学习UML最难的应该是转变思维习惯、提升思维水平，而不是UML的语法。UML中的每种符号，都有很特定的含义，你需要在实际案例中去体会，而不是只听理论讲解。不要指望学习了UML你就会马上提高了一个档次，如果你的思维方法不得到提升，你只是UML理论家，你可能不学UML会更好，这些UML理论反而会在实际工作中限制你的发挥。
UML知识超级扫盲
UML这三个字母的全称乃Unified Modeling Language，直接翻译就是统一建模语言，简单地说就是一种有特殊用途的语言。你可能会说，语什么言，一堆图形，还说是语言？此言差矣，咱们的文字还不是从图形（象形文字）开始的嘛，语言是包括文字和图形的。其实有很多内容文字是无法表达的，你见过建筑设计图纸吗？里面还不是很多图形，光用文字能表达清楚建筑设计吗？在建筑界，有一套标准来描述设计，同样道理，在软件开发界，我们也需要一套标准来帮助我们做好软件开发的工作。UML就是其中的一种标准，注意这可不是唯一标准，只是UML是大家比较推崇的一种标准而已，说不定以后有一个更好的标准可能会取代她呢！UML并不是官方的标准，也没有法律规定你在软件开发中一定要用UML，不能用其它的，我们的目标就是善用包括UML在内的各种标准，来提高我们软件开发的水平。
UML由1.0版发展到1.1、1.2、...，到现在的2.0、2.x，本论坛将会以2.0版本为基础开展讨论。网络上、书籍、还有各种UML工具软件，各自基于的UML版本可能会不一样，大家在学习过程中可能会有一些困惑，不过没关系，本课程在某些关键地方会描述1.x与2.0的差异的。
UML有很多种图，大体可以分为两类：
1.结构型的图(Structure Diagram)
类图(Class Diagram)
对象图(Object Diagram)
组件图(Component Diagram)
部署图(Deployment Diagram)
包图(Package Diagram)
2.行为型的图(Behavior Diagram)
活动图(Activity Diagram)
用例图(Use Case Diagram)
状态机图(State Machine Diagram)
序列图(Sequence Diagram)
协作图(Communication Diagram)
时序图(Timing Diagram)
注：UML图的中文名字，因为翻译的原因可能会有所不一样，大家要留意看英文名字噢！
在我们软件设计时，我们需要考虑需要那些类、哪些组件、系统最后怎样部署等，这些内容可以看成是“静态”的，我们可以利用UML的结构型的图来设计。
同时，我们也需要考虑软件如何和用户交互，类、组件、模块之间如何联系等“动态”内容，我们可以利用行为型的图来设计。
当然所谓“静态”和“动态”不是绝对的，对UML还不是很熟悉的朋友，先大致这样了解便可。
下面谈谈一些UML的常见认识误区：
1)UML只适合用来做软件设计？
UML可以用来做软件设计，这是大家的普遍认识，实际上不仅如此，UML还可以用来做需求开发（或者叫需求分析）。不仅是用例图可以用来描述需求，类图、活动图、序列图、状态机图等都可以用来深入发掘和整理需求。
2)UML的语法很多很繁杂？
UML的全部语法确实很多很繁杂，但实际上经常用到的内容不多，也很容易记忆。
3)掌握了UML语法，就是OO高手了？
要成为OO高手哪有这么容易啊！OO理论家就很多，真正实战高手其实没几个。我未懂UML之前，还自认为自己OO水平还不错，学习UML后发现自己是如何之渺小。通过实际工作不断地应用UML，不断地思考总结，才能不断地提高自己的OO水平。
如果不懂UML，有可能是OO高手吗？我一直也有思考这个问题，我觉得不懂UML的不太可能是OO高手，因为确实只有用好UML（特别是类图）才能真正体会到什么是OO！
4)光用UML就足够了吗？
UML可以表达软件设计的所有情况吗？用了UML就不需要用文字来表达设计吗？
非也非也！UML在表达界面设计、用户体验设计、数据库设计等方面，能力还是很弱的，不要只用UML，应该善用一切可以利用的东西，包括文字。
UML的秘密
很多资料将UML说得太复杂了，事实上我们需要经常用到的部分并不复杂。很多资料会将大家误导到不常用的那部分，浪费大家宝贵时间，我们应该集中火力去学好那常用部分。
学UML之难，不在于学习语法，关键是要改变思维习惯。UML是一种新的工具，但同时也是代表了一种新的先进的思考方法，如果不能掌握这样的方法，只能学到了UML的形，而没有掌握其神髓。要真正能用好UML，你需要：
1.头脑要清晰（如果你精神不好，就先休息一下，养足精神再来。）
2.抽象能力要强（这句话说得太好了，但太抽象了，呵呵！没关系，后面课程会有很多例子让你体会什么是抽象能力。）
3.归纳总结能力要强（下面马上就有一个挑战你的归纳总结能力的测试。）
4.需要有“面向对象”的思维习惯（类图将特别强调这点，后面课程你将体会到什么是“面向对象”。）
如果你的思维习惯没有被“革新”，那么学习UML是失败的，能力切实的提高往往不只是你学到了哪些知识，而是你的思考方式的提升，这才是真正的质的改变！
对于UML学习，你必须先端正一些认识：
1.UML只是一种武器，能不能用好UML不是看武器本身，而是看用的人的功力！
2.不用UML也能写好需求和设计的人，如果掌握了UML，他写出来的文档质量将更高！
3.用UML写不出好文档的人，就算不用UML也很难写出好文档！
---全文完---
