工作流复杂拓扑结构处理新思路

我们走的设计路线和国外的产品不太一样，不一样在哪里呢？  国外的流程的设计思路是通过事先定义一整套规则(类似XPDL)来约束和控制流程图的复杂度(我对国外的产品了解不够多，仅仅是在有限的了解程度上面提出这样的看法)，从而避免在流程引擎中处理这些复杂的图的问题，而我们却没有通过事先定义这样的复杂的规则来约束和降低用户自定义流程图的灵活性，这样一来，在引擎和流程流转控制这一个层面就会遇到很多相对比较复杂的问题，我的博文中提到的几种算法就是专门处理这些复杂情况的，这样虽然可以把流程图的用户自定义的优点可以发挥到最大，但是也使流程引擎的设计难度大大增加，这是一个矛盾，开发者可以通过定义一套复杂的XML规则来使流程图的用户自定义受到约束和控制，避免用户画出具有很复杂拓扑结构的流程图，但是这种限制对最终用户来讲不是很令他们感到满意的。。在实际应用中，一个组织和企业对流程的需求是不会因为流程系统的限制而降低的，我们既然要给用户自定义流程图的设计器，那么我们就不应该在XML定义中给这种设计的过程太多的限制。。我们的设计目标是尽量的让引擎能够处理用户花出来的复杂的流程图，当然这种复杂是有一定限度的。。。另外定义规则的XML也使流程引擎的设计可以更好的结构化和模块化，更符合OO的思想，这是定义规则的另外一个好处，不过既然都让用户自己可以设计流程图了，我觉得还是我们搞设计和开发的人多费点神，尽量把引擎的做的强大一些，尽量让用户方便些，我们人毕竟不是MS，也不是什么BPM联盟，只是一群依靠获得用户的满意来吃饭的软件工程师。。。

说了那么多废话。。。。。还是要说几句正儿八经话

我们的引擎如果遇到一个复杂的流程图，里面分支和汇聚的拓扑结构都不规则，也不对称，要设计算法比较困难的时候，该怎么办呢？

第一种办法：让用户在设计过程中把特殊的节点设置特殊标志，我们在引擎中针对这些特殊标志做特殊处理
第二种办法:把复杂流程图分区(类似于petri网的四种基本模式的划分)，对不同的区域做不同的处理,我们可以把复杂的图划分为不同的区域，对不同的区域分别采取不同的处理方式。。。

在实际设计开发过程中，我们还会遇到很多困难，不用怕。。。克服困难，继续前进，我们搞技术就是不断在克服困难中取得进步的。。。