我对工作流概念的理解 - 彪悍的人生不需要解释 - BlogJava

我对工作流概念的理解

现在，很多所谓的协同工作流实现都出现了理解歪曲。对此，我将描述一种新的工作流概念的理解，然后基于其上，对xpdl做一个改造，形成新的工作流的描述语言。

 

我们做software,常常自然地关注功能概念，即写码+硬 件组成一种可用的功能，比如我们常说给用户编出一个查询存货列表的功能，再加一个菜单；我们常常单纯基于这种功能概念构造系统。所谓对功能“搭积木”模式 更加体现了这种概念。从深层次讲，这满足了一种静态观察的需求；而随着用户水平的提高，他们逐渐能够表达一种基于动态观察的需求。典型地说，管理者希望确 保某个产品从进货到出货的整个过程都是最有效率的。继而，整个企业需要整个企业的运作中每个环节都是最正确有效的。对于企业而言，企业的每一个变化，活动，最好都是实现企业目标的最有效，最正确的一步。企业的需要，就是帮助他们实现企业，这个系统，一直以正确的活动序列向着企业目标运行着。目前用户还没有完全能把这种需求表达确切，现在所谓“协同”等概念其实就是对这种需求的模糊的表达。下面我试着表达解决这种需求的模型思路。

 

人如何实现目标？人类有一个一般的解决途径---控制系统的变化。比如我们追求自己的某个目标，往往先做一个计划，然后依照计划不断实现，反馈，修改计划。计划本质上就是对变化的控制。我们的思维中很重要的很基本的一条，就是从目标出发，分析出达到目标的途径。之后我们按途径进行受控活动。比如我们想解决温饱，最终就会分析到占有土地，提高种子质量等，然 后我们会控制自己或员工去一步步做这些事。

 

企业的每一个具体活动如果都是某个定义好的流程实例的环节实例(都是计划的一部分)，那么所有的活动就可以完全受控。受控就意味着可以进行优化，监控等，所以能控制到所有活动基本就成为实现最终需求的基础。

 

控制的粒度需要非常灵活。我们允许用户去定义提交一个存货单就是一个环节，也可以包括更多的内容在这个环节中。不同的企业规模，即使同一个业务流程，肯定对控制粒度要求也不同。所以保证这种灵活性非常重要。

流程就是活动的阶段性集合。比如全局就是一个流程，就是说企业的整个运作就是一个流程。之后比如什么请假流程都只是其中的一部分。而活动是一个黑盒，不可再分，它的划分涉及到粒度的把握。定义一个流程，实际是需要规范一系列活动。随着流程种类的不断开发，整个企业的运作就会日益受到控制。随着粒度的分合，运作的管理更加细致科学。而且随着整个社会的进步，活动系列也会相应调整，流程定义也要不断更新。所以要保证流程定义的易操作。这个多采用图形化定义解决。

流程的定义本身是一个控制活动的直接手段。通过借助观察大量流程实例的数据，可以进行统计分析，反过来改善流程定义。再加上对一个流程实例本身可以做暂停等管理，从而实现对整个企业活动的长期规划，即时调整，最终满足企业的需求，控制住企业的良好运作。

   这是基于这种需求的理解，这种解决思路，使得这个模型非常不同。

   1 流程定义。现在的流程定义，都出现了参与者等信息，而且还出现了如何运作的信息——关联某个应用功能模块。这些我认为都是一种歪曲。实际上这样做就将另一层次的需求混杂了进来。那就是通用的功能模块。比如某人在某环节可以填某个表的某些字段。这个出现在流程定义中，混淆了流程定义的本义。我认为流程定义本身仅仅是活动的划分。至于这个活动谁来完成，如何完成，根本不属于流程定义的范畴。定义一个流程，是对全局流程的某系列活动的一个划分，描述信息就是做什么的或者说达到什么目标的，本质是划分依据。每一个元素就是一个活动。这个活动的信息 可能没办法明确出什么目标，但是基本上也是一个划分依据的描述。

   但是我们描述流程的时候，往往习惯有一个流的概念。即 A 结束后是 B 。实际上这种信息根本无法静态描述。这一点和前面说的混淆，这两点导致实现非常不顺畅，高度太低的原因尔。

2 反过来说这两点，以另外的方式处理。表的字段访问控制作为一个通用功能单元即可，参与者放到权限控制模型中去实现。对于 transition ，由活动环节本身在结束时指定下一个。而如何指定，提供一个根据默认定义指定的通用功能。而这默认指定，则可以在流程定义中给出。虽然形式上仍然是元素间连线，但意义不同，这样我们不把这种 transition 信息作为流程定义的必需组成。

3 worklist 。 实现这样一个功能单位，让用户自己去一个列表中领取进行中的环节即可，某个用户判断可以结束了，直接声明结束环节。这是最简单直接的实现。不用担心权限问题，因为即使领取了环节，也不一定有功能权限去做实际功能。当然为了方便用户，可以做一个功能单位，让不同用户看到可以做的环节。

4 管理。其实就是那些暂停，看流程实例状态等。以新的理解，那其实这些也是某环节活动的组成部分。像原来一样做。当某个流程暂停了，那么系统就不会允许下一个环节的诞生。

5 至于所谓业务数据流，其实对于某一个功能，如果当初设计的是环节相关的，那他就可以通过领取的环节取到环节 id, 流程 id, 这些就足够了。如果不是环节相关的，比如某人的基本信息录入，那可能根本用不到这些数据。显然，一个环节可能是需要使用多个功能，这也和以前的理解不同。实际上我是这样做对，一个用户开始进入系统，默认持有系统流程大环节 id, 然后在列表中选择一个环节来参与进去，那就在会话中一直持有该环节。这体现了用户 A 正在受理某业务环节中的现实表现。

探索中，欢迎交流！msn:[e-mail]