本发明可以使一个软件应用通过自上而下的定义和实现企业过 程来协调整个企业的运作。企业过程，十分简单，是为了运作一个企 业，该企业必须执行的过程。例如，一个处于产品销售商业领域的公 司必须能为那些产品接收订单。接收订单和发货的整个行为可以被认 为是一个企业过程。以一个较小的尺度来衡量，一个电话订单进入公 司数据库也是一个企业过程。
用自上而下的方法来分析企业过程意味着该过程的定义始于企 业的最高层。使用这种方法的一个分析人员可能从产品销售过程着手 分析。产品销售过程可以被分解成较小一些的子过程，诸如接收客户 订单和按客户订单发货。每一这些更深一层的子过程都可以被更进一 步地缩小，直到每一雇员的任务都被以商业过程的模式阐明。
自上而下的定义企业过程的概念并不是新的。存在于现有技术中 的图形软件工具有助于自上向下的企业过程模型的建立。使用这些现 有技术工具的最终结果是该企业过程的详细、自上而下的定义。经理 主管人员和分析人员会发现，对于浪费、无效率，这样详细的定义是 有用的，并且一旦企业的过程被以此种方式明确定义，复制就会变得 清晰。接着，该工具使企业过程可被再定义和简化，并且当其采用新 的自上而下企业过程时，企业有希望能够变得更加有利可图。
不幸的是，该新定义的企业过程之后必须能在现实世界中被实 现。正如任何一位主管都知道的，实现一个仅仅存在于纸面上的新过 程从来也不会容易。首先，通常是企业过程的描述交给计算机软件开 发人员，它们之后会以它们最佳的理解来试图实现它。其结果是，几 乎从未确切地与企业分析人员开发的过程相配。企业分析员不能直接 开发软件，而是必须代替依赖软件程序员去实现该定义的过程，这是 该事实的一个固有的结果。
另一个要克服的困难问题是，即使一个单一企业过程的实现也要 求计算机资源的协作。在每个大企业中，大量不兼容的计算平台、操 作系统、网络协议、数据库和客户应用共存。因为不可能希望去除这 样的不兼容性，所以为了实现一个新的企业过程，必须把各种系统集 成。
近几年，一些企业已经转向面向消息的中间件 (Message-Oriented-Middleware，MOM)产品，其目的在于不同种计算 机系统的集成。典型地，这样的中间件产品通过“企业事件”捕捉、 分析和交换信息来为应用提供接口。这种机制使得企业分析员可以将 许多不同的应用平台集成，以使它们工作在一起。
不幸的是，当中间件产品使企业应用可以共通的时候，它们并没 有减轻自动操作新企业过程的任务。中间件产品不能作到在应用之间 的企业结构和企业知识的重新使用。替代它的是，当必须重新使用这 样一个企业结构或知识时，必须要从零开始建立一个新的应用。
当结构或知识必须被重新使用，而中间件解决方案不起作用时， 一些企业转向了面向对象的开发环境以满足此要求。因为可重用性是 面向对象范例中的一个要素，此种方式应该能通过重复利用早期应用 中创建的对象来开发新的应用。不幸的是，由于对象创建、定义和改 进的技术特性，对于典型的企业过程分析人员来说，面向对象范例的 许多可重用性的优势是无法达到的。
因为这些困难，实现一个新设计的、自上而下的企业过程几乎总 是旷日持久、拖拖拉拉的事情。事实上，耗费在实现一个新企业过程 中的精力和时间相当巨大，以致于完成过程的执行还没有获得成功之 前，这个新过程被频繁改动，甚至被抛弃。
需要的是在一个单一步骤中定义和执行自上而下的企业过程模 型的能力，在此步骤中由企业人员，而不是软件程序员创建和拥有的 企业模型的真实的定义，导致了实现已定义的企业模型的可执行软件。 进一步需要的是将新定义的企业模型与现存的企业应用进行集成的能 力，通过利用现存的中间件接口或者通过使用直接连接到共同的应用 和数据库。所期望的应用必须具备在一个高度抽象的层次很容易创建 可重用的对象的能力，以使得该对象无需对每一应用进行再定义就可 以在贯穿企业的应用过程中始终是有用的。最后，还需要的是一个过 程服务器，它通过组织中的雇员或现存的应用配置预定义的过程和赋 值作业

本发明通过合并一套软件工具可以完成自上而下工作流程模型的 图形定义来达到解决这些问题的目的。一旦定义完成，这些模型是完 全的可重用的企业应用，能够被实时的使用而无需中断当前企业运转。
在本发明中，企业过程的定义使用了一种不需要编程的图形化接 口。一个过程模块的各种部件以可视化的方式呈现给设计者，该设计 者可以将各部件连接到一起，以建立工作流和企业逻辑。企业工作流 可以被向下定义直至企业任务级，企业任务级是工作的一个单元，它 可以通过一个单独的程序或一个现存的企业程序来完成。事实上，在 本发明中任务本身被完全定义，包括用于任务完成的呈现给终端用户 的用户接口。这些接口可以被开发用于多种硬件部件，允许通过Java 运行时间应用、Web浏览器甚或是一个PDA接口例如Palm公司 的Palm OS(Santa Clara，CA)来完成。
本发明具有三个主要组件：过程设计者，过程服务器，过程客户。 过程设计者可以让用户从上到下定义企业过程。过程定义由一些诸如 任务和子过程这样的组件组成。任务是由人或由存在的系统自动地完 成的工作项目。过程模型也包括任务安排、终端用户、企业逻辑、和 其他的用于进行并行处理、同步处理、以及服务记时的组件。企业数 据从数据库获得，也可从现存的企业应用中获得。
完成的企业过程定义在过程服务器中被使用和执行。用户登录到 过程服务器，然后过程服务器提交他们的任务安排。随同他们的作业 一起提交的还有完成他们的作业所需的业务数据，并且如果必要，和 执行任务需要的GUI接口。过程服务器把工作流区分优先次序，并且 为任务队列监视器提供管理接口。
过程客户是一个GUI基础的应用、一个web浏览器、甚至是一个 PDA接口，可让终端用户能够登录和连接到该过程服务器(一或多 个)，访问任务列表，以及执行配给他们的任务。终端用户自动的获知 为完成所分配的任务所需的必要的信息和资源。
附图说明
图1是一个本发明中作为可能被定义的两个过程的代表性视图；
图2是一个具代表性的视图，通过一个具有一个子过程的过程， 该子工程又具有一个任务来显示本发明中的数据映射；
图3是表示本发明一个过程模型中各部分的层次的组织的图表；
图4是表示用于本发明中每一包中使用部分的层次规则的图表；
图5是表示本发明中缺省的行为、结果和部件属性的图表；
图6是表示本发明中缺省的行为、结果和部件属性的图表；
图7是一个表示本发明中一个连接部分的流控制的有代表性的视 图；
图8是一个表示本发明中一个定时器部分的流控制的有代表性的 视图；
图9是一个表示本发明中路由器定义中一个比较器部分的流控制 的有代表性的视图；
图10是本发明中软件工具的一个有代表性的视图；
图11是本发明中存储部分的一个有代表性的视图；
图12是一个GUI操作系统窗口，显示本发明中的一个项目管理 接口；
图13是一个GUI操作系统窗口，显示本发明中的项目设计者的 用户接口；
图14是运行于控制流编辑模式中的图13的用户接口；
图15是带有选择的子过程122的图14的用户接口；
图16所示为本发明中控制流和数据流中结合部分的过程流程图；
图17是一个GUI操作系统窗口，所示为本发明中一个新链接对 话框；
图18是一个GUI操作系统窗口，所示为本发明中一个事件图对 话框；
图19是运行于任务编辑模式中的图13的用户接口；
图20所示为本发明中定义一个视图的过程的一个流程图；
图21是一个GUI操作系统窗口，所示为本发明中用于呈现给终 端用户的一个任务列表。

过程模型100
如图1所示，过程模型100是一种企业行为的代表或模型，它存 在于企业、部门或其他一些类型的实体或企业单位。每一过程模型100 将包括一个或多个过程120，它们中的每一代表了一个特殊的真实世 界的企业行为。例如过程120包括“接受购物订单”和“付发票”。
每一过程120可以包括一个或多个子过程122，或一个或多个任 务130。一个任务130是一个典型的工作单元，由一个人或由在过程 120中的作为一个步骤的自动操作的计算机程序来完成。在一台计算 机终端输入一张购物订单并且发送一张帐单到打印机打印，是举例的 任务130。过程120中包含子过程122表明子过程122必须在包括的 过程120可以被认为完成之前被完成。一个单一过程120可以包含多 个子过程122，但是只能直接包含一个单一的任务130。
在本发明中，一个子过程122被认为是包含它的过程120的一个 “组件”，因为它构成了过程120的一部分。过程本身被认为是一个“容 器”，因为它包含了一个或多个组件。过程120也被认为是一个组件， 是因为它本身可能被包含在一个更大的容器中。
每一过程120通过一个事件102被激活。例如，用于一个“接受 购物订单”过程120的激活事件102可以是一个购物订单的收据。除 了被一个事件102激活以外，当过程120完成时，每一过程120也创 建一个新的事件102。举例说，在接受购物订单过程120之后，新事 件102可以被称为“购物订单已接受”。激活一个过程120的事件102 被称为动作104。由已完成的过程120创建的事件102被称为结果106。 当一个真实世界事件发生时，它将典型的由第一个过程120的结果106 和另一个过程120的动作104来代表。虽然图1中每一过程120只表 示了一个单一的动作104和结果106，但是对于一个组件有可能具有 多个动作104和结果106。
创建一个完整的过程模型100有两个重要的步骤。首先，必须创 建过程模型100的控制流。该控制流描述了在一个企业中过程120和 任务130的顺序。通过分析获知过程120和链接一个过程120的结果 106(一或多个)到另一个过程120的行为104(一或多个)，一个用 户可以创建控制流模型。
过程120通过事件102进行的链接不是在它自身里创建一个完整 的过程模型100。这是因为企业数据也在企业中流动。一个仅表示了 过程和事件而没有表示企业数据的运动的模型100是不完整的。举例 说，一个“处理索赔”的过程120，其结果导致了一个“索赔已被处 理”的结果106，如果没有有关是谁的索赔被处理了的信息，该过程 是没有意义的。这样，一个过程模型100必须包含控制流和数据流， 两者都要有。因为显示在图1中的过程模型100只显示了控制流而没 有数据流，所以它不是过程模型100的完整的代表。
图2的概念性图表显示了一个更完整的过程模型100。此图显示 了索赔处理过程120。置于索赔处理过程120之中是索赔批准子过程 122，它依次由一个单一得到批准任务130构成。索赔处理过程120， 索赔批准子过程122和得到批准任务130中每一都有一个动作104和 一个结果106。可以激活索赔处理过程120的一个动作的例子可以是 一个“接受索赔”动作104。当索赔处理过程120完成时，过程120 将向控制流模型100的剩余部分提交结果106，例如“索赔已批准” 或“索赔被拒绝”。此结果106可以接着激活进一步的过程120。
为了决定是否该索赔应该被批准或被拒绝，执行获得批准任务 130的人将需要回顾与此索赔相关的特定的数据。在本发明中，这种 类型的数据存储在索赔处理过程120中的变量或属性108中。有三个 属性108显示在图2中，即客户名称、索赔金额和索赔批准状态。索 赔处理过程120可以有更多的属性108，例如客户地址、电话号码、 客户身份证号、索赔原因、产品序列号等等。图2中所示的属性108 是用于举例目的，在实际执行中可能不够充分。相似的属性108也显 示在索赔批准子过程122和得到批准任务130中。
本发明中数据映射的目的是当控制流被执行时使数据能够从一组 件的属性108移动到另一组件的属性108。通过映射容器的属性108 到组件的属性108，一个容器既可传送数据到一被包含的组件，又可 接受来自一被包含的组件的数据。例如，如通过点划线所示，索赔处 理过程120的客户名称和索赔金额属性108被映射到索赔批准子过程 122的属性108。用这种方式，索赔处理过程120中的客户名称和索赔 金额属性108就被传送到在索赔批准子过程122中的以相似名称命名 的属性108中。
类似地，子过程122传送这些值到被包含的得到批准任务130的 属性。当得到批准任务130被完成时，该“是否批准？”属性108将 具有一在任务130的完成期间被赋的值。该值其后通过数据映射被映 射回子过程122的该“是否批准？”属性108，它将容器的属性值与 组件的属性108联系起来。最后，该“是否批准？”属性值映射到索 赔处理过程120中该恰当的属性108。
组件110
为了创建一个处理模型100，本发明使用了一套被定义的构件。 如图3中所示，这些构件可以被分成组件110和资源250。组件110 是用于图形化地建立过程模块110的控制流的基础构件。资源250是 企业业务数据的持有者，并且在过程模块100中支持信息流的建模。
所有的组件110都具有与之相联系的基本性质109，包括动作104、 结果106和属性108。如上面所解释的那样，动作104和结果106是 既用于控制流，又用于信息流的业务事件102。属性108被用于存储 对组件110有用的业务信息。与组件110本身一样，事件102也具有 将数据从一组件110移到另一组件的属性108，。
一些组件，即过程120、任务130和控制器150，可被同时用于一 个过程模型中多个位置。这是被允许的，因为经过恰当设计的购物订 单过程120如果被用于一个企业中的不同地点，应该要求几乎没有或 者没有改变。如果在可重用组件110里需要做改变以适应任何变化(例 如由销售税或相似的地方法律引起的变化)，组件110可以被复制，并 且新创建的组件110可以作出改变。创建一个组件110的拷贝的这种 相同的技术也可被用于不被认为是可重用的组件110。当进行复制时， 组件不被重用，因为要为每一应用创建一个组件110的新的实例。
除了动作104、结果106和属性108以外，组件110也将具有另 外的性质109，例如组件名称和说明。存在有两类性质109：全程特征 和上下文相关特征。全程特征提供给所有的组件110的实例，无论组 件110是否在该处被使用。例如，一个过程120的名称和说明都是全 程特征。结果，改变名称就会导致使用过程120的任何地方的名称都 被改变了。上下文相关的性质仅在组件110的个体的迭代之间改变， 并因此仅通过可重用组件110使用。例如，一个特别的任务任务130， 被使用多次，可能在每一反复中具有不同的性质。结果是，上下文相 关的性质优先。属性108也是上下文相关的。
容器112
如图3所示，有两种主要的组件110类型，即容器112和元素160。 容器112是能包含其他组件110的那些种类的组件110。本发明利用 了四个容器：过程120、任务130、路由器140和控制器150。元素160 是不包含其他组件110的过程模型定义的那些部分。
当容器112通过定义能够包含其他组件110的时候，它们不能包 含每一种类型的组件110。图4中的表格表示对于每一种类型的容器 112都有效的组件110。如图4中所注释的，一些容器112仅支持一种 特殊类型的一个被包含组件110的存在。例如，每一过程120只允许 包含一个任务130。这种特殊的限制可以起作用，是因为一个过程120 能够利用多个子过程122，而每一子过程包含一个独立的任务130。图 4的在一个容器中只能出现一次的组件，通过列出时将这类特殊的组 件110标有一个星号来指示。
过程120
如上面所解释的，一个过程120是一组一或多个子过程122、任 务130或其他组件110组合在一起以获得一个特定业务行为。过程120 和其他容器110的缺省的动作104、结果106和其他性质109在图5 的图表中示出。图5中的图表将每一容器112的性质109分成全程特 征和上下文相关特征。如图表中所示，过程120的唯一的缺省动作104 是开始(start)。这个动作显然是通用动作104，用于开始过程120操 作。此动作104通常要将名称改变，以便更精确地反映它的业务目的。 一个常用的第二动作可能会是一个取消动作104。如果取消动作被激 活，一个先前开始的过程将被取消。
图5也表示对于一过程120的唯一缺省结果106是“完成 (complete)”。这个结果106显然指示过程模型100的剩余部分，过 程120已经完成。再有，此结果106通常将会被重新命名。多个结果 可被用于指示从过程120作出的不同的结果。例如，一个结果106可 以表示索赔的批准，而第二个结果106可以表示索赔的拒绝。
一个过程120的全程特征109是名称、检查状态和描述。在一个 过程模型100的结构中，过程120通过它的名称可以被识别。描述特 征109包含一个被定义过程120的描述。虽然通过利用一个图形化定 义工具(见下文)，每一过程120只可以部分自文档化 (self-documenting)，但是，在过程120本身的特征109里嵌入一个描 述使该过程120更加自文档化(self-documenting)。
在确定当前是否已向开发者进行过程120核对的开发期间，使用 该检查状态特征109。
用于过程120的唯一上下文相关特征109是链接特征。该链接特 征保存了所有其他组件110的路径，以连接该过程120的特殊实例。
除了特征109之外，缺省的动作104和结果106，每一过程120 也将具有属性108、定制的事件102及被包含、链接的组件110，以帮 助从所有其他的过程120中定义和区分过程120。通过一些步骤定义 一个过程120的这些元素，下面将对该步骤进行说明。
任务130
如上所述，对每一个体或用于完成一个特定任务的程序，每一任 务130包含一个工作安排。除了工作的简单安排之外，每一任务130 也包含实际完成该分配的工作元素所需的所有的业务逻辑和业务数 据。例如，如果一个任务130被安排给一个终端用户去批准一个保险 索赔请求，该任务130将i)结合终端用户需要的必要的业务数据去 批准索赔请求，ii)提供用于批准索赔请求的业务逻辑，和iii)将这 个信息在一个定制的GUI接口内提交给终端用户。结合任务编辑器的 描述，下面将对结合接口内的所有这些信息的过程进行说明。
任务130包括两个缺省动作104(开始和取消)和一个缺省结果 106(完成)，如图5中所示。任务130也包含如过程120的三个全程 特征109，即名称、检查状态和描述特征。缺省动作104、结果106 和全程特征109的形式和功能已经在上述过程说明中进行了说明。任 务130不共享特征109特定的初始化的事实表明本发明不允许任务被 特定的初始化。虽然优选方案中，在特定的初始化之前，确定了需要 任务130结合到过程120中，但是也可以做出不同的决定，并且不能 认为这是对本发明范围的限制。
任务130有三个不同的上下文相关特征109，即链接、角色和优 先权。链接特征109与过程120的链接特征109相同，其中它表示被 链接到任务130特定实例的其他组件110。
角色特征109表示去完成任务130的用户。本发明不将任务130 安排给个体用户，而是如角色270所指的用户组。一个服务器接着将 个体用户分配给一或多个角色270。在过程模型100中，该角色270 是从所有预定义的角色270的列表中选择出来的。
缺省地，任务130被安排给一个角色中所有的用户，并且当一单 个用户完成了任务就视为完成。在指定任务完成之前，必须多于一个 用户结束任务130是可能的。控制在一个角色中怎样将任务分配给用 户也是可能的。例如，任务130可以被分配给单独一个用户并跟随着 一个连续的模式(第一用户号1，接着第二用户号2，等等)。按照角 色属性108(下面会详细说明)的值，限制对角色270的任务130的 分配也是可能的。例如，对于角色销售员，一个任务130可以只提供 给那些在美国工作的销售员。
多个角色270可以与单独一个任务130联系。例如，在一个客户 服务部门，“客户电话处理”任务130可以与两个角色270联系：“客 户代表”和“客户代表主管”。通过将这个任务130与这两个角色270 联系，该系统将不但允许主管也允许客户代表来处理客户电话。
另一个任务分配选项是用于给完成了过程120中该前述任务的人 分配该任务130。例如，业务规范可要求该索赔批准任务130由做索 赔回顾任务130的相同的人来完成。
在系统运行时使用优先权特征109，以把提交给一给定终端用户 的工作的区分优先次序。优先权特征109可被简单的用于从列表中挑 选有用的任务130提交给用户，或者可被用于自动地选择该用户要完 成的下一个任务130。
一个任务130的优先权可以被设置成从1(低)到10(高)的数 值。在过程120中，这个该任务可以静态地做，可以动态地源于上下 文，或从过程120中的该在前任务130中继承。如果优先权被动态设 置，则通过条件句(例如if customer＝“IBM”then priority＝10 else priority＝1)产生一个优先权决策树或与下面所述的控制流树相似的决 策树。
路由器140
当设计一个业务过程120的控制流时，使用路由器140。一个路 由器140将基于特定的条件或决策把一个控制流分成不同的分支。典 型的拆分行为的发生基于存储在属性108内的业务数据。例如，当诸 如浏览提议的一个任务130完成时，根据可能存储于该任务结果106 的属性108中的该提议浏览任务130的结果，控制流可以分为三个分 支：
批准提议和初始化下一个任务130；
拒绝和结束提议行为；或
意见和把提议送回它的创作者去修订。
如图5中所示，路由器140具有一单缺省动作104(开始)，和多 个、相互独立的结果106(具有为分支1和分支2的缺省值)。一个路 由器140的该特征109和过程120的该全程特性相同，不同之处仅在 于路由器140不具有一个初始的特定特征。
控制器150
一个控制器150有两个有用的属性。第一，控制器150在其他的 项目中是可重用的；第二，控制器150可被用作其他组件110的容器 120，特别是适配器240。
如下所述，适配器240为存在于过程模型100外的业务数据提供 通路。不幸的是，适配器240的使用需要编程知识。为了使业务分析 人员可以避开不得不直接使用适配器240来访问业务数据，程序员将 适配器240嵌入到控制器140中。于是该业务分析人员可以使用控制 器150来定义过程模型，而无需知道适配器240底层的技术细节。
如图5中所示，除了缺乏特定的初始的特定特征109，控制器150 和过程120具有相同的缺省事件102和特征109。
元素160
元素160是过程模型100的那些不包含其他组件110的部分。如 图3中所示，本发明的优选实施方案使用八个不同的元素160，即视 图170、接合180、比较器190、记时器200、赋值器210、动作-启动 器220、通报器230和适配器240。图6表示每一元素160和它们的缺 省动作104、结果106和全程特征109。因为元素160不能被重用，所 以对于元素160不存在上下文相关特征109。下面对这些元素160进 行更详细的说明。
视图170
每一任务130包含终端用户完成任务130所必须的业务数据、逻 辑和接口元素。通过一个由任务130的视图170定义的用户接口，此 信息被呈现给用户。因为本发明被设计成用户通过各种不同的操作系 统环境进行交互，所以视图170必须被创建成能够处理这些不同的平 台。在该优选实施方案中，被支持的平台环境包括Java、HTML和Palm OS。在本发明的范围内，支持其他的操作环境也将是可行的。
因为需要为每一这样的环境产生单独的接口，所以在一个任务 130中，本发明为每一可被支持的环境使用了单独的视图170。一特定 任务130中包含的所有视图170的全体被指定为一组视图172。可能 定义视图170，该视图170将被用于通过接受该任务分配的该角色270 完成一任务130。例如，一个终端用户在他/她的办公室里做一张与任 务相关的购物订单，他/她可能使用的是在一台式电脑上的Java(或称 “Swing”)接口，而同时一个在股票交易场所的经纪人可能更喜欢使 用一个具有一个无线接口的掌上电脑上的Palm OS接口。
每一视图170将包含一或多个面板174，每一面板提交给终端用 户一屏信息。该面板174包括传统的接口元素，诸如文本、图形、数 据域、按钮和复选框。本发明为图形化地设计这种面板174提供了工 具，将会结合任务编辑器进行更详细地说明。为了便于将GUI面板链 接在一起和为面板174的进一步完善的更新提供手段，本发明使用任 务控制器176。任务控制器176与一个或多个面板174联系，并用于 诸如一个面板174上控件的可用或不可用的管理功能，执行数据有效 性，或控制多个面板174间的交互作用。
接合180
接合180使多个过程120或任务130同步，要求从每一过程120 或任务130产生的结果106应该在进行下一过程之前被接收到。结果 是，当两个或更多个并行过程120或任务130汇集到单一一个控制线 程时，接合180可能被使用。例如，只有在完成所有的初始步骤之后， 一个接合180可被用于开始一个用于批准一笔贷款的过程120。
图7包含一个接受抵押应用的过程120的示意图，它以这种方式 利用了一个接合180。此图使用的图标与下面所要说明的用于控制流 编辑器340中的组件110的图标相似。在此图中，启动处理抵押需求 过程的动作104用一个带有绿灯亮的交通指示灯图标表示。此动作104 被用于同时启动三个另外的过程120：一个用于完成应用、一个用于 检验薪水信息、及一个用于获得信用报告。每一个这些过程120用包 含一小流程图的图标表示。该接合元素180被用于将这三个过程120 的结果集合到一起，并且阻止最后一个过程120(“回顾和批准”)在 所有三个过程120都已完成之前启动。一旦此最后的过程120完成了， 该结果“完成”106被作出，它用一个带有停止灯亮的图标表示。
如图6所示，接合180有多个输入动作102，预定义为分支1和 分支2，及被称为完成的单一缺省结果106。接合180通过在做出完成 结果106之前等待所有的动作104都被接收来实现它的功能。表示在 图6中的一个接合180的特征，与结合图5说明的相似的名称特征相 同。
记时器200
通过在一段时间后产生业务结果106，记时器200被用于过程模 型100中的控制流。记时器200可被用于在过程120和任务130中生 成警报，提供内置的延时，和为过程120和任务130完成创建最后期 限。
当一个记时器200被串联地置于控制流中时，该记时器200起到 延时元素的作用。直到设定的时间周期过去，该流程才会继续进行。 当一个记时器200被并联地置于控制流中时，如果过程120或任务130 的执行超过了设定的时间周期，该记时器200能够被用于提供通知事 件。在使用记时器200时，当通知不再需要时(例如，记时的过程120 或任务130已被完成)，一定要小心以确保记时器200被取消。
图8表示的是一个并联地使用记时器200的示意图。如果完成过 程120的时间超过了时间限制，该记时器200激活一个时间到期的结 果106。注意，该过程120和该记时器200都通过开始动作104激活。 当过程120完成时，过程120不仅激活一个完成结果106，而且通过 传送被记时器200视为取消动作104的结果106(表示在图8的第202 行)取消记时器200。
如图6所示，记时器200具有两个缺省动作104：开始和取消。 记时器200只有一单个结果，即“完成”。当开始动作104发生时，记 时器200开始运行，然后当定义的时间间隔被完成时，发出完成结果 106。先于过期时间的一个取消动作104的收据将阻止过期事件被激 活。
记时器200具有五个特征109，如图6所示。该链接特征109表 示那些连接到记时器上的其他的组件110。日历特征109表示被用于 记录时间的日历290。正如下面要更详细地解释的，一个日历290是 一个资源250，它被用于决定什么算作“可计算的”工作时间。例如， 在工作时间为星期一到星期五，上午9点到下午5点的地方，四个小 时的时间可以意味着绝对的四个小时，或者可以意味四个工作时。工 作时间的定义被保存在日历290里。
类型特征109指明记时器用的是绝对时间(2003年1月1日，东 部标准时间下午4点)，还是相对时间(从开始时间起三个小时)，或 者是推导时间(每隔一个月的第一个星期二)。特征109也用于存储适 当的时间数据(例如选取的绝对或相对时间，或决定相对时间的逻辑)。 这个信息被存储在绝对时间、相对时间和推导时间特征里。
比较器190
一个比较器190使用一组运算符来比较两个值，以产生True或 False的布尔结果。在一个过程120中，当只需要两种结果，或能在一 个路由器140中被结合用于更复杂的决策树需求，比较器190可以被 直接地使用。
一个使用两个比较器190定义的路由器140的一个例子如图9所 示。该路由器打算比较某一个数值(“Amt1”)和两个其他的数值 (“Amt2”和“Amt3”)。如果Amt1小于Amt2，则标题为Branch1的 结果106应该被激活。如果Amt1大于或等于Amt2，但小于Amt3， 则Branch2应该被激活。如果Amt1大于或等于Amt3，则标题为 Branch3的结果106被激活。
对于数字的属性，比较器190可以用下述标准的比较类型：小于、 小于或等于、等于、大于、大于或等于、不等于。对于字符串属性， 比较器190可以完成相等(如果串相同则为TRUE)或不等(如果串 不同则为TRUE)的比较。另外的运算，例如一个字符文本小于或大 于，虽然没有在本发明的优选实施方案中具体表现，但是对于本领域 的技术人员会是显然的且在本发明的范围之内。
如图6所示，比较器190具有单一一个动作104，即输入。输入 动作104将比较器190初始化，并且传送要比较的值给比较器190的 属性。一个比较器190的三个可能的缺省结果106是true，false和fail。 最后，比较器190具有两个另外的特征109：链接和操作数。链接特 征109表示连接到该比较器190上的组件。操作数特征表示将要运算 的值。这些值可以是上下文数据或硬代码的值。
赋值器210
赋值器210被用于给属性108赋值。如图6所示，该赋值器210 具有单一一个输入动作104。一个赋值器210的可能的结果106是完 成(表示成功地赋值)，或失败(赋值失败)。就象比较器190，赋值 器210具有链接和操作数，作为其仅有的特征109。
动作-启动器220
动作启动器元素220被用于一个过程120或一个任务130中，以 异步地启动一个新过程120或任务130。该初始化过程120或任务130 在一过程120或一任务130的被启动的文本外部被启动。这不同于嵌 入的过程120，在那里，在父过程120能被认为完成之前，该父过程 120必须等待嵌入的过程结束。
一动作-启动器220的该单个动作104是一个开始动作，用于初始 化新过程120或任务130。图6中没有列出结果106，因为一个动作- 启动器220创建一个独立的过程120或任务130并且没有结果返回。
一个动作-启动器220的两个特征109是类型(它表明了是否一个 过程120或任务130被初始化了)和被初始化的名称，它确定了被初 始化的组件的名称。
通报器230
一个通报器230被用于给一事件出现的终端用户提供异步消息。 当通报器230被激活时，一个文本消息通过本发明的过程服务器500 被送到指定地址的用户的收件箱中，或者另外一种可供选择的方式是， 一个邮件消息被送到一个特定用户的email地址。没有与通报器230 相关的结果，因为如同动作-发射器220，一个通报器230是在当前过 程120或任务130的文本的外部启动的。
一个通报器230的单一的动作104被发出，它初始化了消息和传 送相关的属性给通报器230。该名称特征109是作为消息的主题出现 在收件箱里的名称，或作为e-mail里的相关行。地址特征109可以定 义角色270或者应该接收该通报的e-mail地址。
优选权特征109仅被用于伴随消息通过过程服务器收件箱，它以 任务130中设置优选权的相同的方式设置。消息特征109是消息的正 文。发送类型区别是过程服务器消息还是e-mail。最后，该描述是目 的的文本文件和通报器230的使用。
适配器240
适配器240提供一个访问现存的业务数据或逻辑资源的方法，例 如现存的公司的应用，中间件和数据库。除了访问业务数据，适配器 240可被用于初始化一个外部程序，去启动一个独立定义的业务过程 100，或去访问或产生中间件事件。知道一个适配器240不包含业务数 据或程序逻辑本身是很重要的。相反的，适配器240为外部源提供了 一个接口。
为了实现各种任务，适配器240通过过程120和任务130压缩外 部数据或控件到一个可用的格式。虽然过程120和任务130能够直接 利用适配器240，但是适配器240通常被编入控制器150。这是因为压 缩现存的数据或控件的过程可能非常复杂。当适配器240被编入一个 控制器150，这些复杂的细节被隐藏起来，并且代替它的是，信息通 过控制器150的简化的接口提供给过程模型110的设计者。
本发明为适配器240预定义了许多格式。第一种格式是用于新的 或现存的Java类的接口。第二种格式让适配器240作为现存中间件产 品的接口，例如Computer Network Technologies(Minneapolis，MN)的 企业/访问中间件产品，或Active Software(Santa Clara，CA)的 ActiveWorks中间件产品。
不管适配器240是什么格式，适配器240对外部源的特定的接口 都在本发明的适配器编辑器中有详细的说明。除了定义这个接口，适 配器编辑器也定义了适配器240的标准动作104和结果106。适配编 辑器将使它的功能近似于在先前的中间件产品中使用的接口，也起到 将异类的业务数据和逻辑集成的作用。
DB组件242
除了一个DB组件242为工业标准数据库管理系统提供一个接口 之外，一个DB组件242非常象一个适配器。举例说，DB组件242 可以提供一个SQL接口，以使得可以查询多个支持使用SQL访问和 修改数据的数据库。
BE工厂244
如下所述，业务实体260是逻辑构造的信息组。BE工厂244是 在任务130执行期间允许任务130产生业务实体260的元素160。例 如，一个任务130可被定义成让一个用于输入新的索赔要求。一个索 赔要求可能由多条信息组成，并被组合到单一的一个业务实体260里。 此任务130的用户接口可能包括一个用户选用来创建一个新要求的按 钮。此按钮可和一个BE工厂244联系起来，创建一个索赔要求业务 实体260的一个新实例。
锁246
利用一个业务实体260中的数据作为一个钥匙，锁246被用于为 过程120加锁或解锁。例如，一个邮寄订单过程120可以在完成给客 户送帐单的任务130后，使用一个客户订单业务实体260作为钥匙自 锁。与邮寄订单过程120并行运行的可以是一个接收客户所做的订单 付款的付款接收过程120。付款接收过程120可以使用同一个客户订 单业务实体260作为钥匙为邮寄订单过程120解锁。一旦解锁，邮寄 订单过程120就会重新开始运行，并且接着执行控制流中下一个任务， 即发货订单任务130。
资源250
资源250是另一种类型用于定义一个过程模型100的构件。特别 是，资源250定义了过程模型100中使用的基础业务数据。换言之， 该资源250制定了被用于存储业务信息的数据的结构和这些结构的实 例。例如，当一个事件102、组件110或元素160的属性108被初始 定义时，需要将属性与特定类型的资源250联系起来。在本发明中， 资源250包括业务实体260，角色270，用户280，日历290，决策标 准292和数据控制294。
业务实体260
业务实体260是逻辑组成的多条信息，表现一个业务中使用的实 体。业务实体260的结构可以是有利于过程模型100的设计者的几乎 任何类型。通常，业务实体260通过创建一个或多个属性108(数据 结构中的数据域)来定义，就每一属性108来说，不是一个标准的预 定义的变量类型(例如文本/串，整型，长型等)，就是另一个业务实 体260。例如，一个业务实体260可以为一个地址而创建，该地址由 分离的属性108，街道地址，城市，州，邮政编码组成。该地址业务 实体260接下来可以是一个名称为“客户”的不同的业务实体260的 一个属性108。这样就使得业务实体260能表现记录结构，可以以有 用的格式记录业务信息。
角色270
角色270是被预定义来记录一个企业的工作功能的资源250。实 际上，角色270是一个预定义的业务实体260，带有某种强制性的属 性108，例如角色名称。角色270的使用已经在上面讨论任务130分 配时进行了说明。通过向角色270而不是向个别用户280分配任务 130，本发明使得在完成任务130中更具有灵活性。此方法在当今快速 变化的业务环境，如高速的员工调整和频繁的任务再分配中，特别有 用。
角色270具有的灵活性足以使过程模型100的设计者对每一角色 增加额外的属性108。例如，“销售人员”的角色270可以有区域、地 域、配额等属性。角色属性的值可以在配置时或运行期间赋值。
用户280
就象角色270，用户280是预定义的具有某种强制属性108的业 务实体260。用户280资源表示执行任务130，定义业务模型100或以 别的方式与本发明进行交互的真实的人类使用者。执行任务130的用 户280可被赋予多个角色270。本发明中用户280的定义包括强制属 性：名称、用户ID、密码、主管和该用户280所赋予的角色270。每 一用户280也可以被指派给多个用户组282，例如定义为男性雇员的 一个组282或定义为参加股票所有权计划的雇员的一个组282。虽然 用户280被预定义为这些属性，但是每一企业可以增加更多的适用于 它们业务的用户级属性。
日历290
日历290是另一种预定义的业务实体260。如上面结合记时器200 所提到的，日历290提供了一种定义一组预定时间的方法。在大多数 的企业里，需要使用不同的日历跟踪时间，例如工作时间、实时、过 时等。日历290资源可以按照一个特定的企业的实际定义时间。举例 说，一个工作时间日历290可被定义成包括标准工作时间而不包括周 末和节假日。工作时间日历290可以被用于跟踪与记时器200有关的 时间段，该时间段被定义来确保所有的订单都在订单接收的三个工作 日内发货。
决策标准292
决策标准292是用于代表一个特定值的特定业务实体260。因为 决策标准292是简单的业务实体260，决策标准可被用于业务实体260 数据被使用的任何地方。
决策标准292的例子包括对于退款或索赔所需的管理者可批准的 特定元的限制，如此的元的限制可在整个企业范围，或通过部门或地 理区域赋值。使用决策标准292去代表此元的限制的选择要好于使用 一个业务实体260，因为限制是稳定的，不会象一个典型的业务实体 260一样在运行时间改变。决策标准292被用在过程模型100的硬代 码(hard-coding)值的地方，因为它可能在以后需要改变此值，并且 改变决策标准292比寻找一个硬代码(hard-coding)值的所有实例容 易。
另一个决策标准292的恰当的应用是标志，它根据当前的业务条 件，用于开关不同的过程模型100。通过使用这样一个标志，在运行 期间，业务的过程流可仅仅通过改变标志而改变，而无需重新定义已 定义的控制流。
数据控制器294
数据控制器294是一个特殊类型的资源250，而并不仅仅是一个 特定类型的业务实体260。数据控制器294是一个代表一系列全部的 对过程模型100有用的业务数据的对象，包括业务实体260中的所有 的数据，以及在其中建立数据控制器294的任务130中的属性108和 特征109。所有这些数据被集中放到数据控制器294中的一个地方， 以使任务130的定义更容易，在下面将结合任务编辑一380对此进行 解释。
软件工具
如图10所示，本发明使用三个软件工具来创建和实现过程模型 100：一个过程设计器300、一个过程服务器500、和一个过程客户机 600。过程设计器实际上是用来定义过程模型100的软件工具。过程设 计器300可以使用户280，指的是业务分析员、设计者、或开发员302， 为它们的企业定义一个过程模型100。为了完成此目的，过程设计器 300为开发者302提供一个GUI接口，目的是帮助开发组件110和资 源250，并且可以在组件110之间定义过程和数据流。除了适配器240 的创建，所有这些都可以通过过程设计器300的图形接口来完成，而 无需做任何传统的编程。
完成后，企业过程模型100在过程服务器500上进行配置，过程 服务器起到本发明的工作流引擎的作用。过程服务器500运行建立在 过程模型100中的程序120，向恰当的角色270提交任务130。过程服 务器500通过独立任务130的优先权属性109调整任务130的安排。 过程服务器500还为指定的用户280，被称为控制业务过程120的管 理员502，提供管理接口。管理员502直接登录到过程服务器500，可 以观察日常的企业工作。任务130的优先权的确定和安排可以被监控， 并且在必要的时候可以被调整，而当超过卷或延迟极限时警报就会产 生。
过程客户机600是一个GUI基础的应用，允许终端用户602登录 并连接到过程服务器500，访问安排给它们的任务130，并且按照它们 的优先级别执行任务130。终端用户602通过为任务130设计的视图 170可以自动地获取必要的信息和资源。
过程设计器300
数据仓库310
过程设计器300是完成过程模型100定义的地方。通过将编排的 过程模型100的对象存储到一个数据库或一个被称为数据仓库310的 对象中，过程设计器300允许多个设计者302协同工作。如图11所示， 数据仓库310自身包含了仓库对象312。仓库对象312大致相应，而 不是精确地一对一的与当前定义的组件110对应。这是因为数据仓库 仅仅包含可被重用的对象312，即过程120、任务130、控制器150及 适配器240。不能被重用(即路由器140)的容器112和除了仅作为对 象存在于数据仓库310中的适配器240以外的元素160，被嵌入在其 他仓库对象312里。
数据仓库310被组织到一个或多个项目314中。项目314的目的 是将创建的过程模型100的任务分解成独立，更易于管理的工作，每 一工作具有有限的一组设计者302，工作在带有预定的最后期限的限 定的目标。多个设计者302可以在同一个项目314中同步地工作。当 仓库对象312正被修改时，它们被检出给单一的用户。工作在同一个 项目312的其他设计者302将不能看到修改的情况，直到对象312被 被核查返回。如果一个设计者302企图修改已经被另一个设计者302 检出的对象312，他们将会被通报，该对象正被使用并且将被告之哪 一个设计者检出了此对象312。
当一个对象312被核查返回时，产生此对象312的新版本。那个 新版本将是该项目314中唯一的对象312的版本。使用同一个对象312 的其他项目314将不使用这个新版本，而是继续使用他们正在使用的 对象312的相同的版本。以此方式，在数据仓库310中每一项目314 有它自己的对象312的版本依赖的视图。如果当前项目314需要在另 一不同的项目314中修改的对象312的版本，则该版本可被引入到当 前项目314中。
项目314包含下列属性108：名称、创建者、描述、最后期限、 设计者和任务安排。名称、创建者和描述属性108分别记录了项目314 的名称、创建者和描述。最后期限属性108记录了项目完成314的真 实世界的最后期限。设计者属性108特指工作在此项目314中的实际 的设计者302。一个项目314中可被访问的版本对象312通常限定到 安排了此项目任务的设计者302。任务安排属性108给特定的设计者 302安排编排成项目314的版本对象312。任务属性108也可以跟踪安 排的对象被完成的最后期限，及对象312事实上是否已被完成。
通过跟踪任务，有可能创建一个诸如图12所示的项目管理接口 318。利用该项目管理接口318，有可能在一个单一的屏幕上跟踪一个 项目中所有的对象312、安排该对象312任务的设计者302、最后期限 日期、及对象312完成的状态。
用户接口320
图13表示的是过程设计器300的用户接口320。在界面的顶部是 ID标题行322，它包含了被编辑的项目314的名称。在ID标题行322 的下面是菜单条324和工具条326。菜单条324、工具条326都按标准 的接口设计，并且设计者302使用它来访问过程设计器300中的程序 命令。程序命令也可以通过弹出式菜单和热键来访问，它们也是现有 技术中标准的技术。
用户接口320还包括三个面板：选择面板328，编辑器面板330 和特性面板332。为了按照面板的重要性分给这些面板或多或少的面 积，这些面板可以被调整大小。选择面板328列出所有在本项目314 中有用的仓库对象312，按照对象类型组织在一起。在选择面板328 中的可视化的指示器表示所列对象312是否已被选中、已被改变和该 过程设计器是否允许编辑上述对象312。编辑器面板330是组件110 被设计的地方。编辑器面板330的外观和操作方式将会根据当前被编 辑的对象的不同而有所变化。特征面板332显示并可以编辑编辑器面 板330中被选择的对象312的特征109。选取的面板可以被用于为每 一对象类型组织不同类型的特征109。
控制流编辑器340
如图14所示，当一个过程120、路由器140或控制器150通过用 户接口320进行编辑时，编辑器面板330包含控制流编辑器340。控 制流编辑器340的主要用途是编辑控制流，获得数据映射和调整各种 组件110的特征109。
编辑器元素
当使用控制流340的时候，设计者302能够从选择面板328中选 择仓库对象312，并且为了编辑它们，可以放大和缩小独立的组件110。 组件110可以以各种方式放大，例如通过双击一个代表组件110的图 标。当设计者302放大一个组件时，选择面板328并不改变。代替它 的是，在选择面板328上的被选择的仓库对象312和编辑器堆栈334 的组合将唯一的标识编辑器面板330中正被显示的组件110。如果直 接从选择面板328进行了一个新选择，那么堆栈334的内容被重新设 置。因为堆栈334表示的与选择面板328一致，所以就很清楚，图14 表示的是索赔处理过程120的定义。如果编辑器堆栈显示“<<索赔处 理<<索赔回顾”，这将表示在放大索赔处理过程120之后正在编辑索 赔回顾子过程122。
控制流编辑器340包含代表组成被定义过程120的多个组件110 的图标342。值得注意的是，图标342不仅代表构成过程120的组件 110，也代表过程120自身的事件102。这样图14显示的是单一的动 作104的图标(所示为一个“走”交通灯)，两个结果106的图标(所 示为一个“停”交通灯)，和子过程122的图标(所示为小的流程图)。 在图标之间的箭头344表示过程120的控制流。在编辑器面板330中 显示的图标最好对于设计者302是可认识的和可理解的，在优选实施 方案中使用的真正的图标342并不是本发明的至关紧要的部分。图标 342的变化落在本发明的保护范围之内。
命令
一些可以在控制流编辑器340中执行的操作表示在下面的图表1 中。
                        表1 操作 定义 新组件 添加一个新组件110(受图4中的层次规则限制) 从仓库增加 从仓库中310添加一个可重用对象312(也受层 次规则限制) 步入 如果被选择的组件110是一个容器112，编辑器 面板330更新成被选的组件110的内容，同时堆 栈334更新显示带层次的内容。 步出 重新设置编辑器面板330为父容器112 选中 使现在的组件110可以被编辑 登记 登记一个被修改的组件110的变化 回复 将组件110回复到选中前的版本 安排任务/重新安排 改变组件110的任务安排 组件重命名 重新命名组件 删除组件 从内容中删除组件110，但(如果不可重用)，在 仓库310中组件110不能被删除 定义属性 定义所选组件110的属性108
为了定义一个过程120，一个设计者302会首先创建过程120的 部分或全部的组件110。新组件110通过从菜单条324、工具条326 或弹出式菜单中选择创建所需组件类型的命令来创建。只有那些图4 中所示的组件层次许可的组件110能够被创建。当每一组件110创建 时，一个代表组件110的图标342就会放置在编辑器面板330上。通 过从列在选择面板328上的仓库对象312中选择组件110，先前存在 的、可重用的组件110也能被添加到所选过程120的定义中。
当图14的索赔处理过程120首次被创建时，控制流编辑器340 显示缺省动作104“开始”和缺省结果106“完成”。为了创建所示过 程120，设计者302添加了一个第二结果106，并且重新命名了动作 104和结果106，分别为“索赔数据已接收”，“索赔被批准”和“索赔 被拒绝”。设计者302接着创建了一个新子过程122并且将它命名为“索 赔回顾”。设计者302还定义了索赔处理过程120的“决策标准”，“客 户”和“索赔”属性108，在图14中通过检查特征面板332可以被看 到。只要通过简单地执行“定义属性”命令就可以实现。决策标准属 性108是一个决策标准292资源，同时客户和索赔属性被定义为业务 实体260。客户业务实体260由数据域和其他的预定义的业务实体260 组成，例如名称、客户ID、地址和电话号码。相似地，“索赔”业务 实体260可以包括描述索赔原因、索赔金额和索赔是否已被接受或拒 绝的域。
如果索赔回顾子过程122被选择而没有放大该子过程122，则该 子过程122为高亮度显示，并且其后索赔回顾子过程122的属性108、 动作104和结果106被显示在特征面板332里，如图15所示。利用这 种方式，有可能无需不改变堆栈334的内容，就可以看到组件110的 属性108和事件102。如该图所示，索赔回顾子过程有三个属性108 (“客户ID”、“索赔原因”和“索赔金额”)，一个单一的动作104(“索 赔请求收到”)，和两个结果106(“被批准”和“被拒绝”)。虽然没有 在图15中显示，但是索赔回顾子过程122很可能包括一个任务130， 它准许一个终端用户602决定是否该索赔应该被批准还是被拒绝。
控制流配线
通过为控制流编辑器340上的图标“配线”，为索赔处理过程120 创建了控制流。作为配线的一部分，本发明将一个结果106和一个动 作104连接到一起，将数据从装入的容器112映射到被装的组件110， 以及创建所需的属性108以使数据映射。这些步骤显示在图16的流程 图350中。
流程图350的第一步352是简单地拖拽光标从一个图标(源元素) 到另一个图标(目标元素)，它在控制流编辑器340上产生了从源拖拽 到目标图标342的箭头344。此箭头344表示了从源元素结果106到 目标元素动作104之间的连接。因为源元素可能具有多个结果106， 而目标元素也可能有多个动作104，所以重要的是设计者应该被允许 选择在该连接中要被使用的事件102。此步骤在步骤354中，通过一 个提供可能的事件102供用户选择的弹出式窗口来完成。图17中显示 了这样一个窗口346的例子。在本案中，此窗口346显示了在索赔回 顾子过程122(具有两个结果106：被承认和被拒绝)和索赔处理过程 120的索赔批准结果106之间的连接。当设计者302在此窗口中选择 完恰当的事件102之后，在图标342之间的箭头344就会加上源元素 的所选结果106的标签。通常，目标元素的所选动作104也要在控制 流编辑器340上标识。
因为有非常多的信息要被传送到控制流编辑器340的图形接口 中，所以仅通过检看图标342和箭头344就可以了解大量的有关索赔 处理过程120的控制流。例如，在图14中，很清楚的是，被定义的过 程120具有一个动作104和两个结果106。动作104被命名为“索赔 数据记录”，并且它激活索赔回顾子过程122。从这个子过程产生两个 可能的结果106，即“被批准”或“被拒绝”。如果接收到被批准的结 果106，则索赔处理过程120的“索赔被批准”结果106被激活。如 果从子过程122接收到被拒绝的结果106，则“索赔被拒绝”结果106 被激活。
似乎比较奇怪，索赔数据记录动作104被连接到索赔回顾子过程 122的一个动作104上。通常，连接发生在一个结果106和一个动作 104而不是两个动作104之间。此难题的答案在于被定义的组件的事 件102在控制流编辑器340中被处理的方式。虽然动作104和结果106 表面上不是索赔处理过程120的组件110，它们之所以在控制流编辑 器340中被这样处理，是出于控制流配线和数据映射的目的。例如， 索赔数据记录动作104被处理就好象是它是一个被包含的具有单一事 件102的组件110，即一个名称为“索赔数据记录”的结果106。虽然 一个动作104被作为一个有唯一结果106的组件处理看起来似乎不寻 常，但是为了使索赔数据记录动作104的“结果”能与索赔回顾子过 程122的索赔已接收动作104连接，这是需要的。相似地，索赔被批 准结果106和索赔被拒绝结果106被作为每一只有唯一的事件102的 被包含的组件110处理，即带有相同名称的一个动作。
数据映射
数据映射是图16中说明的程序的最后一步356，它之后程序结束 于步骤358。数据映射被定义成从一个被包含的组件110的属性108 的任务安排映射到里面包含该组件110的容器112的属性108。如图 15所示，索赔回顾子过程122被包含在索赔处理过程120中。这样， 在例子中，数据映射可以通过映射索赔回顾子过程122的属性108到 索赔处理子过程120的属性108来完成(即如图14所示的“决策标准”、 “客户”和“索赔”)。
典型地，映射可以通过简单地双击被包含的组件110的一个动作 来完成，例如图15中所示的索赔回顾子过程122的“客户ID”属性 108。这将打开一个数据映射窗口347，如图18中所示。窗口347的 左侧指明了当前正在映射的属性108是索赔回顾子过程122的“客户 ID”属性108。虽然没有在图18中显示，让用户从显示在左侧348的 组件110(当前正被映射的组件110)的所有属性中选择是可以的，例 如通过使用下拉式菜单或其他用户接口工具。
右侧349列出了容器112的属性，其包含正被映射的组件110， 即索赔处理过程120。在此例中，索赔处理过程120的三个属性108 是决策标准、客户和索赔属性108。注意客户属性108是一个已定义 的业务实体260结构，其由名称、客户ID、家庭地址、业务地址和业 务电话号码组成。从右侧349选择一个属性108并且点击OK按钮， 使数据在组件110和包含组件110的容器112的属性108之间映射。 在图18中，索赔回顾子过程122的客户ID属性108将被映射到索赔 处理过程120的客户属性108的客户ID域。
当然，还有其他的方法和用户接口也可被用于完成组件110和包 含它们的容器112之间的属性108映射，并且仍然落在本发明的范围 之内。例如，比起直接连接组件110和容器112的属性108，将属性 108赋值给事件102可能会更好。在这种情况下，通过把第一组件110 的属性108赋值给事件102的属性108，第一组件110的属性108可 以被传递给第二组件110，将第一组件110和第二组件110连接起来。 可辩论的是，理论上，通过事件102的属性108进行的组件属性108 的传递是一个更清晰的方法，因为通过使用事件102，数据映射和控 制流都可能专有地发生。然而，实际上，终端用户更倾向于直接将一 个组件110的属性108赋值给它的容器112的属性108。
任务编辑器380
当一个任务130正在被编辑的时候，编辑器面板330进入任务编 辑器模式380，如图19所示。通过从选择面板328中选择一个任务130， 或通过在控制流编辑器模式340中放大一个任务130，任务130被编 辑。编辑一个任务130比编辑一个过程120更复杂，因为定义一个任 务130经常需要一个用户接口的定义和外部业务数据和逻辑的使用。 因此，任务编辑器380给设计者302提供了图形化地建立用户接口的 方法而无需编程。任务编辑器380还将用户接口组件和数据资源250 连接起来，并且将额外的业务逻辑或集成和一个外部系统通过使用适 配器240和控制器150合并起来。
任务编辑器380包含编辑器堆栈38、一个视图选择接口384、一 个面板组件选择区386、一个面板设计区390和对象井392。任务编辑 器380的编辑器堆栈382具有和控制流编辑器340的编辑器堆栈334 同样的功能。视图选择接口384使设计者302可以选择当前要被编辑 的视图170。如上所述，任务130有一系列视图172，包含任务130 的所有的视图170，每一视图170只工作在单一的操作环境下并且由 一个或多个面板174组成。任务编辑器380的面板组件选择区386可 以为当前的面板174选择单独的GUI组件388(例如文本域，单选按 钮，复选框等)。在图19中，只有Swing(或Java)组件388是可见 的，以表示Java操作的当前视图170。面板设计区390是设计者302 将从组件选择区386选出的组件388合并进一个面板174，以供终端 用户602使用的地方。
对象井392包含数据控制器294。如上所述，数据控制器294代 表所有对于数据和面板组件连接可用的数据。特别是，数据控制器294 将包含被定义的任务130的属性108，还有通过适配器240和控制器 150来访问的全程数据。除了数据控制器294，对象井392还包括为任 务130定义的所有动作104和结果106，以及已经为任务130定义完 成的面板174、任务控制器176、控制器150、通报器230和适配器240。
在某些方面，定义一个任务130的过程与定义一个过程120很相 似。通过控制流编辑器340，任务130可以在包含它的过程120中被 创建。通过在控制流编辑器中选择任务130，而不“放大”它，任务 130的动作104、结果106和属性108可以在控制流编辑器340的特征 面板332中被定义。如上所述，在过程120中，任务130也可以被连 接到其他的组件110。数据也可以被从过程120的属性108映射到任 务事件102的属性108。
当一个任务130从控制流编辑器340中被放大或从选择面板328 中被选择时，任务编辑器380被初始化。任务编辑器380然后被用于 创建视图170，为视图170设计面板174和任务控制器176，通过连接 面板组件388和实际业务数据以及任务事件102来完成必要的数据配 线。特征面板332被用于为任务130本身的特征109，以及用于定义 任务130的对象的特征109赋值，例如组件388、面板174或视图170。
为一个任务130创建一个视图170和它的面板174的过程显示在 图20的流程图400中。为了创建一个新视图170，设计者302只需要 选择一个命令来创建一个新视图170，它需要设计者302为了这个视 图170选择操作系统(步骤402)。设计者302接着为这个视图170创 建一个新面板174，例如通过选择一个“新面板”命令，如步骤404 所示。一旦面板174建立起来，它就会被添加到那个视图170的对象 井392里。
为了编辑面板174，面板174被从对象井392中选择出来(步骤 406)。然后设计者从面板组件选择区386中选择面板组件388，并且 将组件直观地安置在面板设计区390上。各种面板组件388的属性108 通过选择组件388和改变出现在特征面板332上的属性来定义(步骤 408)。
在本发明中，一旦为了便于与终端用户602的交互将这些组件388 设置到一个面板174上，就需要将数据相关的组件388与资源250建 立联系(或说“配线”)。通过从对象井392中选择数据控制器294和 拖拽光标到被配线的数据组件388，在步骤410中完成数据配线。一 个窗口打开，它使数据组件388可以与任何属性108或定义在数据控 制器294里的外部数据连接。一旦配完线，数据组件388将直接关联 到数据控制器294中的数据，允许显示并可以通过终端用户602修改 外部数据。数据控制器294建立后，做面板组件388的这种配线就不 费力了。
数据组件388配线后，还必需为面板174上的控制导向组件388 指定含义，例如当“提交”或“OK”按钮被按下时，产生一个特定的 结果106。同时也需要将动作104连接到面板174上，以使得当动作 104发生时，特定的面板174被打开和显示给终端用户602。这些需求 在步骤412中完成。因为对象井392显示了当前任务的动作104和当 前视图的面板174，所以连接动作104到面板的动作非常简单。所有 必需做的仅仅是点击一个动作104并拖拽光标到所需的启动面板174。 一旦完成，一个窗口打开，以便让设计者302选择此动作104将使面 板174显示还是隐藏。为了连接一个按钮或其他的面板组件388到一 个结果106，设计者302仅需要选择在面板设计区390上的组件388， 并拖拽光标到所需的结果106。一个弹出式窗口跟着会确认在组件388 和结果106之间所需的连接。
也可能必需的是让一个控制导向组件388创建一个业务实体260 的新实例。为此，一个被称为BE工厂的对象被创建在对象井392中， 并与业务实体260相关联。BE工厂跟着被连线到一个控制组件388， 以使得当终端用户选择控制组件388(例如通过按一个面板174上的 按钮组件388)时，业务实体260的一个新实例被创建。
如果一个设计者302希望在一个视图中使用多个面板，步骤414 会返回控制到步骤404，使得可以添加另外一个面板。如果不需要设 计更多的面板174了，就会提交给用户创建一个任务控制器176的选 项。任务控制器176是用于帮助协调为一个特定视图170创建的各种 面板174的对象。在步骤416中，为了创建一个任务控制器176，设 计者302使用一个命令创建一个新任务控制器176。一旦建成，任务 控制器176就会出现在GUI设计面板的对象井392中。需要多少，设 计者302就可以添加多少任务控制器176。
任务控制器176使用户可以创建一个多面板视图170，并且一般 可以协调在面板174中的更高层次的交互行为。创建多面板接口或高 层交互行为所必需的元素和步骤在现有技术中已是广为人知的。在本 发明中，任务控制器176的唯一独特的元素是在任务控制器176中事 件102和属性108的使用。通过给任务控制器176事件102和属性108， 本发明的任务控制器176能够很容易地被连接进控制流和数据映射 图。
一旦任务控制器步骤416中被定义了，在步骤418中创建一个视 图170的程序也就完成了。当然，创建一个视图416的步骤并不需要 跟在线下面。事实上，任何需要改动的时候，我们都期望设计者302 会回到视图170的定义，并且修正面板174、任务控制器176和数据 配线。
值得注意的是，任务编辑器380的上述描述假设了一些和一个完 成任务所必要的终端用户602的交互。有可能要用到中间件适配器240 来简单的启动一个外部应用，以完成一个任务130。在这种情况下， 创建任何视图170、面板174或任务控制器176都不是必需的。全部 所需的仅仅是创建恰当的适配器240，连接和数据映射适配器的事件 102到任务130的事件102。用这种方式，控制流被传递到外部应用， 数据可以在过程模型100和外部应用之间流动。
过程服务器500
当过程模型100被定义完成后，过程设计器300产生一个配置包 并且将它安装在一个过程服务器500上。配置包包含执行运行时间应 用时所有必要的信息，包括经过编译的过程模型100、相关的类和对 象、和中间件适配器240。配置包同时也校验过程120定义的一致性 和完整性，以及仓库对象312的登记状态。
一个更新过的过程模型配置包的安装可以在服务器500启动和运 行的时候进行。此机制允许实时的在运行的服务器500上覆盖一个已 修正过的或一个新的过程模型100。当一个修正过的过程模型100正 在被配置时，已经进行中的任务130可以仍按任务130的旧定义进行。
一旦配置包被安装在过程服务器500上，过程服务器500的运行 时间系统就被接管。运行时间系统中断包含在运行时间模型中的过程 数据，对被终端用户602获得的输入和分配任务的过程起作用。运行 时间系统也维护有关用户和组的信息，为可以登录到过程服务器500 的用户授权，以及维护服务器500的访问控制策略。通过一个运行在 过程服务器500上的用户管理者应用程序，这些信息被一个或多个系 统管理者502控制和管理。
过程服务器500必须维护每一过程120和任务130的状态。每一 过程120可能是下列的状态之一：非活动的、活动的、暂停、完成或 中断。由任务130中的角色特征109决定，任务130被赋值给角色270。 当一个任务130准备赋值时，它被放入每一可以处理此任务130的角 色270的队列。过程客户600接着从队列中取出任务130执行。如上 所述，可能要定义在被视为完成之前必须完成该分配的任务130的终 端用户602的分布和数量。过程服务器500跟踪分配给终端用户602 的任务130的完成状态，为的是知道什么时候任务130被认为是完成 了。当达到正确的数值时，任务130不再提交给过程客户600去完成。
过程客户600
过程客户600是让终端用户602登录进过程服务器500和观看、 取得并且执行任务的前端应用。一旦连接到一个过程服务器500，按 照登录用户602的角色和属性，过程客户600就会被通报位于过程服 务器队列里的有效任务。这些任务130显示在一个任务列表604里， 如图21所示。任务列表604显示了任务130的名称、角色270、优先 级和安排任务的时间。
在任务列表604中的任务130可以被接受、退回、完成或中止。 当一个任务130被接受时，过程服务器500标记此任务，并通知在相 同的任务安排的角色270中的其他用户602。在此时的过程服务器500， 任务130不会从任务130队列中移走，因为一个已经接受了一个任务 130的终端用户可以将未完成的任务130退回给过程服务器500。如果 一个任务130已经按这种方式退回，则过程服务器500移走该任务安 排并且使此任务130对所有的在被分配的角色270里的用户602再次 有效。当一个用户602完成了一个任务130时，过程服务器500将从 未完成任务130队列中移走此任务130。
对于系统管理者502，在一个任务130被分配后，中止它也是可 能的。当一个任务被中止时，过程服务器500从队列中移走任务130。
本发明不该视为是对它们的所有细节的修改的限制，可能对它们 所做的改变并不脱离本发明的精神和范围。例如，有可能使用另外的 或更少的组件100来实现本发明的过程模型100。具有只支持唯一一 个操作环境的视图170，或不用角色270直接分配任务130给用户280， 都会完全落在本发明的范围之内。特性和元素的许多种可能的组合也 可能在本发明的范围内，所以它的范围仅应该由下面的权利要求来限 制。
本申请要求了临时专利申请的救济，美国序列号：60/191,166，提 交日期：2000年3月20日。