“Python猫”，一个值得加星标的公众号
剧照|《NormalPeople》
一、背景
二、图为了解决什么问题
三、不同流程中适合运用的图
1.用例图
用例图是UML交互图中的一种，是指由参与者（Actor）、用例（UseCase），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（UserCase）是外部用户（被称为参与者，一般为软件的面向用户）所能观察到的系统功能的模型图。
适用场景：当新做一个产品或者功能的时候，首先需要明确核心方向，用例图就是整理这个核心方向的工具。它用来说明的是谁要使用系统，以及他们使用该系统可以做些什么。可以理解为是MVP思想的写照，去除画龙点睛的功能，这些就是基础、核心。
缺点：仅仅描述的是提供什么功能，不能表达非功能需求，如可靠性、性能等非功能需求。
2.鲁棒图（RobustnessDiagram）
可能英文名RobustnessDiagram更为常见一些，用于衔接用例图之后的设计，识别出系统在用例图中的各种职责，对后续的细节设计提供基础。算是对用例图的一种延伸。
适用场景：在确立用户场景之后，如果需要将关键功能设计出来，那么就需要它了。作图过程中最关键的2个点，发现职责，和梳理各个职责之间的关系。
缺点：和用例图是一样缺点，唯一的变化是，其有了粗粒度的实现层面的内容。
3.思维导图
思维导图是一个很厉害的发明，他将我们的思考过程具象化了，完美展示了由点到面不断发散的过程。但是它最大的价值，反而不是最终呈现出来的这个图，而是促进了思考的过程。并且需要注意的是，一定要把一条分支走到尽头，再回过头来走其它的分支，把思想榨干。
适用场景：在一个事情刚开始的萌芽期，不知如何下手；或者陷入一个困境的时候。利用思维导图来活跃大脑，进行发散思维。这时候如果结合头脑风暴，效果更佳。
缺点：它是一种树状的信息分层可视化展视，结构比较固定，不适合分支间互相交互比较复杂的信息展示。
4.DFD（DataFlowDiagram）图
DFD图是从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。
适用场景：在将思维导图得出的东西进行整合、梳理形成一个粗粒度的流程。这个其实类似与DDD中的上下文映射图，是在需求分析过程中做宏观设计的一种方式。
缺点：反映系统“做什么”，不反映“如何做”，粒度算是中等，需要其它更细粒度的图来对细节做支撑。
5.流程图
上面贴了2张图都是流程图，流程图有时也称作输入-输出图。该图直观地描述一个工作过程的具体步骤，各种操作一目了然，不会产生“歧义性”，便于理解，算法出错时容易发现。流程图对准确了解事情是如何进行的，以及决定应如何改进过程极有帮助。大到系统级别、小到某个操作背后的运转逻辑都可以使用流程图来画，我个人认为这应该是被最多人认识的图，没有之一。
适用场景：正如上面所说这个适用场景比较广，日常工作中小到算法逻辑，大到战略层面的执行落地都需要它。主要用它来将背后的流程可视化，辅助做决策去（如改进等）。
缺点：所占篇幅较大，由于允许使用流程线，过于灵活，不受约束，使用者可使流程任意转向，从而造成程序阅读和修改上的困难，不利于结构化程序的设计。
6.UML类图
适用场景：一般作为编码前做的最后一步，将设计转为相应的模型。也可以使用CodeFirst的方式直接在项目中建模，现在的VS也支持直接从代码中生成UML类图。
7.状态图
适用场景：当有一个对象拥有多个状态的时候，想要表达清楚状态之间的演变关系（也就是这个对象的生命周期）。比如通过什么条件触发状态变动的，到达某个状态之后会做什么动作等。这也是基于事件驱动设计的良好可视化图。
缺点：仅能表达行为/事件与状态之间的演变关系，不适用于其它领域。
8.E-R图
E-R图提供了表示实体型(Entity)、属性(Attribute)和联系(Relationship)的方法。其中最核心的还属联系(Relationship)的表示。
缺点：相对类图来说，E-R图无法定义类/实体的行为。它更面向数据库而不是代码。
9.UML时序图
四、实际的运用
其实上一节中图的顺序就是按照由层次从高到底，粒度从粗到细规划的。我们可以用用例图来确定用户核心需求，再用RobustnessDiagram定义好关键功能，随后在关键功能的实现上通过思维导图进行发散，然后用DFD图把粗粒度的内容串起来，至此大体的设计工作算是完成了。
然后再通过流程图、UML类图、状态图、E-R图、时序图在不同的场景确定细节实现。最终就是Coding的事情了。
至于每个图绘画的规范网上资料比较多，这里就不赘述了。如果大家有什么疑问继续交流。