轻量级工作流引擎地设计与实现

《轻量级工作流引擎地设计与实现》由会员分享，可在线阅读，更多相关《轻量级工作流引擎地设计与实现（45页珍藏版）》请在装配图网上搜索。

1、word目 录目录1摘要3Abstract4第一章引言51.1 轻量级工作流引擎的概念51.2 工作流管理系统的分类与本文的侧重点51.2.1 面向文档的与面向过程的51.2.2 结构化的与即席的61.2.3 基于和基于数据库61.2.4 任务推动的与目标拉动的61.2.5 本文的侧重点6第二章工作流管理系统参考模型简介7第三章系统分析与设计93.1 工作流模型的设计93.1.1 工作流模型的对象93.1.1.1 从一个简单的业务实例看业务的需求93.1.1.2 工作流对象的具体分析和说明113.1.2 对象之间的逻辑关系133.1.2.1 对对象进展分类以与各个分类中对象之间的关系133.1

2、.2.2 各个模型之间的逻辑关系153.1.3 工作流实例，流程实例，环节实例和工作项的状态转换163.1.4 任务分派193.1.5 转换条件的满足193.2 系统结构213.3 系统模块的划分223.4 数据库设计223.5 类的设计263.5.1 实体类的设计263.5.1.1 数据库访问类263.5.1.2 值对象类313.5.2 业务类的设计353.5.3 接口类的设计37第四章系统实现374.1 关键问题的解决方案374.1.1 启动工作流实例374.1.2 推进工作流实例的进程384.1.3 类型为文档的附件的处理394.2 一个简单工作流管理系统的实现394.2.1 系统应用框

3、架394.2.2 J2EE相关技术的应用404.2.2.1 J2EE核心模式和类的实现414.2.2.2 JavaBean技术与类的实现414.2.2.3 OSS应用服务器和工作流引擎的实现414.2.2.4 Jsp/Servlet技术和系统界面的实现434.2.3 具体编码实现43第五章系统的不足44第六章总结44参考文献45轻量级工作流引擎的设计与实现摘 要工作流管理技术由于良好的企事业业务适应性得到了广泛的应用，基于工作流管理技术的工作流管理系统已经为各企事业单位带来传统信息系统所没有的效益。工作流是一种反映业务流程的计算机化的模型，是为了在先进计算机环境下实现经营过程集成和经营过程自动

4、化而建立的可由工作流管理系统执行的业务模型。工作流管理系统是支持企业经营过程高效执行并监控其执行过程的计算机软件系统。工作流引擎是工作流管理系统的核心。它为管理系统提供一系列通用的服务，以实现各种管理系统的具体应用。针对目前企事业的一般业务，我们运用了轻量级工作流引擎的概念，主要探讨轻量级工作流引擎的具体设计和具体实现。实践证明，轻量级的工作流引擎可以满足企事业一般的需求，而且明显缩短了开发周期。关 键 字:轻量级，工作流引擎，工作流模型，工作流实例，业务规如此AbstractBecause of the good adaptabilities to the enterprises busin

5、ess, the workflow management technology now has already been used extensively. The workflow management system which bases on the workflow management technology has also already brought the benefit that the traditional information system couldnt bring. The workflow is a puterize model which reflects

6、the business process, and it is also a business model which can be carried out by the workflow management system, setting up with the purpose of acplishing the integration and automation of the management process under the advanced puter circumstances. The workflow management system is a puter softw

7、are system that can support the enterprises management process to carry out in a high efficiency and dominate the management process. The workflow engine is the core of the workflow management system. The workflow engine offers series of mon services for the management systems with the purpose of br

8、inging all kinds of management systems to be applied concretely. In connection with the mon business of the present enterprises, we put the definition of the lightweight workflow engine to use, and research the concrete design and acplishment of the lightweight workflow engine chiefly. The practice

9、has proved that the lightweight workflow engine can meet the mon demands of the enterprises, and can shorten the development periods visibly.Keywords：Lightweight, workflow engine, workflow model, workflow instance, business rule第一章 引 言1.1 轻量级工作流引擎的概念轻量级的工作流引擎指的是从够用、灵活和低本钱的设计原如此出发，不追求工作流引擎的功能的完备和复杂，只

10、是实现其中必不可少的功能和特征。在设计工作流引擎时主要考虑对其数据模型的定义和解释、活动之间的协调以与任务的分配和控制等功能提供支持，而不支持诸如提供内建built-in的应用开发工具、对应用资料的定义和完整性维护、完善的异常处理以与长事务控制等功能。轻量级工作流引擎的概念的提出，给开发工作流管理系统的开发人员开辟了一条新的道路。工作流管理技术本身就是一项抽象复杂的技术，它致力追求从企事业各种各样的业务中抽取出一个通用的模型，由这个模型去描述所有业务的一致性，以达到“放之四海皆可用的程度。不过，要把众多的而又错综复杂的业务都集中在这个模型中，这是一件非常困难的工作，要经过一段漫长的摸索历程。而

11、轻量级的概念让我们认识到可以从一般性的而又简单的业务入手，为企事业快速的开发出一个适应他们本身业务需求的而又带有可扩展性可移植性的信息管理系统，为他们提高工作效率，并保证在一段很长的时间内满足不断增加的业务需求。1.2 工作流管理系统的分类与本文的侧重点根据工作流过程本身的特点、系统建模的方式、所使用的底层支撑技术、以与工作流过程的执行方式等的不同而对工作流管理系统进展相应的分类。1.2.1 面向文档的与面向过程的前者的侧着点在于将电子形式的文件、图像等在有关的人员之间进展分发，以便能够得到不同人的处理与审阅。现有的文件管理与映像管理系统均属此类。在面向过程的WFMS中，工作流被描述成一序列执

12、行环节。与各环节相应都有待处理的资料对象。各环节的资料对象可以按不同的方式分发到其它环节中去，如可以将资料对象的值作为控制条件、或者依此资料对象组装成其它的资料对象等。高端的WFMS一般都属此类系统。1.2.2 结构化的与即席的结构化工作流指的是在实际工作过程中会反复重复、严格按照某个固定的步骤进展的业务过程。定义此种工作流所需要的各种类型的信息可以通过对业务过程进展详细的分析而得到，从而得到完整的过程定义并在以后的应用过程中反复使用。大量的办公程序，如公文处理、审批等都属此类。即席工作流如此是针对那些重复性不是很强或没有重复性的工作流程的，关于这类流程执行所需的有关参数(如参加者等)事先无法

13、确定，而必须推迟到过程实例运行时才能确定，同时在执行过程中间还可能会发生一些意外的情况。这种动态多变的特点在提供更高灵活性的同时，也为过程的建模与执行带来更多的复杂性。1.2.3 基于和基于数据库前者使用电子来完成过程实例执行过程中消息的传递、资料的分发与事件的通知。低端的系统所使用的经常就是此种方法，它可以充分发挥电子系统在广域环境下的资料分发功能，但整个系统将运行于一种松散耦合的模式下。在基于数据库的WFMS中，所有的资料都保存在某种类型的DBMS中，过程的执行实际上就是对这些资料的查询与处理。高端的大规模系统所使用的一般都是此种方法。1.2.4 任务推动的与目标拉动的前者指的是从过程的开

14、始逐步地一个环节一个环节的执行，当某个活动实例被处理完之后，后续的有关活动将被创建并被激活，由此直至整个工作流程的完成。这是目前大多数面向过程的WFMS所使用的执行方式。而在目标拉动的WFMS中，一个业务流程被看成是一个目标。过程实例执行时，该目标将被分解得到多个相互之间按一定约束条件的关联起来的可执行的多个环节，其中各环节还可以当成是子目标而进一步进展分解。在各环节均执行完毕之后，整个过程也就完成了。目标拉动是一种全新的执行方式，下一代的WFMS将具有此种特征。应该说明的是：上述分类只是从不同的角度入手的。一般来说，后面那些特点将给WFMS带来更好的灵活性，同时也将成为那些能够支持跨机构的大

15、规模复杂工作流管理、面向关键任务的WFMS不可缺少的特征。本文的侧重点不在于完全实现其中一种工作流管理系统的所有功能，更不在于实现所有种类的工作流管理系统的全部功能，前文已经说过，这是一件非常困难的事情。那么我们的侧重点在哪里呢？就在于综合以上四种工作流管理系统的主要特点，是一个面向文件的，基于数据库的，由目标拉动的结构化的工作流管理系统，并且由此去设计和实现工作流管理系统的核心工作流引擎。从一般性来说，目前大多数的企事业的业务都是事务申请，公文流转，各项通知等等，这些业务或者需要查看，或者需要审批，而这些业务的资料根本上是以文件的形式保存在计算机上，而其中一些格式化的资料是保存在数据库中，所

16、以面向文件和面向数据库是轻量级工作流引擎的一个重要特征。业务的发起和完毕是一项过程化的任务，任务又可以分解成一个一个环节任务，而任务是带有目的性的，由这个目的去拉动这个过程中的一个一个的环节任务，促使环节任务的推进，最终达到任务完成的目的。这些业务的过程化不是随机的，而是已经严格规定好的，只有遵循这些过程化的规如此和流程环节才能完成整个业务。轻量级的工作流引擎就组合了以上这些，不追求工作流引擎的功能的完备和复杂，以满足一般性业务为目的，为企事业快速开发出适合他们业务的工作流管理系统。第二章 工作流管理系统参考模型简介在阐述工作流引擎之前，我们来了解一下工作流技术的根本知识。早在几年前，为了建立

17、工作流管理系统的相关标准，国际上成立了一个称为“工作流管理联盟简称WFMC的国际组织。她提出了有关工作流管理系统的一些规X，定义了工作流管理系统的结构与其与应用、管理工具和其它工作流管理系统之间的应用编程接口，也就是工作流系统参考模型。WFMC给出的工作流参考模型如如下图：接口2接口3接口4接口1接口5过程定义工具工作流API与交换格式工作流执行服务工作流机工作流引擎工作流管理工具其它工作流执行服务工作流机工作流客户应用工作流机直接调用的应用图2.1 工作流参考模型从图中可以看出，参考模型包含了五类接口，分别是：接口1：过程定义输入输出接口，这是工作流服务与工作流建模之间的接口，该接口提供的功

18、能包括通信建立，工作流模型操作和工作流模型对象操作。接口2：客户端函数接口，这是工作流服务与客户应用之间的接口，这是最主要的接口规X，它约定所有客户方应用与工作流服务之间的功能操作方式。包括通信建立，工作流定义操作对过程模型定义操作，过程实例管理功能，过程状态管理功能，任务项列表/任务项处理功能，数据处理过程，过程监控功能，其它的管理功能，应用程序激活。接口3：激活应用程序接口，这是工作流引擎和直接调用的应用程序之间的接口，包括通信建立，活动管理功能，数据处理功能。接口4：工作流执行服务之间的互操作接口，这是工作流管理系统之间的互操作接口，包括连接的建立，对工作流模型和其中对象的操作，对过程实

19、例的控制和状态描述，对活动的管理，对资料进展处理。接口5：系统管理与监控接口，这是工作流服务和工作流管理工具之间的接口，包括资源控制，角色管理，用户管理，过程实例的管理，状态管理，审核管理。五个接口以与对应的API函数囊括了工作流管理系统的全部功能。一个完整的工作流管理系统就是以工作流引擎为中心，向外部部件应用程序或其它工作流引擎提供这五个接口，提供其实现的所有功能。第三章 系统分析与设计在所有准备工作完成后，我们就开始进展系统设计和设计，构造一个轻量级的工作流引擎。轻量级的工作流引擎并不完全实现WFMC所提出的工作流模型包含的五个接口，特别是接口4，在分布式工作流管理系统才具有该接口。既然我

20、们从轻量级的概念出发，我们就不再明显区分各个接口的界限以与其所具有的特定的功能，以够用、灵活和低本钱的设计原如此去设计出我们所理解的工作流引擎。我们运用了面向对象的方法，首先从众多的业务需求中抽取出工作流模型所包含的对象，再分析各个对象之间的逻辑关系，然后提出一个系统结构，再进展模块划分，数据库设计，最终完成类的设计。我们当中所用到的建模工具就是ROSE UML。3.1 工作流模型的设计对工作流模型的设计是工作流引擎设计的重要组成局部。 3.1.1 工作流模型的对象企事业经营过程就是一项项业务的实现过程，我们从一般业务入手，并对这些业务进展详细的分析，研究，其结果就是得到一般性的业务对象，从而

21、抽象成工作流模型对象。3.1.1.1 从一个简单的业务实例看业务的需求目前企事业的一项根本事务就是出差管理。它主要是对企事业的人员因为某种工作上的原因需要到别的地方出差进展的管理。我们可以列出出差的相关步骤：申请人需要出差，并且他她具有出差的权利；申请人填写出差表格，说明因何事出差，出差何处，申请出差金额，何时回来等等和出差相关的情况；申请人需要其它说明的话，可以将更具体的说明以文档的形式保存下来；申请人确认申请无误后提交申请，等待申请的结果；根据规定，该申请必须先让申请人的上一级审批，那么该申请就会以一项工作项的形式交给该级领导处理；处理该申请的领导对该申请进展处理，他她会先查看该申请所有的

22、资料，包括出差申请表和与之相关的其它文档，然后对其进展审批，审批的结果是同意那么该次申请会交给再下一级领导处理；审批的结果不同意，该申请被打回，通知申请人申请不通过的结果。等所有需要审批的领导都审批通过了，该申请就成功完成，通知申请人申请通过的结果；申请人得到申请的结果，如果审批通过如此准备出差，如果审批不通过如此根据审批结果对该申请进展修改，重新提交申请；申请事务完毕。这是一个简单的业务实例，对该实例进展分析我们可以得到该业务的一些对象：申请人：他她属于该企事业的某个部门的成员，并且具有启动该业务的权利；审批领导：他她也属于该企事业的某个部门的成员，并且具有对该业务进展处理的权利；出差表格：

23、它是该业务规定的格式化资料，并且是必须的出差具体说明：它是该业务附加的资料，可以不要的申请人已经填写好的出差表格：它是出差表格的实例化，代表一个具体的应用审批同意和不同意：它们是对该业务的处理，遵循一定的业务规如此申请：这是一个过程，不是一个动作，需要时间和人的活动才能完成审批：这是一个活动，是过程的一局部，并且可以向另外一个活动转化 其它应用程序：申请人要填写出差具体说明时要调用相应的外部应用程序编辑该说明并以一定的格式保存下来，审批领导要查看出差具体说明时也要调用相应的外部应用程序打开该说明并以一定的格式显示出来。从这些业务对象，再利用工作流技术，我们可以得到工作流模型的一些根本对象：用户

24、：正如申请人，审批领导，他们就是工作流管理系统的用户，由他们去使用该系统的各种功能，并且直接参与业务活动，促使业务的完成。角色：有些人可以申请出差，有些人对出差申请可以审批，这两种不同的人可以作为两个不同的角色。角色是具有某种使用系统特定功能的权利的一个人员或多个人员的组合。工作流应用资料：出差申请表格，出差具体说明，这些就是对应某个具体业务这里是出差管理的相关资料，根据这些业务资料我们可以对该业务进展处理。需激活的应用程序：在需要其它应用程序提供支持的时候，会去激活这些应用程序。流程：整个出差申请的过程就是一个流程，它从整体去描述一个业务。环节：又称活动，它反映了业务流程的局部情况，通常业务

25、流程是由一个一个的环节组成。流程实例：将该出差申请这个业务流程实例化，就得到一个流程实例。环节实例：将流程的其中一个环节实例化，就得到一个环节实例。业务规如此：业务的开始和完毕需要一定的条件，在处理业务的过程中必须按照一定的规如此，这些都是业务规如此，只有严格遵循业务规如此，业务才能完成。3.1.1.2 工作流对象的具体分析和说明通过一个具体的业务我们可以得到工作流模型的一些对象，那么我们再对其他一般性业务进展分析，研究，我们就会找到它们的共同点，并归纳出基于这些业务的公共的对象，这些公共的对象的组合，就是一个通用的模型，也就是工作流模型，这个模型能去描述每个业务，是我们追求轻量级工作流引擎的

26、最终成果。用户：业务的执行者和参与者，对应于企事业的每一个雇员，是一个独立的、具有一定行为能力和一定技术能力的人的实体；角色：以技能为前提，能够完成某项功能的人员的总称；部门：对应于企事业的静态结构划分，由企事业的实际部门设置情况来决定，可以是传统的面向职能的，也可以是现在流行的面向过程与客户的；职位：以行政责任为前提，代表了管理上的等级关系；工作组：以执行某一任务为目标而动态组建的、跨部门划分的一种组织结构；流程：对应于一个业务过程，表示一个业务由发起、处理、完毕的一个过程；流程实例：对应于一个业务流程具体应用，是业务流程实例化的表现形式；环节：对应于业务流程中一个单一的业务操作，是流程按照

27、业务要求的细化；环节实例：对应于一个环节的具体应用，是环节实例化的表现形式；工作流定义主信息：描述一个工作流模型的主要信息，从整体来描述工作流模型；工作流附件信息：描述一个工作流模型所用到的附件信息，也就是工作流应用资料，或者叫业务资料。按照WFMC提出的工作流模型，这不是工作流模型所包含的对象，可是我们对其进展格式化，把它抽取成一个模型对象，用来规定了工作流模型在具体应用时所需业务资料的格式，我们把它分为两类： 表格类型：这是以表格的形式保存附件信息，可以用关系结构来定义附件信息，并保存在数据库中，每一条记录就是一个该附件的实例； 文档类型：只是以文件形式保存附件信息，可以是work文档，也

28、可以是文本文件，它的实例化是就是一个一个带有对应某个业务应用标志的文件，保存在硬盘上工作流实例信息：描述一个工作流模型实例化的信息，也作为启动一个工作流的信息，它记录该业务流程随着时间和人员的参与处理的不断变化，直到整个业务的完毕；工作项信息：描述参与某个业务应用时被分配到的一项任务，这就表现了参与人员和系统交互的典型特征；业务规如此：描述业务在运行的过程中必须要遵守的规定和原如此，也是业务活动得以向另一个活动推进的规如此。我们把它分为四类规如此，分别是： 自动型：它主要描述一些只给参与人员查看业务信息的业务规如此，例如通知、公文流转等等业务。该类业务不需要参与人员去审批或其它人为上的处理，只

29、需要参与人员去查看其中的内容就足够，整个业务流程的完成是全自动的。 与聚合：业务活动的完成是需要参与该活动的所有人员都进展人为处理，其中有一个人员没对其进展处理，整个活动只能停在原地，等待所有人员的处理，当最后一个参与人员执行了处理工作，它才能完成。 或聚合：在参与某一业务活动的人员当中只要有一个对其进展处理，整个活动就可以完成。 投票聚合：统计参与该活动的参与人员的处理结果，当满足一定条件该活动才能完成。 转换条件：描述流程、活动状态改变时需要的条件，用于业务运行过程中的约束。例如流程的完成必须等待所有活动的完成才能完成，活动的完成必须按照业务规如此去完成等等；需激活的应用程序：工作流管理系

30、统需要其它应用程序的支持，例如编辑和查看文本文件信息等等；日志信息：描述工作流中所有的状态改变、事件和控制流相关资料的变化，工作流实例和环节实例的启动、完毕、挂起和激活等等信息都会记录下来，以便对其进展管理。3.1.2 对象之间的逻辑关系在找出工作流模型的对象后，我们就开始分析它们之间的业务逻辑关系。3.1.2.1 对对象进展分类以与各个分类中对象之间的关系到此为止，我们有必要对工作流模型对象进展一下分类，根据工作流对象对工作流管理系统所起的作用我们可以分成以下几类：组织模型组织模型描述了企事业的组织机构关系，包括的对象有用户，部门，职位，角色，工作组，它们的关系可以用如下图表示：设置负责组成

31、组成资格组成部门职位用户工作组角色图3.1 组织模型结构从图中可以看到它们之间的关系，用户是根本的单位，部门是由用户组成，每个用户对应一个职位，负责该职位所要求的职能，用户凭着某种资格赋予一种角色，工作组也由用户组成，也可以由角色组成。这几个根本的对象以与其关系所构成的组织模型，已经可以满足轻量级工作流引擎对组织模型的需要了。工作流定义模型工作流定义模型描述了工作流模型的定义信息，包括工作流定义主信息，流程定义信息，环节定义信息，工作流附件信息，业务规如此。它们之间的关系如如下图：图3.2 工作流定义模型结构包含包含包含包含遵循包含工作流定义附件信息主信息业务规如此环节流程包含流程是包含假如干

32、环节的，而环节遵循一定的业务规如此，再加上工作流主信息和附件信息，共同构成工作流定义模型。工作流实例模型工作流实例模型描述了工作流模型实例化时的信息，通过这些信息我们可以知道实例过程中的各种状态变化和最终的结果，因而得到一个业务具体应用的情况。它包括流程实例，环节实例，工作流实例信息，工作项信息和转换条件，它们之间的关系如如下图：记录记录细化细化影响影响影响影响记录记录转换条件环节实例信息流程实例信息工作项信息工作流实例信息日志信息日志信息细化图3.3 工作流实例模型结构转换条件影响工作流实例，流程实例，环节实例和工作项的状态，并由转换条件去决定它们的状态转变，工作流实例信息流程实例信息环节实

33、例信息工作项信息，自上而下逐层细化，不但从全局了解业务运行情况，而且从局部了解业务运行的细节情况。而它们的状态改变都会记录在日志中，用以追踪工作流实例的运行情况。外部支持模型外部支持模型在本文只包括一个对象，就是需激活的外部应用程序，严格来说这不是工作流模型的一局部，可是提供接口去激活所需的外部应用程序为工作流管理系统提供支持是工作流模型的功能之一。有了这些外部应用程序的支持，我们的工作流管理系统的功能才变得更完善。3.1.2.2 各个模型之间的逻辑关系不但模型中各个对象有一定的逻辑关系，而且各个模型之间也有一定的逻辑关系，如如下图所示：调用依赖使用使用角色和工作组用户定义工作流实例模型外部支

34、持模型工作流定义模型组织模型图3.4 模型之间的关系组织模型的用户定义工作流定义模型；工作流定义模型使用组织模型的角色和工作组，用来规定工作流模型的启动条件和任务分配条件，因为工作流模型的启动和任务的分配必须由一定的角色或工作组完成；工作流实例模型依赖工作流定义模型，同时使用组织模型的所有对象，并且调用外部支持模型为其提供支持。3.1.3工作流实例，流程实例，环节实例和工作项的状态转换工作流实例，流程实例，环节实例和工作项从不同的层次去描述业务运行过程的具体情况，不同级别的用户可以看到业务运行的不同方面，创建工作流实例的用户可以看到工作流实例信息以与其状态转换，参与该工作流实例的用户可以看到工

35、作项信息以与其状态的改变，系统管理员可以看到所有信息以与其状态的转换。工作流实例状态图 创建管理员管理员管理员Running运行pleted完毕正常情况Suspended(挂起)terminated(终止)Initial初始化图3.5 工作流实例状态图提交流程实例状态图管理员管理员管理员Running运行pleted完毕正常情况Suspended(挂起)terminated(终止)图3.6 流程实例状态图环节实例状态图处理中承受完成正常处理没有完成异常处理回退处理提交给下一环节图3.5 环节实例状态图工作项状态转换图等待操作完成通过没有完成不通过无操作，超时操作下一工作项回退处理已查看初始化未

36、审批未查看图3.5 工作项状态图承受任务分派是工作流引擎的一个重要功能。当环节实例产生时，就会以一定的准如此把需要处理的工作当作一项任务项工作项分派给参与该环节实例的所有用户，而这些用户是同属一个角色或者工作组的。我们又把角色和工作组进展细化，可以得到以下准如此：基于部门的：这就是说把任务分派到某个部门的所有人员，该部门的所有人员都参与了该项任务，因而会为该部门的所有人员都产生一个工作项；基于职位的：这就是说把任务分派到某个职位的所有人员，同属该职位的所有人员都被分配到一项工作项；基于部门职位的：这就是说把任务分派到某个部门的某个职位的所有人员，同属该部门的该职位的人员都被分配到一项工作项；基

37、于所有人的：这就是说把任务分派到该企事业的所有人，该企事业的所有人都被分配到一项工作项；基于工作组的：这就是说把任务分派到该企事业的某个特定的工作组上，同属该组的所有人员都被分配到一项工作项。基于部门的，基于职位的，基于部门职位的和基于所有人的这四种类型，其实是基于角色的细化，通过这些准如此的分类，我们尽量做到系统与企事业有较强的适应性，以与使系统在任务分派时有较大的灵活性。工作流实例，流程实例，环节实例和工作项的状态转换有各自特定的条件，分别如下：工作流实例的转换条件工作流实例从整体看业务运行过程，工作流实例被用户创建后就进展初始化并提交给工作流引擎，由工作流引擎去处理，此时实例处于运行状态

38、；在运行过程中，它会根据流程实例的状态而不断进展本身的状态改变；当管理员由于某种原因要挂起它时，它就处于挂起状态，直到管理员重新激活它使它处于运行状态或者终止它使它非正常完毕；当它被正常处理完毕后，就正常完毕。流程实例的转换条件流程实例也从整体看业务的运行过程，流程实例在工作流实例初始化时就开始它的工作。在运行过程中，它会根据各个环节的完成程度来改变自己的状态，当所有环节实例都正常完成它就正常完毕；管理员可能要挂起它使它处于挂起状态，直到管理员重新激活它使它处于运行状态或者终止它使它非正常完毕。环节实例的转换条件环节实例从某个方面看业务的运行过程，环节实例在流程实例运行时就开始它的工作处于处理

39、中状态。之后环节实例的状态由两方面决定，一是工作项的处理结果，一是业务规如此的规定。 如果业务规如此是自动型的，不管工作项的处理结果怎样，当系统把任务项分派给特定用户完毕后，该环节实例就正常完成处于正常完毕状态； 如果业务规如此是与聚合的，系统分派完任务项后，当所有参与人员都正常处理完该环节各自的工作项后，该环节才正常完成处于正常完毕状态；在处理过程中，只要有一个工作项是非正常处理的，该环节就非正常完成处于非正常完毕状态；在处理过程中，有工作项还未被处理并且没有一个工作项被非正常处理，那么环节实例仍然处于处理中状态； 如果业务规如此是或聚合的，系统分派任务后，只要有一个工作项是正常处理的，该环

40、节实例就正常完成处于正常完毕状态；如果所有同属该环节实例的工作项都被非正常完成，那么该环节实例就处于非正常完毕状态； 如果业务规如此是投票聚合的，系统分派任务后，统计工作项的完成程度，当正常完成的工作项数量达到一定数量时，该环节实例就正常完成处于正常完毕状态；当正常完成的工作项数量不达到规定的数量时，该环节就非正常完成处于非正常完毕状态；当所有工作项还没处理并且正常完成的工作项还没达到规定数量时，该环节实例仍然处于处理中状态。工作项的转换条件工作项从更细节的方面看业务运行过程，工作项的状态转换要看参与人员对各自的工作项的处理情况和业务规如此的规定。我们把与聚合，或聚合和投票聚合这些要人工干预的

41、规如此统称为人工型规如此。 如果业务规如此是自动型，同属该规如此的工作项的状态就只有正常处理后的正常完毕状态，当然如果对该工作项还没被处理如此处于处理中状态，可这不对环节实例等产生影响； 如果业务规如此是人工型，就会有正常处理和非正常处理两种情况，正常处理该工作项如此使到该工作项处于正常完毕状态，非正常处理该工作项如此使到该工作项处于非正常完毕状态。3.2 系统结构本着基于轻量级工作流引擎的原如此，我们已经对工作流模型进展了详细的分析和详细的设计，在这里我们就提出一个系统结构，如如下图所示：工作流定义器工作流解析器实例调度中心任务管理器任务分派器启动控制器工作流定义数据工作流实例数据日志数据工

42、作流定义接口工作流实例接口组织定义数据组织定义接口组织定义器状态转换器组织管理器图3.6 工作流引擎系统结构图从图中可以知道，系统提供了三类接口：组织定义接口、工作流定义接口和工作流实例接口。这三类接口实现了工作流模型的接口一，接口二，接口三和接口五规定的主要功能；系统有一个实例调度中心，这是一个很重要的部件，它控制工作流实例的运行，通过工作流解析器对该工作流模型进展解析其含义，通过任务分派器按照一定的分派准如此把任务项分派给参与该工作流实例的用户，通过任务管理器管理各个任务项的信息，通过启动控制器控制工作流的启动权利和启动信息，通过状态转换器控制工作流实例、流程实例、环节实例和工作项的状态转

43、换；组织定义器定义企事业的组织结构；工作流定义器定义工作流模型信息，并通过组织管理器得到组织定义信息，为工作流模型提供组织支持。各个部件处理的相关信息都保存在数据库中。3.3 系统模块的划分根据功能实现的不同我们进展模块的划分如下：用户管理模块：对用户信息的管理，包括注册用户信息，注销用户信息，查询用户信息等功能；部门管理模块：对企事业部门结构信息的管理，包括增加部门信息，删除部门信息，查询部门信息等等功能；职位管理模块：对企事业职能信息的管理，包括增加职位信息，删除职位信息，查询职位信息等等功能；角色管理模块：对企事业某种技能信息的管理，包括新增角色信息，删除角色信息，查询角色信息等等功能；

44、-工作流模型管理模块：对工作流定义模型信息的管理，包括定义新的工作流模型信息，删除旧的工作流模型信息，查询工作流模型信息；工作流实例管理模块：对工作流实例信息的管理，包括启动一个新的工作流实例，查询工作流实例信息，按照一定的业务规如此生成新的环节实例信息，为用户分派工作项，管理工作项信息，按照一定的转换条件为工作流实例、环节实例转换状态等等功能；系统监控模块：为工作流实例，环节实例等的状态转换信息参加日志，挂起、激活工作流实例，强制完毕工作流实例，为迟迟不对自己的工作项进展处理的用户发出提醒或警告信息，查看各个工作流实例的完成程度等等功能。功能模块的划分，为系统的实现做好充分的准备。3.4 数

45、据库设计基于轻量级的工作流引擎的特点之一就是把系统相关的资料，如工作流模型定义信息，工作流实例信息，组织模型定义信息等等，都以特定的实体形式保存在关系型数据库中。工作流定义主信息表workflowTable静态定义工作流主要信息，包括该工作流的标识ID可以定义为以WORKFLOW_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx形式,x是自动生成的序号，工作流名称，工作流描述，工作流类型工作流的类型有自动型，人工型和混合型，自动型不需要人工参与，由工组流引擎自动执行，人工型需要人工参与，混合型包含了自动型和人工型，工作流创建日期，工作流创建者ID即用户ID，工作流创建人名称即用户

46、名，工作流生命周期每个工作流实例都有它的生命周期期限，在该期限内还没完成它的工作就直接死亡，目前该工作流实例数目记录当前工作流实例数目，工作流启动者角色指明该工作流可以由哪个角色发起，属于该角色的用户都可以启动该工作流模型对应的实例。工作流重要信息还包括两方面，一是工作流附件，因为在工作流进展过程中，肯定会带有一些信息，这些信息对于出差申请来说就是出差申请表，对于公文流转来说就是以word文档形式的公文，对于通知来说可能就是以文本文档形式的通知书，等等；一是工作流流程描述，包括假如干个环节activity，这些环节有一定的顺序，表现工作流顺序执行的特征。把工作流附件和工作流流程描述从工作流定义

47、别离出来，是基于工作流附件和工作流流程描述对于不同工作流有不同形式和数量的原因，有利于工作流附件和工作流流程描述的扩展。工作流附件信息表workflowAttachmentTable静态定义工作流所需要的附件，包括附件ID可以定义为以Attachment_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx形式,x是自动生成的序号，工作流ID标识属于哪个工作流，附件类型表或文件，附件名称如果类型是表，如此为该表的名称，如果是word文档，如此为该文档名称，如果是文本文档，如此为该文件名称，其它信息如果类型为表格，该字段以一定的格式保存该附件表格的所有字段的各种信息，包括字段名称，字段

48、数据类型，数据类型长度，字段描述。工作流流程描述表workflowProcessTable静态定义工作流的流程，由假如干环节activity组成，一个环节为一条记录，包括工作流ID环节所属工作流ID，环节ID可以定义为以ACTIVITY_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx形式,x是自动生成的序号，环节名称即该环节名称，环节描述对该环节的具体描述，参与者角色ID将一样权限的用户作为一个集合，在数据库以同一个角色操作数据库特定操作，该项标识角色ID，环节任务分派规如此，上一个环节ID保存上一个环节的ID，由这项可以判断该环节是否整个流程的开始环节，或者该环节的任务没有完

49、成审批不通过，或没在其生命周期期限内完成时作回滚处理的重要数据项，根据这个数据项可以回滚到上一个环节，下一个环节ID保存下一环节的ID，由这项可以判断该环节是否整个流程的完毕环节，或者该环节的任务完成了，根据这个数据项可以启动下一环节，继续向前推进。工作流实例启动描述workflowInstanceStartUpTable动态定义工作流实例启动信息其实这也是工作流实例信息表启动者在产生一个工作流实例之前必须根据工作流的定义做好准备工作，这些准备工作的信息就填入该表中，然后交付给工作流引擎。该描述包括工作流ID所属工作流ID，工组流实例ID标识该工作流实例，可以定义为以WORKFLOWINSTA

50、NCE_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx形式,x是自动生成的序号，工作流实例描述，工作流实例创建时间，工作流实例创建者ID启动者ID，工作流实例创建者名称，当前工作流状态标识当前工作流实例的状态，启动者在创建后却没提交给工作流引擎前的状态为“initialized初始化状态，之后的状态要视工作流类型而定，当前状态具体描述，当前操作者ID当前工作流要被谁操作，当前操作者名称。工作流实例完成标志标识该工作流实例的完成，工作流实例完成时间，当前工作流状态和当前操作者ID和当前工作流状态具体描述三项在工作流实例的运行过程中，可以动态追踪该工作流实例的运行，而这三项再加上工

51、作流完成标志和工作流完成时间，可以知道该工作流实例的完成情况。工作流实例过程描述workflowInstanceProcessingTable以环节为单位动态描述工作流实例的处理过程，启动者创建工作流实例后，提交给工作流引擎后，工作流实例就根据工作流定义的流程进展运转了。包括工作流实例ID，工作流实例所对应环节工作流流程就是由一系列的环节组成，按照预定义的流程一个环节过渡到另一个环节，当前该环节所处状态这标识着该环节在处理过程中的状态，最终状态表示该环节的完成状态，当前操作者对应的是角色，当前状态具体描述。工作项描述workItemTable动态描述已经参与该工作流实例处理的参与者对应已处理环

52、节的角色的每个用户的工作情况。包括工作项ID可以定义为以WorkItem-_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx形式,x是自动生成的序号，工作项名字，工作项描述，工作流实例ID该工作项所属的工作流实例，该环节任务分派规如此继承环节的任务分派规如此，用于判断该环节任务完成方式，当前该工作项所处状态根据不同的工作流类型有不同的状态，根据这些状态可以在参与者接口上显示不同的工作项列表，执行动作记录执行者会对该工作项执行怎么样的动作，如果是申请事务如此是审批通过或审批不通过，执行时间记录该执行动作的时间，用户ID标志该工作项是属于谁的。用户描述UserTable该表描述所有用

53、户的资料，包括用户ID可以定义为以User-_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx形式,x是自动生成的序号，用户名称，用户密码，用户所属部门，职位等等信息，级别是该用户的系统权限，包括普通职员，高级职员和系统管理员。日志信息描述LogTable描述用户的工作日志，便于对各种操作进展追踪。包括日志ID可以定义为以Log-_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx形式,x是自动生成的序号等等，其中有一项为哪一项相关工作项ID，这是当参与者对原始工作项进展执行操作动作时的工作项。角色信息RoleTable描述角色的信息，包括角色ID可以定义为以Role

54、_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx形式,x是自动生成的序号，角色名称，部门名称，职位名称，角色描述。角色由部门和职位组成。部门信息DepartmentTable描述部门的信息，包括部门ID可以定义为以 Depatment_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx形式,x是自动生成的序号，部门名称，部门其它信息。职位信息PositionTable描述职位的信息，包括职位ID可以定义为以 Position_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx形式,x是自动生成的序号，职位名称，职位其它信息。除了以上这些主要表以外，还有一

55、些我们是在定义工作流模型的时候才参加数据库的，如对应工作流附件类型为表的表格。为了减少网络流量和提高系统的运行速度，我们把一些有关联的数据库操作写成存储过程：删除工作流模型存储过程：删除一个工作流模型，必须删除它的工作流定义主信息，同时删除对应的附件信息，附件为表的表格，环节信息；创建附件类型为表的表格：定义附件信息时已经把该表格的字段信息保存在该附件信息的其它信息字段中，并且有一定的格式，那么我们从该字段中按照一定的格式复原表格的字段信息，并根据这些信息在数据库中创建该表格。3.5 类的设计用面向对象的方法和UML建模工具，再根据系统结构图，模块的划分和数据库的设计，我们把对象转化成类，进展

56、类的设计。我们把整个系统的类分成三局部，一是实体类，二是业务类，三是接口类。3.5.1 实体类的设计工作流模型的对象就是一个一个的实体，实体类又分为数据库访问类和值对象类。数据库访问类是对存储在数据库的实体信息进展访问插入，删除，更新，查询的类，值对象类是在客户端和服务器端之间交换资料的实体信息类。3.5.1.1 数据库访问类数据库连接类：该类是其它数据库访问类的父类，管理数据库的连接，负责从数据库连接池找可用的数据库连接给其它数据库访问类使用，使用完毕后负责放回连接池，类图如如下图：说明：属性只有一个connection，它代表数据库的一条连接，类型为Connection，方法有一个构造函数

57、workflowDAO()和一个关闭连接的函数closeConnection()。WorkflowDAO()实现从数据库连接池找一个可用连接并赋值给属性connection，closeConnection()负责把连接放回数据库连接池。工作流定义主信息访问类：对应数据库的工作流定义主信息表，该类封装了对该表格记录的各种操作，就是插入或删除一条工作流定义主信息，查询特定工作流定义信息或者所有工作流定义信息，类图如如下图：说明：构造函数WFDefineMainInfoDAO()调用父类构造函数，从数据库连接池中找一个可用的数据库连接其它数据库访问类也一样。工作流流程信息访问类：对应工作流流程描述表

58、，该类封装了对该表格记录的各种操作，流程是由假如干环节组成，就是插入或删除一条环节信息，查询同属于一个流程的环节信息等等，类图如如下图：说明：findWorkflowFirlstActivityInfo()函数负责找该工作流模型的第一个环节的信息，findWorkflowNextActivityID()负责根据当前环节ID找下一环节的信息。工作流附件信息访问类：对应工作流附件信息表，该类封装了对该表格记录的各种操作，就是插入或删除一条工作流附件信息，查询同属于一个工作流模型的附件信息。类图如下：工作流附件类型为表的信息访问类：对应工作流附件类型为表格的信息表，该类封装了该表记录的各种操作，就是

59、插入或查询一条工作流附件类型为表格的具体信息，类图如下：工作流实例启动信息访问类：对应工作流实例启动信息表，该类封装了该表记录的各种操作，就是插入或查询一条工作流启动信息，查询同属于一个用户的工作流实例启动信息，更新局部字段信息，类图如下：说明：selectFinishedWorkflowInstanceStartUpInfoVO()负责查询特定用户启动的并且已经完成的工作流信息，selectNotFinishedWorkflowInstanceStartUpInfoVO()负责查询特定用户启动的并且还没有完成的工作流信息，updateWFInstFinishedFields()负责在工作流实

60、例完毕时更新特定的字段信息，updateWFInstProcessingFields()负责在工作流实例运行工程中更新特定的字段信息。工作流实例过程信息访问类：对应工作流实例过程信息表，该类封装了该表格记录的各种操作，每一条记录实际上是一个环节实例，就是插入、删除或查询一条环节实例信息，查询指定工作流实例的所有环节信息，更新局部信息字段，类图如下：说明：SetWFInstProcessingCurrentPerformerNumField()负责更新已经处理该环节实例对应的工作项的参与该环节实例的用户数目，updateWFInstProcessingFields()负责在环节实例处理过程中更新

61、特定的字段信息。工作项信息访问表：对应工作项表，该类封装了该表格记录的各种操作，就是插入或删除一条工作项信息，查询工作项信息，更新工作项信息，类图如下：说明：selectFinishedWorkItemVO()负责查询特定用户已经处理完毕的工作项信息，selectNotYetFinishedWorkItemVO()负责查询还没有处理的工作项信息，updateWorkItemFields()负责更新工作项在处理过程中的特定字段信息，isPerformedInWorkItemByUser()负责判断该工作项是否已经处理完毕。用户信息访问表：对应用户信息表，该类封装了该表格记录的各种操作，就是插入、删除或查询