[1]几天狂想的成果：工作流的定义与模型

我现在神经亢奋，因为想了几天的东西终于想通了，正式接触工作流有四天了，有些成果，现在写出来与大家共享。

我理解的工作流（WorkFlow）分为顺序工作流（Sequentail WorkFlow）和状态机工作流（State Machine WorkFlow），它们的定义和之间的关系为：
WorkFlow :<steps | states>  说明： |  表示或者，下同。
step | state : <steps | states>
leaf state : <steps>
即工作流是一个步骤集或一个状态集；一个步骤或状态也是一个步骤集或一个状态集；而最终的叶子状态只能定义为一个步骤集，微观上的状态也是由一个或多个动作来完成的（正如面向对象的方法内部是面向流程的）。而Step的定义可以直观认为：给定一组输入，通过Step的执行，给出一组输出，即叶子节点上的Step不可再分割。
这是一个递归定义的系统。基于这样的定义，就可以定义一个复杂的工作流，比如一个工作流被定义为一个顺序的，其中有一个步骤有几个状态，那么这个步骤可以被定义为一个状态集，这个步骤相当于一个子工作流。可以想象，基于这样的定义的工作流引擎将会是非常灵活的！

从上面的定义可以看出，步骤（Step）是关键。如果把Step进一步定义为:
step | state : <steps | states | action>
action : <add|modify|delete forms>
于是任何一个步骤或状态都归结为表单操作！对于大多数工作流而言，所有的动作不都是围绕数据展开的吗？对于Action的定义，也可以是操作其它对象的动作，而不仅仅是表单。

实际上，对于step和state可以看成同一回事情，都把它看作Step，试想最终的叶子状态也是由Step组成，理应可以归结为Step，只是概念上怎么看待它的问题。为了能够适应一个状态到多个可能状态的转移，为Step加上了一个分支控制。

那么给出我最后的工作流定义：
WorkFlow :<&Step>
Step : <Steps , Branches , Waits>  --  如果没有定义branches，则顺序执行steps中所有的Step；Waits则表示了该Step等待的条件。
Branch:<Result , Steps> -- 这是一个key-value的字典，如果Step的执行结果与Result匹配则跳到相应的一个或多个Step执行。
Wait:<Step,Result> -- 等某个步骤的某种结果。
&符号表示：step本身就是一个完整的流的定义，上面说了，这是一个递归定义。

如果在Step上做一些文章：数据持久化、权限控制、自定义单据、自定义报表，那么工作流的引擎就可以建立起来了！！

目前用C#做了一个最为简单的框架，稍微测试了下，可以正常运作，等一个阶段的测试完成，也会在后续的文章中与大家共享。