[原创]JWFD工作流引擎设计--简单矩阵建模与应用(初步讨论)

暂时忽略工作流状态的问题，仅仅表示工作流的拓扑结构

为什么要搞这样的东东,jwfd v0.96版本中的引擎算法已经足以应付常见的工作流模型了，其它工作流系统的状态机模型也是比较不错的解决方案.因为在我设计0.96的引擎的时候，由于嵌入式代码模块和外部 数据(表单等)的加入，核心引擎的代码出现了膨胀，引擎算法的结构出现复杂化的趋势,这个变化趋势让我感到流程系统的引擎核心由于负担的功能的增加而产生的代码量的膨胀和结构的复杂化是流程系统设计的一大障碍，因此我们有必要为克服这个障碍而作出一些新的尝试，因此寻找一种更加清晰和简明的流程数学模型就成为必须

这里还有一个重要的原因促使我要采用矩阵来构建流程的数学模型，因为在我前面对“JWFD工作流引擎设计--节点匹配搜索算法(再讨论)”这篇文章中我遇到了如何用算法来寻找一对匹配的节点的问题(带条件选择的并行汇聚路由问题 http://comsci.javaeye.com/blog/339756),虽然采用递归算法初步解决了这个问题，但是我始终认为有更为简单的办法来解决这个问题，经过一段时间的探索，我发现了一个比较有趣的现象，在流程矩阵中分支和汇聚的拓扑结构会在矩阵的数学模型中表现为一个类似对称子矩阵的结构，我们可以根据一些很简单的逻辑判断就可以发现一对互相匹配的分支汇聚点


* 构造矩阵步骤

* 1：用设计器画出流程图(验证用流程图相对比较简单，包含一个简单的对称分支和汇聚结构)

2：统计流程图的节点总数N(流程图有多少个节点？)

这个流程图一共有8个节点（包括开始和结束的点）

3：生成一个N*N的空矩阵(N就是第一步中的节点总数,如果不了解或者忘记矩阵的概念，可以翻翻线性代数的教材)

1 2 3 4 5 6 7 8
**************************
1 * 0 0 0 0 0 0 0 0
2 * 0 0 0 0 0 0 0 0
3 * 0 0 0 0 0 0 0 0
4 * 0 0 0 0 0 0 0 0
5 * 0 0 0 0 0 0 0 0
6 * 0 0 0 0 0 0 0 0
7 * 0 0 0 0 0 0 0 0
8 * 0 0 0 0 0 0 0 0
*

* 4：根据流程图的节点之间的连接来填充第二步中生成的N*N空矩阵

根据流程的节点之间的连接线的情况，比如说节点1到节点2有一条连接线，那么我们就在矩阵的第一行和第二列的交叉处用1来表示..节点2和节点3有一条连接线，那么我们就在第二行和第三列的交叉处用1来表示，如此类推，这个流程矩阵模型就完成了 (如果还不太理解这个流程模型的矩阵表示法，请参阅“算法导论”第22章-图的算法)

1 2 3 4 5 6 7 8
**************************
1 * 0 1 0 0 0 0 0 0
2 * 0 0 1 1 1 0 0 0
3 * 0 0 0 0 0 1 0 0
4 * 0 0 0 0 0 1 0 0
5 * 0 0 0 0 0 1 0 0
6 * 0 0 0 0 0 0 1 0
7 * 0 0 0 0 0 0 0 1
8 * 0 0 0 0 0 0 0 0

图2

这个时候，我们观察到矩阵中有一个比较对称的地方，在第二行和第六列分别有三处为1的地方(矩阵中粗体的数字所在处)，而这两组共6个为1的地方，恰巧是流程图中对称的分支和汇聚的拓扑结构所在之处(如图2)，这个时候我在先前的文章“JWFD工作流引擎设计--节点匹配搜索算法(再讨论)”中曾经为寻找分支和汇聚的匹配点而做的一些工作显然又多了一种解决方案，以后我们在对一个工作流的进行矩阵建模之后，如果发现矩阵中出现这种行和列均有相同个数的连接点，且位置呈对角线对称的子矩阵，那么这个行数和列数所对应的流程节点既是一对分支和汇聚的匹配点，这个解决办法在逻辑上面比我原来使用的“节点匹配搜索算法”更为简洁明了。

关于矩阵的存储结构，在计算机中有很多种办法，如果这种工作流的矩阵模型的存储比原来采用的邻接表数据库方式更为简单，占用的空间更加少，那么我认为在不抛弃过去邻接表数据库存储(流程在运行过程中的状态转换需要数据库，所以无法完全抛弃数据库)的基础上，增加矩阵结构的存储和运算，将为工作流引擎在处理复杂分支汇聚和其它拓扑结构的时候带来一些便利。。。。。。。。

采取矩阵模型来表示工作流的拓扑结构的意义尚不局限在上面说的地方，随着我们的进一步的探索，相信会有更多的发现。。。。。。