十八年开发经验分享（08）开始学习UML时需要知道的几点建议

这次谈谈UML的学习体会。经常在论坛或者群里看到很多人提出各类问题。群其中相当一部分是属于初学者的常见问题，这里将这些还记得住的问题小结归类，一并做个说明。当然这是我的个人看法，不作为标准答案。 

1.UML不是必须的

这个意思是说不要把UML看的太过重要，或者更恰当的说法是在很多场合中UML不是很重要。初学者的一个毛病就在于有点崇拜UML，甚至把UML神化了。应该说适当尊重UML是可以的，太过看重就没必要了。开发最终需要关心的还是自己的软件是否能更好的顺利完成。 

上世纪六，七十年代出现了软件危机，从而促成了软件工程的诞生，然后这个方向的内容和技术不断的发展和完善，最终在设计方法上出现了UML。从历史上来看，对于开发软件来说UML确实不是必须的。所以在学习UML是必须明确一个目标，学习UML是为了开发软件而不是为了UML去学习UML。 

2.需要学习UML么？

一般有这样的问题的人基本上是不需要学习UML的。理由很简单，一样你不知道要不要的东西那一定是你离开它也无大碍的东西。学习UML的理由来自实际的工作需要，开发的软件足够复杂的是否，是否需要更好的设计等等，这些就是很好的理由。当然有些人是为了增加知识，为今后发展做准备的，那学一下也当然可以，但是需要注重实践。一般来说如果实际工作中用不到的话一般就不建议学习了。一个折中的做法是，虽然工作中用不上，但是可以拿工作中的实际项目来练手，自己可以尝试用UML来设计一下。这是非常好的实践。 

3.如何学习

第一个当然是看书。中文版的书籍好的确实不多。大量的书籍是为了解释UML本身缩写，就算一些结合例子的也和实际开发相差的比较远。那么什么内容比较好呢？如果英文可以的话，我推荐IBM的网站上的材料。可以在页面中输入想查找的关键字，然后就可从结果中选择比较吻合的内容。有些链接会导向IBM的知识库，其中会有很多UML相关的内容。是非常不错的选择。 

另一个可以参考的是UML设计工具自带的帮助文档。当然目前绝大部分都是英文的。另外由于不同开发厂商对UML的理解上会有一定的“个性化”差异，所以相关的内容会有一定的不同。其三是WideUnion也会不定期的发布相关的内容。这些与UML建模的相关内容是和Entity Model Studio产品高度结合的，所以实用性很强，针对性也很强。可以经常去www.WideUnio.com看一下。 

第二是参加培训。这个就不好说，这个取决于培训机构的好坏。 

第三就是用自己工作中的实际项目练手，一边学习一边实践。 

第四个是上网找资料。可以看别人的学习笔记，博客等等。这个不是系统学习的方法，但是针对某个具体问题而言，这个方法是很有效的。当然资料可以多看一些，这个样有个比较。 

4.不必太关心对错

这是一个非常常见也是非常突出的问题。在实际工作中很难找到一个所谓正确的做法。在实际的工程问题中，只有所谓合适的做法，或者实际最优的做法，而不会有一个正确的做法。所以在学习UML的过程中，对于自己的设计或者疑问要有一个完整的认识态度。那会是如果有更好的做法我就选择，同时也要敢于坚持自己的方案。 

经常看到一些初学者为了一些非常小的细节花费了大量的时间去讨论和琢磨。这种追求正确结果的态度当然值得肯定，但是是否值得花费这么多的时间是值得考虑的。对于不同的设计，不要关心对错，而是要关心差异，以及为什么会有这些差异。不同的方法不是有错又对，而是适合使用的具体场合不同，和设计目的不同。绝对的错或者对是很难在实际项目中遇到的。 

5.什么时候学习UML

当开始学习UML时，实际上已经是在接触软件设计层面的内容了。而初学者往往忽略了这个问题，往往只是为了多一点知识开始学习UML，并没有意识到自己还没有足够的能力进行软件设计或者软件建模。所以我不推荐这个做法，在这个案例中笨鸟先飞的道理是不适用的。一个更有效率的做法是先打好基础然后再去学习UML。这个所谓的基础就是软件开发能力，说的再直白一点就是编码能力，问问自己一个人能独立开发好多大的软件或者代码。 

当独立开发的软件越来越大时，与软件设计相关的问题会随着具体的细节非常自然的产生。开发者可以在解决这些细节中潜移默化的增加自己的设计能力。长期的坚持就会让自己可以进行有效的设计思考，从而为软件设计打下坚实的基础。当软件大到一定程度时，对一个设计的需求就自然产生了，这个时候学习UML就水到渠成了。 

6.不求甚解，循序渐进

完整版的UML是内容很多，我们很难学完，同时有些概念也很少用，也晦涩难懂。所以要坚持不求甚解，循序渐进的策略。一时无法理解的可以暂且放一边，看其它的。逐步学习在工作中可以使用的内容，而不要按部就班的学习整个UML。关于这个话题，我会写后续的文章，结合Entity Model Studio对UML常用的内容梳理一次。