uml|产品经理的思考利器——UML（7000字长文）( 五 ) 数据库|CRM|产品经理

如下图，带有实心箭头的实线表示发送的消息，带有线状箭头的虚线表示返回消息
另一类消息叫做异步消息，这种机制下发送者把控制权交给了接收者，并不等待操作完成，这种消息用带有线状箭头的实线表示时序图跟跨职能流程图有些许相似，不过时序图可以更清晰的展示每个线程的动作顺序，以及线程之间的通信关系，如果是用跨职能流程图的方式来绘制，就不便于展示每个线程之间的多条通信了
依然拿请假的流程举例，如图。

时序图还有帧化的概念，不过对于非研发工作来讲，没必要学习，基本用不到。不再赘述
行为元素-活动图终于到了最后的类型了！活动图，用圆角矩形表示，与状态图不同的是，活动图的图例更接近椭圆。一个活动的处理一旦完成，就自动引起下一个活动发生。
状态图侧重于描述对象的状态变化，活动图侧重于描述活动，与业务单线流程图大多数逻辑类似，不过区别是活动图更适合展示判断过程，和并发路径。如果用基础的单线流程图标识，会不太直观

比如判断是类似的表示方法
并行路径的表示方法如果日常工作中使用流程图较多，也不必非要用这个， UML本质目的是快速沟通，能沟通清楚就行
实战应用下面讲下我平时是怎么应用的，有两类案例，一类是研究一个系统，多数的时候是凭借兴趣研究的，感觉很有意思。另一个是工作里实际使用时展示的
拆解与理解saleforce
saleforce是CRM业界非常知名的一个产品，因为这个系统太过于庞大， UML的类图是快速理解的一个利器。此时应用UML不是还原到如何实现，而是为了理解它是怎么设计的。通过demo很难有机会能接触到更深层的实现细节应用到工作
在设计内部BI系统时，用到了类图，和用例图。
在设计CRM系统时，商机（例子）状态的流转图。 CRM的设计，我会单起一系列文章讲除了这些还有很多应用，不过都差不多，应该可以给大家足够的帮助了。关于UML的介绍内容，就到此结束，下面我做下对应的答疑
高频的疑问解答在调研UML是否值得学习的时候，我也会经常看到这样那样的问题，比如
1、我看完了，真的有必要学吗？研发不看怎么办？
我的个人建议是，如果自身喜欢这方面的思考，可以凭兴趣去学；
如果是B端从业且想继续发展的业务产品，建议去学，学了以后会有如虎添翼的功效，不过学习需要时间，建议收藏，或者转发给小号后续常看，我平时看到东西也这么干哈哈，最好能买书学，更系统
UML本质还是沟通工具，可以跟研发去协商，看团队更倾向用什么方式沟通， UML只是一种，如果有别的更合适的表示方法，能把逻辑梳理清楚，歧义消除干净，最好不过了。
2、UML和数据建模是否有关系？
跟研发同事交流过，他们说UML其实就跟JAVA编程过程中的思考很接近，不断抽象和建模，平时也会用到。
数据库建模与UML有一定的联系，数据库建模的过程是逻辑层到物理层的逐层过程，都是构造模型，但侧重点不一样，数据库建模侧重数据层面逻辑效率，模型可用性等等。
3、UML之后如何使用？
除了上面的那些基本功能点以外，使用UML的本质目的就是为了多方理解，尽管UML有一些法则，也不要被禁锢，能达到沟通顺畅无歧义的目的，就足够了
4、画图使用什么工具呢？
·starUML 。 win/mac平台都有， win的平台有个版本很复古，但是功能很完善。 mac有starUML4.0的版本，颜值很高，但是感觉画起来没win的好用。大家可以百度搜下。