2007年05月15日
(15)Multiple Instances without a Priori Run-Time Knowledge 与上面模式相反，是在 B 产生最后一个实例以前（或者所有实例合并以前），都可以产生新的实例，而且不限数量。"实例生成"模式，指明了多实例模式所需要的前提条件（主要是实例个数N），而"运行时关系"模式，则给出了多个实例产生以后的相互关系。所以，多实例模式的应用是通过"实例生成"模式和"运行时关系"模式的结合，才能完整的表示多实例的业务。☆多实例与子流程的结合 这种方式的出现，主要是为了解决上面方式中无法表示多实例内部的流程。阅读全文>
发表于 @ 2007年05月15日 17:38:00|评论(loading...)|举报|收藏
2007年04月24日
就是当所有正在运行结点都没有后继结点，流程就视为结束了。这个模式现在 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...)|举报|收藏
2007年04月20日
国内所谓的工作流权限模型，一般是参考 RBAC，或者是树状的组织结构与角色的结合。这样就有一个十分显然的差别：工作流中，是某人一定要做这件事情，而且这个人在工作的过程中系统不会再将这个工作分发给其他人，其他人也不可能在系统没有分配的情况下"抢"（这个"抢"，实际上就是 RBAC 中的 Access 的概念）到正在工作的任务。譬如说，网络直销部虽然和销售部的是上下级部门的关系，但是如果实际业务流程中，网络直销部不需要向上汇报的流程，销售部也没有下达命令的流程，那么分发目标的集合中，不需要反映两者之间的关系。阅读全文>
发表于 @ 2007年04月20日 16:51:00|评论(loading...)|举报|收藏
2007年04月19日
现在讲述的四种模式，包括：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...)|举报|收藏
2007年04月16日
这种模式只处理 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...)|举报|收藏
2007年04月11日
细心的可能会发现，这个模式是 XOR-split、AND-split 更为泛化的一个模式（所谓的"泛化"，是概括、继承的意思）。该模式既然是 XOR-split 和 AND-split 的泛化，那表示他的最终表现可能会像 XOR 或者 AND 那样子，只是这里留给了一个用户选择的余地。对于这些企业的流程设计，可能因为许多自由选择的分支而形成一个复杂的网状流程，在我的个人经验看来，这样对工作流引擎所支持流程模式的要求越来越高。可以看到，一个工作流模型对模式的支持，是对业务流程设计与开发有着相当重要的影响。阅读全文>
发表于 @ 2007年04月11日 10:45:00|评论(loading...)|举报|收藏
2007年04月04日
我们前面已经详细叙述了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...)|举报|收藏
这一模式就是只有一个分支接受，遵循先到先得的原则。这个模式主要是为了应付前躯是 XOR 分支的流程，这个模式也是一个很常用的模式。到目前为止，我们所提到的5种模式已详细讲解完（Sequence、Parallel Split、Synchronization、Exclusive Choice、Simple Merge），这就是基本的流程控制模式。后面的两种模式应用没有涉及太多内容，因为要结合起来才能讲，基本工作流模式的组合应用则另外叙述。阅读全文>
发表于 @ 2007年04月04日 15:53:00|评论(loading...)|举报|收藏
从该模式的名字来看，"排他选择"，显然就是比较常见的 XOR 分支模式。一般来说，这个模式的实现一般为在运行时的条件选择，就是条件判断的代码放到XOR 这个结点，然后去根据这些代码去判断下一步的走向。心思细密的人，也许发现这个XOR 本质上就是流程图的菱形结点，就是根据条件选择路径，而且只能选择一条。阅读全文>
发表于 @ 2007年04月04日 15:21:00|评论(loading...)|举报|收藏
2007年04月02日
注意，在并发的语义下，可以明显的看到合并后的工作单元和合并前的工作单元，是一个"同步"的关系，因此这一模式的名字，应该是采用了计算机方面的惯用语。这样，AND分支和AND合并的模式组合起来，就可以讲讲实际流程设计的经验了。是否需要拆分牵涉到流程再造的问题，若大家支持，我们还会去开辟专门的栏目论述业务流程再造的各方面配合（包括业务、管理、工作流模式和技术方面的配合而进行的流程再造）。也是流程再造的问题，考虑到上一个变化的实际业务状况，可以选择用Structured Discriminator模式来替代AND合并模式。阅读全文>
发表于 @ 2007年04月02日 17:24:00|评论(loading...)|举报|收藏
2007年03月30日
就技术上来说，涉及到并发的就存在这一个并发线程/进程的管理问题，如这些并发单元怎么组织管理其运行状态，如何通知不同的并发单元的交互，以及考虑到中途当机、重启恢复，资源争夺，并发冲突、死锁等等较为繁琐的细节。所以如果一个公司愿意投入成本去实现这种并发模式，我认为这个公司起码在3个方面能表现出他的"技术脱贫"：首先是团队有技术实力解决并发应用所带来的问题；不过这个模式本身看起来比较简单，就他与其他模式配合使用，和实际业务条件的限制下，就显得错综复杂。阅读全文>
发表于 @ 2007年03月30日 17:01:00|评论(loading...)|举报|收藏
2007年03月29日
多实例模式：12. Multiple Instances without Synchronization，异步多实例13. Multiple Instances with a Priori Design-Time Knowledge，设计期多实例14. Multiple Instances with a Priori Run-Time Knowledge，运行时前置多实例15. Multiple Instances without a Priori Run-Time Knowledge，运行时非前置多实例。阅读全文>
发表于 @ 2007年03月29日 22:42:00|评论(loading...)|举报|收藏
这个理论模型十分简单，只是一个工作单元完成了，紧接着无条件执行下一个工作单元。每一个工作流系统都直接实现了这种模式，这个模式是工作流能运行的一个重要基石。比较有趣的是许多不同形式的分支，在业务的实践中都可以退化成为顺序模式。阅读全文>
发表于 @ 2007年03月29日 22:05:00|评论(loading...)|举报|收藏
“如果你原来的业务流程是这样操作，那么它本身就不规范，所以我们不能这样做……”接下来下面一大堆道理，叙述信息化应该以规范化为基础才可能有效实施，然后提出一个更好的流程设计方案，推动用户对现有的业务流程进行优化。这次沟通完了以后，项目经理的跟班——一个刚入行的菜鸟，就会感叹“果然是老鸟，先规范化，再信息化，一针见血啊！”，项目经理笑了笑，说：“只是那种流程，我们没办法实施而已。”首先客户尊崇了信息化和规范化的理论，菜鸟尊崇了项目经理的经验，而项目经理则是蔑视了工作流模型反映实际业务的能力。阅读全文>
发表于 @ 2007年03月29日 12:19:00|评论(loading...)|举报|收藏