本文探讨了工作流建模的不同方法，包括UML活动图和基于WfMC规范的模型，并提出了一种新的建模思路，即明确区分工作流逻辑与业务逻辑，以确保流程的准确执行。
前言：我计划把我的blog从51cto移到javaeye，陆陆续续地把我对工作流的理解贴上来，和大家交流。
关于工作流，我认为其基石就是工作流模型，我很久以前研究过wfmc，也在项目中应用过jbpm，我认为二者都有缺陷。我的理解如下文。
这里，以一个简单的案例讨论一下流程建模。
[b]案例3-1：[/b]某审批业务的业务流程如下，受理科接受用户的申请，并打印相关的回
执；受理后的业务资料移送给审批科进行审批；若审批通过，则继续移交给制证科制作相
关的文书和证件；最后业务材料由档案室归档。在这里暂不考虑审批不通过的情况，也不
考虑文书和证件发放的工作。
通常，我们有如下方法对这个业务进行建模。
[b]第一种方法：[/b]
我们可以用UML的活动图描述这个业务，如下图3-1（见附件中的3-1图）：
[img]http://www.iteye.com/upload/attachment/44601/4aef4662-3d8b-3822-8057-3f537c32a005.jpg[/img]
UML活动图从业务层次精确描述了这个案例，但是，这种建模一般只用在需求分析阶段。因为现在好像还没有一个引擎可以去执行它，虽然他也可以转换为xml文件。
因此，活动图是概念层次的建模，离可执行的工作流建模有很大距离。
[b]第二种方法：[/b]
我们可以用工作流工具对这个业务进行建模。在这里，我用自己的Bestsolution Workflow Designer（这是我很久以前写的，现在重写一遍，名字改了，叫做FireWorkflow）建立的流程模型，如下图3-2（见附件中的3-2图）。
[img]http://www.iteye.com/upload/attachment/44603/6549054f-0b6c-3657-bf1d-1cd02b217db8.jpg[/img]
这个模型是按照WfMC的规范建立的。
从图3-2 可以看出，用工作流设计器建立的流程模型与UML 活动图类似 。唯一的区别在于从图3-2 导出的流程定义文件（xpdl1.0 格式）是从代码执行的角度描述业务的，从而比较方便开发出一个所谓的工作流引擎来执行这个流程定义文件。
然而，WFMC 定义的工作流建模语言，以及其他许多工作流建模语言都没有回答一个根本性的问题：[b][color=red]用这个建模语言定义的流程真的能执行吗？能正确无误地执行吗？[/color][/b]从我的经验看，xpdl 还缺乏逻辑严密的语义，在稍微复杂一点的情况下，它定义的流程很难正确执行。
[b]下面我们用第三种方法建模：[/b]
如果我们把“案例3-1”所描述的审批系统分为两部分：工作流逻辑子系统和业务逻辑子系统。那么“图3-2”建立的工作流模型完全没有描述出工作流逻辑子系统需要完成哪些工作，业务逻辑子系统需要完成哪些工作；从这个意义上说，它和“图3-1”的UML活动图没有什么本质区别，都是很笼统的一个业务流程而已，只是xml 文件的DTD 有点不同。
我个人认为，[b][color=red]正是这种在两个子系统之间的职责的模糊与混乱导致工作流引擎无法进行正确的计算。[/color][/b]
我们把审批系统分成工作流逻辑子系统和业务逻辑子系统。工作流子系统的操作用圆圈表示，业务逻辑子系统的操作用方框表示。如图3-3（见附件中的3-3图）
[img]http://nychen2000.iteye.com/upload/attachment/44605/78151d94-b4ca-3f1e-a8e2-8f36f0b06a26.jpg[/img]
系统的执行过程如下：
首先，工作流逻辑子系统启动一个新的业务流程实例，然后启动一个新的任务“受理”，并将控制权交给业务逻辑子系统，由业务逻辑子系统完成受理工作。
第二步、受理完成后，控制权交给工作流逻辑子系统。由该子系统决定下一步的业务操作。工作流逻辑子系统根据流程定义以及相关流程变量的计算和判断，得出下一步的工作是“审批”，于是启动之，并将控制权交给业务逻辑子系统。
第三步、第四步以及后续步骤与之类似，直至最后工作流逻辑子系统计算得出流程实例应该结束，于是结束该流程实例。
图3-3 的建模似乎比图3-2 没有什么优越性，反而有点复杂，至少图形变得复杂了。但是我们如果考虑下面这种情况，那么图3-3 的建模的好处就非常明显了。在案例3-1中，我们没有考虑审批不通过的情况，现在把这种情况考虑进去，形成案例3-2。
[b]案例3-2：[/b]在案例3-1 的基础上考虑审批不通过的情况。如果审批不通过，则需要告知申请人，然后结束业务流程。
如果我们用xpdl对案例3-2键模，则图形表示如下图3-4（见附件图3-4）
[img]http://nychen2000.iteye.com/upload/attachment/44607/8af2311f-9fc5-3be4-9746-b55b1574d571.jpg[/img]
图3-4 的问题在于，业务逻辑和工作流逻辑叠加在一起，没有精确地指出到底在什么时候，由谁来决定审批之后的操作。我们可以理解为由“审批”这个环节决定后续环节是“制证”还是“告知申请人审核不通过”，这种情况下审批环节既代表了业务操作，又代表了工作流逻辑操作。当然，还有其他的执行方式，例如：计算连接“审批”到“制证”之间的狐（xpdl 称之为转移）以及联结“审批”到“告知申请人审核不通过”之间的狐得值来决定下一步的操作。总而言之图3-4并没有把业务说清楚。
如果我们用第三种方法，也就是图3-3 中的方法对案例3-2 进行建模，那么这个模型的局部如图3-5（见附件图-5）。
[img]http://nychen2000.iteye.com/upload/attachment/44609/b3480b28-8751-3fc5-b7e0-034ae491d49f.jpg[/img]
在图3-5 中，工作流逻辑和业务逻辑分得非常清晰，审批之后执行哪个业务操作是由工作流逻辑子系统的一个“操作”决定的。业务逻辑子系统中的“审批”操作仅仅负责完成业务特定的逻辑，其他的与之无关。
Fire Workflow正是基于这种理解而设计的，进一步，Fire workflow可以通过更加严密的数学逻辑进行证明，这一点还在完善中。。。
关于工作流，我认为其基石就是工作流模型，我很久以前研究过wfmc，也在项目中应用过jbpm，我认为二者都有缺陷。我的理解如下文。
这里，以一个简单的案例讨论一下流程建模。
[b]案例3-1：[/b]某审批业务的业务流程如下，受理科接受用户的申请，并打印相关的回
执；受理后的业务资料移送给审批科进行审批；若审批通过，则继续移交给制证科制作相
关的文书和证件；最后业务材料由档案室归档。在这里暂不考虑审批不通过的情况，也不
考虑文书和证件发放的工作。
通常，我们有如下方法对这个业务进行建模。
[b]第一种方法：[/b]
我们可以用UML的活动图描述这个业务，如下图3-1（见附件中的3-1图）：
[img]http://www.iteye.com/upload/attachment/44601/4aef4662-3d8b-3822-8057-3f537c32a005.jpg[/img]
UML活动图从业务层次精确描述了这个案例，但是，这种建模一般只用在需求分析阶段。因为现在好像还没有一个引擎可以去执行它，虽然他也可以转换为xml文件。
因此，活动图是概念层次的建模，离可执行的工作流建模有很大距离。
[b]第二种方法：[/b]
我们可以用工作流工具对这个业务进行建模。在这里，我用自己的Bestsolution Workflow Designer（这是我很久以前写的，现在重写一遍，名字改了，叫做FireWorkflow）建立的流程模型，如下图3-2（见附件中的3-2图）。
[img]http://www.iteye.com/upload/attachment/44603/6549054f-0b6c-3657-bf1d-1cd02b217db8.jpg[/img]
这个模型是按照WfMC的规范建立的。
从图3-2 可以看出，用工作流设计器建立的流程模型与UML 活动图类似 。唯一的区别在于从图3-2 导出的流程定义文件（xpdl1.0 格式）是从代码执行的角度描述业务的，从而比较方便开发出一个所谓的工作流引擎来执行这个流程定义文件。
然而，WFMC 定义的工作流建模语言，以及其他许多工作流建模语言都没有回答一个根本性的问题：[b][color=red]用这个建模语言定义的流程真的能执行吗？能正确无误地执行吗？[/color][/b]从我的经验看，xpdl 还缺乏逻辑严密的语义，在稍微复杂一点的情况下，它定义的流程很难正确执行。
[b]下面我们用第三种方法建模：[/b]
如果我们把“案例3-1”所描述的审批系统分为两部分：工作流逻辑子系统和业务逻辑子系统。那么“图3-2”建立的工作流模型完全没有描述出工作流逻辑子系统需要完成哪些工作，业务逻辑子系统需要完成哪些工作；从这个意义上说，它和“图3-1”的UML活动图没有什么本质区别，都是很笼统的一个业务流程而已，只是xml 文件的DTD 有点不同。
我个人认为，[b][color=red]正是这种在两个子系统之间的职责的模糊与混乱导致工作流引擎无法进行正确的计算。[/color][/b]
我们把审批系统分成工作流逻辑子系统和业务逻辑子系统。工作流子系统的操作用圆圈表示，业务逻辑子系统的操作用方框表示。如图3-3（见附件中的3-3图）
[img]http://nychen2000.iteye.com/upload/attachment/44605/78151d94-b4ca-3f1e-a8e2-8f36f0b06a26.jpg[/img]
系统的执行过程如下：
首先，工作流逻辑子系统启动一个新的业务流程实例，然后启动一个新的任务“受理”，并将控制权交给业务逻辑子系统，由业务逻辑子系统完成受理工作。
第二步、受理完成后，控制权交给工作流逻辑子系统。由该子系统决定下一步的业务操作。工作流逻辑子系统根据流程定义以及相关流程变量的计算和判断，得出下一步的工作是“审批”，于是启动之，并将控制权交给业务逻辑子系统。
第三步、第四步以及后续步骤与之类似，直至最后工作流逻辑子系统计算得出流程实例应该结束，于是结束该流程实例。
图3-3 的建模似乎比图3-2 没有什么优越性，反而有点复杂，至少图形变得复杂了。但是我们如果考虑下面这种情况，那么图3-3 的建模的好处就非常明显了。在案例3-1中，我们没有考虑审批不通过的情况，现在把这种情况考虑进去，形成案例3-2。
[b]案例3-2：[/b]在案例3-1 的基础上考虑审批不通过的情况。如果审批不通过，则需要告知申请人，然后结束业务流程。
如果我们用xpdl对案例3-2键模，则图形表示如下图3-4（见附件图3-4）
[img]http://nychen2000.iteye.com/upload/attachment/44607/8af2311f-9fc5-3be4-9746-b55b1574d571.jpg[/img]
图3-4 的问题在于，业务逻辑和工作流逻辑叠加在一起，没有精确地指出到底在什么时候，由谁来决定审批之后的操作。我们可以理解为由“审批”这个环节决定后续环节是“制证”还是“告知申请人审核不通过”，这种情况下审批环节既代表了业务操作，又代表了工作流逻辑操作。当然，还有其他的执行方式，例如：计算连接“审批”到“制证”之间的狐（xpdl 称之为转移）以及联结“审批”到“告知申请人审核不通过”之间的狐得值来决定下一步的操作。总而言之图3-4并没有把业务说清楚。
如果我们用第三种方法，也就是图3-3 中的方法对案例3-2 进行建模，那么这个模型的局部如图3-5（见附件图-5）。
[img]http://nychen2000.iteye.com/upload/attachment/44609/b3480b28-8751-3fc5-b7e0-034ae491d49f.jpg[/img]
在图3-5 中，工作流逻辑和业务逻辑分得非常清晰，审批之后执行哪个业务操作是由工作流逻辑子系统的一个“操作”决定的。业务逻辑子系统中的“审批”操作仅仅负责完成业务特定的逻辑，其他的与之无关。
Fire Workflow正是基于这种理解而设计的，进一步，Fire workflow可以通过更加严密的数学逻辑进行证明，这一点还在完善中。。。
扫一扫
1340
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
