专利名称：用于自上而下的企业过程定义和执行的方法和系统的利记博彩app
技术领域：
本发明涉及一种用于企业过程的自上而下的定义和实现的方法和计算机系统。
背景技术：
本发明可以使一个软件应用通过自上而下的定义和实现企业过程来协调整个企业的运作。企业过程，十分简单，是为了运作一个企业，该企业必须执行的过程。例如，一个处于产品销售商业领域的公司必须能为那些产品接收订单。接收订单和发货的整个行为可以被认为是一个企业过程。以一个较小的尺度来衡量，一个电话订单进入公司数据库也是一个企业过程。
用自上而下的方法来分析企业过程意味着该过程的定义始于企业的最高层。使用这种方法的一个分析人员可能从产品销售过程着手分析。产品销售过程可以被分解成较小一些的子过程，诸如接收客户订单和按客户订单发货。每一这些更深一层的子过程都可以被更进一步地缩小，直到每一雇员的任务都被以商业过程的模式阐明。
自上而下的定义企业过程的概念并不是新的。存在于现有技术中的图形软件工具有助于自上向下的企业过程模型的建立。使用这些现有技术工具的最终结果是该企业过程的详细、自上而下的定义。经理主管人员和分析人员会发现，对于浪费、无效率，这样详细的定义是有用的，并且一旦企业的过程被以此种方式明确定义，复制就会变得清晰。接着，该工具使企业过程可被再定义和简化，并且当其采用新的自上而下企业过程时，企业有希望能够变得更加有利可图。
不幸的是，该新定义的企业过程之后必须能在现实世界中被实现。正如任何一位主管都知道的，实现一个仅仅存在于纸面上的新过程从来也不会容易。首先，通常是企业过程的描述交给计算机软件开发人员，它们之后会以它们最佳的理解来试图实现它。其结果是，几乎从未确切地与企业分析人员开发的过程相配。企业分析员不能直接开发软件，而是必须代替依赖软件程序员去实现该定义的过程，这是该事实的一个固有的结果。
另一个要克服的困难问题是，即使一个单一企业过程的实现也要求计算机资源的协作。在每个大企业中，大量不兼容的计算平台、操作系统、网络协议、数据库和客户应用共存。因为不可能希望去除这样的不兼容性，所以为了实现一个新的企业过程，必须把各种系统集成。
近几年，一些企业已经转向面向消息的中间件(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 elsepriority＝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和PalmOS。在本发明的范围内，支持其他的操作环境也将是可行的。
因为需要为每一这样的环境产生单独的接口，所以在一个任务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
为了定义一个过程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，都会完全落在本发明的范围之内。特性和元素的许多种可能的组合也可能在本发明的范围内，所以它的范围仅应该由下面的权利要求来限制。
权利要求
1.一种用于定义和实现企业过程的方法，其包括a)添加组件到一个过程定义，包括至少一个需要用户交互的任务；b)为该任务定义接口元素；c)在过程定义的组件之间定义控制流；d)向一个过程服务器提交过程模型，用于执行控制流，并且通过定义的接口元素向终端用户提交至少一个任务。
2.权利要求1的方法，进一步还包括e)在过程定义的组件之间定义数据流。
3.权利要求2的方法，其特征是，至少一些组件具有事件，所述组件是一动作或是一结果，并且进一步的特征是，控制流至少部分是通过连接一组件的一结果到一第二组件的一动作来定义。
4.权利要求3的方法，其特征是，某些组件被包含于其他组件之内。
5.权利要求4的方法，其特征是，该组件具有属性。
6.权利要求5的方法，其特征是，定义数据流的过程包括将包含另一组件的一组件的属性与该被包含的组件的属性相关联。
7.一种产生一个企业应用的方法，包括以下步骤(a)确定多个定义一个工作流程的构件，每一构件是工作流程中的一个步骤的代表；(b)将该多个构件定排序并连接到一起，以创建一个工作流程模块；(c)在该构件的至少一个构件中，定义至少一个要被完成的任务；(d)将数据与至少一个任务相关联；(e)装载工作流过程模型到一个过程服务器上；和(f)在过程服务器上产生一个可供用户访问的客户应用。
8.权利要求7的方法，其特征是，每一构件包含至少一组件和资源其中之一。
9.权利要求8的方法，其特征是，该组件包含至少一容器和一个元素其中之一。
10.权利要求9的方法，其特征是，该容器包含至少一过程、一任务、一路由器和一控制器其中之一。
11.权利要求9的方法，其特征是，该元素包含至少一视图、一接合、一比较器、一记时器、一赋值器、一通报器、一动作-启动器、一适配器和一锁其中之一。
12.权利要求8的方法，其特征是，该资源包含至少一个业务实体、一个角色、一个用户、一个日历、一个决策标准和一个数据控制器其中之一。
13.权利要求7的方法，其特征是，步骤(b)包括图形化地显示该构件。
14.权利要求7的方法，其特征是，该任务包括一由计算机程序执行的工作单元。
15.一种用于定义和实现一个自上而下的工作流程的方法，包括以下步骤(a)确定工作流程中的最上层的过程步骤；(b)选择图形化显示的构件来代表每一个最上层的过程步骤；(c)将构件排列和连接，以创建一个最上层的工作流程模型；(d)确定在最上层的工作流程过程模型中的哪一个最上层的过程步骤是按照子过程的步骤控制的；(e)为步骤(d)中确定的每一个最上层的过程步骤，选择更进一步的构件来代表子过程的步骤，并且将这个选择出的构件与步骤(d)中确定的各自的最上层的过程步骤相关联；(f)将非控制数据与至少构件的一部分相关联；(g)将构件和至少一部分非控制数据装载到一个过程服务器上；和(h)运行包含任何相关联的子过程的步骤的该最上层工作流程模型。
16.权利要求15的方法，其特征是，每一个构件包含至少一个组件和资源其中之一。
17.权利要求16的方法，其特征是，该组件包含至少一个容器和一个元素其中之一。
18.权利要求16的方法，其特征是，该容器包含至少一个过程、一个任务、一个路由器和一个控制器其中之一。
19.权利要求17的方法，其特征是，该元素包含至少一个视图、一个接合、一个比较器、一个记时器、一个赋值器、一个通报器、一个动作-启动器、一个适配器和一个锁其中之一。
20.权利要求16的方法，其特征是，该资源包含至少一个业务实体、一个角色、一个用户、一个日历、一个决策标准和一个数据控制器其中之一。
21.权利要求15的方法，其特征是，该构件被图形化地连线在一起。
22.权利要求15的方法，其特征是，步骤(f)包括映射数据。
23.权利要求15的方法，还包括在一被连接的构件里修改子过程的步骤。
24.权利要求15的方法，还包括通过一过程设计服务器使该构件对用户有效。
25.权利要求15的方法，还包括要求具有关于一或多个子过程的特殊知识的人来帮助选择和排列代表它们的构件。
26.一个用于设计和实现一企业过程的系统，包括(a)一具有图形化接口的过程设计器工具，用于以自上而下的方法定义一个企业过程模型，该企业过程模型具有(i)至少一具有在至少两组件之间定义的控制流的过程；和(ii)至少一具有一定义的任务，每一个任务定义结合了一个用户接口，以执行任务和定义访问完成任务所需的业务数据；和(b)一个过程服务器，通过跟随过程里定义的该控制流和由用户接口向至少一个终端用户提交该定义的任务，该过程服务器能够配置该过程模型。
27.一个用于为企业创建和实现过程模型的系统，包括一包括图形化用户接口过程设计器，其用于开发组件和资源并且用于在上述组件和资源之间定义过程流和数据流，该过程设计器能够定义至少一个与上述组件和资源至少其中之一相关联的程序；一个过程服务器，用于运行该至少一个程序和用于按照过程设计器中定义的优先级计划分配任务；和一个过程客户机，其包括一个可操作的图形化用户接口，以使终端用户可以登录和连接到过程服务器，访问任何分配的任务和执行上述分配的任务。
28.权利要求27的系统，其特征是，该过程设计器给用户提供多个构件。
29.权利要求27的系统，其特征是，还包括一与过程服务器联系的系统管理器。
30.权利要求27的系统，其特征是，该分配的任务由计算机来执行。
31.权利要求27的系统，其特征是，该过程设计器使开发的组件和资源可用于其他的过程模型里。
32.权利要求27的系统，其特征是，还包括在该组件和资源之间定义一个公共的用户接口的工具。
33.权利要求27的系统，其特征是，还包括在组件之间、资源之间和组件与资源之间数据映射的工具。
全文摘要
本发明公开了一种利用一套软件工具图形化地定义自上而下的工作流程模型的系统和方法。本发明具有三个主要的组件过程设计器(300)，过程服务器(500)和过程客户机。过程设计器(300)可以使用户自上而下地定义企业过程而无需编程。过程定义由组件构成，例如任务和子过程。本发明中的任务将一个终端用户(602)完成任务所必需的所有的GUI面板结合到一起。事件连接了过程模型。过程模型也包括角色、终端用户(602)、业务逻辑和其他组件。适配器可以使本发明外部的业务数据和逻辑结合进过程模型中。过程模型定义接着被安装到过程服务器(500)上，它将任务提交给终端用户(602)。终端用户(602)通过过程客户机访问和执行任务。
文档编号G06Q10/00GK1419675SQ01806972
公开日2003年5月21日 申请日期2001年3月20日 优先权日2000年3月22日
发明者斯科特·欧佩兹, 阿莱克斯·艾尔金 申请人:伟博麦德有限公司, 斯科特·欧佩兹, 阿莱克斯·艾尔金