绘制流程图遵循的规则标准流程图怎么做( 三 ) _流程图

此时，只要是网上支付或现金支付，就完成了支付。也就是说，条条大路通罗马。只要可以到达一条路径，我们就可以进行下一步。这时候有两种表达方式：
第一种方法是通过我们之前看到的三个传输线直接连接到下面的活动。第二种方法是画一个菱形，一进一出。注意这里的菱形符号不是判断的意思，只是借用了菱形符号，所以不需要在行旁边加上判断条件。
其实第二种绘制方式是UML标准的绘制方式。但毕竟有些看流程图的人不是程序员，画出来会让人产生误解。为了方便交流，可以选择第一种画法。但是，当你看到网上的流程图??加上合并的菱形符号时，你必须意识到这不是判断，而是合并。
这里再举一个例子，用户可以点击确认收货，系统也可以自动确认收货。也是先确认收货，清点收货，最终完成订单。
当用户收到发票和产品时，如何表示订单完成？ - 通过融合解决。
我们之前提到过货物和发票是分开寄的。对于用户来说，发票和货物必须同时收到，然后才能点击“确认收货” 。两者缺一不可。具体表示如下图：
表达式是一条粗的水平线，加上多进多出。进货分公司是发货和发货发票。这时候是同步处理的，但不关心谁先做，但是收敛的时候，必须完成后才能进入下一步。
另一个例子是上菜的例子。我们去餐厅的时候，菜是分开上的，直到所有的菜都吃完才算完整。在叶璐子的流程图中，没有办法表达这种并行合并处理。
通常并行和汇合成对发生，其中两组活动并行执行，但必须完成两组活动才能进行下一个会话。上图是完整的流程图。
5.流程图总结
流程图表示方法最后总结如下表：
三.通过问题学习概念
看完流程图的绘制方法和逻辑，我们来看看网上的一些流程图，一一理清常见问题有哪些？所以让我们避免同样的错误。
案例1：流程图中不应有非活动内容
上述流程图表示产品经理的工作包括需求收集、需求讨论和需求评审，为此绘制了流程图。想一想，这个流程图有什么问题？
根据流程图的概念，流程图要求每一帧都是一个，典型的是“主语+谓语+宾语” 。
“有效需求、现有功能、需求池”在这里不是一个活动，它们都在谈论不同类型的需求和功能概念。真正体现活动的是产品经理的“需求收集、需求讨论、需求评审” 。
这里人们会说，我应该怎么做才能体现“有效需求和需求池”这样的概念？
那么可以这样描述：我们可以将需求划分为新需求+旧需求，其中新需求产品经理需要过滤为有效需求和无效需求。进入需求评审环节的是新需求的有效需求和旧需求，并放入需求池。在此链接中，我们决定在此期间开发哪些需求。
上面的描述，如果你理解UML的面向对象的思维方式，就可以有效的描述。稍后会有一个关于这个的话题。此外，知识实际上是相同的。如果按照金字塔原理逻辑思考，也可以得到上面的描述。
通过这个案例，我们发现将需求处理计划的描述和需求评审过程的描述混在一起会混淆观众，但如果分开描述会更清晰。
案例2：流程图不同于状态图
这是买家的订单和付款流程。这里还是按照“主谓宾”的拆分，我们发现待付款不是一个活动，而是一个状态。横线上的“买家下单”是一个（即用户点击下单）。
所以这仍然不是流程图，用UML中的状态图来表达更合适。这时候如果从状态图的角度来看的话，这里也有问题，以后状态图我们会有专门的话题。
案例3：流程图的逻辑需要仔细考虑

绘制流程图遵循的规则 标准流程图怎么做( 三 )

绘制流程图遵循的规则标准流程图怎么做( 三 )