再谈UML，我不建议产品经理特意去学这玩意……
前言
在去年的某段时间，我非常有激情的学了一段时间的UML，然后写了一篇文章叫作《我的踩坑实践：一文并学不会UML……》
然后到前段时间为止，那些琐碎的语法和规范我基本忘光了，我甚至怀疑我去年是不是没学过这个东西，不然怎么会没啥印象呢？
于是，我趁着五一假期，又把之前的收集的资料拿出来看了一遍，主要是三本书和三个视频。
三本书分别是：
《火球：UML大战需求分析》 《大象：Thinking in UML》 《“图解”产品：产品经理业务设计与UML建模》
三个视频分别是：
这次重点看的是《火球：UML大战需求分析》和《“图解”产品：产品经理业务设计与UML建模》，没有看《大象：Thinking in UML》是因为它枯燥了，啃不太动……因为我的目的就是花20%左右的时间和精力去获取80%左右的知识量，啃太专业的书籍回报率比较低……
结合实际学习的过程和网上找的一些资料，我斗胆提出了一个自己过激的观点：
不建议产品经理特意去学UML，尤其是啃一本又一本的专业书。在这么焦虑的时代，别太容易被他人裹挟，也包括我的观点……
这个观点仅代表我个人，也是我反反复复学了这么多次，用了这么多次UML之后的感触。如果你有不同意见，请不用和我对杠，我默认你的观点都是对的……
如果你想知道我为啥会有这样的感触，请看下文！
学习UML的新感悟
这次再啃UML，我不是像之前一样，走马观花般看完就算了，而是实打实的一个一个图对着画，然后还找了一些案例进行补充，以加深自己的印象和认知。
随着我越学越多，越看越多，我逐渐发现了我为啥学不好这个东西，也知道为什么我总是用不上这个东西了。
感悟1：UML规范太复杂
过了很久之后，再使用UML画图的时候，总是会忘记一些规范，例如是实线还是虚线，是实心还是空心，是A指向B，还是B指向A……
我记得刚开始看《火球：UML大战需求分析》的时候，一直在纠结聚合和组合有什么区别，继承和泛化有什么区别，什么时候用包含，什么时候用继承，什么时候用关联……
这些规范让我这个强迫症患者很痛苦，导致我时不时还要打开指导书找找”语法规范“，然后画一个图的时间成本嗖嗖嗖地就上去了。
最后发现，好像这个图我用自己的语言，用其他的工具也能展示，甚至还能展示得更好……
感悟2：画图工具不好用
这一点和UML规范也有关系，如果为了强行达到它的规范，画一个图的时间远超过调整样式、间距的时间。
例如大家可以去看看一些成熟系统的顺序图（Sequence Diagram），以微信支付的API文档中的时序图为例。哪怕大家看的时候感觉还挺简单，但是实际用一些UML的工具去画一个这样的图，如果要达到美观，整齐的效果，起码20分钟以上，如果不是软件的熟手，估计要更久……
实际在画类似的图的时候，要考虑激活框的高度，角色（系统）生命线的间距，Message的实线和虚线等……
这些规范，如果不多画几张图，很难快速上手记忆，只能对着参考资料一点点打磨。
感悟3：使用的场景很少
产品工作当中能使用到的UML图一般就是：用例图，类图，状态机图，活动图这四类。
状态机和活动图比较简单一些，可以统称为流程图，在日常工作中经常有用到，所以使用场景还算多一些。
类图我一般用于梳理一些业务对象的关联关系，例如订单和包裹，包裹和跟踪号的关联关系。用的场景也不算多，复杂场景下用这个简图表示的比较有效，简单场景下，直接文字描述就好了。
用例图实在是用得很少，因为我一直觉得没啥用处，或者说用例图来表示用例的关系，太繁琐了，也不高效，大多数时候我都是用XMind来做用例分析。
感悟4：身边用UML的人很少
当一个工具只有少数人使用的时候，少数人就变得很尴尬了。画的太复杂，别人看不懂；画的太简单，这好像也不是UML……
所以我昨天晚上在梳理一个业务的时候，得出了一个新的感悟：
UML现在就是有点变成了少数人的狂欢，很多大佬们写文章、写书或多或少都会提到，建议大家去看，去学习UML，但是实际周边的朋友会用这个的还是很少，这就是最尴尬的境地。
大家都不会用，也不会给到自己正反馈，也不知道自己理解对不对，做得好不好，那这件事注定就是孤独的……
今年我比较推荐感兴趣的朋友去看看《“图解”产品：产品经理业务设计与UML建模》这本书，尤其是此书的最后两章。
因为他揭示了我之前学UML，学一次忘一次的真相，也阐述了为什么业内有很多人推崇UML，觉得必须要学；也有很多人反对，觉得会UML也没啥用。
我个人看完了之后的观点是，可以学，但是没太大必要。
很多复杂的理论，高大上的概念，本质上都是为了解决某些问题，而解决问题的途径永远不会只有一个，大多数好用的或者被论证推广的，往往已经被大多数人掌握了，只不过应用起来的时候需要灵活裁剪、调整而已。
一些摘抄的笔记
下面是一些我自己摘录的一些笔记和做的练习，感兴趣的朋友可以看看，算是一波回顾复习，不感兴趣的朋友可以跳过了，因为看了也会忘记。
1. 类图
先识别什么是类，类包含了：
类名 属性 方法
在实际的业务建模过程中，可以忽略方法，多考虑类名和属性方面的挖掘即可。
怎么样的可以定义为类，这个类有哪些属性比较关键，和其他类之间的关系是什么？
类除了自身之外，还会与其他类有关系，这些关系很重要，是帮助梳理 多业务主体（类）之间关系的重要方式，也就是怎么确定并画出关系，主要的关系有：
关联（Association) 聚合（Aggregation），也称为“弱包含” 组合（Composition），也称为“强包含” 泛化（Generalization），也称为“继承” 依赖（Dependency）
维他感悟：
画类图的时候可以使用最简单版的画法，不用纠结箭头是实虚线，有一些特殊关系存在时，使用文字注释的方式来解决就好了，不要按部就班地遵循UML的规范，不然反受其害……
2.顺序图
顺序图，一般产品工作中画的比较少，我个人也建议没什么特殊的情况不用画这个图。如果一定要画，也可以使用一些精简的语法规范，提升效率，避免陷入各种UI细节中，得不偿失。
维他感悟：
有一些UML画图工具不是很好对齐各种元素的，例如尤其是激活框的高度一改就会影响Message的对齐方式，所以建议画图的时候丢弃激活框，直接在生命线上画，加上一些备注说明即可。
3.用例图
至今为止我也没有找到一个过往的工作案例可以证明类图有不可代替的地方，所以我很少画类图，一般能用XMind解决就绝不用其他工具。
维他感悟：
用例之间包含和拓展关系，不用强行去记忆箭头顺序，都用一个方向的箭头，然后加上备注文字就好了；同理，继承关系也可以用这种方式。用Excel来做用例表，是一个不错的方式，比直接画图可能要好一些。
总结
这篇文章有明显的个人倾向，建议初中级的产品朋友理性看待。
知识肯定是有用，但是盲目地学习，囫囵吞枣般的接收肯定没啥效果。
如果你觉得UML真切的帮助到了你，你是投赞同票的那位，也欢迎后台跟我交流交流；如果你还是在门外看热闹的，跃跃欲试但又诚惶诚恐，我也建议你试着学一下，翻车了也就当涨知识了。
溜了，溜了，不能再多说了，拜了个拜！
