产品研发辅助图们

博客概要

     在我看来，不论做什么事，理清思路是蛮重要的，有了比较清晰明确的思路之后，再去执行事务，会很有效率，往往事半功倍，这一点在下深有体会。那么，怎么更好的理清自己那乱如麻的思路呢？一个很有效的方法就是“画图”，画各种图，毕竟所谓“一图抵万语”。本博文，就是针对近期研发产品时，自己用到一些图来进行规整和分享，制图如有不规范，望谅解。

1.画图意义重申

     画图其实算是一种前期设计所必备的技能，就举软件开发而言，用到图最多的地方就是在前期的需求、开发阶段，因为总的来说，软件产品的研发算是一个比较抽象的过程，而且在大部分情况下，需要一个团队、多人来进行协作完成，那么在此过程中，如果团队成员仅仅通过文字或者口头来进行交流的话，会比较效率低下，因为很多抽象的细节往往是很难仅仅通过文字或者口头表述的交流，就能让彼此达成共识的，就很容易产生纰漏，从而引发不必要的麻烦。

     所以我觉着画图呢，就是给所有人都提供一个很具象的参照物，把很多难以使用语言、文字描述的事务细节也好，还是产品功能这些东西，用图的形式，有一个很清晰的呈现。这样的意义，不仅仅是使得团队之间的研发交流效率更高，而且在产品研发的过程就能有比较直观的设计流程、标准等依据，并且我想即使在软件产品后期的产品更新、维护等阶段，也能有一定的作用。

     总而言之，在研发过程中，用好“图”，意义重大~

---

2.建议在不同流程中合适的用图

2.1用例图

图形介绍：
     *小人——参与者（Actor）与应用程序或系统进行交互的用户、组织或外部系统
     *椭圆——用例（Use Case）外部可见的系统功能，对系统提供的服务进行描述
     *箭头——之间关系
     简单确立核心功能、方向。用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点

图形描述	描述内容
适用场景	用于在制作新产品或建立新功能时，确定核心方向，用最基础直观的方法说明： 1.“谁”使用 2.“什么样的功能” 3.“用来做什么”
缺点	仅仅描述粗颗粒功能，不能表达非功能需求，如可靠性、性能等

2.2思维导图

图形介绍：
     画思维导图的过程，是一个由点到面的过程，是一个思维发散的过程，是将我们思考方式具象化的呈现出来，促进了我们的思考，也很有助于杂乱思路的梳理。

图形描述	描述内容
适用场景	在思路凌乱、对接下来不知道该从何下手之时，用一张思维导图，可以达到活跃思维，发散想法，也能很好的理一下思路 适用于简单单一模块的结构梳理，多模块梳理可能会有问题
缺点	结构比较固定，对于一些如果有很多模块的项目，就很对在模块间的关系进行更加清晰的梳理

2.3E-R图

图形介绍：
    * 矩形——实体（Entity）
     *菱形——联系（Relationship）
     *椭圆——属性（Attri）
     *线上数字或字母——对应联系
     在概念结构设计阶段用来描述信息需求和/或要存储在数据库中的信息的类型，显示数据库的完整逻辑结构

图形描述	描述内容
适用场景	在关联数多的情况下，使用E-R图能清晰一些
缺点	无法定义类/实体的行为。它更面向数据库而不是代码

2.4流程图

图形介绍：
     流程图有时也称作输入-输出图。该图直观地描述一个工作过程的具体步骤，各种操作一目了然，不会产生“歧义性”，便于理解，算法出错时容易发现。流程图对准确了解事情是如何进行的，以及决定应如何改进过程极有帮助。大到系统级别、小到某个操作背后的运转逻辑都可以使用流程图来画

图形描述	描述内容
适用场景	适用场景比较广，日常工作中小到算法逻辑，大到战略层面的执行落地都需要它。主要用它来将背后的流程可视化，辅助做决策去（如改进等）
缺点	所占篇幅较大，由于允许使用流程线，过于灵活，不受约束，使用者可使流程任意转向，从而造成程序阅读和修改上的困难，不利于结构化程序的设计

2.5数据流图

图形介绍：
     表示过程中，数据的方向，从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。

图形描述	描述内容
适用场景	研发过程中，对数据流向进行描述
缺点	绘制需要一定的技巧，以及一定的思维过程

---

以上就是我此次研发用到五种辅助图了，下面介绍另外一些辅助图

---

2.6鲁棒图

图形介绍：
     用于衔接用例图之后的设计，识别出系统在用例图中的各种职责，对后续的细节设计提供基础。算是对用例图的一种延伸。

图形描述	描述内容
适用场景	在确立用户场景之后，如果需要将关键功能设计出来，那么就需要它了。作图过程中最关键的2个点，发现职责，和梳理各个职责之间的关系
缺点	和用例图是一样缺点，唯一的变化是，其有了粗粒度的实现层面的内容。

2.7UML类图

图形介绍：
     类图是描述系统中的类，以及各个类之间的关系的静态视图。它不但是设计人员关心的核心，更是实现人员关注的核心。

图形描述	描述内容
适用场景	一般作为编码前做的最后一步，将设计转为相应的模型。也可以使用Code First的方式直接在项目中建模，现在的VS也支持直接从代码中生成UML类图。
缺点	画起来太费时间了，但反过来其表达的粒度更细致，是代码实现级别的内容。由于现在有比较多的工具可以从代码生成UML类图，甚至在大部分提倡使用Code First的场景下，我们画UML类图的机会是越来越少了。

2.8状态图

图形介绍：
     状态图是对类图的补充。描述类的对象所有可能的状态，以及事件发生时状态的转移条件。可以捕获对象、子系统和系统的生命周期。他们可以告知一个对象可以拥有的状态，并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类；该图可以确定类的行为，以及该行为如何根据当前的状态变化，也可以展示哪些事件将会改变类的对象的状态。

图形描述	描述内容
适用场景	当有一个对象拥有多个状态的时候，想要表达清楚状态之间的演变关系（也就是这个对象的生命周期）。比如通过什么条件触发状态变动的，到达某个状态之后会做什么动作等。这也是基于事件驱动设计的良好可视化图。
缺点	仅能表达行为/事件与状态之间的演变关系，不适用于其它领域。

2.9DFD图

图形介绍：
     是从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。

图形描述	描述内容
适用场景	在将思维导图得出的东西进行整合、梳理形成一个粗粒度的流程。这个其实类似与DDD中的上下文映射图，是在需求分析过程中做宏观设计的一种方式。
缺点	反映系统“做什么”，不反映“如何做”，粒度算是中等，需要其它更细粒度的图来对细节做支撑。

2.10UML时序图

图形介绍：
     时序图也是UML交互图中的一种，是描述对象是如何交互的，并且将重点放在消息序列上。也就是说，描述消息是如何在对象间发送和接收的。时序图有两个坐标轴：纵坐标轴显示时间，横坐标轴显示对象。

图形描述	描述内容
适用场景	一般当我们想反映一个包含顺序的交互流程，比如http请求的生命周期、页面上某个按钮背后流转细节等情况时，就需要它了。
缺点	一个时序图仅能面向一个Case，同时画起来比较费时间。

3.实际运用个人体会以及建议

     有很多辅助图种类，每种都有各自的用处，都有各自的适用场景，在使用图的时候，要用对场景，才能真正达到用图的效果。而且，也不是每张图都必须用到，只有需要时，画上，才有效。

     本次研发的话，我的用图过程是：

1.先用思维导图把握转瞬即逝的灵感，进行初步的研发整体的方向确认
2.使用用例图进行核心功能、方向的确认
3.反复使用思维导图对功能细节进行进一步发散
4.使用思维导图进行数据库的设计，以及页面逻辑的设计
5.绘制E-R图确认数据实体、联系、属性等
6.使用流程图在具体编码的过程中进行思路整理
7.绘制数据流图用于梳理数据流向，多用在思路不清的时候用来规整思路

参考博文

【1】软件开发中会用到的图
【2】面向百度
【…】…