(15)Multiple Instances without a Priori Run-Time Knowledge 与上面模式相反，是在 B 产生最后一个实例以前（或者所有实例合并以前），都可以产生新的实例，而且不限数量。"实例生成"模式，指明了多实例模式所需要的前提条件（主要是实例个数N），而"运行时关系"模式，则给出了多个实例产生以后的相互关系。所以，多实例模式的应用是通过"实例生成"模式和"运行时关系"模式的结合，才能完整的表示多实例的业务。☆多实例与子流程的结合 这种方式的出现，主要是为了解决上面方式中无法表示多实例内部的流程。阅读全文>
发表于 @ 2007年05月15日 17:38:00|评论(loading...)|收藏
就是当所有正在运行结点都没有后继结点，流程就视为结束了。这个模式现在 BPEL、XPDL、BPMN 等流程的标准都支持，就是不需要指明结束的结点，只要跑完所有的结点（或者没有找到后继结点），就视为流程结束。"出口"、"输出"、"结束"等特殊的结点，就是采用 (43)Explicit Termination 这种模式的。阅读全文>
发表于 @ 2007年04月24日 15:17:00|评论(loading...)|收藏
这个模式可以说不是针对直接"套现"的情况，主要是流程设计的过程中自然形成循环。而这种在绘制流程图时候所形成的自然循环，没有明确的循环入口或者出口。因为是自然形成的循环，所以这个模式界限较为模糊，没有明确的循环入口，也可能没有明确的循环出口，还有可能多个入口，多个出口。在大部分的情况下，最好要有明确的循环入口点，已形成一个"有计划"的循环结构，如 (21)Structured Loop，和 (22)Recursion 这两个模式。阅读全文>
发表于 @ 2007年04月24日 11:03:00|评论(loading...)|收藏
国内所谓的工作流权限模型，一般是参考 RBAC，或者是树状的组织结构与角色的结合。这样就有一个十分显然的差别：工作流中，是某人一定要做这件事情，而且这个人在工作的过程中系统不会再将这个工作分发给其他人，其他人也不可能在系统没有分配的情况下"抢"（这个"抢"，实际上就是 RBAC 中的 Access 的概念）到正在工作的任务。譬如说，网络直销部虽然和销售部的是上下级部门的关系，但是如果实际业务流程中，网络直销部不需要向上汇报的流程，销售部也没有下达命令的流程，那么分发目标的集合中，不需要反映两者之间的关系。阅读全文>
发表于 @ 2007年04月20日 16:51:00|评论(loading...)|收藏
现在讲述的四种模式，包括：Multi-Choice、Structured Synchronizing Merge、Multi-Merge、Structure Discriminator，一般将其归纳为高级的分支和同步模式（Advanced Branching and Synchronization Patterns）。如果一些研究过早期工作流模式的朋友，可能会发现没有了 Synchronizing Merge 这种模式，因为现在已经被拆分为三个模式：Structured Synchronizing Merge、Acyclic Synchronizing Merge 和 General Synchronizing Merge。所谓的终端用户参与，即根据业务数据（或者终端用户的选择）来确定流程路径的走向（分支）；阅读全文>
发表于 @ 2007年04月19日 17:19:00|评论(loading...)|收藏
这种模式只处理 A、B 分支同时执行的情况，最直接的上文是采用 AND-split 使得 A、B 并发执行。这里 A、B 执行，若 A 先完成，则触发后躯结点 C，然后 B 完成以后，则到了这个 Discriminator 后就忽略其执行结果。一般工作流各种不同结点之间，一般是传递资源或者数据（关于资源和数据的概念，这里不详细解释）。业务操作时，C 的前驱动态决定，一般会得到前驱所持有的一些资源和数据，然后就处理这些数据。阅读全文>
发表于 @ 2007年04月16日 11:18:00|评论(loading...)|收藏
就这个模式本身不能独立的决定合并方式，需要根据上下文的信息来适应不同的情况变化（如：这一个模式需要知道前面的 OR-Split 结点如何分支才能决定合并方式）。在有分支流程的情况则更为麻烦，财务人员深有体会：在核对不同的单据凭证时（譬如销售部门的采购订单、仓库的收货单），甚至有可能要深入的了解暂缓执行的收货发货（对月份的财务报表有影响）、货品质量、退货数量等等。若存在这样的流程，尽可能让合并后的工作分担到各个分支上来，那样合并后的业务就相对简单多了，而其他工作因为分担到了各自的分支流程中，则效率更快。阅读全文>
发表于 @ 2007年04月16日 11:18:00|评论(loading...)|收藏
这一个模式实际上是一种相同分支的同构情况。注意，当 A、B 分支到达这个合并结点的时候，并不是合并，而是继续相同的后续分支。如 A 先完成，那么就触发 C1（这里要区别一下，第一次触发这个 C 我们称之为 C1），然后 B 完成后，再触发C2（第二次触发的 C 叫 C2）。在业务操作的各个细节都相同，这种模式无疑是一种很好的简化方式。阅读全文>
发表于 @ 2007年04月16日 11:18:00|评论(loading...)|收藏
细心的可能会发现，这个模式是 XOR-split、AND-split 更为泛化的一个模式（所谓的"泛化"，是概括、继承的意思）。该模式既然是 XOR-split 和 AND-split 的泛化，那表示他的最终表现可能会像 XOR 或者 AND 那样子，只是这里留给了一个用户选择的余地。对于这些企业的流程设计，可能因为许多自由选择的分支而形成一个复杂的网状流程，在我的个人经验看来，这样对工作流引擎所支持流程模式的要求越来越高。可以看到，一个工作流模型对模式的支持，是对业务流程设计与开发有着相当重要的影响。阅读全文>
发表于 @ 2007年04月11日 10:45:00|评论(loading...)|收藏
我们前面已经详细叙述了5种基本的工作流控制模式，包括：Sequence、AND-split（Parallel Split）、AND-join（Synchronization）、XOR-Split（Exclusive Choice）、XOR-join（Simple Merge）。我们可以做一个简单的对等，流程图中普通的矩形框就是 Sequence 模式，菱形框（条件判断）就是 XOR-Split，而一个矩形框接受多个分支作为前躯的情况就是 XOR-join。这5个模式较为明确，一般在流程设计中考虑，如没有可并发性工作的考虑，都能用 Sequence、XOR-Split、XOR-join 这三种模式来解决。阅读全文>
发表于 @ 2007年04月04日 17:25:00|评论(loading...)|收藏