? ?UML是一个工具集，涵盖了从用户需求，系统分析，系统设计，部署的方方面面；一个人的项目可以使用UML，几百人的项目也可以用。多么神奇的UML，能包容万象，其实包容万象的不是UML，而是它后面的哲学思想和方法论。
??????? 1，认识事物应该由表及里：
??????? 针对这一条我们经常犯的错误是思维跳跃，过早陷入对实现和细节的思考。
????????和客户谈及需求的时候，总是忍不住就谈到了专业知识，这其实是一种思维的跳跃。由于你是IT技术的专家，会不自觉的将客户的需求和最后的实现技术映射起来。记住，这时你要做的仅仅是全方位了解客户的需求，而不是如何实现。
??????? 在做系统分析时，过早地考虑用什么类来实现，用什么技术。过早地陷入细节之中，不可自拔，甚至感觉没有了方向。如果，你在这个阶段的文字中提到“数据表”，“类”，就说明这必定不是一个好的系统分析。
???????? UML对于用户需求，系统分析和设计提供了相对应的图形，比方实现类图只会出现在设计阶段，不会出现在用例和系统分析阶段；这是一种强迫你按照认识事物的客观规律来做事，抑制你跳跃思维的冲动。
??????? 并不是不提倡跳跃思维，如果的确有过类似度很高的项目经历那也没有必要从头开始；我个人的感觉是，大多数时候思维跳跃带来的后果是误导了你，过于乐观的估计了开发难度。
??????? 2，事物是联系的：
??????? 除了静态图，还有像时序图，状态迁移图，以及更复杂的泳道图；这些动态图揭示的就是事物之间的联系，A-》B，A和B就是你要设计的类，B要处理来自A的调用或消息，这就是B要实现的方法。这就是面向对象的设计方法，UML就是服务于面向对象的设计。
?
??????? 3，简单而又准确的表达：
??????? 以前我写PPT给老大汇报时，老大总是说，这一段太长，试试用一句话表达出来；那这时折磨人啊，究竟把那些内容精简了呢；慢慢摸到了规律：第一，多用主谓宾格式，谁把什么怎么了。第二，这个ppt写给谁看的，只写他关心的内容。第三，用短句。
?????? 再回来想想，用户需求阶段的用例图不就是这么回事嘛：用户（主），用例 （谓+宾）。
?
?????? 所以我说UML是个工具，是个蕴含方法论和哲学的工具。如果不能认识到这些思想，会导致面对很多UML图不知如何使用，在什么阶段使用；会导致，过早陷入细节，跳出边界，而无所适从。推荐《大象 - UML》这本书，他在教你UML的同时不断在强化上面提到的哲学思想。
??????? 想到之前有位大拿提到，UML是个通用工具，且随着发展包含的内容和图也越来越多，不管怎样它只是个用来表述系统和需求工具，即使是用甲骨文一样也能达到效果。这句话我想当认可，如果你把UML背后的方法论和哲学思想都掌握了，用什么工具都是无所谓。
?????? 在学习UML过程中注意到了潘嘉宇老师的作品 《UML软件方法》。在作品了甚至把实现技术，语言工具比作了卫生间里抽水马桶，这对技术至上的童鞋来说绝对是个打击；其实，老师的意思只是让大家不要把技术当做最重要的最了不起的东西，特别是不要在和用户访谈时，是不是蹦个技术词汇出来，像是在向用户展示你是个专家，素不知，你这时已经违法了上面提到的第一条，过早陷入了细节。
相关文章
