Fire Workflow2.0规划(1)——模型的优化

[b]1、Fire workflow工作流模型的设计目标[/b]
1.0版本的模型主要是从技术的角度进行分析得出的结论，遇到了不少的批评，这些批评归结起来有如下几点。
A) 业务上不直观：流程图太技术化，业务描述有点啰嗦。例如，顺序连接的两个Activity之间也必须要有Synchronizer。
B) 某些业务场景不能够很好地刻画：由于“每个Activity只允许一个输入”，使得一些公用的环节很不好表达。

经过一段时间的回顾和思考，我认为，Fire Workflow模型的设计目标是：[b]增强其表达力，能够更简洁通俗地刻画业务，同时便于计算机处理[/b]。

如何增强表达力及其效果，在接下来的章节中详细描述。

[b]2、模型更充分地体现“以业务过程为中心组织资源、逻辑和数据”的思想[/b]
什么是“以业务过程为中心组织资源、逻辑和数据”的思想呢？
我们以政府部门为例，以前我们的政府部门的架构以层次结构为主，注重纵向的上下级关系和职责分配。群众要申请某个事项必须亲自携带资料在这些政府部门之间穿梭；如果在办理过程中出现差错，群众更加不知所措，不知道找谁。这种组织结构和办事规则显然不是很好地实现政府部门的“服务群众”的业务目标。
后来，很多政府部门提出了“一站式”服务的理念，群众只要在服务大厅提交申请事项即可坐等结果，后续工作由政府部门按照规章制度制定的业务过程自行调度组织。这个理念的目的是方便群众，其本质就是以业务过程为中心，调整政府组织架构和行为方式。

那么Fire Workflow的模型如何体现“业务过程”，“资源”，“逻辑”和“数据”这些要素呢？
首先，业务过程（Process）由Activity, Synchronizer, Transition , Loop来表达。
资源有很多种，包括人、计算机、软件系统等等，在Fire workflow当前版本中，只对“人”进行了建模——Performer。
逻辑和数据向来密不可分，逻辑操作的对象就是数据。在Fire Workflow中 Task代表的是业务逻辑，同时，由于没有找到简便的合理的数据业务数据建模方式，所以它同时也代表了业务数据。

紧接着的一个重要问题是：这些要素之间是什么关系？如何体现“以业务过程为中心组织资源、逻辑和数据”的思想？

在1.0的模型中有这样的描述：Activity是Task的容器。这句话首先太技术化了，另外，也没有从业务的角度看问题的意思。
在2.0中Activity的图示没有变化，但是赋予了新的含义。如下图
[img]http://dl.iteye.com/upload/attachment/170383/99fe163e-c287-367e-afd6-6d539f20425e.jpg[/img]

多个业务步骤（Activity）在Synchronizer, Transition, Loop等逻辑组织下形成一个业务流程（业务过程），资源、逻辑、数据都是以这个过程为中心进行分配和组织的。

[b]2、Activity可以有多个输入[/b]
在2.0的模型中，Activity可以接受多个Synchronizer的输入，但是Activity并不对这些输入做任何的同步操作（这不是Activity的职责），即在运行时任何一个输入都可以激活Activity。

但是，Activity的输出仍然只允许1个。

这个修正对于使得“转移到公共步骤”的场景更加简单。例如，银行贷款流程可以这么画。
[img]http://dl.iteye.com/upload/attachment/170385/6a157549-53cb-34ac-ab3f-6a4781018aa2.jpg[/img]

[img]http://dl.iteye.com/upload/attachment/170387/23cb07a3-5cb0-3956-9644-b99be139cdcc.jpg[/img]

[b]4、增加“业务视图属性”和业务视图[/b]
没有分支和汇聚节点Synchronizer自动被隐藏，空Activity可以设置业务试图属性来决定是否需要自动隐藏。
[img]http://dl.iteye.com/upload/attachment/170389/8ad78a4a-dbfe-32e3-9e52-0ec2a15b37dd.png[/img]

[img]http://dl.iteye.com/upload/attachment/170391/da7c23a7-8de8-34f6-9dc1-5c5c94194634.png[/img]