背景：
初级产品经理在接到需求时，不能够将抽象的概念，用文字表达出来，而是需要用一些计算机的行话（大家都理解的术语或者图表），将抽象的概念，通过图形，图表描述出来。下面，将会讲解产品经理常用的图表类型，以及图表的使用场景。
ER 图
ER（Entity Relationship）图是一种描述实体对象（Entity） 之间关联关系（relationship）的经典图表，由科学家Peter chen 于1976年发明，最早被用于关系型数据库。
ER 图是产品经理在工作中，经常会打交道的一种图表，ER 图的呈现方式有很多种，比较常用的是使用UML 中的类图（class diagram）所规定的符号标记规范来进行描述和呈现。
下面的所有例子，都是通过Process On 这个工具来进行操作的。有兴趣的同学可以用我的链接进行注册，可以免费获取七天会员
ProcessOn助您和好友一起高效办公！https://www.processon.com/i/58247ef9e4b064c051b329fe
一个ER 图中，每一个大方框代表一个对象，方框中的第一行描述的是对象的名称，第二行描述的是对象中的数据字段，大方框和大方框之间的连线，表示实体之间的关系，如果新手产品经理，不了解什么是“关系”，可以看看之前这篇文档http://www.woshipm.com/pmd/5176906.html
多对一关系ER 图示例：
两个ER图使用实线链接，实线标注N ：1，表示着多对1 对关系，即 多个学生对应着一个教室。
如下图所示，则为一对一关系ER图，表示着一个公民，必定对应着一张身份证，一张身份证，也对应着一个公民。
使用场景
我们在产品设计初期，我们就要想好这些实体类型之间的关系，如果你现在做的产品，经常出现逻辑混乱，功能重复的问题，以后分解需求以后，可以先从分析ER 图开始。除此之外，产品经理在输出prd 文档时，如果使用文字，以及图表，不能够很好的体现需求中的实体关系，这时候，我们就可以考虑使用ER 图来进行表示。
通常产品经理，只要掌握一对一关系，一对多关系，多对多关系，那么就可以解决我们在工作中遇到的绝大多数实体问题了。
流程图：
国际标准组织ISO（International Standard Organization）在1970年定义了流程图的基本符号规则，方便不同背景的读者阅读理解，建议尽量采用简单的绘图规则，例如，只使用开始，结束，执行，判断这四种符号来绘制流程图。
1. 流程图的符号要求
流程图看起来很容易画，但是想要画好、画标准一张流程图，还是需要一些练习的，下面这张图介绍了画流程图的一些特定符号，我们一定要记清楚每个符号的含义，在画流程图的时候可不要弄错了。
下面是几个重要且最常用的符号，需要牢记！
2. 流程图的三大结构
流程图由三大结构构成，这三大结构分别为顺序结构、选择结构和循环结构，这三个结构构成了流程执行的全过程。
（1） 顺序结构
在顺序结构中，各个步骤是按先后顺序执行的，这是一种最简单的基本结构。如图，A、B、C是三个连续的步骤，它们是按顺序执行的，即完成上一个框中指定的操作才能再执行下一个动作。
（2） 选择结构
选择结构又称分支结构，选择结构用于判断给定的条件，根据判断的结果判断某些条件，根据判断的结果来控制程序的流程，判断的流程可以有
（3） 循环结构
循环结构又称为重复结构，就是流程在一定的条件下，反复执行某一操作的流程结构。循环结构下又可以分为当型结构（when）和直到型结构（while）。
当型结构：该结构可以理解为，判断所给条件p是否成立，当P成立，则执行A（步骤）；再判断条件p是否成立；当P成立，则又执行A，若此反复，当条件p不成立时，则跳出循环。
直到型结构：先执行流程A，再判断所给条件P是否成立，若p不成立，则再执行A，如此反复，直到P成立，该循环过程结束。
流程图是产品经理必须掌握的一种图表，当产品经理拿到一个涉及跨模块，跨部门，跨角色协作的需求时，使用流程图来描述业务的过程，以及用户的操作过程，比做高保真的原型要简单清晰。如下图所示，就可以很清晰的描述每个角色，在流程中，应该要做什么事。
状态机图（State Machine Diagram）
在面对业务流程时，初级的产品会使用文字去描述状态之间的流转，如我一个订单的开始状态，到订单的确定状态，再到订单的结束状态，这种描述是非常难明白的，我们需要通过状态机图，给你的小伙伴们介绍各种状态。状态机图也叫有限状态机图（Finite State Machine Diagram），是一种描述所有状态以及状态之间流转规则的图形。
源状态 (Source State)：受转换影响的状态;如果对象处于源状态，则当对象接收到转换的触发事件并且满足保护条件（如果有）时，可以触发传出转换。
目标状态 (Target State)：过渡完成后处于活动状态。
在软件设计领域，“状态”在业务系统中，无处不在：订单要有状态，账号要有状态，门店要有状态，可以说任何对象都有状态。状态机要注意以下几点
1. 状态值是有限的集合，状态的所有枚举值，必须涵盖所有实际可能的情况
2. 状态值之间要互斥，不能出现二义性
3.为了更准确的描写状态，状态还能有子状态，如订单的“已取消”，可以对应为的子状态为“客户取消”，“商家取消”，“系统取消”
4. 状态应该是能持续一定时长的，而不是很快就会结束的瞬时态，如订单的状态可以是“待发货”，“待评价”，但不能是“发货中” - 可以是等待xxx 发货，“评价中” -- 可以是等待xxxx 评价。
使用场景：
当产品经理接收到的需求中，一个实例，可以承载多种操作，以及存在多个状态时，那么这个prd 文档，就必须包括状态机图，否则这个prd 文档是很难描述清楚实体之间的状态关系的。
下图的状态机图，则是描述了一个订单的复核，待执行，中间态，以及完结态时的状态流转。使用状态机图比用文字，要简单明了。
用例图
是用户与系统交互的最简单表示形式，展现了用户和与他之间相关的用例之间的关系，通过用例图，人们可以获取系统不同种类的用户和用例，简单说就是某个角色或者用户在不同场景下，可以做什么，实际工作中，我们会用到简单的用例图，复杂的用例图，比较少接触到。
尽管用例本身会涉及大量细节和各种可能性，用例图却能提纲挈领地让人了解系统概况。它为“系统做什么”提供了简化了的图形表示，因此被誉为“搭建系统的蓝图”。
由于其简单纯粹的本质，用例图是项目参与者间交流的好工具。用例图的画法是对现实世界的一种刻画，可以让项目参与者明白系统要做成什么样。
2. 用例(Use Case)——用例就是外部可见的系统功能，对系统提供的服务进行描述。用椭圆表示。
3. 子系统(Subsystem)——用来展示系统的一部分功能，这部分功能联系紧密。
用例图涉及的关系，如关联，泛化，包含，拓展等，在这里就不一一展开，有需要的小伙伴，可以去百度对应的资料。
使用场景：
产品经理使用用例图的场景一般是有两种。
第一种是描述用户的行为，通常，我们会使用用例图，描述这个用户在模块上可以做的操作。
第二种是搭配ER 图，描述实体的操作时，我们也会用用例图，去描述实体可以支持的操作。
