1. <tbody id="adk9k"></tbody>
    <em id="adk9k"><ruby id="adk9k"></ruby></em><dd id="adk9k"><track id="adk9k"></track></dd>
    1. <dd id="adk9k"><center id="adk9k"><noframes id="adk9k"></noframes></center></dd>

      产品数据管理PDM中工作流引擎技术设计

      工作流的概念最早起源于生产组织和办公自动化,1993年,国际工作流管理联盟(Work flow Management Coalition,WfMC)对工作流管理系统的相关术语、体系结构、参考模型及应用编程接口等方面制

      4.1产品数据管理中工作流管理技术基础
          工作流的概念最早起源于生产组织和办公自动化,1993年,国际工作流管理联盟(Work flow Management Coalition,WfMC)对工作流管理系统的相关术语、体系结构、参考模型及应用编程接口等方面制定了一系列标准。工作流管理技术是实现企业业务流程管理自动化的一项重要的计算机技术。工作流技术作为计算机支持的协同工作(CSCW)研究的一个重要方向,工作流技术管理的主要目标是通过调用有关的信息资源与人力资源来协调业务过程中的各个环节。使之按照一定的顺序依次进行,从而实现业务流程的自动化。在这个过程中,各种文本、信息和任务都根据设定的规则,从一个人/地方传送到另一个人/地方。
       
          WfMC提出的工作流管理系统的体系结构如图4.1所示,这个体系结构给出了抽象的工作流管理系统的功能组成和接口,它能够满足工作流管理系统和产品所应该具有的主要功能特征,可为实现工作流产品之间的互操作提供公共的基础。但是,组成工作流管理系统的每个功能部件可以在不同的软硬件平台上采用不同的方法实现,同样接口也可+以在不同的软硬件平台上采用不同的设计技术和编程语言进行编程。
       
      图4.1WfMC工作流管理系统的体系结构
       
          一般来说,工作流管理系统的研发商也不会将这些部件之间的所有接口完全对外丌放,但是为了实现不同工作流系统之间的集成,会按照互操作和协作的不同要求在一定层次上开放其接口。从图4.1可以看出,工作流管理系统主要由三类构件组成,这三类构件分别是:

          (1)软件构件:完成工作流管理系统不同组成部分功能的实现,对外提供服务;

          (2)系统控制数据:在工作流管理系统种的一个和多个软件构件使用的数据;

          (3)应用与应用数据:对于工作流管理系统来说,它们不是工作流管理系统的组成部分,而是属于外部系统和数据,它们被工作流系统调用来完成整个和部分工作流管理的功能。
       
          WfMC也提出了一个工作流参考模型,约定了工作流管理系统的应用接口及主要特性,目的是为了实现工作流技术的标准化和开放性,图4.2为工作流参考模型。工作流管理联盟给出了五类接口:


          .接口1,工作流服务和工作流建模工具间接口,包括工作流模型的解释和读写访问;

          .接口2,工作流服务和客户应用之间的接口,这是最主要的接口规范,它约定所有客户方应用和工作流服务之间的功能访问方式;

          .接口3,工作流引擎和应用间的直接接口;

          .接口4,工作流管理系统之间的互操作接口;

          .接口5,工作流服务和工作流管理工具之间的接口。
       
      图4.2WfMC的工作流参考模型图
       
          工作流管理系统参考模型各部分功能如下:

          (1)工作流执行服务
          它由一个或多个工作流引擎组成(在分布环境下,由多个工作流引擎组成)提供了过程实例和执行的运行环境,工作流执服务的主要功能是:

          1)解释过程定义,生成过程实例,并管理其实施过程;

          2)依据工作流相关数据实现流程活动导航,包括顺序或并行操作、期限安排等;

          3)与外部资源交互,完成各项活动;

          4)维护工作流控制数据和工作流相关数据,并向用户传送必要的相关数据。
       
          工作流执行服务通过下面两种途径使用外部资源,一是客户应用接口,工作流引擎通过任务项列表管理来管理资源,任务项列表管理器负责从任务项列表中选择并监督工作项的完成。二是直接调用应用接口,工作流引擎直接调用相应的应用来完成一项任务。这主要是针对基于服务器的无需用户参与的应用,那些需要用户操作的活动则通过任务项列表管理器来调用。
       
          在分布式的工作流执行服务中,多个工作流引擎系统协同工作,推进工作流实例的执行,每一个工作流引擎控制过程的一部分,并使用相关的资源和应用工具,这种执行服务需要共同的命名和管理范围,便于过程定义和用户/应用名称的一致。分布式的工作流系统采用特定的协议来同步各个工作流,工作流执行服务中这些协议可以采用不同方式实现。当选用不同的工作流系统产品时,各工作流引擎之间需要一个标准来进行转换,能够在异构的工作流之间传递过程、子过程及活动,支持共同的管理职能。
       
          (2)工作流引擎
          是一个为工作流实例提供运行执行环境的软件服务或“引擎”。它主要提供以下功能:

          1)对工作流过程定义进行解释;

          2)控制过程实例的生成、激活、挂起、终止等;

          3)控制过程活动间的转换,包括串行或并行的操作、工作流相关数据的解释等;

          4)支持用户操作的界面;

          5)维护工作流控制数据和工作流相关数据,在应用或用户间传递工作流相关数据;

          6)提供用于激活外部应用并提供工作流相关数据的界面;

          7)提供控制、管理和监督过程实例和活动实例的功能。
       
          (3)工作流建模工具
          主要用于分析、建模、描述并记录业务过程。它输出一个能被工作流引擎动态解释的过程定义。不同的工作流产品其建模工具输出的格式是不同的,接口1不仅使工作流的定义阶段和运行阶段分离,使用户可以分别选择建模工具和执行产品,还可以使不同的工作流产品合作提供一个过程定义的运行服务环境。
       
          (4)工作流管理工具
          主要负责对工作流实例的运行进行监控。管理员可以通过工作流管理工具获得目前各个活动的运行情况报告,并干预实例的推进,工作流队列的管理。
       
          WfMC工作流参考模型涉及到三种数据分别是:
          1)工作流控制数据(workflow control data),工作流执行服务/工作流引擎通过内部的工作流控制数据来辨别每个过程和活动实例的状态。这些数据由工作流执行服务/工作流引擎进行控制。用户、应用程序或其它的工作流引擎、工作流执行服务不能对其直接进行读写操作,它们可以通过向工作流执行服务/向工作流引擎发送消息来获得工作流控制数据的内容。

          2)工作流相关数据(workflow relevant data),工作流管理系统通过工作流相关数据来确定过程实例状态转换的条件,并选择下一个将执行的活动。这些数据可以被工作流应用程序访问并修改。因此,工作流管理软件需要在活动实例之间传递工作流相关数据。
       
          3)工作流应用数据(workflow application data),这种数据指那些由应用程序使用的数据。是针对应用程序的,是企业完成具体的业务功能所需要的数据,如产品结构数据、订单数据、生产作业计划数据等。工作流管理系统无法也不需要对它们进行访问。
       
          产品数据管理中工作流管理技术以工作流管理联盟提出的体系结构的参考模型为基础,根据产品数据管理的具体特点,设计产品数据管理系统中的工作流管理系统。主要在于实现产品数据管理中对工作流管理的需求。




       
      4.2产品数据管理中工作流过程模型
          一个企业从设计、生产到销售、管理等各个阶段,都可看作是一系列的过程。企业过程包括营销过程、产品设计过程、资金流过程、物流过程和计划流过程、各种数据的审批流程等,企业是这些过程组成的有机体。
       
          在产品数据管理中也存在各种各样的过程模型,如产品的研发流程、产品数据的审批流程、产品数据的变更流程、产品数据的发放流程和新产品研发的项目管理过程等,要实现对这些过程的管理,必须首先建立这些业务过程的模型,即进行业务过程定义,给出业务工作流模型。工作流模型是工作引擎设计的基础。
       
          本文根据产品数据管理中工作流管理的需要和具体特点,提出产品数据管理中业务工作流模型设计必须满足:

          1)企业用户,以简单,直观,容易掌握为前提;

          2)过程描述能力强,能够定义可能发生的各种过程逻辑;

          3)应该体现产品数据管理这一复杂系统的多视图特性。
       
          描述业务过程的模型有活动网络图、Petri网、状态图、语义一行为模型,各模型各有优缺点,其中活动网络图(Activity Network Diagram)是可读性最好的一种,对于非专业人员而言是最直观、最自然的过程表达方式。根据产品数据管理的特点和具体应用以及产品数据管理中工作流引擎的设计原则,以活动网络图为基础建立产品数据管理系统中的工作流过程模型。
       
          本文提出在产品数据管理中,业务过程模型的结构采用改进增强的活动网络图(有向图)的描述方式。一个业务工作流过程可以看成是一个由节点与连接弧所组成的有向图。其中,节点代表活动,连接弧代表活动间的顺序关系。同时,在活动网络图的基础上,增加了“状态”、“条件”和“自动机”这几个概念以增强过程模型的语义,使其能够处理足够复杂的业务过程逻辑来满足企业对产品数据管理的需求。
       
          产品数据管理中的业务过程模型由四部分组成,分别是‘‘过程模型”、“组织模型”、“资源模型”以及“工作流相关数据”。其组成结构以及内部各模型间的关系如下图4.3所示。
       
      图4.3产品数据管理中业务工作流模型的组成结构
       
          下面对本文提出的产品数据管理中业务过程模型一增强活动网络图,包括“结点”、“连接弧”、“状态”和“条件”等进行说明与定义。
           定义1:结点N是过程中的一个活动,即一个工作步骤,N=<n,t,d,u,m,preA,PostA,preC,postC,T>,是一个十元组。其中,n表示结点名称;t表示活动类型,结点类型分为原子结点a和子过程结点P:d是用到的数据集合,即结点的参数集合,包括活动执行时用到的输入、输出数据,这些数据都保存在相应的数据库中,数据库同时包括组织模型库和资源库,活动之间通过数据库和电子文档两种方式传递信息;u表示活动的执行者,可以是人员、计算机或其他机器:m表示手动执行或自动执行的执行模式;preA表示与当前结点相连接的前驱边集合,以及每条边的控制流程,可能的控制流程有:串联、与分叉、或分叉;PostA表示与当前结点相连接的后继边集合,以及每条边的控制流程,可能的控制流程有:串联、与合并、或合并、迭代。在此,前驱边与后继边组合起来,控制流程有五种情况:串联、与分叉一与合并、与分叉一或合并、或分叉~或合并、迭代;preC表示当前结点的前置条件:postC表示当前结点的后置条件,T表示结点执行所需的时间,即活动的持续时间。

          定义2:原子结点a是一个不能再分的结点。

          定义3:子过程结点P是可以细化成另一个过程的结点。

          定义4:有向边C描述活动之间的数据流动关系和控制关系。C=<NI,N2>表示从N1到N2的一条有向边。N1到N2分别为边c的前驱结点和后继结点。

          定义5:c--为结点N的前驱边集合:C--=<C|C.N2=N>。

          定义6:c++为结点N的后继边集合:c++=<e|c.NI=N>。

          定义7:有向图G表示一个过程,G=<n,N,C>为一个三元组,n是过程的名字;N是所有活动的集合,在此处称为结点:c是全部有向边的集合,它描述各活动之间的控制关系。
       
          通过对业务过程的定义,给出产品数据管理中工作流模型一业务过程的形式化描述。该模型只是一个静态模型,还不能直接用于工作流管理系统的中工作流引擎的执行。通常,将工作流的一次执行过程称为一个工作流过程实例,将工作流过程实例中的一个活动称为活动实例。要想在工作流引擎中运行业务工作流模型,首先要建立该工作流模型的一个实例,然后给出该实例运行之前所需要的全部数据,最后才能运行该实例。也就是说,产品数据工作流引擎中运行的是模型的实例,而不是模型本身。下面给出实例的定义。

          定义8:活动实例Ni是过程实例中的一个工作步骤,Ni=<n,st,et,s>。其中,n表示与此活动实例相对应的活动的名称;st表示Ni的开始时间;et表示Ni的结束时间;S表示Ni的状态,它可能的状态有初始、执行、就绪、等待、挂起和完成。在创建了活动实例之后,结点N的属性自动地赋给了Ni。
       
          定义9:过程实例Pi是工作流的一次执行过程,Pi:<n,np,st,et,S,Pri>。其中,n表示过程实例的名字;np是相对应的工作流模型的名字;st是过程实例的开始时间;et是过程实例的结束时间:s是过程实例的状态,它可能的状态有初始、运行、完成、终止;Pri是过程实例的优先级,工作流引擎利用它进行过程间的调度。本文提出的产品数据管理中业务工作流模型对象组成与运行关系如下图4.4所示。
       
      图4.4工作流模型对象组成与运行关系图
       



      4.3产品数据管理中工作流管理体系结构
      4.3.1产品数据管理中工作流管理体系结构

          本文提出的产品数据管理中工作流系统体系结构如图4.5,它是作为整个产品数据管理系统中的最关键的子系统之一。
       
      图4.5产品数据管理中的工作流管理体系结构
       
          在产品数据管理中的工作流管理系统作为系统核心的关键模块,它主要有两方面的功能,一方面提供业务数据的审批和审核流程,另~方面为产品数据的变更和技术状态管理以及项目管理提供技术手段。工作流引擎是整个体系结构的核心,提供业务过程的解释,任务的分发,执行等工作。
       
          工作流管理系统主要包括三部分的内容:图形化设计平台,执行平台以及外部结构。其中执行平台中的工作流引擎是最为核心的组件。系统中组织模型采用LDAP来进行管理。

          (1)工作流设计界面是用户使用的视图。具有为用户提供建立工作流的过程模型,装载工作流模板,定义规则设计,角色分配,数据交换映射等功能。其采用B/S结构,利用Java Applet实现。

          (2)工作流执行服务是管理视图。实现WfMC规定的工作流执行服务功能,它由工作流引擎、任务列表、规则引擎、模板装载器和工作流实例以及工作流监视器等组成,工作流引擎是其核心,负责工作流实例的创建、调度和跟踪等功能。同时,提供对外的接口。

          (3)数据库管理系统层,提供工作流系统的数据持久化处理,保存工作流的状态到数据库中,提供数据库适配器功能等。数据库处理接口,采用JDO方式,动态模板数据通过cvs或XML来表示。
       
      4.3.2产品数据管理中工作流引擎控制器结构
          在产品数据管理中,业务控制模型将组织模型和信息模型有机地结合在一起,它根据其中定义的业务规则,对业务过程中的各项业务活动的流转以及任务指派等工作进行控制和协调。控制模型是工作流引擎的控制中心。图4.6提出了引擎控制器的控制结构图。
       
      图4.6工作流引擎控制器结构图
       
          (1)度中心
          调度中心接受从外部接口发送过来有关流程控制的请求(如业务初始化、获取任务以及结束任务等),然后根据不同的请求类型调用相应的处理模块完成与本次请求相关的操作并将结果返回。由于是在DBM$内部实现工作流引擎的控制模型,因此有关请求的并发处理等问题完全可以交给数据库管理系统来完成,也不需要诸如请求队列等形式的数据结构。因此,事实上可以将调度中心看成一个多线程的并发服务器,它可以对多个外部请求提供并发服务。对外部请求的处理过程中肯定会涉及到对内部数据结构(即工作流引擎的数据模型)中有关数据的读写和更改操作,这些数据的完整性和互斥操作则可咀通过DBMS提供的各种加锁机制来实现,从而实现了多个外部请求之『蟊J的独立性。
       
          (2)任务管理
          任务管理主要根据调度中心的指示完成诸如任务创建、任务状态的转换以及相关数据的维护等工作。每次“结束任务”的外部请求将触发调度中心调用“任务管理”为后继活动(如果存在的话)创建新的实例。同时,其它不同的外部请求也将触发“任务管理”实施任务状态的切换。任务状态(活动实例)的状态关系将在后面叙述。

          (3)任务分派
          任务分派处理只是针对常规交互活动。通常情况下,在任务状态由“Pending”切换到“wairing”过程中完成任务的指派工作,即处于就绪状态的任务确定了其执行者(FCFk除外),任务指派过程首先根据任务指派基准确定可以执行此任务的群体人员,这是一个包含多个人员的集合,然后根据任务分派方法确定由这个群体中的哪些个体柬执行任务。

          (4)依赖检查
          依赖检查指的是活动的前依赖规则的检查。调度中心在将任务切换到就绪状态之前将进行相关的前依赖规则检查,只有满足检查条件的任务才可以进行状态的切换。

          (5)运转控制
          当应用发出“结束任务”的外部请求时,该请求将触发调度中心启动“运转控制”。运转控制的主要依据是为工作流数据模型中定义的后转发规则,后转发规则定义了当前活动与其后继活动之间的关系。运转控制的处理过程是根据“结束任务”请求中所携带的“任务结束标记”以及相应前趋活动和当前活动的活动标识,从而得到相应的后继活动列表,然后由调度中心根据后继活动列表启动“任务管理”为相应的后继活动新建任务实例。

          (6)启动控制
          启动控制负责常规自动活动所对应的自动执行体的启动并对其活动进行监控。
       
      4.4产品数据管理中工作流引擎实例算法、状态转换与调度
      4.4.1工作流实例算法

          根据我们在产品数据管理中业务模型的活动实例和过程实例的定义,给出工作流过程实例的执行算法如下。此算法由两部分组成:一是过程实例和活动实例的创建,二是活动实例的执行。
       
      4.4.2工作流实例状态转换
          根据定义8和定义9可知,过程实例和活动实例都分别存在不同的状态。在工作流实例执行时,过程实例和活动实例的状态会不断变化。过程实例有六个状态,初始、准备运行、运行中、挂起、结束和终止。初始状态是指该过程实例已经被创建,但还没有被执行的这个期间的状态;执行状态是指过程实例正在执行;完成状态是指过程实例已经完成:终止状态指过程实例被用户非正常取消。其状态变化关系如图4.7所示。
       
      图4.7过程实例的状态转换
       
          在上图中,发生状态转移(用箭头表示)来响应WAPI的命令。过程定义中的转移条件满足时,也可能发生状态转移。
          1)初始(Initiated):过程实例已经生成,但该过程实例目前还没有满足开始报告的条件。

          2)准备运行(Running):该过程实例已经可以执行,但还不满足执行第一个活动并完成任务项的条件。

          3)运行中(Acting):一个或多个活动已经开始执行(也就是已经生成一个或多个任务项并分配给了合适的实例)。

          4)挂起(Suspended):该过程实例正在运行,但处于静止状态,除非有一个启动命令或者外部事件促使该过程实例回到运行准备状态,否则所有活动都不会执行。

          5)结束(Completed):该过程实例执行已经完成,并且满足了结束该实例的条件,系统将执行过程实例结束后的操作,并删除过程实例。

          6)终止(Terminated):该过程实例在正常结束前被迫终止(如出现错误或者异常情况),系统将执行补救措施,并删除该错误过程。在工作流中的过程实例由活动实例组成,活动实例的状态变化如下图4.8所示。
       
      图4.8活动实例的状态转换
       
          活动实例包括以下几种状态:
          1)初始:一个活动实例已经生成,但还没有被激活;

          2)就绪:开始条件满足,活动就能运行:

          3)执行:活动正在执行实例;

          4)挂起:由于出现异常情况或错误,该活动实例被暂挂起,活动处于静止状态。

          5)执行后:活动执行完成,但结束条件不满足时的状态;

          6)复位:该活动实例在正常结束前被迫终止,恢复到初始状态;

          7)结束:该活动已经执行完毕,系统将进行活动后的导航工作,激活下一个符合启动条件的活动实例。
       
          工作流引擎的控制活动实例围绕上面的状态变化进行工作。工作流引擎的启动是由外部的事件请求触发的,在外部的请求下创建新的过程实例。工作流引擎启动,首选创建一个主过程,然后通过查询过程模板的解释数据表,创建一个过程实例,同时创建一个线程,在线程中创建过程的第一个活动的实例。此时过程实例处于初始状态、活动实例处于未开始状态,并且在过程实例控制表、活动实例控制表、工作机事务处理表中增加记录。在实例控制表记录创建的实例时间、实例标识号、过程类型、当前活动实例号、状态。在活动实例控制表中,记录活动实例的创建时间、活动实例标识号、过程实例号、状态。在工作事务表中,记录工作流的动作,即启动、创建过程实例、创建活动实例。
       
          工作流引擎根据过程模板数据表中描述的活动,开始条件判断创建的活动实例是否满足开始条件。若满足,将活动激活,进入就绪状态,修改活动实例控制表中对应的活动实例的状态为激活状态。同时判断活动的类型,若活动的类型为自动型,直接调用模板中指定的应用程序,此时修改活动实例控制表中活动为执行状态,修改过程实例控制表中活动为运行中状态;若活动为手动型,将活动实例的数据写入任务列表,等待用户响应,同时结束活动所在的线程,此时修改活动实例表中活动为挂起状态,修改过程实例控制表中的活动为挂起状态。若不满足,活动停留在初始状态,等待条件满足。工作流机会定时循环检测直到条件满足或出现错误中断,同时修改过程实例控制表中活动为准备运行状态。
       
          对于自动型的活动,执行后,若无错误或异常情况,将自动运行完成。完成后自动将完成的信息发送工作引擎,工作引擎将判断活动的结束条件是否满足。如果满足,将完成的活动从活动实例控制表中删除,同时根据工作流模板定义的转移条件,确定下一步应该开始的活动。在原线程中创建该活动实例,后继操作同上,同时将该活动实例标识号,记入到过程实例控制表相应的形式记录中。
       
          对于人工型活动,当用户从自己的工作任务表中开始处理该活动时,工作流引擎将得到消息,创建新的线程响应,修改活动实例控制表中活动为执行状态。当用户未完成而终止,工作流引擎将再次修该活动实例控制表中活动为挂起状态,同时结束所在线程,直至活动再次被执行。当用户完成活动,用户的应用程序将完成信息发送给工作流引擎,工作流引擎将判断活动的结束条件是否满足。如果满足,将完成信息从活动实例控制表中删除,同时根据工作流模板定义的转移条件,确定下一步应开始的活动。创建该活动实例,后续操作同上,同时将该活动实例标识号,记入到过程实例控制表相应的过程记录中。如果存在两个或两个以上的后续活动并行工作的情况,将在后文中描述处理方法。
       
          当工作流模板中定义的最后一个活动完成,工作流引擎将把过程实例控制表的对应的过程记录和活动实例控制表中的对应的活动实例记录删除。如果过程实例中的某~活动被手工删除,则工作流引擎将按工作流模板中的定义要求,对整个过程实例进行处理,然后删除过程实例,关闭相关的所有线程。
       
      4.4.3多工作流实例状态转换

          此外上述的每一步操作,同时记录在工作流引擎事务表中。上面描述仅是针对工作流处理唯一一个过程实例时的情况,但实际上系统运行,将是多个实例并行存在的。针对这种情况工作流引擎做如下处理:

          对于多个过程实例同时启动,首先在过程实例控制表中建立相应的过程实例,分配过程实例标识号,然后根据过程实例个数,创建同样个数的新线程,分别在新线程中斜建过程实例的第一个半自动实例,以后的处理与前面描述的处理方法相同。如果创建的线程总数受限制,线程则采用抢先原则,即谁先申请就先响应谁,未获得响应的按申请的先后、放入先进先出堆栈,等待有空闲的线程再响应。
       
          对于同一活动的后续活动是并行活动的,同样是增加新的线程处理,再遇到超过线程总数时,并行的活动就优先处理。再记录过程实例的当前活动实例标识时,并行的活动的标识号同时记入记录中。
       
          在用户创建了一个过程实例及活动实例后,过程实例刚刚创建时的状态为初始状态。当用户发出指令开始执行过程后,过程实例转入执行状态。有两种可能性使过程实例停止运行:一是过程实例执行完毕,此时过程实例的状态是完成态;二是过程实例被强迫终止,此时过程实例的状态是终止态。
       
          在用户创建了一个过程实例及活动实例后,过程实例开始时刻的状态为初始状态,同样,每一个活动实例在开始时刻的状态也为初始状态。在过程实例开始执行后,工作流引擎将调度各个活动实例的执行。当一个活动实例被激活时,它的状态从初始状态变为等待状态。在确认前置条件满足以后,则进入就绪状态。工作流引擎在调度执行时,将选择执行处于就绪状态的活动实例。被调度执行以后,活动实例的状态为执行状态。在活动实例的执行过程中,它有三种状态可能转变:一是活动实例执行完毕,活动实例的状态变为完成态;二是用户将工作流管理系统挂起,则状态变为挂起态;三是需要某些数据,但这些数据未曾获得时,状态变为等待状态。

          处于完成状态的结点通常是已经完成了一次活动,实现了既定的功能,在过程实例中可以不再进行考虑。但当该结点需要迭代执行时,则该结点会被重新执行一次。此时,需要把它的状态由完成状态变为等待状态,在所需的条件满足时,进入就绪状态,然后被调度执行。
       
          若一个活动实例原处于执行状态或就绪状态,此时可因挂起命令雨由原来的状态变为挂起就绪状态。当处于挂起就绪状态的结点接到解除挂起命令后,就由原来的挂起就绪状态变为就绪状态。挂起命令和解除挂起命令都由用户通过工作流引擎发出。
       
          若一个活动实例原处于等待状态,它可因挂起命令而变为挂起等待状态,直到解除挂起命令到来,才能把它重新变为等待状态。处于挂起等待状态的活动实例,将继续为所等待的事件到来提供服务,即当事件发生后,该活动实例就由挂起等待状态变为挂起就绪状态。
       
      4.4.4工作流实例调度
          在过程实例执行过程中,将出现这种情况,一个工作流模型的多个实例或不同工作流模型的不同实例同时存在,两且它们之间有可能存在资源(人、机器、计算机等)竞争。当多个过程实例对某种资源发生竞争时,需要由工作流引擎进行调度,才能使整个工作流管理系统顺利执行下去。如图4.9所示,有个过程实例对资源1发生了竞争,此时,调度问题可以看成是使平均流程时间最短的单机调度问题。
       
      图4.9过程实例调度队列
       
          根据过程实例的优先级进行调度。为了使占用资源的时间最短,即工作流实例的平均流程时间最小,采用SPT+AT规则来指定优先级。即:
       
          (1)首先运用SPT(shortest processing time)规则,过程实例的优先级为:zi=pi。其中,zi是过程实例i的优先级;pi是过程实例:i占用资源的时间,且pi≠pj,当i≠J。

          (2)当在两个pi相等的情况下,采用AT(arrivaltime)规则,即:zi=ri,ri为实例i的到达时间。在规则中,zi越小,实例的优先级越高,即zi=min zi。




       
      4.5小结
          本章研究“产品数据管理中的工作流引擎技术”。首先研究产品数据管理中工作流管理基础,对WfMC提出的工作流管理系统的体系结构和参考模型进行了研究。研究了产品数据管理中业务过程模型的表示,提出了产品数据管理中业务过程模型的三个设计原则:

          1)企业用户,以简单,直观,容易掌握为前提;

          2)过程描述能力强,能够定义可能发生的各种过程逻辑;

          3)应该体现产品数据这一复杂系统的多视图特性。
       
          在这些设计原则的基础上提出了产品数据管理系统中工作流模型为增强的活动网络图模型,采用增强的活动网络图表示产品数据管理中的过程模型。由于在多种不同结构的过程模型中(如活动网络图、Petri网、状态图、语义一行为模型等),活动网络图是可读性最好的一种,对于非专业人员而言是最直观、最自然的过程表达方式。
       
          产品数据管理中工作流模型应该是一种综合性的模型,不仅能够描述一个经营过程“是什么”的问题,而且还应该能描述“由谁做”、“怎么做”等方面的问题。因此,需要在过程模型的基础上,加入描述企业人员的组织模型,描述企业资源的资源模型以及提供信息定义的工作流相关数据,以使其成为一个完整的、具有多视图特性的模型,提出了产品数据管理中工流流模型的组成。同时,给出了以活动网络图表示的工作流模型的几个定义,工作流定义、活动定义、过程实例与活动实例等。
       
          提出了在产品数据管理中工作流系统体系结构以及工作层次,提出了工作流引擎的控制器的结构,研究了的各部分主要功能。研究并提出了工作流引擎中过程实例与活动实例的执行算法,过程实例与活动实例的状态转换关系,多个工作流实例的状态转换以及工作流过程实例的调度等,这些都是工作流引擎的主要关键技术。
       
          工作流模型表示是工作流技术的基础,工作流引擎根据工作流模型对工作流进行解释、执行、调度分配和监控其运行。工作流引擎的核心算法包括过程实例执行及状态转换算法、活动实例执行及状态转换算法,多过程实例、活动实例的调度等。本章从设计的角度分析研究了产品数据管理中工作流引擎的设计技术。
       
          本文下一章将具体介绍产品数据管理中工作流及工作流引擎技术的具体应用实现,同时,提出建立独立于应用的工作流引擎中间件,一方面为产品数据管理系统提供支持和服务,另一方面也提供给需要工作流引擎支持的应用信息系统使用。
       
       

      他们选择了我们
        1. 中车PLM:实现企业一体化设计、一体化采购主数据平台

        2. 金龙PLM案例:全车系产品配制管理,快速生成产品BOM与成本。

        3. 三一PLM案例:实现企业技术保累,协助企业研发过程。

        4. 一拖PLM:从源头达成零件管理

        5. 中石化PLM :全项目控制管理查看更多

        1. 正泰PLM:电器、结构、电子多专业协作平台

        2. 上柴动力PLM:产品模块化设计应用。

        3. 朝阳轮胎PLM:流程制造业PLM方案,配方与工艺管理。

        4. 皇明PLM:设计工艺制造一体化方案。

        5. 喜临门PLM:集团化应用,参数化产品BOM运算应用。

      了解更多
        1. 中兴汽车PLM :整车行业配制化产品管理方案。

        2. 铁科院PLM:企业研发业务,数据一元化管理

        3. 伊利PLM应用:食品行业配方与工艺管理PLM应用

        4. 中国航天二院:以PLM为中心的多系统集成应用。

        5. 徐工集团:复杂BOM的产品简化产品管理

        1. 创新精神2_2:创新是我们发展的源泉

        2. 创新精神:创新是我们发展的源泉

        3. 创新精神:创新是我们发展的源泉

        4. 创新精神:创新是我们发展的源泉

        5. 创新精神:创新是我们发展的源泉

      了解更多
        1. 京城重工PLM:设计工工艺制造一体化方案

        2. 中集华骏PLM:从客户需求参数化直接转化成产品BOM管理

        3. 聚光科技PLM:电子行业IPD管理模式PLM应用

        4. 舟山电力局PLM:大数据汇总管理,数据的快速转化与查询

        5. 东方电气PLM:汽轮机行业,一体化管理。

        1. 创新精神3_2:创新是我们发展的源泉

        2. 创新精神4:创新是我们发展的源泉

        3. 创新精神5:创新是我们发展的源泉

        4. 创新精神6:创新是我们发展的源泉

        5. 创新精神7:创新是我们发展的源泉

      了解更多
      联系我们
      本港台 <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>