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