在我之前的产品经历里，经常会遇到一个场景，在我拆解（或调研）某个业务系统时，无法梳理出一个系统层面清晰的脉络，思考出整个业务和系统架构的融合方式，即使后期我梳理清楚了，也是一个“大力出奇迹”的方式，一步一步硬推出来的。
在工作中，我们接触新领域/产品的时候，都会“开头难”，这个难在于没有在这个新领域下有历史经验，以致于用最笨的方法去调研，验证，学习，然后积累出一点点优势，慢慢滚雪球，形成加速。但如果又换一个新领域，我们很大概率还依赖这种行为方式，这就会造成认知的低效率。
“领域知识”是一个元概念，有时候和用户/客户交流，你会被带入到全新的领域（不理解领域的话，可类比行业去理解，实际不太一样）中，和领域内的专家与客户交谈，他们的独有的业务经验，对你来讲，就是一个“领域知识”，这种场景在B端业务中会更为常见。
如果我们无法定义一件事，就无法注意到它。
好了，
我现在把定义引入进来了，大家可尝试在工作或生活中注意到它：
在与客户交谈时，
注意客户描述业务实体的名词术语，这些名词术语会被当成「类」，还要注意听到的动词，这些动词可能会构成「类」中的「操作」，然后还有其他名词可能变为「类」中的「属性」。
当梳理出来之后，
再去询问客户每个「类」的作用，客户会告诉你「类」的职责
，这样就能快速了解该领域的基础逻辑。
就是我开篇提到的痛点，在学习了UML之后，对“领域知识”有了新的认知，有信心在进入陌生领域时系统的建立起认知
引了这么多，直接看UML有啥东西吧！
主要可分为如下图两大类：
1、
结构元素
，图例左半部分，自上而下为类图，接口，用例图，关系，分组，注释
2、
行为元素
，图例右半部分，自上而下为状态图，时序图，协作图，活动图
可以理解为这就是咱们现实世界的粗暴分解，结构和过程组成了世界上的一切，形成了时空
再奉上一张网上超级经典的图，UML拆解的样例，这里基本用上了UML中高频使用的图例类型，请保存好，后面会持续用到
那么，产品同学要掌握的图有哪些？
类，是一类或者一组具有类似属性和共同行为的事物
，映射到现实中，可参考我上面的那个黄颜色的图
类图（Class Diagram）是面向对象系统建模中最常用和最重要的图，是定义其它图的基础，主要是用来显示系统中的类、接口以及它们之间的静态结构和关系的一种静态模型
类图描述一个类的
属性和操作
，以及对系统的约束。它们是唯一的，可以直接映射到面向对象的语言的 UML图。请看详解
「类」的实例，叫做「对象」
类和类之间，也会存在相互关系，这个关系也有专门的标识方式
，这里要先引入“面向对象”的一些相关概念了，如下图
面向对象的思考方式，是以开发出能够反映出现实世界某个特定片段为目标的，或者叫建模。
对象是类的实例，比如你和我都是“人”这个「类」的实例，对象具有自身的结构，属性和操作。
比如
抽象，是过滤掉对象的一部分属性，保留解决问题所够用的属性和操作
，因为现实生活中，解决问题不一定需要全部的信息
再就是
继承，我们的电冰箱，电烤箱可以看成单独的「类」，都是电器这个「类」下的子类，继承了电器的“开”与“关”，但冰箱有冷冻功能，烤箱有加热功能。对应的，电器这个「类」也是电冰箱电烤箱的「超类」
其他的可以看图，要解释下本图不是UML全部的内容，但足够本文章讲和使用了
好了，终于可以讲正题了！
「类」之间存在的关系，有如图几种，我们详细用图片展示
接触过数据库的同学对这个定义比较熟悉，基本等同于ER的思考逻辑
使用直线表示
就像「类」和「对象」的层级关系，「类」和「类」之间的“关联”关系，也是一个「类」，且这个「关联类」对应的「对象」叫做「链」。
听起来有点套娃，但这个就是核心的思考方式了，可以向上抽象思考，也可以向下实例思考
关联讲完了，咱们来讲
抽象，继承，泛化
这三个放到一块讲，是他们的联系可放到一块去思考，在设计游戏时，「计时器类」是从「投球计时类」和「游戏计时类」抽象出来的，对应的子类用
空心实线箭头指向被继承的类，这个箭头就是泛化关系
，代表“is a kind of……”
好好琢磨下哈，然后咱们继续介绍下
接口和实现
接口跟封装可以一起介绍，可以理解为你在使用冰箱的时候，不需要知道冰箱怎么制冷的。只需要插电和开关冰箱门就好了。冰箱把制冷的细节都封装在了里面，给你留下了开关和插电的接口
冰箱这个「类」对应的他的开关接口，这之间的关系就是实现，
使用空心虚线箭头标识
用虚线单箭头表示，一个类使用了另一个类，比如在设计报表类系统时，会存在类似的关系。“展示报表”的功能，使用了“报表”这个类，有一个前置的逻辑，形成了依赖关系
最后就是类图里的最后一块
聚集和组成
这其中
有点形似与混合物 与 化合物的区别。
聚集，用空心菱形剪头，从部分指向整体，一种混合物的关系
组成，用实心菱形剪头，代表强聚集关系，类似化合物的关系，桌子由桌面和桌腿组成。
当然这只是为了没接触的同学好理解，如果有ETC精请克制自己不要自动抬杠……
篇幅最长的类图介绍完了，接下来介绍一个也很常用的用例图，相对简单很多，跟画画一样，一个小人儿和一大堆气泡发生了连线的关系
用例图可以在设计系统或者需求的时候，理清楚实际的场景，排坑。比如设计某功能时，总会有一些操作场景被遗漏，导致进入测试阶段中了，才发现有问题，要修补。使用用例图，能很大程度上在设计阶段避免这种情况。
小人儿就是
参与者
气泡就是
用例
二者之间使用依赖线连接，
上面可以标记<< include>> 或 << extend>>，<< include>>可理解为用例间包含的关系，一个用例包含了下一层级的用例。<< extend>>可以理解为此用例还有其他场景可以使用，扩展出了一个入口
用例图只用来标识参与者和用例的关系，并不代表先后顺序
用例图在交付时通常给客户和开发组参考，每个用例图的场景描述至少占一页文档，包含：
·发起用例的参与者
·用例的假设条件
·用例的前置条件
·场景中的步骤
·场景完成后的后置条件
·从用例中获益的参与者
终于大半篇幅讲完了结构元素，本节开始讲行为元素了，如果小伙伴们看麻了，可以收藏或者转发给自己的小号，后面继续看~
行为元素对于产品同学来讲，基本是不陌生的，如果经常绘制业务流程图的话，会发现有很多一致的地方，很正常，都是团队的沟通工具嘛
这种图在制作大型业务系统的时候，肯定会用到，比如我在设计CRM系统的时候，里面的商机就会有多种状态流转，就用到了这个图。
给研发兄弟看，也会沟通的很顺畅，因为研发在实际工作中会频繁用到这里，他们基于这些状态去设计代码层面的调用逻辑。便于他们设计的时候提前规划，提高研发的效率。研发最怕的，是做一半了中途改了基础底层状态的设计，分分钟掀桌子
状态图的定义，可以说是对象改变了自己的状态，以响应事件和时间的流逝，比如灯的开与关。
状态图和类图的差别，是状态图针对的是单个对象来建模，类图可以针对一组类来建模
绘制方法，圆角矩形代表一个状态，状态间带箭头的实现代表状态的迁移，箭头指向目标状态。实心圆点代表状态转移的起点，牛眼圆圈代表重点
记不住那么多没关系，有专门的工具，跟visio一样，直接找来拖就行了，文章末尾会介绍绘制工具
下图是基于工单类的审批流程绘制的状态图
时序图，也叫顺序图，强调了时间维度，时序图的关键思想是强调了对象之间的交互按照特定时间发生，这些特定时间的交互序列，从开始到结束需要一定的时间。
时序图通常用对象标识，从每个对象下方延展出一条生命线，一个时序图可以用单个或者多个如下单元组成
每个线程对象之间可以用消息通信，有两类
一类消息叫调用，这是一个来自消息发送者对象的请求，它被传递给消息的接收对象，请求接收者对象执行某种操作。通常，需要发送者等待接收者执行，等待反馈，这种消息又叫做同步消息。
如下图，带有实心箭头的实线表示发送的消息，带有线状箭头的虚线表示返回消息
另一类消息叫做异步消息，这种机制下发送者把控制权交给了接收者，并不等待操作完成，这种消息用带有线状箭头的实线表示
时序图跟跨职能流程图有些许相似，不过时序图可以更清晰的展示每个线程的动作顺序，以及线程之间的通信关系，如果是用跨职能流程图的方式来绘制，就不便于展示每个线程之间的多条通信了
依然拿请假的流程举例，如图。
时序图还有帧化的概念，不过对于非研发工作来讲，没必要学习，基本用不到。不再赘述
终于到了最后的类型了！活动图，用圆角矩形表示，与状态图不同的是，活动图的图例更接近椭圆。一个活动的处理一旦完成，就自动引起下一个活动发生。
状态图侧重于描述对象的状态变化，活动图侧重于描述活动，与业务单线流程图大多数逻辑类似，不过区别是活动图更适合展示判断过程，和并发路径。如果用基础的单线流程图标识，会不太直观
比如判断是类似的表示方法
并行路径的表示方法
如果日常工作中使用流程图较多，也不必非要用这个，UML本质目的是快速沟通，能沟通清楚就行
下面讲下我平时是怎么应用的，有两类案例，一类是研究一个系统，多数的时候是凭借兴趣研究的，感觉很有意思。另一个是工作里实际使用时展示的
在调研UML是否值得学习的时候，我也会经常看到这样那样的问题，比如
1、我看完了，真的有必要学吗？研发不看怎么办？
我的个人建议是，如果自身喜欢这方面的思考，可以凭兴趣去学；
如果是B端从业且想继续发展的业务产品，建议去学，学了以后会有如虎添翼的功效，不过学习需要时间，建议收藏，或者转发给小号后续常看，我平时看到东西也这么干哈哈，最好能买书学，更系统
UML本质还是沟通工具，可以跟研发去协商，看团队更倾向用什么方式沟通，UML只是一种，如果有别的更合适的表示方法，能把逻辑梳理清楚，歧义消除干净，最好不过了。
2、UML和数据建模是否有关系？
跟研发同事交流过，他们说UML其实就跟JAVA编程过程中的思考很接近，不断抽象和建模，平时也会用到。
数据库建模与UML有一定的联系，数据库建模的过程是逻辑层到物理层的逐层过程，都是构造模型，但侧重点不一样，数据库建模侧重数据层面逻辑效率，模型可用性等等。
3、UML之后如何使用？
除了上面的那些基本功能点以外，使用UML的本质目的就是为了多方理解，尽管UML有一些法则，也不要被禁锢，
能达到沟通顺畅无歧义的目的，就足够了
4、画图使用什么工具呢？
·starUML。win/mac平台都有，win的平台有个版本很复古，但是功能很完善。mac有starUML4.0的版本，颜值很高，但是感觉画起来没win的好用。大家可以百度搜下。
·Visio。可以画的图很多，包含了UML的基础图例，不过看个人习惯，我Visio和starUML都用，Visio常用来画流程
·其他有用的也可以推荐下，工具嘛，趁手就行
5、有哪些书籍推荐？
·UML基础、案例与应用（入门）
·大象UML（进阶）
·大话设计模式（感兴趣可以看）
·系统架构（值得反复长期啃，我确实还没看完，太大了，不过是本神书）
另外其他的书，可以白嫖微信读书无限卡，香滴很！
6、PPT请关注公众号回复
UML
进行获取
未来，我会出一些关于业务系统的相关文章，尽量大白话，可能有些大佬看着文字会评价我的思考肤浅，但能有人听懂和交流，才是我的初衷。
我期望我的些许产出，可以让新手产品同学们不再像我当年那样随机漫步，能快速度过无人带领自己摸索的成长期，我愿意做一块铺路石~
追更的同学可以点个关注和置顶，防止迷路
肝了这么久，不知道你们学废了没有，如果有收获，还请关注下我的公众号：罗文正雄
如有问题，可加私人微信teshutieqiu1600进行交流
