基于OA系统的工作流引擎设计与实现.doc

精品文档XX大学本科学生毕业设计 基于OA系统的工作流引擎设计与实现学 生： 学 号：指导教师：专 业：计算机科学与技术XX大学计算机学院二OO八年六月I欢迎下载I欢迎下载。精品文档摘 要工作流管理系统是一个软件系统，它用于工作流的定义和管理，并按照在计算机中制定好的工作逻辑推进工作流实例的执行，实现自动传递文档、信息或者任务。工作流引擎在工作流管理系统中处于核心地位，是系统的任务调度器和资源分配器。它可以创建新的流程、基于过程模型生成工作项、支持活动的执行、分配资源以及记录工作流的相关信息。目前，工作流技术在办公自动化（Office Automation, OA）系统中的应用月来越广泛，对OA系统中的工作流引擎进行探索具有重要的应用价值。 本文结合一般的办公室办公自动化的需求，从软件生存周期的角度，使用面向对象的设计方法，给出了一个结构清晰、配置简单的工作流引擎设计方案。重点介绍来了引擎的设计与实现。该引擎借鉴了已有的工作流引擎的设计，在保证实用性的基础上，在权限和流程管理方面进行了针对性的取舍。最后给出了重要功能的部分代码，并进行了详细的描述。经过测试应用，该引擎可以支持灵活的流程定制，配置部署简单，达到了预定目标。关键词：JSP, Spring, Hibernate, Ajax , JavaScriptABSTRACTWorkflow Management System is a software system. It is mainly used for the definition and management of workflow. It makes the workflow instance executes fluently with some scheduled rules to achieve the goal that pass documents, information or tasks automanticlly. Workflow engine is the kernel of a workflow management system. It is a distributor of tasks and resources, which can create new processes, create work items based on process models, support executions of activities, and allocate resources and record information of the workflow. Nowadays, as there are more and more workflow applications in office automation, it is very important to do research in workflow fields. From the perspective of the software life cycle，this paper proposes a well-structed, easy-to-deploy workflow engine solution with the general demands for office automation, which was designed in an Object-oriented way. The designment and implementation will be focused on. This engine has referenced other engines and has done some choices on the basis of normal function. At last, an implementation is showed with detailed description of some important part.After testing, this engine is easy-to-use and meets the requirements.Keywords: JSP, Spring, Hibernate, Ajax , JavaScript目录摘 要IABSTRACT21引言51.1课题的背景与目标51.2课题研究内容及文本组织62相关技术及原理72.1工作流技术72.1.1工作流引擎核心功能72.1.2两种现有工作流引擎82.2Spring框架102.2.1Spring 声明式事务管理112.2.2Spring Web MVC143工作流引擎需求分析173.1相关概念介绍173.2总体需求173.2.1基于业务的需求分析173.2.2需求描述183.3任务实时通知183.4多种业务流程的文件存储问题193.5文件权限问题193.6业务流程的基本模式193.7用例阐述203.7.1启动流程203.7.2 挂起流程203.7.3 激活流程213.7.4 终止流程213.7.4 接收任务213.7.5 打开工作项223.7.6 保存文件223.7.7 发送文件223.7.8 挂起工作项223.7.9 恢复工作项233.7.10 驳回文件233.7.11 跟踪流程状态234设计254.1时序图254.1.1执行工作项254.1.2提交任务264.1.3实例化流程274.2数据库设计284.3流程路由机制334.4流程的控制模型344.4.1流程实例导航344.4.2工作项管理344.4.3业务文件管理344.4.4文件权限管理354.4.5任务实时通知354.5引擎类365系统实现395.1OAworkflow总体框架395.2重点功能实现395.2.1实例化流程的遍历算法395.2.2巧用Spring SimpleFormController获取表单405.2.3JSTL Core taglib和Spring bind处理表单显示415.2.4流程导航核心426总结447致谢454欢迎下载。1 引言1.1 课题的背景与目标工作流的概念起源于生产和办公自动化领域，是针对日常工作中具有固定流程的业务活动提出的一个概念。工作流管理联盟(WFMC)给出的工作流定义是：工作流是一类能够完全或者部分自动执行的经营过程，它根据一系列过程规则、文档、信息或任务能够在不同的执行者之间进行传递与执行。该技术的目的是通过将工作分解成定义良好的任务、角色，按照一定的规则和过程来执行这些任务并对它们进行监控，达到提高工作效率、降低生产成本、提高企业生产经营管理水平和企业竞争力的目标。工作流管理系统的核心部分是工作流引擎，引擎是驱动流程流动的主要部件，它负责解释工作流流程定义，创建并初始化流程实例，控制流程流动的路径，记录流程运行状态，挂起或唤醒流程，终止正在运行的流程，与其他引擎之间通讯等等工作。目前，工作流技术还处于发展曲线的初级阶段，然而，关于这方面的研究十分活跃，形成了许多规范标准。例如主要的有：工作流管理联盟（Workflow Management Coalition ，WfMC）在体系结构6、工作流相关术语7及应用程序接口8、管理控制接口9、过程语言描述10等方面提出的一系列规范。还有Microsoft, BEA, IBM, SAP等公司联合提交发布的BPEL规范等等。在实际应用中开源产品占据了重要的地位，如JBoss 项目中的jBPM、由OpenSymphony组织开发的OSWorkflow、Enhydra组织开发的Shark。在国内，上海交通大学的基于Petri网点分布是工作流管理的研究，浙江大学的基于工作流过程定义语言（WPDL）的工作流建模平台，都取得了良好的研究成果。但是工作流管理技术很多方面还不成熟，在使用过程中往往会遇到的一个重要问题是系统过于庞大复杂：一些工作流软件产品，特别是国外成熟的产品，经过多年的发展，功能强大，配置和接口多样灵活。对于国内大部分初次使用工作流技术的中小型项目来说，这些工作流软件的功能特性大大超过了需要，客户需要承受漫长的学习周期、复杂的安装配置等带来的风险。鉴于上述的原因，本课题的目标在于提出一个配置简单、使用方便、功能实用的工作流引擎的设计方案，并完成编码。该工作流引擎OAworkflow是借鉴了已有的工作流引擎，对某些复杂功能进行简化后，重新设计的。与传统工作流管理系统相比，本工作流管理系统具有以下优点：1) 支持灵活的流程定制该系统能够针对办公自动化系统中的典型流程案例对流程进行灵活定制，支持的流程路由包括：顺序路由、汇聚路由和分支路由。用户可以根据具体的业务流程，使用客户端建模工具定制合适的模型。2) 功能详细实用例如该系统支持流程分支跳转的时候，允许用户手动指定流程的直接后续步骤；当审批不合格时，文档回退的功能等。3) 文件权限设置精确该系统的每个业务流程绑定一个公文，处于流程中的各个活动对公文的读写权限看精确到字段。4) 支持可视化建模5) 结构清晰，配置简单1.2 课题研究内容及文本组织本课题的重点研究内容有：1) 模型定义。本文分析了办公自动化项目的功能需求，然后针对项目对流程控制的灵活需求，采用了一种结构清晰、功能完整的过程定义格式，使引擎在支持流程分支跳转的时候，还允许用户手动指定流程的直接后续步骤，在借鉴了现有工作流引擎设计思想的基础上，给出了一个工作流引擎的设计方案。2) 工作流引擎的实现。本文分别从流程实例化、流程实例管理、流程导航和维护相关数据等模块详细描述了实现方案，其中关于系统的关键功能部分给出了具体API语义分析。3) 技术架构。本项目采用了Spring + Hibernate 这种流行的Web应用程序设计框架组合。从而使得该引擎具有架构清晰开放的特点，系统有着清晰的分层结构。本文由以下六章和参考文献组成：第一章 引言，介绍了本课题的背景和意义。第二章 相关技术及原理，介绍了Spring 开发框架、Hibernate 数据库持久层技术、Ajax 技术、JavaScript、JSTL第三章 需求分析，给出了用例阐述及用例图第四章 系统设计，包括数据库设计、时序图等第五章 实现，重点从流程实例化、流程实例管理、流程导航和维护相关数据等模块描述了实现方案及一些关键API 的分析第六章 总结47欢迎下载47欢迎下载47欢迎下载47欢迎下载47欢迎下载47欢迎下载47欢迎下载47欢迎下载47欢迎下载47欢迎下载47欢迎下载。2 相关技术及原理2.1 工作流技术工作流的概念起源于生产组织和办公自动化领域，它是针对日常工作中具有固定程序的活动而提出的一个概念。目的是通过将工作分解成定义良好的任务、角色，按照一定的规则和过程来执行这些任务并对它们进行监控，达到提高工作效率、降低生产成本、提高企业生产经营管理水平和企业竞争力的目标。2.1.1 工作流引擎核心功能工作流引擎降低了工作流系统应用模块与业务流程之间的祸合度，当业务流程发生变化时，只需修改流程定义，具体的应用程序保持不变，工作流引擎对于用户来说是透明的。目前，工作流引擎的应用可以分为三种方式: 作为一个完整的系统提供给最终用户，能单独运行，如IBM的Lotus Domino/Notes系统。 仅仅作为企业应用集成(Enterprise Application Integration EAI)平台。EAI将进程、软件、标准和硬件联合起来，在两个或更多的企业系统之间实现无缝集成，使它们就像一个整体一样，如B2B形式的电子商务。 嵌入到企业应用中，只提供工作流引擎服务，开源领域的OS Workflow引擎即属于这种情况。从图2.1.1中可以看出，用户可以通过系统提供的客户端(如建模工具、任务列表等)与工作流引擎进行交互。从应用上来说，一个工作流引擎必须具有的核心功能包括：(1)流程实例化及执行过程模型:解释企业经营过程的流程定义，根据过程执行需要的初始条件和执行参数生成过程实例，运行过程实例并管理其运行过程。一个过程模型实际是企业经营过程的一个模板，它可以被执行多次，也可以有多个有关这个过程模型的实例在同时运行。(2)为过程和活动的执行进行导航:包括启动和终止实例，根据活动定义中的条件决定后续活动的执行顺序。(3)与外部资源交互完成业务活动:分为用户应用接口和直接调用应用接口两种情况。用户应用接口是指首先通过任务列表管理器向用户提供任务列表，供用户选择相应的任务(必要的时候可以调用相应的工具来完成)，任务完成后由用 户修改任务项的状态。直接调用应用接口是指由工作流引擎直接调用相应的应 用程序，应用将执行情况反馈给工作流引擎，如一份流转过程中的学校公文经 过校领导会签以后，系统进行归档并自动发往各相关职能部门。(4)维护工作流相关数据:工作流在执行过程中要维护不同过程和活动实例的内部状态信息，以及用于协调和恢复的各种检查数据和恢复/重起信息，向用户传递必要的相关信息。图2.1.1工作流引擎应用层次图2.1.2 两种现有工作流引擎目前，OpenSymphony组织开发的OS Workflow,和Moss项目中集成的jBPM是应用比较广泛的工作流产品，本节将对这三种引擎的设计方案和实现机制进行分析介绍。1. jBPMjBPM结合了工作流应用开发的便利性和企业应用集成能力，其业务流程是通过本身提供的流程定义语言jPDL (jBPM Process Definition Language)进行配置，但由于没有提供规范接口，从而不易于与其它工作流引擎进行交互。由于JBPM持久层采用Hibernate技术来实现，因此具有一定的可扩展性。jBPM中结合了状态图、活动图和PetriNet的知识，它采用了Token的概念，用来表示任务分配给某一个Acto叹执行者，可以是人或应用系统)的依据，即只有当某个执行者获得了一个Token，才有可能去执行任务，因此，jBPM的流程推进机制实际上表现为Token的转移。引擎在一个流程实例开始的时候产生一个Root-Token，而这个Token对象会随着流程实例运行而转移，从而来表示任务的依序执行。在此过程中，如果将一项任务分配给某个执行者，该执行者就会获得一个Token对象标识。2. OSWorkflowOSWorkflow基于有限状态机(Finite State Machine, FSM)的概念，它的每个State是通过StepID和Status联合表示，而State的转换是由动作驱动的。在工作流生命期内有至少一个或多个活动的State.OSWorkflow本身自带了一个可选的用户组织模型，该模型只提供了用户和用户组的存储，没有涉及用户的角色概念，在系统访问控制和授权方面不够完善，因此使用时通常选择配置使用自己实现的用户组织模型。OSWorkflow具有一定的灵活性，在流程建模方面不仅支持BeanShell脚本，还支持Java, BSF和EJB等，并且可以采用JDBC, Hibernate, EJB等多种数据持久化方式。1 流程建模OS Workflow采用自己的流程定义格式，其流程定义遵守的规则包括:一个工作流定义由多个步骤(Step)组成，其中每一个步骤由一个或多个动作(Action)组成，一个动作可以由用户触发执行，也可能自动运行.每个动作至少有一个Unconditional Results和零个或多个Conditional Results，如果指定了多个Conditional Results，那么第一个符合条件的将会被执行，如果没有符合条件的Conditional Result，那么Unconditional Result将会被执行。一个步骤的后续步骤有可能是其本身、一个新的步骤、一个分支结构(Split)或者一个汇合(Join)结构，当然，这些情况下工作流自身的状态也有可能发生改变。如果结果是一个分支结构，在流程定义时需要设置一个“split”属性，其值表示将要执行的分支路径的标识。相应地，一个分支结构也具有一个或多个Unconditional Results. Unconditional Results的值指向分支结构的各个不同分支。OSWorkflow流程定义文件开始部分包括的initial-actions标签里面定义的是流程的初始化动作，每个步骤(就叩)里面包含一个或多个动作(action);在每个动作里面可以手动设置pre-functions和post-functions，表示在该action执行之前或之后要执行的动作;results元素则定义了执行完该动作后的结果流向。2 流程推进机制OS Workflow的流程推进机制与通常所说的流程不同，其驱动是通过动作 (Action)的执行来进行的，其实现是分为两个步骤，一是具体实施动作，另一个是维护流程状态变迁。一个动作的执行所造成的状态改变，可能使流程从一个Step的某个Status变为另一个Status，也可能从一个Step的某一个Status变为另一个Step的Status。在状态变迁的过程中，会执行预先定义的前置和后置函数。 OSWorkflow不强调Step的概念，所有的流程推进都是通过Action的切换来表示。所以在OS Workflow的执行引擎类中，只有针对Action的迁移，而没有针对某一步骤( Step)的转换。对于工作流引擎来说，任何一种状态改变都意味着是由某个Action引起的变化结果。如果设置Action的结果为Finished，表示该Action在执行完以后的结果状态就是Finished。有限状态机的基本原则是，一个Finish状态的产生意味着流程实例中该动作的结束。OSWorkflow的流程运转和调度的核心理念是，在一个工作流程的生命周期中，总会存在至少一个或多个State;一个State到另一个State的转移 (Transition)，依赖于Action的发生。OS Workflow实现流程导航功能的算法可以描述为： 首先得到流程实例，判断其状态是否处于活动状态。根据流程定义解 析到的结果和当前步骤的id取得当前步骤。 判断当前用户是否有执行该活动的权限，然后将当前用户从当前步骤 的用户列表中删除，遍历此列表，若为空表示该步骤已经完成，进入 下一步;否则退出。 将当前步骤数据作为历史记录存入数据库。取得下一步信息，并将其 设置为当前步骤。 重复上述步骤，直至流程完成。OSWorkflow最大的特点就在于其灵活性，它实质上只是向用户提供了一个引擎核心，它的原则是由开发人员而不是由用户来设置和修改系统工作流程的配置。正是于其轻量级特性，所以可以方便的将它集成到应用系统中去。2.2 Spring框架Spring 是一个开源框架，是为了解决企业应用程序开发复杂性而创建的。框架的主要优势之一就是其分层架构，分层架构允许您选择使用哪一个组件，同时为 J2EE 应用程序开发提供集成的框架。它是一个分层架构，由 7 个定义良好的模块组成。Spring 模块构建在核心容器之上，核心容器定义了创建、配置和管理 bean 的方式，如图 2.2.1 所示。图2.2.1 Spring框架概述组成 Spring 框架的每个模块（或组件）都可以单独存在，或者与其他一个或多个模块联合实现。每个模块的功能如下： 核心容器：核心容器提供 Spring 框架的基本功能。核心容器的主要组件是 BeanFactory，它是工厂模式的实现。BeanFactory 使用控制反转 （IOC） 模式将应用程序的配置和依赖性规范与实际的应用程序代码分开。 Spring 上下文：Spring 上下文是一个配置文件，向 Spring 框架提供上下文信息。Spring 上下文包括企业服务，例如 JNDI、EJB、电子邮件、国际化、校验和调度功能。 Spring AOP：通过配置管理特性，Spring AOP 模块直接将面向方面的编程功能集成到了 Spring 框架中。所以，可以很容易地使 Spring 框架管理的任何对象支持 AOP。Spring AOP 模块为基于 Spring 的应用程序中的对象提供了事务管理服务。通过使用 Spring AOP，不用依赖 EJB 组件，就可以将声明性事务管理集成到应用程序中。 Spring DAO：JDBC DAO 抽象层提供了有意义的异常层次结构，可用该结构来管理异常处理和不同数据库供应商抛出的错误消息。异常层次结构简化了错误处理，并且极大地降低了需要编写的异常代码数量（例如打开和关闭连接）。Spring DAO 的面向 JDBC 的异常遵从通用的 DAO 异常层次结构。 Spring ORM：Spring 框架插入了若干个 ORM 框架，从而提供了 ORM 的对象关系工具，其中包括 JDO、Hibernate 和 iBatis SQL Map。所有这些都遵从 Spring 的通用事务和 DAO 异常层次结构。 Spring Web 模块：Web 上下文模块建立在应用程序上下文模块之上，为基于 Web 的应用程序提供了上下文。所以，Spring 框架支持与 Jakarta Struts 的集成。Web 模块还简化了处理多部分请求以及将请求参数绑定到域对象的工作。 Spring MVC 框架：MVC 框架是一个全功能的构建 Web 应用程序的 MVC 实现。通过策略接口，MVC 框架变成为高度可配置的，MVC 容纳了大量视图技术，其中包括 JSP、Velocity、Tiles、iText 和 POI。Spring 框架的功能可以用在任何 J2EE 服务器中，大多数功能也适用于不受管理的环境。Spring 的核心要点是：支持不绑定到特定 J2EE 服务的可重用业务和数据访问对象。毫无疑问，这样的对象可以在不同 J2EE 环境 （Web 或 EJB）、独立应用程序、测试环境之间重用。2.2.1 Spring 声明式事务管理Spring提供的事务管理可以分为两类：编程式的和声明式的。编程式的，比较灵活，但是代码量大，存在重复的代码比较多；声明式的比编程式的更灵活方便。大多数Spring用户选择声明式事务管理。这是对应用代码影响最小的选择，因此也最符合非侵入式轻量级容器的理念。这一节将要介绍Spring 提供的声明式事务管理。Spring的声明式事务管理是通过Spring AOP实现的，其中的事务通知由元数据（目前基于XML或注解）驱动。代理对象与事务元数据结合产生了一个AOP代理，它使用一个PlatformTransactionManager实现品配合TransactionInterceptor，在方法调用前后实施事务。 概念上来说，在事务代理上调用方法的工作过程如图2.2.2 所示：图2.2.2 Spring 事务代理以DataSource，mysql举例，介绍声明式的事务管理的配置与应用：onlyfun.caterpillar.IUserDAOPROPAGATION_REQUIREDTransactionProxyFactoryBean需要一个TransactionManager，由于这里使用的是JDBC，所以使用DataSourceTransactionManager，TransactionProxyFactoryBean是个代理对象，target 属性指定要代理的对象，事务管理会自动介入指定的方法前后，这里使用 transactionAttributes 属性指定，insert* 表示指定方法名称以insert开头的都要纳入事务管理，您也可以指定方法全名，如果在方法执行过程中发生错误，则所有先前的操作自动撤回，否则正常提交。在insert* 等方法上指定了 PROPAGATION_REQUIRED，表示在目前的事务中执行操作，如果事务不存在就建立一个新的，相关的常数意义都可以在API文件的TransactionDefinition接口中找到。您可以加上多个事务定义，中间使用逗号 , 区隔，例如可以加上只读，或者是指定某个异常发生时撤回操作：PROPAGATION_REQUIRED,readOnly,-MyCheckedExceptionMyCheckedException前面加上 - 时，表示发生指定异常时撤消操作，如果前面加上 +，表示发生异常时立即提交。由于userDAO被userDAOProxy代理了，所以要做的是取得userDAOProxy，而不是userDAO，IUserDAOuserDAO=(IUserDAO)context.getBean(userDAOProxy);userDAO.insert(user);申明式事务管理一般都是粗粒度的，这里可以看到，整个方法都被纳入事务管理，其实在大部分的业务处理中，这样的做法是可以接受的。2.2.2 Spring Web MVCSpring的web框架是围绕DispatcherServlet来进行设计的。DispatcherServlet的作用是将请求分发到不同的处理器。Spring的web框架包括可配置的处理器（handler）映射、视图（view）解析、本地化（local）解析、主题（theme）解析以及对上传文件解析。处理器是对Controller接口的实现，该接口仅仅定义了ModelAndView handleRequest(request, response)方法。你可以通过实现这个接口来生成自己的控制器（也可以称之为处理器），但是从Spring提供的一系列控制器继承会更省事，比如AbstractController、AbstractCommandController和SimpleFormController。1. DispatcherServlet和其它web框架一样，Spring的web框架是一个请求驱动的web框架，其设计围绕一个中心的servlet进行，它能将请求分发给控制器，并提供其它功能帮助web应用开发。然而，Spring的DispatcherServlet所做的不仅仅是这些，它和Spring的IoC容器完全集成在一起，从而允许你使用Spring的其它功能。下图展示了DispatcherServlet对请求的处理流程：图2.2.3 Spring Web MVC处理请求的工作流程2. 命令控制器Spring的CommandController是Spring MVC的重要部分。命令控制器提供了一种和数据对象交互的方式，并动态地将来自HttpServletRequest的参数绑定到你指定的数据对象上。它的功能和Struts中的ActionForm有点像，不过在Spring中，你不需要实现任何接口来实现数据绑定。首先，让我们看一下有哪些可以使用的命令控制器： AbstractCommandController 你可以使用该抽象命令控制器来创建自己的命令控制器，它能够将请求参数绑定到你指定的命令对象。这个类并不提供任何表单功能，但是它提供验证功能，并且让你在子类中去实现如何处理由请求参数产生的命令对象。 AbstractFormController一个支持表单提交的抽象控制器类。使用这个控制器，你可以定义表单，并使用从控制器获取的数据对象构建表单。当用户输入表单内容，AbstractFormController将用户输入的内容绑定到命令对象，验证表单内容，并将该对象交给控制器，完成相应的操作。它支持的功能有防止重复提交、表单验证以及一般的表单处理流程。子类需要实现自己的方法来指定采用哪个视图来显示输入表单，哪个视图显示表单正确提交后的结果。如果你需要表单，但不想在应用上下文中指定显示给用户的视图，就使用这个控制器。 SimpleFormController 这是一个form cotnroller，当需要根据命令对象来创建相应的form的时候，该类可以提供更多的支持。你可以为其指定一个命令对象，显示表单的视图名，当表单提交成功后显示给用户的视图名等等。 AbstractWizardFormController 这是一个抽象类，继承这个类需要实现validatePage()、processFinish() 和processCancel() 方法。你有可能也需要写一个构造器，它至少需要调用setPages()和setCommandName()方法。setPages()的参数是一个String数组，这个数组包含了组成向导的视图名。setCommandName()的参数是一个String，该参数将用来在视图中调用你的命令对象。和AbstractFormController的实现一样, 你需要使用命令对象（其实就是一个JavaBean， 这个bean中包含了表单的信息）。你有两个选择：在构造函数中调用setCommandClass()方法（参数是命令对象的类名），或者实现formBackingObject()方法。AbstractWizardFormController 有几个你可以复写（override）的方法。最有用的一个是referenceData(.)。这个方法允许你把模型数据以Map的格式传递给视图；getTargetPage() 允许你动态地更改向导的页面顺序，或者直接跳过某些页面；onBindAndValidate() 允许你复写内置的绑定和验证流程。3 工作流引擎需求分析3.1 相关概念介绍在进行工作流引擎的需求分析之前，先引入几个将要使用的重要概念。 流程实例，是指工作流系统处理的业务流程，每个流程实例的生命期是有限的，并且都有一个唯一标识。案例属性是一系列同案例相关的变量，能用来管理案例，它们的值可能随着案例的进展而发生变化。 活动，是指流程实例下的各个节点的描述。每个活动具有唯一标识，对应流程模型中的一个节点。它的重要属性有状态及状态改变时间。它可以对应多个工作项，但是在一个时间内只能有一个当前的工作项，当该工作项被执行后，活动状态发生相应改变。 工作项，是活动的实际执行。只要流程实例状态允许，工作项就被创建。我们可以把工作项看作是要被执行的实际工作块。 3.2 总体需求3.2.1 基于业务的需求分析该工作流管理系统用户分为流程设计员和普通用户两种。流程设计人员主要操作包括：建立流程模型、设置流程相关属性、设置用户权限、删除流程模型、修改模型、保存模型、添加用户、删除用户。流程设计人员的功能大多属于建模部分，不是本课题的范围，在此不作分析。普通用户功能基本覆盖了一个标准工作流引擎的核心功能，将是重点本文的重点阐述部分。普通用户的操作包括：启动流程实例、挂起流程实例、激活流程实例、接收任务、打开工作相、查看办公文档、发送文档等等（如图3.3.1所示）。用户通过验证登录后，通过导航菜单进入各个页面进行相关的操作。大多数用户进行的日常操作主要是与工作项有关，包括有：接收任务、打开工作项、查看文件、保存发送文件、回退文件、跟踪流程状态以及用户信息管理；对于处于开始节点的用户，除了上述的操作外，还可以启动一个流程实例，并且可以对其启动的流程进行一些控制管理，如挂起、激活、终止以及查看状态。图3.3.1 普通用户用例图3.2.2 需求描述(1) 接收任务，流程中每个活动指定人员进行办理，当流程执行到人员负责的活动时，负责人可主动查询未完成任务。(2) 打开工作项，即选择未完成任务，进入文件审批界面，进行批阅。(3) 查看文件，用户对自己经手过的文件进行查阅，不能编辑。(4) 保存发送文件，用户完成审批后提交任务。(5) 回退文件，用户审批文件时，发现前一级部门的工作不符合要求，可以把文件打回让其重新审批。(6) 跟踪流程状态，分为三种：跟踪用户自己创建的流程的状态、跟踪用户办理过的流程的状态和跟踪用户将要办理的流程的状态。3.3 任务实时通知常见的信息通知有两种驱动方式：拉和推。拉是指用户主动向服务器获取信息；推是指服务器自动将信息显示给用户。作为一个比较人性化的系统，应该具备这两种机制，尤其是对于实时性要求比较高的系统，“推”机制是一种很好的解决方案。工作流管理系统是对业务流程的管理系统，任务能实现实时通知，有助于提高流程流转速度，提高业务执行的效率。3.4 多种业务流程的文件存储问题工作流管理系统与一般的MIS系统不同，它不是为特定业务设计的，而是能够支持多种不同的业务。然而，不同业务处理的文件之间存在很大的差别。流程设计者在定制流程的同时，可以选择已存在数据库的表单，甚至可以添加表单。所以，业务文件同样具有灵活定制的需求，其数据存储结构也是该系统要解决的问题。3.5 文件权限问题文件权限问题是指流程执行者对流程绑定的文件的各个部分具有不同的读写权限。例如，在一个申请审批流程中，处于流程某个活动的部门只能对审批表中该部门负责的部分进行编辑，其他的部分不允许修改。3.6 业务流程的基本模式文献1中归纳了22中常见的工作流模式，经过对普通的办公室办公自动化需求进行分析，其中5种最基本的模式是一般业务流程中必需的：1) 顺序流向：一个步骤完成后，无条件地流向固定的下一步骤。如图3.6.1 所示：活动A活动B 图3.6.1 顺序流向2) 选择分流:一个步骤完成后，按一定的条件流向不同的下一步骤。这种情况下用户执行当前任务并提交任务后，OAworkflow寻找后续步骤，并返回让用户进行选择，以决定后续步骤。如图3.6.2 所示: 活动A活动B活动COR 图3.6.2 选择分流活动A活动B活动CAND3) 并发分流:一个步骤完成后，同时激活多个后继步骤，即多人分工同时工作的情形。当活动A完成，并提交任务后，OAworkflow将文件无条件转向活动B和C。如图3.6.3 所示：图3.6.3 并发分流4) 选择汇合:若干个步骤完成后，都流向步骤C，而只要这些步骤中有一个或多个完成了，步骤C就可以开始。活动C的任一前节点提交任务后，引擎将遍历活动C 的所有前活动实例，判断其状态，当且仅当完成的活动实例数等于活动C定义的最少通过数时，引擎才会产生一个对应活动C的工作项。如图3.6.4 所示:活动A活动B活动COR图3.6.4选择汇合活动A活动B活动CAND5) 并发汇合:若干个步骤完成后，都流向步骤C，只有当这些步骤都完成了，步骤C才可以开始。即活动C的任一前节点提交任务后，引擎将遍历活动C 的所有前活动实例，判断其状态，当且仅当所有这些活动实例都处于完成状态时，引擎才会产生一个对应活动C的工作项。如图3.6.5 所示: 图3.6.5 并发汇合3.7 用例阐述3.7.1启动流程参与者：普通用户前置条件：已经登录，运行服务中有待运行的流程。后置条件：用户启动了一个流程。步骤序列：1) 进入启动流程界面。2) 用户选择想要启动的流程。3) 系统启动选中的流程，初始化活动节点。4) 打开公文编辑页面3.7.2 挂起流程参与者：普通用户前置条件：已经登录，运行服务中有该用户启动的流程。后置条件：用户挂起了一个流程。步骤序列：1) 进入流程控制界面，列出由该用户启动并且在运行或挂起状态的流程信息，包括序号、流程名称、当前状态、启动时间。2) 用户选择想要挂起的流程。3) 系统弹出确认框，用户点击确认挂起流程4) 流程被挂起，相应状态改成“挂起”。3.7.3 激活流程参与者：普通用户前置条件：已经登录，运行服务中有该用户启动的流程，并且流程处于挂起状态。后置条件：用户激活了一个流程。步骤序列：1) 进入流程控制界面，列出由该用户启动并且在运行或挂起状态的流程信息，包括序号、流程名称、当前状态、启动时间。2) 用户选择想要激活的处于挂起状态的流程。3) 系统弹出确认框，用户点击确认激活流程4) 流程被激活，相应状态改成“执行”。3.7.4 终止流程参与者：普通用户前置条件：已经登录，运行服务中有该用户启动的流程。后置条件：用户终止了一个流程。步骤序列：1) 进入流程控制界面，列出由该用户启动并且在运行或挂起状态的流程信息，包括序号、流程名称、当前状态、启动时间。2) 用户选择想要终止的流程。3) 系统弹出确认框，用户点击确认终止流程4) 流程被终止，被终止的流程不再显示相关信息。3.7.4 接收任务参与者：普通用户前置条件：已经登录。后置条件：进入了任务列表界面。步骤序列：1) 点击导航菜单中的“接收任务”链接。2) 进入任务列表界面，列出由该用户未处理的工作项信息，包括序号、流程名称、公文名称、接收时间。3.7.5 打开工作项参与者：普通用户前置条件：已经登录，进入任务列表界面。后置条件：进入公文编辑界面。步骤序列：1) 选择要执行的任务，点击“打开”。2) 进入公文编辑界面，用户只能编辑规定的字段，其他节点的编辑的内容此时为只读状态。3.7.6 保存文件参与者：普通用户前置条件：用户已经登录，进入了公文编辑界面。后置条件：保存了经过编辑的公文内容。步骤序列：1) 点击“保存”按钮。2) 页面刷新，内容被保存。3.7.7 发送文件参与者：普通用户前置条件：用户已经登录，进入了公文编辑界面。后置条件：公文被发送到后续节点。步骤序列：1) 点击“发送”按钮。2) 系统自动保存公文