工作流的业务模型和数学模型之间的矛盾

 

     通常我们用流程设计器画一个流程图的时候,都是根据实际业务来完成这个过程的,而我们画出来的流程图,这个时候应该叫做业务流程图,但是这样一个业务流程图在提交给后台流程引擎进行处理的时候,往往会因为流程图中一些在逻辑上,数学上面不太清晰的拓扑结构而导致引擎的处理失败,一般在这种情况出现的时候,我们就需要对流程图进行修改,比如说增删插改若干个节点和连接线,以便让流程图的拓扑结构更加便于后台引擎中的拓扑算法来处理,但是这里却又会出现一个矛盾,我们为了方便引擎算法处理流程图而对流程图的修改往往又会破坏流程的实际业务拓扑结构。

 

      比如说原来一个业务过程由总经理下发一个项目到执行部门,本来这个拓扑结构是明确的,但是往往为了整体拓扑结构的修改,而要破坏这个局部的业务流程过程,导致最后修改完成的流程图虽然符合了引擎的算法模型却又和实际业务相背离,真是个麻烦的问题啊。。。。

 

      现在的流程管理系统中已经相续出现了两大矛盾,一个是流程引擎的相对静态的模型结构和通过设计器设计的灵活的,变化的流程拓扑结构之间的矛盾,另外一个就是前面说到得流程业务模型和流程数学模型之间的矛盾。。。。。如果能够有一个比较好的方法能够化解和解决这两个主要矛盾,那么我们设计的流程系统是否会更加实用一些呢?

 

你可能感兴趣的:(工作流的业务模型和数学模型之间的矛盾)