数    据    库

实习报

告

目录

一、前言

二、实习时间

三、实习内容及过程

四、实习感想或心得

五、评语

前言

21世纪是知识经济的时代，是人才经济的时代。随着21世纪的到来，人类已步入信息社会，信息产业正成为全球经济的主导产业。随着计算机技术的普及，数据信息处理技术得到空前发展，使得越来越多的人员从事于数据库操作相关的开发工作，并且不断有新人准备加入其中。

近20 年间，管理信息系统（MIS）的应用得到了迅速发展，尤其是近年来Internet技术的飞速发展，为企业建立MIS 系统提供了良好的支持环境。开发MIS 系统不仅仅是一个应用程序编写的过程，更重要的是前期的系统分析和设计阶段所做的工作。本书以多个实用的中小型信息管理系统为基础，严格地按照软件工程的思想，详细讲述如何利用Visual C++ 在应用程序开发上灵活和效率高的特点来开发管理信息系统。

系统开发主要包括后台数据库的建立和维护以及前端应用程序的开发两个方面，实现物资管理数据库的创建及物资信息的输入、删除、修改、查询和入、出物资信息的统计，使得系统具有功能强大、界面友好的特点。本系统主要完成对物资基本信息的管理、物资入库信息管理、物资出库信息管理、物资余额信息管理等六个方面。系统可以完成对各类物资信息的浏览、查询、修改、删除、等功能。系统的核心是数据库与应用程序用数据源的连接。此外，系统用完整的用户登录、用户添加、用户删除和修改密码功能。

管理信息系统就是我们常说的MIS（Management Information System），在强调管理，强调信息的现代社会中它越来越得到普及。MIS 是一门新的学科，它跨越了若干个领域，比如管理科学、系统科学，运筹学、统计学以及计算机科学。在这些学科的基础上，形成信息收集和加工的方法，从而形成一个纵横交织的系统。

在本次实习中，在老师和同学的指导下，设计了典型的酒店业务管理系统以及物资管理系统所要完成的功能，对各个功能进行分析和设计。

一、实习时间

实习时间：3周（12/12----12/30）

实习地点：南苑2号教学楼203教室

实习单位：中原工学院

部门： 经济管理学院

实验环境：Windows2000 和SQL Server2000

任    务：完成《物资管理系统》和《酒店业务管理系统》的分              析设计工作，并选用适当的开发工具完成系统的开发。

指导老师：王小黎、刘克兴

实习目的和要求：通过实践使学生经历一个数据库系统开发的全过程，并受到一次综合的训练，以便能较全面地理解、掌握和综合运用所学的知识去分析、解决实际问题。

二、实习内容及过程

以物资管理信息系统的设计为例，物资管理信息系统的内容及程：

1)        系统设计

系统开发的总体任务就是实现物资信息的系统化、规范化和自动化。系统功能分析是在系统开发总体任务的基础上进行的。本例中的物资管理信息系统需要完成的主要功能有：

²  有关物资基本信息的输入，包括物资编号、物资名称、规格型号、种类和计量单位等。

²  物资基本信息的查询与修改。

²  入库物资基本信息的输入与查询。

²  入库物资基本信息的修改与输入。

²  出库物资基本信息的查询与修改。

²  物资余额信息的查询与浏览。

2)        数据库设计

a、 数据库需求分析

用户的需求具体体现在各种信息的提供、保存、更新和查询等方面。这就要求数据库结构能充分满足各种信息的输入和输出。收集基本数据、数据结构以及数据处理的流程，组成一份详尽的数据字典，为下一步的数据库具体设计做好充分的准备。

b、数据库概念结构设计

设计物资管理信息系统的E-R图：

c、 数据库逻辑结构设计

现在需要把上面设计好的数据库概念结构转化为SQL Server 20## 数据库系统所支持的实际数据库模型，也就是数据库的逻辑结构。

3)        数据库结构的实现

在 SQL Server 20## 数据库系统中，实现上面设计的数据库逻辑结构。这一步是利用SQL Server 2000数据库系统中的SQL 查询分析器实现的，此时开始用SQL语言创建系统用户、物资基本信息、入库物资信息、出库物资信息、物资余额信息等五个表格。

4)        物资管理信息系统主窗体的创建

下面通过物资管理信息系统中各个功能模块的实现来实现用Visual C++ 6.0来编写数据库系统的客户端程序。

a、 创建工程项目——Material_MIS

b、创建主窗体菜单

c、 创建公用模块

5)        模块的创建

a、用户管理模块

主要实现如下功能：

²  用户登录。

²  添加用户。

²  修改用户密码。

b、物资基本信息管理模块主要实现如下功能：

²  添加物资基本信息。

²  修改物资基本信息。

²  删除物资基本信息。

²  查询物资基本信息。

6)   系统的实现与发布

系统的实现：

参考随书附带光盘中附带的代码，添加好所有代码后，开始编译之前，需要设置好数据源，这样才能保证程序中所有针对数据库的操作有效。单击“测试数据源”按钮，进行数据源测试。测试成功后，选择菜单添加信息，并且做进一步的查询操作。

系统的发布：

如果在上面对系统的操作中都没有出现错误，想要发行这个系统，需要更改一下编译模式，选择Project|Settings，在出现的对话框中左边部分的Settings for 中选择Win32 Release，如图11-56 所示。单击“OK”按钮，保存设置。 设置好编译模式以后，按F7键，进行编译。经过上面两次编译，在C:\VC\06 目录下面已经有了两个文件夹，Debug 文件夹和 Release文件夹。进行发布时，只需要发布 Release文件夹中的Material_MIS.exe文件，但是在使用这个系统的同时需要设置相应的数据源，才能够保证这个系统正常运行，按照前面介绍的方法把数据源设置为Material_MIS，双击Material_MIS.exe文件，就可以运行这个系统了。

实习体会

一年多的大学生活，让我对计算机理论知识有了一定的了解，但实践出真知，唯有把理论与实践相结合，才能更好的运用所学的知识。

这个星期是我们SQL Server 数据库管理课的实训，经过一个星期的实训，让我领会到了许多平时课堂上所没有接受的课外知识，很让人受益匪浅，懂得如何去运用，而进行的一次分析设计综合的训练。而本次实训的目的是让我们掌握数据库系统的原理、技术。将理论与实际相结合，应用现有的数据库管理系统软件，规范、科学地完成一个设计与实现。

实训课是在学习与探索中度过的，短暂的一星期实训是结束了，但其中让我们学到了许多知识，出现许多未知的为什么，如仓库管理数据库的初步设置、数据备份与还原的步骤，如何建立视图、触发器等一系列的问题，正是在老师和同学的共同努力之下，我们才一步步把问题解决了，最终完成了不可能完成的任务

在此次实训中，除了让我明白工作中需要能力，素质，知识之外，更重要的是学会了如何去完成一个任务，懂得了享受工作。当遇到问题，冷静，想办法一点一点的排除障碍，到最后获取成功，一种自信心就由然而生，这应该就是工作的乐趣。有时候不懂的就需要问别人了，虚心请教，从别人的身上真的能学到自己没有的东西，每一次的挫折都会使我更接近成功。还有学会了在工作中与人的合作与交流，同乐同累，合作互助，这是团体的精神，也是必须学习的东西。

第二篇：1前言如果数据库系统(

1.前言：如果数据库系统（ database systems）像受人尊敬的智者讲述的条理清晰的故事，那么工作流（workflow）就像一群乳臭未干的小子在大谈各自的“哲理”。之所以这样讲，我是想指出，工作流系统 （workflow management systems）还处于技术发展曲线（ technology hype curve ）上的初级阶段。在这个领域我们将面临一个激动人心的阶段。为了描述这一点，可以和关系数据库系统（RDBMS）做一个对比。当在软件开发团队中谈论RDBMS时，大部分人会有一个清晰的概念，在你和他们交流的时候，人们会通过轻微的点头表示认可或理解你所说的。可当使用工作流术语讨论工作流时，他们会摇头表示不同意，因为每个人对工作流术语都有不同的理解。

导致形成这种状况的原因之一，是在工作流中使用了过多的概念。在这个领域中的大量规范和工具没有一个是相似的。当然，它们相互之间有重叠并且会相互参考引证。

在介绍工作流时有一个话题必须包括，那就是工作流和业务流程管理（BPM）的关系。术语“工作流”通常描述人与计算机系统的一系列相关交互。在开发人员中，工作流经常被提及。有时，工作流的意思是指一些不同的UI界面。业务流程管理的范围比较广，相比之下工作流多半局限于技术领域。业务流程管理还从管理人员的角度涉及了非技术问题，比如分析、组织的效率。

在本文中，我首先解释什么是工作流管理系统，然后介绍业务流程管理的优点。接下来描述一下为什么工作流市场乍看起来如此混乱。本文给出的主要结论是：选择工作流系统是想用工作流系统的公司，将要面对的最困难的事情。为此，本文的核心部分描述了一个流程定义（process definition）的四个层次，为你选择工作流提供一个基础。本文还用中立的语言描述了工作流和BPM的通用概念。最后，给出了一些规范和工具的指导性描述。

2.什么是工作流管理系统（WFMS）

定义

工作流系统是以规格化的流程描述作为输入的软件组件,它维护流程的运行状态,并在人和应用之间分派活动。

1

为了后面的描述，我们先定义一些基本的术语：流程定义（process definition）和流程实例（process instance）. 一个流程定义是一个业务流程或过程的规格化描述。一个流程实例是流程定义的一个运行实体。 都目前为止，概念还比较清晰是不是？但当再深入一步时，我们就要小心使用文字了。如何阐述流程中的步骤，现在还没有一个统一的方式。这是各种工作流规范和工具之间主要的分歧。

为什么应当禁止使用术语“活动（activity）”...

流程定义通常用一些活动表述。我认为这是导致工作流领域所有混乱的主要原因。我告诉你为什么：因为术语“活动”混淆了状态（state）和动作（action）之间的差异。在流程中，状态 (或者说等待状态)代表了一种对外部参与者（actor）的依赖。在流程运行时，这意味着流程引擎必须等待，直到外部参与者通知工作流管理系统指定的状态完成了。比如，等待可进一步运行的认可。动作 是在流程运行过程中，工作流系统为响应指定事件（event）运行的一段程序逻辑（programming logic）。当流程运行过程中指定的事件发生时，工作流系统启动并执行这些动作。比如，当状态分配给一个参与者时，发一封Email。你也能看出，状态和动作是如此不同，因此使用同样的术语去描述这些概念是一个坏习惯。我的建议是避免使用术语“活动”，使用“状态”或者“动作”代替它。

工作流系统另一个重要的职责是维护每一个流程运行的上下文信息。 流程上下文变量（process context variable） ，或简称变量，是与流程实例相关的变量。如，休假申请的开始日期、数据库中一条记录的键值、文档管理系统中一篇文档的索引等。通常在流程定义中声明这些变量，然后在流程实例生成时，这些流程变量被实例化。所有成熟的工作流管理系统都支持定制的变量类型。

目标领域（Target usage）

使用工作流管理系统的目的之一是作为企业应用系统集成（EAI）的平台。在当前大部分企业级IT架构中，各种各样的异构（heterogeneous）应用和 2

数据库运行在企业内网中。在这些系统被应用到组织时，都有一个清晰的目标。例如，客户管理、文档管理、供应链、订单、支付、资源计划等等。让我们称这些系统为专门应用（ dedicated applications）。每一个专门应用都包含它们所支持业务流程的领域知识。这些专门应用中的自动化流程，被拼装到企业中更大的非自动化流程中。每当一个这样的专门应用安装并投入使用，都会带来涉及其他多个应用的新功能需求。企业应用系统集成（EAI）就是通过使用多个专门应用满足软件新需求的方法。有时，这只需要在两个应用之间提供数据通讯的通道。专门应用将很多业务流程硬编码在软件中。可以这么说，在你购买专门应用时，你是购买了一组固定的自动化业务流程。而工作流管理系统是不必事先知道问题域的相关信息的。工作流系统将业务流程描述作为输入并管理流程实例的执行，这使得它比专门应用更灵活（当然你也要花精力编写业务流程的规格化描述）。这就是为什么说工作流系统和专门系统是相互补充的。工作流系统可以用来管理全局的业务流程。如果专门应用支持你所需要的业务流程，那么使用专门应用。在此讨论的工作流系统的第一种使用方式就是：结合所有的专门应用，使用工作流系统构建一个EAI平台。

工作流系统能够发挥很大价值的第二个使用方式是：协助涉及多人相关任务工作流软件的开发。为了达到这个目的，大部分工作流系统都有一个方便的机制，来生成执行任务的表单。对于专注于ISO 或者 CMM认证的组织，采用这种方式使用工作流系统能够显著提高生产率。 不用将过程用文字的形式写在纸上，工作流系统使你通过流程定义建模实现过程的自动化（如使用基于Web的应用）。

工作流系统的第三种使用方式是：将工作流引擎嵌入到其他应用中。在前面我们谈到，专门应用将指定问题域相关的业务流程固化在软件中。开发专门应用的公司也可以将工作流引擎嵌入到他们的软件中。在这里，工作流引擎只是作为一个软件组件，对于应用的最终用户是不可见的。将工作流引擎嵌入到应用中的主要原因是为了重用（不重复发明轮子）和应用软件的可维护性。

The case for workflow

3

对于引入工作流的组织，能够在软件开发和业务两个层次受益。 方便开发

工作流管理系统能够简化企业级软件开发甚至维护。

? 降低开发风险 - 通过使用状态和动作这样的术语，业务分析师

和开发人员使用同一种语言交谈。这样开发人员就不必将用户需求转化成软件设计了。

? 实现的集中统一 -业务流程经常变化，使用工作流系统的最大好处是：业务流程的实现代码，不再是散落在各种各样的系统中 。

? 加快应用开发 - 你的软件不用再关注流程的参与者，开发起来

更快，代码更容易维护。

业务流程管理 (BPM)

在自动化业务流程之前，分析并将它们规格化是一件艰苦但会有很好回报的工作。e-workflow.org对于分析流程能够带了的益处有不错的阐述：

?

? 提高效率 - 许多流程在自动化过程中会去除一些不必要的步骤 较好的流程控制 - 通过标准的工作方法和跟踪审计，提高了业

务流程的管理

? 改进客户服务 - 因为流程的一致性，提高了对客户响应的可预

见性

? 灵活 - 跨越流程的软件控制，使流程可以按照业务的需要重新

设计。

? 业务流程改进 - 对流程的关注，使它们趋向于流畅和简单

我认为他们还遗漏了一个使用工作流系统最重要的因数：提高对迭代开发的支持。如果软件中业务流程部分不容易更改，组织就会花很大的精力在开发前的业务流程分析中，希望一次成功。但可悲的是，在任何软件项目开发中，这 4

都很少能实现。工作流系统使得新业务流程很容易部署，业务流程相关的软件可以一种迭代的方式开发，因此使用工作流系统使开发更有效、风险更低。

缺失的一环（Missing link）

我确实认为工作流系统是企业应用开发中缺失的一环。将企业业务流程逻辑在企业级软件中实现的缺省方式是分散的。这意味着业务流程逻辑散布在各种系统中，如EJB、数据库触发器、消息代理等等。这样得到的软件难于维护，结果，企业只能将改变业务流程软件作为最后的选择。他们经常能够做的是，改变流程以适应软件。上述问题也适用于采用大型外部ERP软件包的企业。进一步，假设我们认识到这个问题，并打算将一个流程相关的代码都集中起来。对于一个流程来说这很不错，但当你要实现多个流程时，你会看到管理状态和流程变量的代码被到处复制。最后，我们会整理这些代码放到一个集中的库中。好，...这就是一个工作流管理系统了，不用费心自己来实现，你可以从本文后面的列表中选择一个。

A closer look

WFMS interfaces

一个工作流管理系统以流程定义作为输入。在这里，可以将流程定义看作UML活动图、UML状态图或者有限状态机。在提交一张费用单据、申请休假、要求一个报价、...之后，工作流系统负责维护这些流程定义的执行状态和上下文。为此，需要通知工作流系统状态的变化。运行流程的状态变化可以记录下来，以备监控管理。

? 定义 工作流系统的定义接口使流程开发人员能够部署流程定

义。注意，这里的“流程开发人员”可以是业务分析师和软件开发人员的组合。

5

圈套（Pitfall）

许多工作流管理系统的开发商想使你相信，通过使用他们的图形化流程开发工具，只要业务分析师就可以生成流程定义。这种幻想源于“编程很难”这样的事实。开发商的销售人员喜欢说“看，你不用写一行代码”。不用写代码是好事，可大部分开发商在这点上走的太远，忽略了在某些场合提供一种将代码集成到流程定义中的机制是很适合的。在将工作流系统作为EAI平台时，必须在流程中集成代码。开发流程定义需要业务分析师和软件开发人员的合作。一个好的图形流程设计工具应该能够支持这种合作。

? 执行 执行接口使用户和系统可以操作流程实例。流程实例是

流程定义的执行。流程定义的控制流通过状态机描述。执行接口的两个主要方法是启动一个流程实例和通知工作流系统一个状态结束了。

? 应用 应用接口代表了由工作流系统发起的工作流系统和外

部系统之间的交互。当一个用户或系统操作一个流程实例的运行时，会生成一些事件（如一个迁移的执行）。流程定义中可以指定一段响应一个事件的可执行代码逻辑，这段代码和组织内外部的其他系统打交道。

? 监控 管理人员通过监控接口获得流程运行的确切数据。有时，运行日志也可用于审计。

这些是WfMC参考模型（reference model of the WfMC ）中定义的五个接口中的四个。

流程定义的四个层次

在下面这部分，我尝试回答这样的问题“什么是流程定义包括的内容？”。这是从各种规范和工具所使用模型的原则和概念中总结得来的，反映了大部分模型中通用的基本思想。流程定义的内容可以分为四个不同的层次：状态 6

（state）、上下文（context）、程序逻辑（programming logic）和用户界面（UI）。

状态层

所有状态和控制流的表述，都属于业务流程的状态层。标准编程语言中的控制流来源于Von Neuman体系。控制流定义了必须被执行的指令的顺序，控制流由我们书写的命令、if语句、循环语句等确定。在业务流程中的控制流基本与此一致。但在业务流程中不是使用命令而是使用状态作为基本元素。

在流程中，状态 (或者说等待状态)代表了一种对外部参与者（actor）的依赖。状态的意思就像“现在X系统或某某人必须作某些事，在此等待直到参与者通知这些任务已完成”。状态定义了一种对外部提供结果的依赖。状态典型的例子是批准步骤（step）。

流程定义中的状态也指定了执行依赖于哪个参与者。在活动图中，泳道（swimlanes）的标注代表这些参与者的名字。工作流系统使用这些信息构建任务列表，这是一般工作流系统都有的功能。如前所述，参与者可以是人也可以是系统。对于需要人参与的状态，工作流系统必须在运行时计算出具体的个人。这样的计算使工作流系统必须依赖于组织结构信息。关于这方面的一篇非常有趣的文章是在 further reading section 提到的“工作流应用中的组织管理”（ 'Organizational Management in Workflow Applications'）。

流程定义的控制流包含一组状态和它们之间的关系。状态之间的逻辑关系描述了哪些执行路径可以同时执行，那些不可以。同步执行路径用分叉（forks）和联合（joins）建模，异步执行路径用判断（decisions）和合并（ merges）建模。注意在大多数模型中，在每个状态之前都有一个隐式合并。

UML活动图经常被用来做业务流程建模。作为一种直观和通用的表达，活动图在图形表述上有一个主要问题，就是没有区分状态和动作，它们都用活动来表示。缺少这种区分（导致状态概念的缺失）是学术派对UML活动图的主要批评。UML活动图的第二个问题是在UML2.0版中引入的。当多个迁移（transitions） 7

到达一个活动时，以前的版本规定这是一个缺省合并（merge），在2.0版中规定这是一个需要同步的缺省联合（join）。在我看来，UML活动图的图形部分仍旧可以用来对业务流程状态层次建模，只要使用时对两条构建语义作如下的变化：

1. 在用图形表述业务流程时，只建模状态层（状态和控制流），不

要包括动作。这意味着图形中的矩形都是状态而不是活动

2. 如果多个迁移到达一个状态，缺省定义为不需要同步的合并

（merges）

在流程运行过程中，工作流系统用一个令牌（token）作为指针跟踪流程的状态。这相当于Von Neuman体系中的程序计数器。当令牌到达一个状态时，它被分配给工作流系统等待的外部参与者。外部参与者可以是个人、组织或者计算机系统。我们定义流程运行的执行人或系统为“参与者”（actor）。只有在工作流系统将令牌分配给一个参与者时，才需要访问组织结构信息。工作流系统通过分配令牌构建任务列表。

上下文层

流程上下文变量（process context variable） ，或简称变量，是与流程实例相关的变量。流程开发人员可以使用流程变量存储跨越流程实例整个生命周期的数据。一些工作流管理系统有固定数目的数据类型，另一些你可以定义自己的数据类型。

注意变量也可以用来存放引用（ references）。一个变量可以引用如数据库中的记录、网络上的文件。什么时候使用引用，取决于使用引用数据的其他应用。

和流程变量相关的另一个令人感兴趣的方面是：工作流系统如何将数据转化为信息。工作流是用于组织内部跨越各种异构系统实现任务和数据协同的。对于业务流程中人工执行的任务，工作流系统负责从其他相关系统，如SAP、数据库、CRM系统、文档管理系统收集数据。在业务流程的每一个人工步骤，只有 8

相关联的数据项被从异构系统中收集和计算。通过这种方式，从不同系统来的数据被转换并展现为信息。

程序逻辑层

如前所述，动作是在流程运行过程中，工作流系统响应指定的事件（event）执行的一段程序逻辑（programming logic）。程序逻辑可以是二进制或源代码形式的、用任何语言或脚本编写的软件。程序逻辑层是所有这些软件片断和关于在什么事件发生时调用它们的信息的组合。程序逻辑的例子包括发Email、通过消息代理发消息、从ERP系统中拿数据和更新数据库。

用户界面层

一个参与者通过向流程变量中填充数据的事件，来触发结束一个状态。比如，在请假的例子中，老板提供“同意”或“不同意”数据到流程中。某些工作流系统允许指定哪些数据可以填充到流程中，以及它们如何在流程变量中存储。通过这些信息，可以生成从用户收集信息的UI表单。基于流程定义生成用户提交表单的Web应用例子，可以访问 the jBpm online demo 。

工作流全景

可执行流程与工作流管理系统的比较（Executional processes versus a WFMS）

当前在BPM领域中，关于可执行业务流程的规范有趋向于统一集中的趋势。 XLANG, WSFL 和BPML合并为基于交互（消息交换）的BPEL。BPEL在面向服务体系结构(SOA)的大背景下定义。它的前提条件之一是涉及的服务必须用WSDL声明。BPEL规定了一套XML语法，这套语法可以看作一种编程语言，用来描述包括对WSDL定义的服务调用的控制流。

在可执行业务流程和基于状态的工作流管理系统所使用的方法中，我注意到了三点主要的区别：

9

? 基于状态的工作流系统以状态（或者活动）概念为中心。工作流引擎维护状态并计算从一个状态到另一个状态的迁移。另一方面，像BPEL这样的可执行流程以对输入消息响应的定义为中心。一组这些响应外加其他信息（other bells and whistles）可以看作一个业务流程。这也解释了为什么BPEL可以看作是对基于状态的工作流系统的某些方面的补充。一个响应输入消息的BPEL onMessage事件处理器，可以在工作流状态之间的迁移中执行。

? 自消息相关性的处理。流程描述的一部分必须说明BPEL引擎如何从输入消息中确定具体流程的标识。这必须基于输入消息的一个数据项。而工作流系统在每个流程实例生成同时生成了实例ID，客户端在后续调用引擎API时使用这个ID。

? ：工作流系统提供一组集中的API，客户端通过调用API完成与所有流程实例的交互。在可执行业务流程中，每个流程表现为一个服务。这意味着对于每个流程定义都有一个不同的访问点。 3.JBPM流程介绍

Jbpm工作流可以实现非常复杂的工作流程，并且它是开源的免费的，而且是便于维护的，

例如用jbpm来实现一个拍卖流程如下：

10

其设计样式如图所示，其XML描述为

<process-definition>

<start-state>

<transition to="auction" />

</start-state>

<state name="auction">

<transition name="auction ends" to="salefork" /> <transition name="cancel" to="end" />

</state>

<fork name="salefork">

11

<transition name="shipping" to="send item" /> <transition name="billing" to="receive money" /> </fork>

<state name="send item">

<transition to="receive item" />

</state>

<state name="receive item">

<transition to="salejoin" />

</state>

<state name="receive money">

<transition to="send money" />

</state>

<state name="send money">

<transition to="salejoin" />

</state>

<join name="salejoin">

<transition to="end" />

</join>

<end-state name="end" />

</process-definition>

流程图由节点和转换组成.

12

每个接点有一个指定的类型. 节点类型定义当执行到达这个节点的时候将发生什么. jBPM 有一套你可以使用的预实现的节点类型.另外,你可以编写自己的定制代码实现你自己的指定的节点行为.

每个节点有2个主要责任: 首先,它可以执行传统java代码. 典型的传统java代码同节点功能相关. 比如.建立一个新的任务实例, 发送一个通知, 更新数据库,.其次,节点服务传播流程执行.基本上来说,每个节点有下列可选的传播流程执行:

?

? 1. 不传播执行. 节点的行为是作为一个等待状态. 2.通过执行节点的一个离开转换来传播执行. 令牌到达节点是

通过一个离开转换API executionContext.leaveNode(String). 现在节点作为可执行一些定制程序逻辑及不用等待连续流程执行的自动节点.

? 3. 建立新的执行路线. 节点可以决定建立新的令牌.每个新令

牌表示一个执行的新路线并且没个新令牌可以通过节点的离开转换被调用.一个很好的例子就是fork(分支)节点模式的行为.

? 4. 结束执行路线. 节点可以决定结束执行路线.令牌可以结束,

也就表示着执行完成了.

? 5. 更加一般的,节点可以修改流程实例的全部的运行时间结构 . 运行时间结构是包含令牌树的流程实例.每个令牌表示一个执行路线. 节点可以建立和结束令牌,把每个令牌放在图的节点里并且通过转换来调用..

节点类型 task-node

任务型接点代表一个或多个可以被人执行的任务. 当执行到达一个任务节点,任务实例将在工作流参与者任务清单中被建立. 这之后,节点将作为一个等待节点. 因此当用户执行他们的任务,任务完成将触发执行继续开始. 换句话说,令牌将调用一个新的信号.

13

节点类型 状态(state)

状态是一个单纯(bare-bones)等待状态. 任务节点的不同是没有任务实例在任何任务清单中建立. 这在流程等待外部系统的时候很有用. 比如.以上的节点入口(通过一个在node-enter事件的动作),一个消息将被送到外部系统. 在这之后, the process will go into a wait state. When the external system send a response message, this can lead to a token.signal(), which triggers resuming of the process execution.

节点类型 决策(decision)

实际上有两个方法模拟决策. 明显的区别在于基于"谁"来做决策. 或者有流程来做决策 (读: 在流程定义中指明. 或者用外部的实体提供决策结果.

当有流程来做一个决策的,就要使用一个决策节点了. 有两个基本方式来指明决策的标准.最简单的方式是给转换增加一个条件元素. 条件是返回结果是boolean的beanshell脚本表达.在运行时间决策代码会被离开转换反复调用(按照XML指定的顺序),来评估每个条件. 第一个转换在条件是'true'的时候发生. 可选的, 用一个DecisionHandler的实现. 在java class中决策被计算并且被选择的离开转换由DecisionHandler 实现的决策方法(decide-method)返回.

当决策是由外部部分决定(含义:不是流程定义的一部分), 你可以用多个转换离开状态或等待状态节点. 然后离开转换可以提供外部的触发在等待状态完成后继续执行.比如 Token.signal(String transitionName) and

TaskInstance.end(String transitionName).

节点类型 分支(fork)

一个分支把一个执行路线分割成多个兵法的执行路线. 默认分支的行为是为每个离开分支转换建立一个子令牌,在令牌要到达的分支之间建立一个父母-子女 关系.

14

节点类型 联合(join)

默认联合(join)假设所有来自同一个父母的子令牌联合.当在上使用

fork(分支)这个情形就出现了并且所有令牌分支建立,并且到达同一个联合

(join).当全部令牌都进入联合的时候,联合就结束了. 然后联合将检查父母-子女. 当所有兄弟令牌到达联合(join),父母令牌将传播(唯一的)离开转换. 当还有兄弟令牌活动时,联合的行为将作为等待状态.

节点类型 node

类型节点是你想写在节点中写你自己的代码. 节点类型节点期望一个子元素动作.动作(action)在执行到达这个节点时候被执行. 你在actionhandler所写的代码可以做任何事情除了它必须负责 传播执行.

如果你想使用来实现一些对业务分析员来说非常重要的功能逻辑,可以使用节点..当使用节点时,节点在流程图形表示里是可见的.为了对照, 动作

(actions) --覆盖着文本-- 允许你加入在图形化流程里看不到的对业务分析员不重要的代码 .

动作(Actions)

动作是一段java代码,在流程执行有事件时执行. 图在软件需求社区是重要的指示.但是图只是将要生产的软件的一个视图(投射).它隐藏了技术细节. 动作是在图形化表示之外加入技术细节的机制.当一个图被放置,它可以用动作来装饰. 这就是说java 代码可以在不修改图结构的情况下和图关联起来. 主要的事件类型是进入节点entering a node,离开节点 leaving a node 和执行转换taking a transition.

注意事件中的动作和节点中的动作的不同. 事件中的动作当事件发生的时候才执行.事件中的action没有方法影响流程的控制流.可以参考以下观察者的设计模式. 另一面,节点里的action有 递执行的责任.

15

我们看看事件中的动作. 假定我们想在给定的转换上做数据库更新.数据库更新技术上是极其重要的,但对业务分析员来说是不重要的.

事件(Events)

事件指明流程执行的时刻. jBPM 引擎在图执行时会产生事件. 这发生在当jbpm 计算下一个状态(请看: 生成信号). 事件总是同一个流程定义中的元素相关,比如流程定义,节点或转换.绝大多数流程元素能产生不同类型的事件. 举例的节点可产生 node-enter(节点进入)事件和 和一个节点离开 node-leave事件 .事件是同动作挂钩的. 每个时间有一个动作清单.当jBPM引擎产生一个事件,动作清单就会被执行.

事件传送Event propagation

超状态根据流程定义生成一个父母-子女关系. 节点和转换包含在一个以超状态为父母的超状态里. 最顶级的元素以流程定义作为父母. 流程定义没有父母.当事件被生成, 事件将被向上传送到父母层.这允许在一个流程中一个中心可以捕捉所有的转换事件和同这些事件关联的动作.

Script

脚本是动作执行的beanshell脚本. 更多有关beanshell参看 the beanshell website . 默认的所有流程变量作为脚本变量script-variables和非脚本变量no script-variables 被写到流程变量process variables. 所有可用的脚本变量:

?

?

?

?

? executionContext token node task taskInstance

<process-definition>

16

<event type="node-enter">

<script>

System.out.println("this script is entering node "+node); </script>

</event>

...

</process-definition>

定制载入和储存到脚本的默认行为, variable 元素可以被用做为脚本子元素.在这个case, 脚本表达式也被放入脚本子元素: expression.

<process-definition>

<event type="process-end">

<script>

<expression>

a = b + c;

</expression>

<variable name= 'XXX' access= 'write' mapped-name = 'a' />

<variable name='YYY' access='read' mapped-name='b' /> <variable name='ZZZ' access='read' mapped-name= 'c' /> </script>

</event>

...

</process-definition>

在脚本开始之前,流程变量 YYY 和 ZZZ 将分别作为脚本变量b和c可用. 当脚本完成后, 脚本变量的值被储存进流程变量 XXX.

17

如果变量的 access属性包含 'read ', 流程变量可以在评估之前载入作为脚本变量. 如果 access属性包含 'write ', 在评估之后脚本变量被存储为流程变量. 属性 mapped-name可以使流程变量在脚本中用另外一个名字被访问 . 这在你的流程变量包含空格或其他非法的文字字符.

流程组成Process composition

流程组成在jBPM被支持意味着 process-state .流程状态是同另外流程定义有联系的状态 .当图执行到达流程状态,sub-process的流程实例被建立并且他是同到达的流程状态的执行路线相关联. 超级流程的执行路线将会等待直到子流程实例结束. 当子流程实例结束是,超级流程的执行路线将离开流程状态继续在超级流程里图执行.

<process-definition name="hire">

<start-state>

<transition to="initial interview" />

</start-state>

<process-state name="initial interview">

<sub-process name="interview" />

<variable name="a" access="read,write" mapped-name="aa" /> <variable name="b" access="read" mapped-name="bb" />

<transition to="..." />

</process-state>

...

</process-definition>

这个'hire' 流程包含 process-state, 跨越了子流程'interview'. 当执行到达'first interview',一个新的执行(= 流程实例)来自最后版本的

'interview' 流程被建立. 然后变量'a' 从hire流程被复制到变量interview 流程里的'aa'. 同样的方式, hire 变量 'b'也被复制到interview变量'bb'. 18

当interview流程完成, 只有interview流程里的变量 'aa' 被复制回了hire流程的变量a.

一般来说, 当子流程开始时, 所有 variables 有 read 访问属性的从超级流程被读出来并添入新建立的子流程,在离开start start产生信号之前. 当子流程实例完成是,所有 variable s有 write 属性的将从子流程复制会超级流程 . 变量的 mapped-name 元素允许你指明子流程中使用的变量名字.

4.JBPM上下文

4.1存取变量

org.jbpm.context.exe.ContextInstance 作为提供流程变量服务的中央接口. 你可以从ProcessInstance 获得ContextInstance:

ProcessInstance processInstance = ...;

ContextInstance contextInstance = (ContextInstance)

processInstance.getInstance(ContextInstance.class);

最基本操作是

void ContextInstance.setVariable(String variableName, Object value);

void ContextInstance.setVariable(String variableName, Object value, Token token);

Object ContextInstance.getVariable(String variableName);

Object ContextInstance.getVariable(String variableName, Token token);

变量名字是java.lang.String. By default, jBPM 支持下列变量类型:

?

?

?

java.lang.String java.lang.Boolean java.lang.Character 19

?

?

?

?

?

?

?

?

?

? java.lang.Float java.lang.Double java.lang.Long java.lang.Byte java.lang.Short java.lang.Integer java.util.Date byte[] java.io.Serializable classes that are persistable with hibernate

要配置jBPM 保存hibernate 永久化对象到变量里,参看保存hibernate永久化对象.

4.2 变量的生命周期

变量必须在流程档案里声明.在运行时间,你可以把任何java object放到变量里. 如果一个变量不存在,将会被建立.同传统的 java.util.Map一样.

变量可被删除

ContextInstance.deleteVariable(String variableName);

ContextInstance.deleteVariable(String variableName, Token token); 已知不足: 类型自动转换目前不支持. 这表明不允许用不同类型的值来覆盖变量. 要想这样做,必须首先删除老变量.当然用同类型的值覆盖是允许的.

4.3 变量永久化 Variable persistence

变量是流程实例的一部分. 保存流程实例到数据库,保持数据库同流程实例同步.作为保存或更新流程变量在数据库中的结果变量从数据库被建立 ,更新和删除 .更多信息。

4.4 变量范围Variables scopes

20

每个执行路线(参看: 令牌) 有它自己的一套流程变量. 变量请求总是在令牌上发生. 流程实例有令牌树 (参看 面向图的程序设计 ). 当请求一个变量没有指明令牌, 那么默认的令牌是根令牌.

变量查询递归到给定令牌的父母令牌. 这个行为同程序开发语言里的变量范围是相似的.

当在令牌上设置不存在变量,那么变量就在根令牌root-token上被建立 .这就是说每个变量默认就是整个流程范围. 如果想建立一个令牌的局部变量,必须显式的使用API:

ContextInstance.createVariable(String variableName, Token token);

4.5 定制变量永久化 Customizing variable persistence

变量保存在数据库中有两个步骤:

user-java-object <---> converter <---> variable instance

变量保存在 VariableInstance s. VariableInstance s 的成员被被hibernate映射到数据库的字段. 在jBPM默认的配置中, 6 类型的

VariableInstances被使用:

? DateInstance (是一个java.lang.Date field 被映射到

Types.TIMESTAMP in the database)

? DoubleInstance (是一个java.lang.Double 被映射到 a

Types.DOUBLE in the database)

? StringInstance (是一个java.lang.String 被映射到

Types.VARCHAR in the database)

? LongInstance (是一个java.lang.Long field 被映射到

Types.BIGINT in the database)

21

? HibernateLongInstance (hibernatable types作为long id

field.一个java.lang.Object 被映射作为一个引用到 hibernate 数据库中的实体)

? HibernateStringInstance (hibernatable types 作为 string

id field. 一个java.lang.Object 被映射作为一个引用到 hibernate 数据库中的实体)

转换器用来在java-user-objects 和保存在VariableInstance s的java objects 来转换. 因此当一个流程变量被设置为

ContextInstance.setVariable(String variableName, Object value) , 变量可选则被改变然后改变的对象被保存在 VariableInstance . 转变器是实现了以下接口:

public interface Converter extends Serializable {

boolean supports(Class clazz);

Object convert(Object o);

Object revert(Object o);

}

转变器是可选的. 转变器必须被 jBPM 类载入器可用

user-java-objects 被转换并保存在变量实例的方法在

org/jbpm/context/exe/jbpm.varmapping.properties文件中配置 . 定制这个属性文件, 把修改后的版本放到classpath的根, 说明在 章节 5.2, “配置文件” 属性文件每行都指明2或3个类名有空格搁开: the user-java-object的类名,可选的转变器的类名和变量实例的名字.当你引用你定制的转变器, 确定他们在 jBPM class path . 当你引用你定制的变量实例, 他们必须在 jBPM class path 并且hibernate 映射文件

org/jbpm/context/exe/VariableInstance.hbm.xml 必须更新以包含定制的 VariableInstance的子类.

比如, 看文件 org/jbpm/context/exe/jbpm.varmapping.properties. 22

java.lang.Boolean

org.jbpm.context.exe.converter.BooleanToStringConverter

org.jbpm.context.exe.variableinstance.StringInstance

这行指明了所有类型为Boolean的类型被转换器

BooleanToStringConverter转换并且 结果对象(a String)将被保存在StringInstance中.

如果没有转变器

java.lang.Long org.jbpm.context.exe.variableinstance.LongInstance 表明Long objects被存储在变量实例LongInstance不需要任何改变.

5. 安全

5.1 验证

验证是流程为谁的利益运行.jBPM 这个信息将从jBPM环境中可使用.造成 jBPM 总是在特殊的环境中运行比如webapp和EJB,swing应用程序或一些其他环境, 它总是让周围环境来执行验证.

在一些情况下, jBPM需要知道谁在运行代码.比如增加验证信息到流程日志记录谁做了什么. 另外一个例子是计算参与者.

jBPM 知道谁运行代码,是通过中央方法 调用

org.jbpm.security.Authentication.getAuthenticatedActorId() . 方法将委托 org.jbpm.security.authenticator.Authenticator实现 . 指明一个实现的证明者, 你能配置jBPM 怎么检索当前验证的参与者.

默认证明者

org.jbpm.security.authenticator.JbpmDefaultAutenticator . 实现维护一个 ThreadLocal 验证的actorId堆栈. 验证块用方法被标记

JbpmDefaultAutenticator.pushAuthenticatedActorId(String) 和 23

JbpmDefaultAutenticator.popAuthenticatedActorId() . 确定总是把这些放入 try-finally块. 实现push和pop方法,这是基本验证class方便的方法.JbpmDefaultAutenticator 维护actorIds堆栈代替一个actorId理由是: 允许jBPM代码区分在流程代码运行的用户和在jbpm引擎运行.

5.2 授权

授权是确认在验证允许用户安全操作之后.

jBPM 引擎和用户模式能校验如果用户被允许执行给定操作用API方法 org.jbpm.security.Authorization.checkPermission(Permission).

授权类将委托调用配置实现. pluggin接口对不同的授权策略API

org.jbpm.security.authorizer.Authorizer.

如果包org.jbpm.security.authorizer 有一些实现授权的例子.大多数都是没有完全实现和测试过的.

另外一个依然需要做的是定义一组有jBPM引擎校验的jBPM许可和校验.一个例子,校验以确定用户有足够特权来结束任务通过API调用

Authorization.checkPermission(new TaskPermission("end",

Long.toString(id))) ,在 TaskInstance.end() 方法

6. 可插入架构

在jBPM里可插入架构也是唯一机制为jBPM引擎添加定制能力.定制流程定义信息通过 ModuleDefinition . 当 ProcessInstance被建立,它将为每一个在 ProcessDefinition的 ModuleDefinition产生实例. ModuleDefinition 用做 ModuleInstances工厂.

最完整的扩展流程定义信息方式是通过给流程档案加入信息通过实现

ProcessArchiveParser . ProcessArchiveParser能解析加入到流程档案中的信息 , 建立你的定制 ModuleDefinition并且把它加入到 ProcessDefinition. 24

public interface ProcessArchiveParser {

void writeToArchive(ProcessDefinition processDefinition,

ProcessArchive archive);

ProcessDefinition readFromArchive(ProcessArchive archive, ProcessDefinition processDefinition);

}

为了让它工作,定制 ModuleInstance必须在执行期间通知相关事件 .定制 ModuleDefinition 可增加 ActionHandler 实现在流程事件之上用做callback handlers .

另外的方法,定制模块可以用AOP来绑定定制实例到流程执行. JBoss AOP 非常适合做这个工作因为它的成熟,易学并且也是JBoss堆栈的一部分.

25