PDM协同开发的工作流管理

【导读】
工作流的概念源于办公自动化领域,它是针对日常工作中具有固定流程的活动而提出的。其目的是将工作分解成预先定义好的任务、角色,并按照一定的规则和流程来执行这些任务,同
3.1工作流概述
3.1.1工作流的相关概念

  工作流的概念源于办公自动化领域,它是针对日常工作中具有固定流程的活动而提出的。其目的是将工作分解成预先定义好的任务、角色,并按照一定的规则和流程来执行这些任务,同时对它们进行监控,达到提高办事效率,降低生产成本,提高企业的生产经营管理水平和竞争能力的目的。但是,工作流在目前还没有一个统一、明确的定义,不同研究者和产品供应商从不同的角度对工作流进行不同的定义。
 
  工作流管理联盟(WfMC)对其定义如下:工作流是一种能够完全或者部分自动执行的经营过程,它根据一系列的过程规则、信息和文档,在不同的流程执行人员之间进行执行和传递。更通俗的形式化定义为:工作流就是对一个项目的各个活动进行规划,明确各个活动的先后执行顺序和相互关系,设定各个活动的起始和终止条件,以及各个活动要达到的目标,指定活动的执行者和所使用的资源以及完成活动的期限等等。
 
  因此一个工作流可以用一个二元组来表示:W(A,C)其中A={a1,a2,…}表示工作流中的各个活动,在工作流模型中表现为节点;C={c1,c2,…}表示各个活动间的连接关系,在工作流模型中表现为节点间的连接弧;每个活动节点a又可以表示为一个五元组(t1,e,c,t2,s),其中t1表示活动的相关任务,
  e表示活动的执行者,
  c表示活动的起始和终止条件,
  t2表示活动的执行时间,
  s表示活动的当前状态。
 
  每个连接线c可表示为一个二元组(ns,ne),其中ns表示连接点的起点,ne表示连接线的终点。
 
  工作流程管理是对工作流程的构建、执行、维护和监控以及对流程的执行历史进行记录的管理方式,它将项目数据和有关过程进行有机的结合。WfMC对工作流管理系统(WfMS)的定义是:工作流管理系统是一套软件管理系统,它执行对工作流程的定义和管理,并按照在系统中事先定义好的工作流执行逻辑来推行工作流实例的运行。
 
  工作流管理系统不仅要能够完成对工作流程的定义,而且还需要将企业的工作流程转化为计算机可识别的格式,同时能够提供一套监测工具对工作流程的运行状态进行监控,对流程中的各活动进行调度和管理,同时还要提供人机交互接口,供参与人员执行各自的工作任务。与工作流有关的概念与联系如下图3-1所示:
 
图3-1工作流概念关系图
 
  工作流程:是指能够完成指定工作目标和策略的相互连接过程和活动的集合,如项目开发流程,图文档审批流程。
  工作流程定义:是工作流程的形式化描述,用来支持工作流系统的建模和运行的自动化。流程可以分为一些子流程和活动,其定义主要包括流程的起始、终止条件以及活动间的关系。PDM工作流管理子系统中的流程模板的构建即是工作流程定义的一个具体实例。
  活动:是实现过程逻辑步骤对工作任务的描述,可分为人工和自动两类处理方式,它是工作流程执行过程中最小的任务完成单位。
  流程/活动实例:是实现运行中的一个流程或活动。每一个实例能够代表一个可以独立控制执行,具有自身状态的线程,可被外界通过标识进行监控。
 
3.1.2PDM系统中的工作流管理
  在产品的整个生命周期内,不管是从整体出发,还是从某一局部环节开始,都得经过若干个不同的工作流程,每个流程都可能有不同的内容、不同性质的活动,有的工作流程甚至还嵌套另一工作流程。只有经历了事先设定的不同工作流程,产品的数据才会不断的产生和完善,最终成为有效的、能够指导实际生产的产品信息。
 
  因此在PDM系统中,应该根据企业的工作实际情况,制定符合本企业习惯的工作流程和管理规则,这便是工作流程管理。所以工作流管理是PDM系统中重要的功能之一,它是用来定义以及控制数据操作的基本过程,主要管理在用户对数据进行操作时人与人之间、活动与活动之间的数据流向,以及在一个项目的生命周期内跟踪所有的事物和数据。

  PDM系统的按照工作流管理的范围和功能进行划分,可以分为三种类型:任务管理,工作流管理,历史管理。
 
  任务管理:只是对任务的执行者和任务的数据对象进行的相关操作,以及根据操作对数据对象产生的影响,需要对相关人员发出通知等进行的管理,即主要管理哪些人在什么时候对哪些数据对象做了哪些事,以及对其他数据产生了哪些影响,应该通知哪些人。任务管理通常是单活动的管理。
 
  工作流管理:也称为流程管理,是对组成流程中的一系列活动以及活动间的相互关系进行的管理。在产品的设计与制造过程中,比如一张工程图纸的审批、发放,或者零部件设计、分析、制造等活动,都得按照一定的流程来进行,都称作工作流程管理。
 
  历史管理:数据的版本管理是对维护产品数据有效性和核查产品演变过程的必要手段,各项活动的完成情况及其过程也都应有完善的记录,便于将来进行查询和经验总结。
 
  PDM系统中工作流管理主要有审批流程管理和更改流程管理。
  一、审批流程管理:
  产品设计的有效性必须要经过审批流程的确认才得以生效。以前审批活动是在纸质上进行,现在企业应用PDM系统使得审批工作实现了计算机化的网上审签。审批文件在网上传阅,大大提高了审批效率;由于审批文件在不同的计算机上可以存档多个副本,使得审批工作的并行展开也成为可能。
 
  企业在长期的产品开发实践中,对文件、图纸、更改通知单等形成不同的审批流程,它们都是企业工作流程规章制度的重要组成部分。企业审批工作的结构化程度较高,是一种相对稳定的流程,如下图3-2所示。在PDM系统中,这些流程通常被制成工作流模板,在用户创建工作流时,可以调用这些工作流模板并做适当修改,即可形成具体对象的工作流定义。
 
图3-2企业的各种审批流程
 
  PDM系统对审批流程管理如下:首先,按照企业的习惯审批规则、审批权限以及审批顺序制定相应的审批流程;其次,在产品设计完成信息完整后,由设计者启动已经定义好的审批流程,需要将审批的设计资料、审查申请以及说明等链接到审批流程的文件夹中。
 
  这种链接操作很简单,只需要设计者在自己的文件夹中把这些文件拖至审批流程的文件夹中即可。审批流程启动后,PDM系统自动依次地将这些文件送到各个审批人员的任务列表中,并提醒他们送审的任务及相关资料已到。
 
  同时,PDM把送审资料标记为提交状态,使所有能够访问这些设送审资料的人员都只能浏览,不能对其修改。当某个审批流程活动需要多个审批者会签时,系统会将送审材料在每个审批者的工作文件夹中进行映射成为副本,使多个审批者可以并行的工作,同时对一份资料进行审核,以此提高审批效率。
 
  二、更改流程管理
  企业在生产中经常会遇到流程更改的情况,比如已经发布的图纸在使用中发现了问题,已经成型的产品构型发生了更改,这就需要对原有的工程图纸进行更改。更改的实现也要经过一定的流程,对这些流程的管理就是更改流程管理。一个完整的更改流程包括更改申请和更改实施两部分。
 
  设计变更的业务流程一般经历以下过程:首先由变更发起者提出变更申请;在提交变更请求的时候,需要提交变更的理由、变更的资料、变更的内容以及可能会对已经完成的工作产生的影响等;然后由上级主管人员对其审批。如果没有审批通过,则变更过程至此停止;如果上级批准了变更请求,则下达变更任务单,并通知有关人员,同时冻结需要变更的材料。
 
  具体更改任务的执行人员接到变更任务单后,必须按照变更说明,执行变更操作,对资料进行修改;经过对资料进行修改,产生新版本的资料。对这些资料还要进行审批,审批通过后,这些资料才可以发放。最后,向本资料所涉及的各个部门分发变更通知单。下图是典型的设计变更路程图,如3-3所示。
 
图3-3设计变更流程示意图
 
3.2协同开发工作流管理的需求分析
  产品协同开发是以顾客的需求为导向,将产品开发范围扩展为包括设计、制造、采购等多个不同企业不同部门之间的协同工作。产品协同开发打破了传统开发只是设计领域内的孤立技术问题的局限性,而成为了以产品开发为核心,将各个相关领域、相关过程、相关资源及相关组织进行综合而形成的开发工程的系统问题。
 
  将工作流技术应用到产品协同开发领域,其目的不仅仅在于实现全部或部分工作流程的自动化,更希望能够高效、实时地实现产品开发应用间的数据、资源共享和协同工作,从而将各个孤立的设计应用集成起来形成一个能够协调企业内或企业间开发过程的完整系统。
 
  随着市场竞争的日益激烈,企业为应对市场的快速变化,满足用户的多样化需求,在产品设计过程中需要进行广泛的信息交换和信息传输,这就要求工作流在产品设计工程中能实时地反应客户需求。
 
  传统PDM系统的工作流管理是针对特定业务定制开发的,流程是基于静态过程定义的,表达能力有局限,灵活性较差,当业务流程发生变化时,整个系统都要发生重大的调整;同时,工作流管理的是一个企业内部的业务流程,不能支持跨部门跨企业的产品协同开发的流程管理,具体缺陷如下:
 
  (1)缺乏反馈和协调机制。
  对于多成员的产品协同开发工作,各参与人员之间有着大量的数据反馈和协调信息,而传统的工作流建模只能描述顺序执行机制,难以表达具有对等逻辑关系的活动。
 
  (2)缺乏动态修改能力。
  对于一个工作流程,其各流程的内容、执行条件、执行逻辑在运行前都已全部设定好,在运行过程中不允许对流程进行动态的修改。这样使得外界条件即使发生微小的变化,都要对模型进行整体的修改。
 
  (3)不支持多实例化。
  在流程执行中,流程的每一次触发只能完成一个工作实例。对于那些任务相同,只是参与人员不同,或者工作流程都一样,只是所属项目不一样等等,都要需要单独建立模型,这不仅增加了工作量,更使得工作流模型变得庞大冗余。此外,许多业务过程需要在执行时根据条件来确定实例的数目,传统的建模方法很难描述这种过程。
 
  因此,这种完全固化的产品开发模式已经不能满足企业产品多样化的需求,企业流程再造成为了企业发展的趋势。这些都决定了产品开发过程必须要有一定的柔性,必须能够适应不同企业环境和不同产品变化的需求。所以,在计算机支持的产品协同开发过程对工作流管理的需求和协同理论思想的指导下,在传统工作流建模的基础上增加如下的建模机制,方能满足产品协同开发下的流程管理需求:
 
  1)子流程的动态创建:
  由于协同开发过程是有着群体性、层次性和动态性的特点,在流程创建初期,不可能清楚所有层次中各部门各组织的工作任务和工作内容。一般来说,某一级部门的工作内容通常是任务执行时由上一级动态分配的,而任务的分配又是依据当时的任务进度、在线人数等条件来进行的,这都是传统流程在静态创建期间不可获取的。因此,子流程的动态创建对协同开发来说尤为重要。
 
  2)流程的多实例化:
  允许一个工作流程可以同时执行多个工作实例,彼此互不干扰,包括同时设定多实例执行的条件和多实例化的参数集合。
 
  3)动态修改机制:
  允许流程在执行期间对活动条件等进行动态的修改设置,以适应不同的运行环境和需求。
 
  综上所述,在协同开发环境下,产品开发过程是一个动态的非确定性过程。因此产品协同开发下对工作流程管理的需求就是要求产品开发过程具有灵活性和柔性,满足工作流程在执行期间的可修改和可扩展,即要求工作流管理从传统的静态管理向协同开发下动态管理转变。
 
3.3基于Petri网的动态工作流研究
  从上节论述中可知,支持产品协同开发的工作流是一个动态工作流。本节的主要内容是研究动态工作流的变化原因,动态工作流的判断,以及基于Petri网理论的动态工作流的实现方法。经典Petri网由德国学者C.A.Petri在20世纪60年代提出的,经过四十多年的发展,Petri理论得到了极大的丰富,并且被广泛地应用于许多研究领域进行系统的建模、分析、仿真和控制。
 
3.3.1Petri网基本理论及工作流建模
3.3.1.1Petri网基本理论


  1、定义
  定义1:满足下列条件的三元组N=(S,T;F)称为一个网:
  a)S∪T≠Φ
  b)S∩T=Φ
  c)F⊆(S×T)∪(T×S)
  d)dom(F)∪cod(F)=S∪T
 
  其中
  dom(F)={x∈S∪T|∃y∈S∪T:(x,y)∈F}
  cod(F)={x∈S∪T|∃y∈S∪T:(y,x)∈F}

  S和T分别表示库所(Place)集和变迁(Transition)的集合,F成为网N的流关系。用图形来表示一个网时,库所画成一个小圆圈,变迁画成一个小矩形。对于x,y∈S∪T,若(x,y)∈F,则从x到y画一条有向边。c)式指出,有向边只存在于小圆圈和小矩形之间,任意两个小圆圈之间或小矩形之间都没有有向边连接,d)式指出,一个网中不应有孤立节点。
 
  定义2:六元组∑=(S,T;F,K,W.M)称为以网N=(S,T;F)为基网的Petri网系统
其中K(s)称为网N的容量函数,表示库所S中容许存放最多托肯(token)数的量;W(x,y)称为N的权函数,表示变迁发生时消耗和增加的托肯数量;M(s)称为N的标示,是库所到非负整数的函数,表示每个库所中托肯的数量。托肯为库所中的小黑点,表示资源。
 
  2、Petri网的表示方法
  传统经典Petri网其实就是一个有向图,用两种类型的节点表示,一种类型节点称为库所S,用小圆圈表示,另一种类型节点称为变迁T,用小矩形表示,库所和变迁之间用有向弧连接,表示它们之间的关系。Petri网中的状态用托肯在库所中的分布来标示,如下图3-4所示:
 
图3-4Petri网的表示方法
 
  3、Petri网的变迁规则
  托肯的数目在Petri网执行过程中会发生增减,库所中托肯的变化会相应的引起变迁发生变更,即为通常说的点火(Fire),变迁的点火会同时使库所中的托肯数量发生变化,从而改变整个Petri网的状态。
 
  变迁的使能:对于∀s,s∈S,当s∈·t时有M(s)≥W(s,t),且s∈t·时有M(s)+W(s,t)≤K(s),称t是使能的。
  其中·t是t的所有输入库所集,t·是t的所有输出库所集;同理·s是s的所有输入变迁集,s·是s的所有输出变迁集。

  变迁的点火规则:
  Ⅰ、一个变迁t是使能的;
  Ⅱ、一个使能变迁可以点火;
  Ⅲ、如果变迁t点火,那么从t的每个输入库所消耗W(s,t)个托肯,同时在t的每个输出库所中产生W(t,s)个托肯。
 
  4、Petri网的触发机制
  Petri网可以准确地区分别活动的使能和活动的执行两种状态。被使能的活动要真正被执行,必须要有相应的触发条件。触发机制可以理解为一种被使能的活动进入执行状态的外部条件,通常分为四种类型:
 
  (1)自动执行:
  活动被使能的同时就被触发。这种机制一般用于那些通过应用程序来自动控制、不需要人为控制操作的自动型活动。这类活动一旦被使能,就开始执行。
 
  (2)人工触发:
  活动的执行需要外界的执行者通过相关工作项来启动。在工作流管理系统中,每个活动执行者都有一个自己的工作流程任务表,表中列出了该执行者可以执行(已被使能)的活动实例。当执行者选中某一工作项去执行时,活动就被触发。
 
  (3)消息触发:
  由系统外部的消息(事件)来触发活动的执行。比如电话、e-mail,等消息的到达。
 
  (4)时间触发:
  由控制时间的定时器来触发使能的活动。这对于那些需要在约定的时间或给定时间间隔要求来执行的活动是必不可少的。
 
3.3.1.2基于Petri网的工作流建模
  随着企业建模、工作流概念的出现以及相关技术的发展,Petri网也被应用于该领域。利用Petri网进行工作流过程建模主要有以下几个优点:
 
  (1)Petri网兼顾了严格的语义和图形语言两个方面。Petri网中的所有元素都经过严格定义,具有规范的模型语义;同时它又是一种图形化的语言,具有直观和易懂的特点。
 
  (2)Petri网的建模方法的是基于状态的建模方法。相比于其他基于事件的建模方法,它明确定义了模型元素的各种状态,同时它的演进过程又是受状态变化驱动的。
 
  (3)Petri网具有强有力的分析技术和手段。如分析网的有界性,活性,不变量等性质和计算响应时间,占有率等各项性能指标。
 
  传统的Petri网模型中每种对象的状态或条件用一个库所表示,每种变化或事件用一个变迁来表示。使用传统的Petri网对动态工作流建模有以下缺陷:
 
  (1)动态工作流建模要求Petri网具有较大的状态空间,这样会使模型节点过多,计算机程序化容易受到限制;
 
  (2)一个工作流流程可能同时被多个工作实例调用,每个工作实例所处的阶段和状态可能各不相同,没有标记就会导致混乱,无法实现监控;
 
  (3)一个实际的工作流程或项目,往往是由更小的子流程或子项目构成,具有结构上的层次性,而传统Petri网是平铺直叙的,没有层次的变化。
 
  为了克服传统Petri网的这些缺陷,本文对其进行着色扩展和层次扩展,形成着色层次Petri网。通过这些扩展,就可以对复杂情况用结构化、容易理解的方式来建模。
 
  在实际应用中,一个工作流可以提交多个任务,多个任务可能处于多个不同的状态,比如一个任务可能处于计划状态,另一个任务可能处于设计状态,这样仍使用传统的Petri网,设计的模型将变得非常庞大和复杂,因此对其进行着色扩展形成着色Petri网。着色Petri网为每个库所定义了一个托肯色彩集合,为网中的每个变迁定义了一个动作色彩集合,可使一个库所的托肯表示多种状态,从而扩大了托肯代表的含义,使得Petri网系统更简明,状态监控更清晰容易;同时减少了传统Petri网重复建立模型的数量。
 
  传统的Petri网是一个扁平的大网,不能反应出网内部节点的层次(隶属、父子等)结构。为此进行了层次扩展,引入了一个新的网络节点,称之为子过程,用双方框表示,它由若干个库所、变迁、连接弧(流关系)和更小的子过程构成,是一个子网。由于子过程都可以有更小的子过程嵌套构成,因此层次Petri网可以层次化的构成一个复杂的过程。
  
  因此经过着色层次扩展的Petri网可以实现区别工作实例、减少节点数量、缩小流程规模、简化流程构造和便于运行监控等功能。
 
3.3.2工作流动态变化原因分析
  作为企业的信息管理支撑平台,PDM系统提供了丰富的功能模块,已有的PDM系统在一定程度上满足了企业对于产品数据和产品开发过程管理的要求。随着市场需求的快速变化,业务过程的复杂化以及企业规模的扩大,企业的工作流程失去了以往的稳定性,经常以一种随机性和不可预测性呈现出来,它常常要求在工作流的执行过程对某些活动进行动态地修改以快速响应市场环境的需求,其中最能体现这种动态变化的就是企业的产品协同开发过程。
 
  产品协同开发过程是一个有着大量的继承、拓展、合并和修改等操作步骤的演化形成产品的过程,该过程中的数据演化是动态的,无法在产品开发之前就建立完善的工作流程,在开发的执行过程中决定下一步的活动方向,这就要产品开发流程必须具有可重构、可扩展、动态性和高度的柔性。
 
  工作流在执行期间有可能会发生变化,通常有以下三个原因:
  (1)工作流在设计期间由于缺乏整体的考虑导致的工作流程规范不完善;
  (2)在工作流执行期间发生错误或异常,同时事前也无明确的流程执行路线,致使工作流的执行发生偏离;
  (3)企业适应快速市场的变化满足客户需求,设计的流程可能会随着客户的不同需求而实时发生变更等等。
 
  一旦工作流发生变化,则需要对工作流进行重新建模和定义,相应的工作流实例将被建立。在应用新的工作流模板之前,依照旧模板建立起来的工作流实例不得不停止或重启,这可能导致运行期间信息的丢失。更重要的是,一些已经完成的任务就被不必要的重新执行,此时,如果工作流实例很复杂且有大量的外部协同工作参与,企业将付出较高的成本。
 
  工作流模型是对业务过程的抽象描述,工作流建模是工作流理论研究和实际应用的基础。要实现工作流的动态管理,其首先需要解决的问题便是应用动态工作流技术建立一个可以支持动态编辑修改的工作流模型。因此实现工作流在执行时的动态更改和扩展,以及工作流管理在执行层的柔性,它最主要的要求就是工作流中的各个元素(活动,活动的属性及其活动间的关系)不受定义时的限制,是动态工作流技术要解决的核心问题。
 
  传统PDM系统中的工作流管理很难满足这样的需求,因为它是以过程的自动化为目标,只能在定义时对其编辑和修改,很难有效地处理流程执行期间出现的动态变化,适合对预先设定好的,重复性强的静态过程进行描述和管理。这些流程管理是基于以下两点来实现的:
  (1)业务流程已被充分优化且长时间不会发生变化;
  (2)流程执行期间不会发生偏离设定方向的意外事件。
 
  因此,开发出协同开发环境下PDM系统中支持流程执行期的动态修改,满足企业流程动态变化的需求,已成为了PDM系统中工作流管理发展的必然。
 
 
3.3.3动态工作流的判断研究
  动态工作流是指在执行阶段的工作流发生了动态变化,它主要关心工作实例的迁移问题,即运行着的工作实例如何从旧的工作流模型迁移到新的工作流模型。如果按照传统基于“静态”过程定义的工作流程,那么一旦流程发生改变,则原来的工作流模型将被修改,整个工作流实例将会按照新的工作流模型重新实例化开始执行,原来的活动信息将丢失,原本已经完成的工作需要重复完成,工作流的运行成本将大大提高。因此动态工作流所要解决的关键问题是支持流程在运行过程中的扩展和改变,实现在用户执行层的柔性,它最主要的要求是工作流中的各元素不受定义时的限制。
 
3.3.3.1工作流的动态变化
  一个工作流在执行期间可能发生的动态变化包括:
  (1)允许直接跳过一些尚未开始的活动;
  (2)允许某些尚未满足条件的活动启动;
  (3)将原本串行的活动在运行时更改为并行;
  (4)在流程中新增或删除活动节点;
  (5)对某个活动节点的一些属性进行修改、改变活动节点间的连接关系等等。
 
  将工作流的各个活动节点按状态的不同进行划分,可划分成五个状态,分别为:新建、就绪、执行、挂起、完成。在工作流执行期间各节点状态将发生改变,不同状态间的转换如图3-5所示所示。
 
图3-5工作流节点的状态转换
 
  工作流在执行期间,某个活动节点发生动态改变,则将该节点暂时挂起,根据要求变更该节点,变更完成后提交解除挂起,进入就绪状态准备再次的执行。该过程只是单个活动的操作行为。除此之外,一个活动节点的变更会影响到其他活动节点随着发生变更和状态改变。
 
3.3.3.2工作流动态变化判断条件
  对于已经完成的节点,为了避免在新的流程中再次被执行,需要在新的流程中找出那些已经完成而不需要重复执行的节点。虽然在原来的流程中已完成的节点很容易找到,但是并不能判断这些节点在新的流程实例是否需要重新执行,比如原先的工作流程在新的流程中的执行顺序发生变化,比如在原来流程节点之前插入新的节点等,这些节点都需要重新执行。对于发生动态变化的流程,判定节点在新流程中是否发生变化,确定节点是否需要重新执行则成了关键。为此提出以下五个条件来对节点进行依次判断,当有一个条件不满足时节点需要重新执行:

  (1)该节点不是新建节点;
  (2)该节点的属性未发生变化;
  (3)该节点的连接关系未发生变化;
  (4)该节点的任务已完成;
  (5)该节点的前面所有节点已经完成。
 
  其中节点的连接关系分为前置连接关系和后置连接关系。前置连接关系的改变会影响节点的执行,后置连接关系的变化会触发事件。
 
3.3.3.3工作流动态变化判断流程
  根据上述五个判断条件,现归纳出五类节点:基于条件(1)的新增节点,条件(2)和(3)的变化节点和原始节点,条件(4)的完成节点,条件(5)的跳转节点。
 
  A、新增节点:节点是在原流程中新插入的,节点的状态为新增,在流程中需要执行。
  B、变化节点:节点的属性发生变化,属性包括节点任务和任务执行者。如果任务被修改,则节点发生了变化,需要重新执行。如果该节点任务的执行者发生了变化,节点在原流程中已经完成,那么在新的流程中就不需要再执行;如果该节点在元流程中未完成或未执行,那么新任务执行需要在新的流程中执行。节点的连接关系发生变化,连接关系包括前置连接关系和后置连接关系,如果节点前置连接关系发生变化,则该节点发生了变化,需要重新执行;如果后置连接关系发生变化,则会产生一个事件驱动后续节点发生变化,后续节点需要重新执行。
  C、原始节点:节点的属性和连接关系都未发生变化,同时在新流程中得以保存的节点,根据具体情况来确定是否需要在新流程中执行。
  D、完成节点:在原流程中已执行完成,同时在新流程中得以保存下来的节点,根据具体情况来确定是否需要在流程中重新执行。
  E、跳转节点:在原始节点和完成节点的基础上,并且所有前置节点都有完成,在新流程中不需要再执行的节点。对于各节点在新流程中是否需要重新执行,下面给出判断流程,如图3-6所示。 
 
图3-6动态工作流节点判断流程
 
  首先判断节点是否为新增节点,若为新增节点,则需要在新流程中执行;若不是,则进一步对节点的相关属性和连接关系进行判断。先是对节点任务进行判断,若节点任务发生变更,则该节点为变化节点,需要重新执行;若没有,则接下来对节点任务完成情况和连接关系同时进行判定。对节点任务完成判定,若任务完成,则为完成节点;若没有完成,则需要继续执行。对节点连接关系进行判定,若连接关系没有发生变更,则为原始节点;若连接关系发生了变更,则判断是前置关系还是后置关系发生了变更。
 
  若前置关系发生了变化,则为变化节点,同样需要重新执行;若仅后置关系发生变更,则该节点不需要重新执行,但需自动触发一个事件,驱动后续节点发生变化成为变化节点。一个节点既是原始节点又是完成节点,则判断该节点前面的所有节点的任务是否都已完成,若完成,则该节点为跳转节点,在新流程中不需要重新执行,同时其前面所有的节点也为跳转节点,不需要重新执行;若有没有完成的,则该节点还需要重新执行。因此,根据节点判断流程,利用计算机程序化的循环递归遍历方法即可找出新工作流程中不需要重复执行的活动节点。
 
3.3.4动态工作流的实现研究
3.3.4.1动态工作流的实现方法

  工作流的变化分为两种类型:工作流类型级的变化和工作流实例级的变化。工作流实例级的变化一般是一种临时变化,常常是由现实活动的异常情况引起的,且一般只影响单个工作流实例;工作流类型级的变化一般是指工作流过程发生的变化,且与此有关的实例都要迁移至新的工作流程上继续执行。每个企业的日常活动中都有一套自己习惯的工作流程和得以遵循的工作规范,各项工作都以此来进行。下图3-7为典型的企业设计审批流程。
 
图3-7设计文件审批流程
 
  当企业经过研究订立好该审批流程,以后企业绝大部分的文档、图纸、资料等需要审批的设计文件都使用该流程,各个具体活动实例的差异在于活动节点属性的设定,比如具体人员的指派,活动时间的设定,具体任务的安排等等。如果某个文件在审批中要临时修改审批流程,像需要改变某两个活动执行顺序,新增或省略某个活动等等,那么只需要对该特殊的流程进行建模,没必要对原来的审批流程进行整体变更。
 
  因此本文提出了基于动态工作实例的工作流实现方法,该方法一方面可以实现大部分相对固化的流程管理,多个工作实例使用一个工作流模板,对每个工作实例进行相关设定;另一方面也可以实现需要动态修改的流程个案,生成新的工作流程,并对新工作流程进行管理。相比基于过程的方法,具有贴合实际需求,能够处理流程个案,减少实例重复工作,不影响其他共用流程模板实例的执行,使用效率高,可视化程度强,简便易懂等特点。
 
3.3.4.2基于动态工作实例的动态工作流实现
  运行实例的实时迁移是解决工作流动态变更问题的主要方法,然而并不是每个实例都需要迁移。需要迁移的工作实例,有的可以直接从变更前的旧的工作流模型中迁移至变更后新的工作流模型中,有的则需要从当前运行节点沿着实例的执行路径回滚,然后再迁移至新的工作流模型中。本文采用版本机制将最新的工作流过程版本保存起来,正在运行的工作实例能够根据自动生成的迁移策略从一个工作流过程版本迁移至新的工作流过程版本。动态工作实例的实现方法有如下四个过程:
 
  1)新建:建立新工作流模板。新工作流模板是以原模板为样板进行绘制,要求先暂停工作流实例,保存所有的原始数据和和过程信息(原流程执行的结果);然后对原模板进行编辑修改使之符合新的工作实例要求,同时给予新的版本号保存在工作流模板库中。
 
  2)迁移:将原版本流程的基础数据和过程信息拷贝至新模板中,同时解决该过程中产生的异常和冲突等问题。
 
  3)继承:标记不需要重新执行的过程节点。利用上述节点判断流程来判断哪些节点是不要重新执行的,可以从原流程中得到继承,给予标记。
 
  4)聚合:将新旧模板的信息进行积聚整合,确保工作实例在新模板中能够顺畅执行。聚合后原工作流模板不除,以备另用或有其他实例正在运行不受影响。
 
  以上四个过程中除了新建过程需要手动操作外,其余三个过程都是由系统自动来执行的。由上述过程可知,解决迁移过程中的异常和冲突问题是实现流程动态变化的关键所在。下面就这两个问题分别进行阐述,同时给出解决方案,最后以实际的应用实例加以说明。
 
  一、异常:
  1、现象描述:新工作流模板本身在创建时可能存在的不完善。新模板创建时,创建者没有对其进行结构分析和性能检验,即未对新建工作流模板的活性、有界性、安全性和各种性能指标进行验证,会产生活动节点被“死锁”,不能继续执行的现象;或活动被“黏住”,进入死循环的现象;或存在活动节点“不可达”现象等。
 
  2、解决方案:绘制可达图(Reachability Graph)检验用户定义工作流程的正确性,判断流程的可达性(无孤岛),活性(无死锁)等性质。可达图是一种基于Petri网的有向图,由节点和箭头构成。每个节点表示一种可达状态,每个箭头表示一种可能的状态改变。工作流,Petri网和可达图的转换如图3-8所示。
 
图3-8工作流模型、Petri网模型和可达图的转换
 

  二、冲突
  1、现象描述:原版本流程中的基础数据和过程信息在迁移至新模板中时产生的不兼容,即原模板中有的过程节点或属性在新模板中没有或者属性发生改变;原模板中有的连接关系在新模板中没有或者不同;原模板中的局部流程结构(如串行)在新模板中发生改变(如并行)等。

  2、解决方案:解决该冲突的方法应遵循先分拣后比对再迁移的顺序。
 
  分拣,即从旧模板中筛选出在新模板中依然存在的活动节点和连接关系。节点分拣可以通过节点编号、名称等具有唯一性标识的属性加以实现;连接关系的分拣可以通过连接线的起始终止节点来实现。
 
  比对,即检查对照已分拣出的节点信息,保存那些依然存在且尚未改变的属性;通过上述分拣出来的连接关系即为原始的连接关系,保存其相关信息。
 
  迁移,即将这些通过分拣和比对的节点、连接关系以及相关信息迁移至新模板中进行保存,以供后续继承活动的判断执行,即将原版过程迁移至新版本过程中。
 
  下面以图3-7企业设计文件的审批流程为例,运用动态工作实例法对动态工作流程的实现进行应用说明。假设某一个文件审批流程到了等待批准阶段,企业因考虑到设计的通用化和标准化,决定在原工作流程的会签节点之前新增标准化审核节点,且与原审核节点同步,如图3-9所示,实线方框表示活动已经完成,3-9(a)为修改后审批流程,3-9(b)为原流程中设计活动的子过程。
 
图3-9修改后设计文件审批流程
 
  运用动态工作实例法如下:
  (1)先暂停该工作实例,取出工作流模板(图3-8),在工作流编辑器中对原工作流模型进行编辑修改。一方面将建好的模型放入到模型库中,另一方面将其转换为数据模型,同时给予新版本号存储在数据库中;此举一方面可以减少建模的工作量和建模过程中产生的异常错误,另一方面为接下来迁移过程中解决异常冲突提供便利。
 
  (2)接着进行迁移,解决此过程中的异常和冲突等问题。对于异常问题的解决,系统将新建模板的数据模型生成相应的Petri网模型和可达图用于验证模型建立的正确性,判断流程的可达性,活性等性质,并通过分析,找出可能存在的错误,给出相应提示,以便改正。用上节介绍的着色层次Petri网对图3-9进行建模,如图3-10所示,可达图如图3-11所示。根据可达图的判断定理可知,该新建的工作模板没有死锁现象,具有可达性、活性和有界性,新模板有效可用。
 
图3-10设计文件审批流程着色层次Petri网
 
 
图3-11设计文件审批流程可达图
 
  对于冲突问题的解决,可以通过设计循环遍历程序,根据先分拣后比对的准则来完成信息的迁移。以下是实现循环遍历的方法函数。
 
  Class Recurrence{
  ////节点遍历、分拣
  Judge Node(Nodenod);
  ////属性遍历、分拣
  Judge Property(Nodenod,Propertypro);
  ////连接关系判断
  Judge Connection(Nodenod,Connectioncon);
  ////信息迁移
  Information Transf(Nodenod,Propertypro,Connectioncon);}
 
  (3)完成信息迁移后,根据节点的判断流程来标记那些不需要重新执行的活动,完成继承。原文件审批流程已经进行到批准等待阶段,对于新的工作流程,通过继承过程可知,审核及其之前的节点都是不需要重新执行的,但校对需要触发一个事件,因其加入了新的后置关系,即让校对的结果也进入标准化审核节点,让其与审核同步;会签工作需要重新执行,因为该节点的前置连接属性发生了改变,由原来的因果顺序关系变成了并行与关系。
 
  (4)最后将该工作流模型实例化,流程自动启动。系统通过层次着色Petri网模型确定流程的执行顺序,监视流程的执行过程和执行状态,同时记录流程状态演变的过程数据和相关信息。
 
3.4本章小节
  本章可以分为三个部分,第一部分是简单介绍了工作流有关概念,以及PDM系统中的工作流管理的技术;第二部分是对协同开发过程中工作流特性进行了分析,得出了传统静态的工作流程已不满足协同开发过程需求的结论,提出对动态工作流的研究;第三部分是基于Petri网的动态工作流研究,首先简要介绍了Petri网的有关知识,其次对工作流动态变化的原因进行了研究,总结了工作流动态变化包含的情形,给出了判断工作流动态变化的条件和判断流程,最后是对动态工作流实现方法的研究,本文提出了基于动态工作实例的实现法,并通过实例加以验证,得出方法的可行性和有效性。



  • 2019-05-28 09:53
  • 我要分享:
声明:文章"PDM协同开发的工作流管理"为XXX公司原创文章,转载请注明出处,谢谢合作!您所在位置:PLM系统 > PLM新闻 > PDM资讯 >

联系清泰代表

  • 申请支持留下信息,我们将与您联系
  • 400热线马上知道,4006-185-708
热门文章
热门标签

内蒙古快3走势图 166彩票 内蒙古快3 内蒙古快3走势图 内蒙古快3 159彩票 内蒙古快3走势图 博悦彩票平台 博悦彩票平台 500万彩票