1. 理论模型

　　AND分支以后，一个最为普遍的合并方式就是AND合并。

　　这一模型也较为简单，其中合并方式是等待所有的分支都完成了，在进行下一步的任务。 注意，在并发的语义下，可以明显的看到合并后的工作单元和合并前的工作单元，是一个"同步"的关系，因此这一模式的名字，应该是采用了计算机方面的惯用语。这点后面一些模式的名字可能还会看到这种惯用语，譬如 Thread、Instance 等等。

2. 应用

　　AND的并发分支，最普遍的汇总方式，是等待所有的分支完成再执行下一步。需要注意的细节是"同步"这个问题，很多时候存在现实业务的考虑，即使是同一个动作，也不一定是非要合并不可。

　　这样，AND分支和AND合并的模式组合起来，就可以讲讲实际流程设计的经验了。如一个人力资源：首先填个人简历，A 要对其中的工作经历核实，B 同时要对教育经历核实，然后递交给C（这个角色一般是部门主管） 做出评价。一般的设计考虑是：

　　变化：

• 当然，在第一个模式里面提到了，大部分的情况都能退化成顺序模式，像是这里，A、B、C这样顺序执行也没什么不妥。
• 若考虑实际业务的效率，C 做出评价，不一定要等待 A 、B 都做完才行，只要 A 核实了工作经历，C便可以先作一部分的评价。那这样的情况为了提高业务效率，怎么办？一般可能的是把 C 的工作拆成两部分，然后到下一步再合并，如图：

  　　

  但是这种情况来说，C的操作相对复杂了，如果把业务拆分后对效率提高的影响不大，则没有必要做出这样的拆分。是否需要拆分牵涉到流程再造的问题，若大家支持，我们还会去开辟专门的栏目论述业务流程再造的各方面配合（包括业务、管理、工作流模式和技术方面的配合而进行的流程再造）。

• 也是流程再造的问题，考虑到上一个变化的实际业务状况，可以选择用Structured Discriminator模式来替代AND合并模式。Structured Discriminator模式会在后面的文章叙述。

3. 难点

　　可以从上面变化的形式看到，这个 AND 合并的难点并非在这个模式本身，也不是它的内部实现复杂。我们需要仔细推敲的是：当使用这一个模式的时候，其要求所有分支完成后才能继续下一个步骤，会不会带来业务效率的浪费。

　　如果是在做电子政务的审批流程，那这个问题不太突出，政府的工作效率也足够慢了，再慢那么一点于大局并无显著影响。但是生产流程的设计，或物流流程的部署，则可能带来巨大的浪费损失，不可不慎察之。

发表于 @ 2007年04月02日 17:24:00|评论(loading...)|编辑