产品全生命周期
项目管理系统
配方管理系统
实验管理系统
电子实验记录本
化工行业
PLM的工作流管理系统方案
PLM中工作流管理的主要目标是实现产品数据的电子化审批、工作任务的自动分发及任务指派、控制产品数据的变更、追踪产品数据技术状态和产品研发项目管理等主要功能。本章将在工
产品应用
1.1引言
PLM中工作流管理的主要目标是实现产品数据的电子化审批、工作任务的自动分发及任务指派、控制产品数据的变更、追踪产品数据技术状态和产品研发项目管理等主要功能。本章将在工作流参考模型的基础上，通过对工作流管理系统的组成进行分析，并结合PLM各功能模块对工作流管理的需求，建立了一套面向PLM的工作流管理系统模型，实现了工作流管理系统与PLM的紧密集成。
1.2工作流参考模型
从上个世纪九十年代开始，工作流应用的得到了飞速的发展，在应用厂商的推动下，也诞生了各式各样的工作流系统。这些工作流系统很难兼容，采用的术语和模型也有很大差异。在这种百家争鸣的状态下，不同的术语和模型，让众多的客户和厂商之间的沟通变得复杂，甚至因为对某些概念理解不一致，导致无法沟通的情况。于是，工作流管理联盟(WfMC)于1995年提出的工作流管理系统的体系结构模型——工作流参考模型(Workflow Reference Model)。
工作流参考模型标识了构成工作流管理系统的基本模块和这些基本部件交互使用的接口。这些基本部件包括：工作流执行服务器、工作流引擎、流程定义工具、客户端应用、应用程序、管理监控工具。
工作流参考模型主要提出了五大接口：
接口一(工作流定义交换)，用于在建模和定义工具与执行服务之间交换工作流定义。
接口二(工作流客户端应用接口)，用于工作流客户端应用访问工作流引擎和工作列表。
接口三(被调用的应用接口)用于调用不同的应用系统。
接口四(工作流系统互操作接口)，用于不同工作流系统之间的互操作。
接口五(系统管理和监控)用于系统管理应用访问工作流执行服务。
图2.1 工作流参考模型
1.3工作流管理系统的组成
图2.2为工作流管理联盟(WfMC)提出的工作流管理系统的通用结构模型。从中我们可以看出，工作流管理系统主要内容包括软件构件、系统控制数据以及被工作流系统调用的外部应用和数据。
图2.2 工作流系统通用结构
1.3.1工作流系统的软件构件
工作流管理系统的软件构件是实现工作流管理的基本构件，负责整个工作流管理的基本功能实现。它包括：工作流定义，工作流执行服务，客户应用管理。
1)工作流定义：工作流模型描述了能够由工作流执行服务、执行的过程所需要的所有信息，它是工作流管理系统的基础。它可以利用第三方的建模工具，形象化地建立流程模型，并通过接口关系，建立系统所需要的控制数据；也可以通过系统本身的流程定义，直接生成控制数据。在流程定义中，要包括流程、活动、转换条件、相关数据、角色、需要的应用等实体。其中工作流建模工具主要是用于图形化的流程抽象表示，用不同的元素符号代表活动或参与者以及其他相关因素，用有向线来表示控制流。
2)工作流执行服务：借助于一个或多个工作流引擎，来激活并解释过程定义的全部或部分，并同外部的应用程序进行交互来完成工作流过程实例的创建、执行与管理，如过程定义的解释、过程实例的控制(创建、激活、暂停、终止等)、在过程各活动之间的游历(控制条件的计算与数据的传递等)，并生成有关的工作项通知用户进行处理等等，为工作流程的进行提供一个运行时环境。
3)客户应用管理：是客户操作具体任务和活动的管理模块，负责工作流任务表中任务的分发管理。可以将一个工作流管理系统中的任务管理器提供给客户；同时，也可以针对多个工作流产品或者是多个应用系统产品，编写通用的任务管理器，进行系统的集成。工作列表(Worklist)处理器对外提供接口，外部应用通过工作列表处理器来获取和管理工作项(Workitem)。
1.3.2工作流系统的数据分类
工作流管理系统中存储的数据可以分成：
1)工作流控制数据(Workflow Control Data)：工作流执行服务/工作流引擎通过内部的工作流控制数据来辨别每个过程活动实例的状态。这些数据由工作流执行服务/工作流引擎进行控制。用户、应用程序或其他的工作流引擎/工作流执行服务不能对其直接进行读写操作，它们可以通过向工作流执行服务/工作流引擎发消息请求来获得工作流控制数据的内容。
2)工作流相关数据(Workflow Relevant Data)：工作流管理系统通过工作流相关数据来确定过程实例状态转换的条件，并选择下一个将执行的活动。这些数据可以被工作流应用程序访问并修改。因此，工作流管理软件需要在活动实例之间传递工作流相关数据。
3)工作流应用数据(Workflow Application Data)：这种数据是指那些由应用程序操作的数据。它们是针对应用程序的，是企业完成具体的业务功能所需要的数据，工作流管理系统无法也不需要对它们进行访问。
1.3.3其他应用的调用
工作流管理系统在设计和实施中，都必须提供足够的柔性，来满足不同应用的需要。在与不同的应用系统进行交互时，要提供足够的灵活性。可以建立应用接口规范和提供标准的API函数在不同的系统间进行交互；可以建立灵活的调用通道，直接调用PLM系统中的应用进行事务处理，这种调用可以在分布和异构的系统间进行。
1.4面向PLM的工作流管理需求分析
上节介绍了工作流管理系统的基本组成要素，但是如何使之满足PLM系统的需求才是本文的所要关注和解决的主要问题，因此本节将对PLM中的工作流管理需求进行分析。在PLM中，进行信息管理的两条主线分别是静态的产品结构和动态的产品设计流程，所有的信息组织和资源管理都是围绕产品设计展开的。其中生命周期状态管理、文档管理、零部件管理、变更管理和项目管理都对工作流管理提出了各自的需求。
1.4.1生命周期状态管理
产品生命周期在PLM系统中是一个核心概念，代表一组状态，用于确定PLM系统中业务对象(包括文档、零部件等)的成熟阶段。产品生命周期状态管理本身不是一个独立的功能，它将贯穿于PLM软件系统的各部分功能之中，作为一种管理思想融合其中成为一种管理的方法。通过将产品生命期分为多个阶段，对产品对象和文件按照生命期阶段制定管理策略和控制机制来实施生命期管理。
通过产品生命期管理主要进行如下的控制和管理：
1)权限控制——处于不同生命期的对象和文件的权限管理要求不同；
2)可用性控制——处于不同生命期的对象和文件可用性不同；
3)变更管理——处于不同生命期的对象和文件版本管理要求不同
4)流程管理——处于不同生命期的对象和文件可用的流程不同；
5)属性维护——处于不同生命期的对象和文件属性维护范围不同；
6)工作内容——处于不同生命期的对象和文件需要开展的工作内容不同；
7)产品及开发管理——需要掌握产品所处生命期阶段。
一般来说，对象会随时间越来越成熟和可靠。而生命周期就定义对象不断成熟的方式。生命周期是包括标识对象发展状态的一组连续阶段和关口的自动化图形模型，对象通过关口从一个阶段移动到下一个阶段。对象的发展状态既是给定时刻对其成熟度的衡量，又是特定生命周期阶段内对其行为的定义。
1.4.1.1生命周期模板
生命周期模板作为PLM系统中重要的一个模块，提供了生命周期管理的基础和依据，它由一系列的生命周期状态(又称阶段)(Phase)和状态迁移关口(Gate)组成。可以表示为生命周期LC={Phase}+{Gate}。在系统中可以设置一系列不同的生命周期模板，来满足不同类型的业务对象和不同的业务流程的需要。
图2.3 生命周期模板
为了较好的描述阶段与关口的关系，可以用如图2.4所示的提交、升级、降级和驳回四个主要操作来表达：提交：将任务直接传递到关口进行决策点判断；降级：从某一阶段越过关口返回上游阶段；升级：从某一阶段经过关口跳跃至下游的某阶段；驳回：决策点通不过，从关口打回到上游某阶段。
图2.4 生命周期操作
在生命周期模板中，可以设置相应的生命周期角色，对于不同的生命周期状态可以选定不同的角色并设置相应的访问权限。关于工作流中访问权限的讨论参见第4章。
图2.5 设置生命周期角色及访问权限
1.4.1.2生命周期状态管理对工作流管理的需求
生命周期管理作为PLM的一个主线，将产品的概念进行放大，既包括物理意义上的实体，同时也包含与该物理实体发生关系的一系列的业务活动，在PLM中通称为业务对象，主要包括：
1)文档，包括具体的文档内容(即主要文件)，如技术说明文档、3D设计图等；
2)部件，构成部件的各种零件、BOM产品结构等；
3)工作流运行实例中的文档申请单等；
4)工作流运行实例中的工程变更请求、工程变更单、工程变更活动等；
在PLM中一个复杂的工作流流程，必定是以提升业务对象状态为根本目的，根据业务对象状态变化的次序和决策评审点的确定，可以划分出业务对象的阶段和关口，工作流管理系统总是和生命周期紧密挂钩，并且延伸到产品结构管理，文档管理，工程变更管理等模块。
生命周期各阶段和关口都可以和工作流相关联，在PLM中，业务对象、生命周期模板和工作流实例的关系如图2.7所示。工作流(WF)是引发业务对象生命周期状态变化的主要因素，一个业务对象通过一系列的状态提升流程，实现自身生命周期状态的成长，工作流的驱动作用可表示为：Phase1→Phase2。因此在生命周期管理模块中预留接口供工作流调用，来实现主对象的生命周期状态更改。
图2.7 工作流与生命周期管理在PLM中的应用
在工作流中由于业务对象具有生命周期状态属性，因此会产生如图2.8中所示的两种情况，在图2.8a中，流程中数据项的生命周期状态自始至终为同一个状态，表示该业务对象在整个流程中所处的生命周期阶段没有发生改变，与生命周期状态相关的访问权限也不会发生改变。而图2.8b中数据项的生命周期状态发生了多次迁移，随着流程的不断向下运行，数据项的生命周期状态不断发生改变，与之相关的访问权限也会随之动态更改。
图2.8 工作流中数据项的生命周期状态
为了支持主对象的生命周期状态的跃迁，需要在工作流中设置生命周期状态更改自动机，一旦数据流通过该节点其生命周期状态就发生迁移，会触发数据项中生命周期状态数据和生命周期权限集数据的更新，实现了工作流和生命周期状态管理的集成。
1.4.2文档流程管理
在PLM中，以零部件与文档为代表的设计目标对象一般都要经历一系列的设计、标准化、校对、审核、会签和批准等步骤，这些步骤存在某种前后关系的串并行，可以形象的用一个有向图加以直观示意，这样就构成了文档过程。当然在实际的设计过程中，某些零部件版本及相关的文档有可能反复使用同一文档过程进行工作，所以文档过程也支持将零部件版本作为过程引擎操作的对象。图2.9的审批流程体现了文档的传递过程，具体描述了文档在不同的状态需要完成的任务。
图2.9 文档审批流程及关联的生命周期模板
流程需求如下：
1)实现规范化的产品数据的电子签署流程，电子化工作流程要能够反映企业的实际产品数据签署流程，文档的生命周期管理与审批流程基本遵循原有的文档流程，通过一些步骤的并行，从而缩短整个文档审批周期。
2)电子化工作流程具有一定的自动化能力，能够进行自动通知和分发任务给相应的参与者，从而减少非增值性工作量，前一步骤的完成会自动触发下一步骤的开
始，即下一步的操作人员会在其个人工作单中收到任务指示，从而大大提高文档传递的有效性。
3)应该完整记录签署过程中产品数据和产品结构的演化以及相关参与者的名称、签署的意见、签署的时间等重要信息;评审人和批准人以电子的方式将自己意见和建议反映出来，并及时反馈给设计人员，从而做到任何变更有据可寻。
4)电子化工作流程中各活动的参与者应该可以在执行前动态指定，工作流程中的各活动可以根据需要委派给他人。
5)可以通过文档生命周期状态的查询和流程监控功能，迅速了解文档进行的状态
1.4.3工程变更管理
由于各种不确定因素的影响，如市场需求变化、产品开发人员疏忽以及产品使用中的问题等原因，对现有产品数据进行更改是难免的。在PLM中，工程变更是对PLM所管理的预发布阶段和发布阶段的产品数据的更改。工程变更管理的目的一方面是保证产品数据的一致性，避免因使用老版本或正在变更中的产品数据而出差错，另一方面是要保证对产品数据修改必要性认证、修改的正确性认证以及修改操作有据可查性。
工程变更的管理分成三个部分：
1)变更申请审批：用户或工作人员因某些原因提出更改申请，企业对变更申请进行确认，必要时则同意申请。
2)变更执行：针对变更申请内容，产品负责人给出变更申请中提出问题的处理意见，并指定专人负责产品数据的修改。变更执行人员按预先定义的流程完成产品数据的修改。对产品数据的更改指定流程是为了保证更改的正确性。
3)变更发布：一方面需要将变更的消息发送到所有的相关人员，另一方面系统要对数据库相应数据更新。这是为了保证数据的一致性，同时让与被变更数据相关的所有用户都能够及时采取相应的措施，减少变更所带来的影响。
另外，系统还提供对工程变更进行跟踪、查询、分类和统计等功能。不同企业可以根据各自产品数据的特点和管理的要求，制定不同的变更流程。在系统中所有变更中的数据都要有明显的状态标志，以避免错误地使用变更中的数据。
图2.10 文档变更申请业务流程图
流程需求如下：
1)提出变更申请
▲对文档有阅读权限的人，可以对最新版本处于“审批完成”状态的文档提出变更申请。启动变更申请流程后，文档变更申请人需要做如下工作：
▲必须填写“变更原因”
▲默认变更申请批准者为文档审批流程中的审核人，但可以由变更申请人修改；对于没有审核人的文档类别，变更申请批准者没有默认值，如果不指定，应该不能完成变更申请任务，且系统给出提示信息。
▲指定修订者，如不指定变更修定者，则系统默认为变更申请本人。
2)批准变更申请申请人完成“提出变更
▲申请”任务后，在批准者的工作表中出现与该变更相关的“批准”任务。
▲批准者可以看到变更申请的相关信息：如要变更的文档编号、名称、变更原因、申请人、修订者。
▲批准者对变更申请进行批示：驳回、否决或同意，对于否决或驳回，必须写明原因。
3)执行变更申请
▲变更申请被批准后，文档的大版本升级，且升级后的第一个版本和升级前的最后一个版本，文件内容一样。比如申请变更文档的版本为A.5，变更申请被批准后，系统自动生成一个版本为B.1的文档，B.1和A.5的物理文件相同。
▲在文档变更时，文档的上一版本的变更原因将会写在下一个版本的“说明”项中。如A.5版本发生变更，其变更流程中的变更原因将自动在B.1版本的“说明”项中显示。
▲系统给修订者赋予升级后文档的修改权限(比如上面的B.1版本)，在修订者的工作表中出现“修改”任务。修订者通过更新文档，提交新版本，完成“修改”任务。
▲修订后的文档使用当前该类文档对应的编组和生命周期，并走对应审批流程。
1.4.4项目管理
项目管理(Project Management)是在项目实施过程中对其计划、组织、人员及相关数据进行管理和配置，对项目的运行状态进行监视，并完成计划的反馈。PLM项目管理定位于产品开发的过程管理，是建立在工作流程管理基础上更高层次管理，项目管理与过程管理的主要区别在于：过程管理通常只是面向一个具体的对象(如图纸、文档等)的状态管理，主要解决对该对象内部数据流的影响，管理粒度很细；而项目管理的范围则广泛得多，它围绕着某一工作目标的实现，进行任务划分、任务排序、任务调度、任务执行结果评估等工作，决不仅仅限于管理一个具体对象，但是通常只涉及任务的人员指派，任务的期限指派，项目资源的分配等粗线条，对内部数据流的涉及深度不及过程管理，管理粒度一般要粗于过程管理。
图2.11说明了PLM系统中项目管理与工作流管理之间的关系。PLM中的项目可以划分为层次形式的子任务，而定义子任务的主要依据是详细的产品结构图，因为，项目的任务结构在一定程度上是产品结构的反映。每处理完一个任务就得到了产品开发过程中的一个阶段成果，为此需要在逻辑上规定一个处理的顺序。
在项目任务结构中的每一个任务都对应了一个相应的工作流，因此项目的完成依赖着工作流管理系统的支持。每一个过程都由一个项目小组完成，并且有自己的项目日历。可以根据需要给项目小组的成员分配相应的活动，而项目小组的成员能否接受所分配的活动则取决于其个人的日历。具体的项目活动可以是生成、更改或使用产品数据。
由一个工作步骤或者一项活动所形成的结果，可以作为另一个工作流的某个工作步骤的基础。当一个工作流结束以后，在产品模型中就增加了一个新的零部件，这样，产品的结构随着项目的进展变得越来越完整。当项目结束时便得到了完整的产品数据。通过PLM系统的项目管理模块，可以将一个产品开发项目及其有关的数据结构化成为一个面向对象的项目模型。利用这个网络式的项目模型，可以确保对项目进行全面的监视和控制。
图2.11 项目管理、过程管理和数据管理的集成
工作流管理系统对整个产品的形成过程进行控制，用以支持和改善所有与产品形成过程有关人员的协同工作，从而从整体上提高工作效率。因此在PLM中，工作流管理模块需要从以下三个方面来支持项目管理的实现。
1)工作流管理模块将面向任务的项目组中属于不同部门的员工联系起来，每一个员工按其专业领域扮演固定的角色，项目负责人按照不同的过程结构，将不同的人员分配给不同的活动。所有与该过程步骤有联系的PLM系统用户，都可以通过PLM项目管理模块得到自己的任务清单。
2)工作流管理模块定义项目流程。工作流管理不仅可以用于控制产品形成过程的各个阶段，还可以对完整的过程链进行控制，该过程链包括了一系列的阶段性标志(项目里程碑)，如产品开发、实验、生产、发放、应用、维护和报废处理等。工作流管理模块定义和维护项目实施、评审、更改、中止和结束等模板，项目经理根据具体情况，从流程模板中选取本项目要使用的流程，确定流程各个节点和项目任务的对应关系，并且规定每个节点(即任务)的操作人员。
3)工作流流管理模块还可以为项目任务数据对象赋予流程。当任务中的业务对象被赋予流程时，流程用于控制该业务对象的流转过程，工作流管理模块根据各环节的操作自动将业务对象推进到下一环节。若任务中有其他相关文档被赋予了流程，只有当所有被赋予流程的文档走完相应的流程后，该任务才能够提交，继续走下一步项目流程结点(即任务结点)。
1.4.5产品生命周期、工作流程、项目以及业务对象之间的关系
在PLM中，业务流程的运行通过工作流实例来完成，包括了为实现共同的商业目标而协同开展的一系列活动，而这些活动又可分解成任务，任务是工作流过程建模的基本单位。因此，一个工作流实例通过把一系列活动依时序和逻辑关系相互连接，依据组织规则在角色之间传递、处理、执行、挂起、或终结。
工作流实例的载体又被称为主业务对象(Primary Business Object，PBO)，用户通过创建主业务对象，关联生命周期，并生成工作流实例。与产品相关的如部件(part)、文档(document)、BOM等称作评审对象或者参考，它们都被直接绑定到PBO上，也就是说将PBO作为评审、参考对象的另一载体。
对于PBO和评审、参考对象，根据业务规则建立生命周期模板，定义合适的阶段和关口；对于整个业务流程，根据功能模块可划分为不同的子过程，然后将子过程与PBO的阶段和关口进行一一对应[18]。PLM中产品生命周期、工作流程、项目以及业务对象之间的关系，如图2.12所示。
图2.12 生命周期、IPD项目、工作流程和业务对象关系
在PLM系统开发过程中，首先对具体业务对象在生命周期模板中定义生命周期历程，包括阶段和关口，然后选择此生命周期历程的角色，通过权限控制列表指定参与人，最后在每个关口给出进阶标准。生命周期定义完成后，要对业务对象进行立项，项目的整个运行过程都在已经定义好的生命周期内展开各种活动。项目立项完成后，要对整个生命周期中阶段和关口来划分工作流实例，每个生命周期阶段或关口都对应分解完成的工作流子过程。当工作流实例启动时，系统自动的将生命周期的角色与项目角色映射，再将项目角色通过二次映射，将参与人或群组赋予工作流实例各种任务的执行者。
因此在整个PLM系统中，工作流与文档管理、变更管理、项目管理以及生命周期状态管理紧密相关，是业务数据流动的载体，是PLM系统的重要支撑模块。
1.5面向PLM的工作流管理系统功能模型
前文通过对工作流系统的组成以及PLM系统中工作流管理需求分析，明确了工作流管理系统在PLM系统中的应用功能，因此本节建立了面向PLM的工作流管理系统功能模型，如图2.13所示，该模型将工作流管理系统作为PLM系统架构的一部分，实现了工作流管理系统和PLM其他模块的紧密集成，可以将结构复杂的过程定义分解成相对简单的生命周期阶段工作流，并可以实现灵活的访问权限控制以及工作流参与者角色解析，实现对文档管理、产品结构管理、变更管理、项目管理等模块的支持，满足了企业对产品全生命周期管理的需求。下面分别介绍该功能模型中的主要功能模块。
图2.13 PLM系统的工作流管理功能模型
1.5.1过程建模工具
建模工具通过图形化的操作界面实现工作流过程模型的定义、修改、删除和批量导入导出标准XML文件的功能，并支持将模型文件编译生成动态库技术，即模型文件在使用之前会编译成模型动态库，一个过程模型对应会生成一个模型动态库。
其优点如下：
①提供了良好的对外接口特性，可以支持用户在建模时自己编写标准C#代码或引用外部系统提供的业务组件，从而使工作流系统可以拥有复杂的业务逻辑和良好的可扩展性；
②改变了加载模型文件定义信息的方式，由传统的从数据库中加载转变为系统反射调用动态库文件来读取向关信息，减少了数据库的访问次数，提升了系统的处理性能。工作流定义的对象以及对象之间的关系如图2.14所示。
1)工作流定义(过程模型)：过程模型反映的是企业的一个经营过程。它一般包括诸如名称、版本号、过程启动和终止条件、系统安全、监控信息等一系列基本属性。
2)活动：活动相当于经营过程中的任务，主要反映完成企业经营过程需要执行哪些功能操作。它一般包括活动名称、类型、活动的前后条件、调用约束参数等。
3)迁移条件：迁移条件对应于企业经营过程中的业务规则和操作的顺序，主要负责为过程实例的推进提供导航依据。主要包括工作流过程条件、执行条件和通知条件。
4)工作流相关数据：工作流相关数据是工作流引擎执行任务推进的依据。主要包括数据名称、数据值等。
5)角色：角色主要描述企业经营过程中参与操作的人员和组织单位。主要包括角色的名称、组织实体、角色的能力等。
6)外部应用程序：外部应用程序主要描述用于完成企业经营过程所采用的工具或手段。主要包括应用程序的名称、类型、路径以及运行参数等。
过程定义元模型的核心是活动。工作流定义与活动、工作流相关数据之间是一对多关系，即一个工作流定义由多个活动与多个工作流相关数据组成。活动、角色、工作流相关数据、需要激活的应用程序、转换条件之间都是多对多关系。如一个活动可以引用多个角色，一个工作流数据可以被多个活动使用。
1.5.2工作流客户端应用
客户端是普通用户用来访问工作流系统的主界面，实现了工作流服务与客户应用之间的接口，包括过程实例管理功能，过程状态管理功能，任务项列表任务项处理功能，数据处理过程，过程监控功能，其它的管理功能等。
1.5.3外部被调用的程序
工作流引擎可以通过调用外部系统提供的接口来实现特定的业务流程，实现了工作流引擎和直接调用的应用程序之间的接口，包括通信建立，活动管理功能，数据处理等功能。
1.5.4工作流管理工具
系统管理与监控主要包括资源控制，过程实例的管理，状态管理，审核管理等。管理工具提供系统中流程、应用管理、工作流实例、活动实例等相关的查看及管理功能。
1.5.5工作流引擎
作为工作流管理系统的核心，在企业经营过程中，它实际上是企业的任务调度器，并且还在某种程度上是企业的资源分配器。引擎提供了过程实例执行的运行环境，主要完成以下功能：
1)对过程定义进行解释：通过读取模型文件和反射调用模型动态库，获取过程定义相关数据，为过程的实例化做好必要的数据准备。
2)启动过程实例：通过对过程定义的解析，并判断满足过程实例启动条件后，启动过程实例。同一个过程模型可生成不同的过程实例，并且互不干扰。如文档审批流程，不同的文档可以同时启动各自的审批流程，在流程引擎的控制下独自运行。
3)为过程和活动的执行进行导航：根据过程定义和工作流相关数据，为过程实例的运行进行导航，如根据人工节点的任务处理人选择的路由进行后续的路由选择，或者通过设置自动节点，由程序根据流程的运行变量信息来进行后续的路由判断，决定并行或串行执行后续活动，或者根据所需激活的应用程序信息启动相应的应用程序等等。
4)对过程实例进行监控：提供控制、管理和监督工作流过程实例执行情况的功能，包括过程实例和节点实例的创建、激活、挂起、终止的操作。图2.15和图2.16分别描述了流程实例和活动实例各个状态之间的转换。
图2.15 流程实例状态转换图
流程实例包括以下几种运行状态：
▲未开始：表示一个过程实例已经生成，但该过程实例并没有满足开始执行的条件。
▲准备运行：该过程实例已经开始执行，但是还不满足开始执行第一个活动并生成一个任务项的条件。此时用户可以调用引擎的接口更改设置流程的实例信息。
▲运行中：表示流程已经处于正常的执行状态中，一个或多个活动已经开始执行；
▲已暂停：该过程实例正在运行，但处于暂停状态，除非有一个“恢复”的命令使该过程实例回到运行中状态，否则所有的活动都不会执行。
▲异常：表示流程因程序或逻辑等的原因出现错误，导致工作流出现异常。可以重新启动该流程来恢复流程的运行。
▲已完成：该过程实例满足完成的条件，工作流管理系统将执行过程实例完成后的操作，并删除该过程实例。
▲已终止：指该流程在正常结束前因错误或人为的原因而被迫终止(如出现错误或者异常情况)，工作流管理系统将执行补救措施，并删除该过程实例。
图2.16 活动实例状态转换图
活动实例包括以下几种运行状态：
▲未开始：表示该节点还没有被实例化。
▲运行中：该活动实例已经被激活，正在运行;
▲已暂停：因系统管理员监控或等的操作，使节点处于暂停状态，节点的活动处于静止状态。可以通过恢复操作使系统恢复到运行态。
▲异常：指表因程序或逻辑等的原因而使节点实例出现异常。可以通过重新启动该节点实例来恢复节点的运行。
▲已完成：该活动已经执行完毕，工作流管理系统将进行活动结束后的导航工作，激活后续符合启动条件的活动。
在任务状态改变时必须遵循如下业务规则：进程状态为“已暂停”，不能使用节点的“恢复”功能恢复“已暂停”的节点的状态为“运行中”。
5)维护工作流控制数据和工作流相关数据，在应用或用户间传递工作流相关数据工作流在执行过程中要维护不同过程和活动实例的内部状态信息，以及用于协调和恢复的各种检查数据和恢复/重起信息，还包括用户传送的必要的相关数据。
6)与外部资源交互完成各项活动：工作流执行服务通过两种途径完成与外部资源和用户的交互：客户应用接口和直接调用应用接口方式。对于客户应用方式，工作流引擎通过任务项列表管理器对任务的执行进行管理。任务列表管理器可以根据不同的任务类型，来让用户进入不同的任务处理界面，从而可以利用各种任务处理界面的不同的业务功能。
在任务执行完成后，系统会修改相关任务项的状态，如设置完成标记，另外系统还会检索该任务项所对应的节点的任务项是否全部处理完成，若全部处理完成则系统会自动触发该任务项对应的节点实例的完成操作。当然，在用户提交完成任务项的时候用户可以自定义各种条件逻辑判断，如果判断不满足，则系统可以阻止用户提交任务项。
1.6本章小结
本章首先介绍了工作流系统的组成，然后分析了PLM系统中生命周期状态管理、文档流程管理、变更管理和项目管理的主要功能及其对工作流管理的需求，建立了面向PLM的工作流管理系统功能模型，并研究了其中的主要功能模块。
PLM中工作流管理的主要目标是实现产品数据的电子化审批、工作任务的自动分发及任务指派、控制产品数据的变更、追踪产品数据技术状态和产品研发项目管理等主要功能。本章将在工作流参考模型的基础上，通过对工作流管理系统的组成进行分析，并结合PLM各功能模块对工作流管理的需求，建立了一套面向PLM的工作流管理系统模型，实现了工作流管理系统与PLM的紧密集成。
1.2工作流参考模型
从上个世纪九十年代开始，工作流应用的得到了飞速的发展，在应用厂商的推动下，也诞生了各式各样的工作流系统。这些工作流系统很难兼容，采用的术语和模型也有很大差异。在这种百家争鸣的状态下，不同的术语和模型，让众多的客户和厂商之间的沟通变得复杂，甚至因为对某些概念理解不一致，导致无法沟通的情况。于是，工作流管理联盟(WfMC)于1995年提出的工作流管理系统的体系结构模型——工作流参考模型(Workflow Reference Model)。
工作流参考模型标识了构成工作流管理系统的基本模块和这些基本部件交互使用的接口。这些基本部件包括：工作流执行服务器、工作流引擎、流程定义工具、客户端应用、应用程序、管理监控工具。
工作流参考模型主要提出了五大接口：
接口一(工作流定义交换)，用于在建模和定义工具与执行服务之间交换工作流定义。
接口二(工作流客户端应用接口)，用于工作流客户端应用访问工作流引擎和工作列表。
接口三(被调用的应用接口)用于调用不同的应用系统。
接口四(工作流系统互操作接口)，用于不同工作流系统之间的互操作。
接口五(系统管理和监控)用于系统管理应用访问工作流执行服务。
图2.1 工作流参考模型
1.3工作流管理系统的组成
图2.2为工作流管理联盟(WfMC)提出的工作流管理系统的通用结构模型。从中我们可以看出，工作流管理系统主要内容包括软件构件、系统控制数据以及被工作流系统调用的外部应用和数据。
图2.2 工作流系统通用结构
1.3.1工作流系统的软件构件
工作流管理系统的软件构件是实现工作流管理的基本构件，负责整个工作流管理的基本功能实现。它包括：工作流定义，工作流执行服务，客户应用管理。
1)工作流定义：工作流模型描述了能够由工作流执行服务、执行的过程所需要的所有信息，它是工作流管理系统的基础。它可以利用第三方的建模工具，形象化地建立流程模型，并通过接口关系，建立系统所需要的控制数据；也可以通过系统本身的流程定义，直接生成控制数据。在流程定义中，要包括流程、活动、转换条件、相关数据、角色、需要的应用等实体。其中工作流建模工具主要是用于图形化的流程抽象表示，用不同的元素符号代表活动或参与者以及其他相关因素，用有向线来表示控制流。
2)工作流执行服务：借助于一个或多个工作流引擎，来激活并解释过程定义的全部或部分，并同外部的应用程序进行交互来完成工作流过程实例的创建、执行与管理，如过程定义的解释、过程实例的控制(创建、激活、暂停、终止等)、在过程各活动之间的游历(控制条件的计算与数据的传递等)，并生成有关的工作项通知用户进行处理等等，为工作流程的进行提供一个运行时环境。
3)客户应用管理：是客户操作具体任务和活动的管理模块，负责工作流任务表中任务的分发管理。可以将一个工作流管理系统中的任务管理器提供给客户；同时，也可以针对多个工作流产品或者是多个应用系统产品，编写通用的任务管理器，进行系统的集成。工作列表(Worklist)处理器对外提供接口，外部应用通过工作列表处理器来获取和管理工作项(Workitem)。
1.3.2工作流系统的数据分类
工作流管理系统中存储的数据可以分成：
1)工作流控制数据(Workflow Control Data)：工作流执行服务/工作流引擎通过内部的工作流控制数据来辨别每个过程活动实例的状态。这些数据由工作流执行服务/工作流引擎进行控制。用户、应用程序或其他的工作流引擎/工作流执行服务不能对其直接进行读写操作，它们可以通过向工作流执行服务/工作流引擎发消息请求来获得工作流控制数据的内容。
2)工作流相关数据(Workflow Relevant Data)：工作流管理系统通过工作流相关数据来确定过程实例状态转换的条件，并选择下一个将执行的活动。这些数据可以被工作流应用程序访问并修改。因此，工作流管理软件需要在活动实例之间传递工作流相关数据。
3)工作流应用数据(Workflow Application Data)：这种数据是指那些由应用程序操作的数据。它们是针对应用程序的，是企业完成具体的业务功能所需要的数据，工作流管理系统无法也不需要对它们进行访问。
1.3.3其他应用的调用
工作流管理系统在设计和实施中，都必须提供足够的柔性，来满足不同应用的需要。在与不同的应用系统进行交互时，要提供足够的灵活性。可以建立应用接口规范和提供标准的API函数在不同的系统间进行交互；可以建立灵活的调用通道，直接调用PLM系统中的应用进行事务处理，这种调用可以在分布和异构的系统间进行。
1.4面向PLM的工作流管理需求分析
上节介绍了工作流管理系统的基本组成要素，但是如何使之满足PLM系统的需求才是本文的所要关注和解决的主要问题，因此本节将对PLM中的工作流管理需求进行分析。在PLM中，进行信息管理的两条主线分别是静态的产品结构和动态的产品设计流程，所有的信息组织和资源管理都是围绕产品设计展开的。其中生命周期状态管理、文档管理、零部件管理、变更管理和项目管理都对工作流管理提出了各自的需求。
1.4.1生命周期状态管理
产品生命周期在PLM系统中是一个核心概念，代表一组状态，用于确定PLM系统中业务对象(包括文档、零部件等)的成熟阶段。产品生命周期状态管理本身不是一个独立的功能，它将贯穿于PLM软件系统的各部分功能之中，作为一种管理思想融合其中成为一种管理的方法。通过将产品生命期分为多个阶段，对产品对象和文件按照生命期阶段制定管理策略和控制机制来实施生命期管理。
通过产品生命期管理主要进行如下的控制和管理：
1)权限控制——处于不同生命期的对象和文件的权限管理要求不同；
2)可用性控制——处于不同生命期的对象和文件可用性不同；
3)变更管理——处于不同生命期的对象和文件版本管理要求不同
4)流程管理——处于不同生命期的对象和文件可用的流程不同；
5)属性维护——处于不同生命期的对象和文件属性维护范围不同；
6)工作内容——处于不同生命期的对象和文件需要开展的工作内容不同；
7)产品及开发管理——需要掌握产品所处生命期阶段。
一般来说，对象会随时间越来越成熟和可靠。而生命周期就定义对象不断成熟的方式。生命周期是包括标识对象发展状态的一组连续阶段和关口的自动化图形模型，对象通过关口从一个阶段移动到下一个阶段。对象的发展状态既是给定时刻对其成熟度的衡量，又是特定生命周期阶段内对其行为的定义。
1.4.1.1生命周期模板
生命周期模板作为PLM系统中重要的一个模块，提供了生命周期管理的基础和依据，它由一系列的生命周期状态(又称阶段)(Phase)和状态迁移关口(Gate)组成。可以表示为生命周期LC={Phase}+{Gate}。在系统中可以设置一系列不同的生命周期模板，来满足不同类型的业务对象和不同的业务流程的需要。
图2.3 生命周期模板
为了较好的描述阶段与关口的关系，可以用如图2.4所示的提交、升级、降级和驳回四个主要操作来表达：提交：将任务直接传递到关口进行决策点判断；降级：从某一阶段越过关口返回上游阶段；升级：从某一阶段经过关口跳跃至下游的某阶段；驳回：决策点通不过，从关口打回到上游某阶段。
图2.4 生命周期操作
在生命周期模板中，可以设置相应的生命周期角色，对于不同的生命周期状态可以选定不同的角色并设置相应的访问权限。关于工作流中访问权限的讨论参见第4章。
图2.5 设置生命周期角色及访问权限
1.4.1.2生命周期状态管理对工作流管理的需求
生命周期管理作为PLM的一个主线，将产品的概念进行放大，既包括物理意义上的实体，同时也包含与该物理实体发生关系的一系列的业务活动，在PLM中通称为业务对象，主要包括：
1)文档，包括具体的文档内容(即主要文件)，如技术说明文档、3D设计图等；
2)部件，构成部件的各种零件、BOM产品结构等；
3)工作流运行实例中的文档申请单等；
4)工作流运行实例中的工程变更请求、工程变更单、工程变更活动等；
在PLM中一个复杂的工作流流程，必定是以提升业务对象状态为根本目的，根据业务对象状态变化的次序和决策评审点的确定，可以划分出业务对象的阶段和关口，工作流管理系统总是和生命周期紧密挂钩，并且延伸到产品结构管理，文档管理，工程变更管理等模块。
生命周期各阶段和关口都可以和工作流相关联，在PLM中，业务对象、生命周期模板和工作流实例的关系如图2.7所示。工作流(WF)是引发业务对象生命周期状态变化的主要因素，一个业务对象通过一系列的状态提升流程，实现自身生命周期状态的成长，工作流的驱动作用可表示为：Phase1→Phase2。因此在生命周期管理模块中预留接口供工作流调用，来实现主对象的生命周期状态更改。
图2.7 工作流与生命周期管理在PLM中的应用
在工作流中由于业务对象具有生命周期状态属性，因此会产生如图2.8中所示的两种情况，在图2.8a中，流程中数据项的生命周期状态自始至终为同一个状态，表示该业务对象在整个流程中所处的生命周期阶段没有发生改变，与生命周期状态相关的访问权限也不会发生改变。而图2.8b中数据项的生命周期状态发生了多次迁移，随着流程的不断向下运行，数据项的生命周期状态不断发生改变，与之相关的访问权限也会随之动态更改。
图2.8 工作流中数据项的生命周期状态
为了支持主对象的生命周期状态的跃迁，需要在工作流中设置生命周期状态更改自动机，一旦数据流通过该节点其生命周期状态就发生迁移，会触发数据项中生命周期状态数据和生命周期权限集数据的更新，实现了工作流和生命周期状态管理的集成。
1.4.2文档流程管理
在PLM中，以零部件与文档为代表的设计目标对象一般都要经历一系列的设计、标准化、校对、审核、会签和批准等步骤，这些步骤存在某种前后关系的串并行，可以形象的用一个有向图加以直观示意，这样就构成了文档过程。当然在实际的设计过程中，某些零部件版本及相关的文档有可能反复使用同一文档过程进行工作，所以文档过程也支持将零部件版本作为过程引擎操作的对象。图2.9的审批流程体现了文档的传递过程，具体描述了文档在不同的状态需要完成的任务。
图2.9 文档审批流程及关联的生命周期模板
流程需求如下：
1)实现规范化的产品数据的电子签署流程，电子化工作流程要能够反映企业的实际产品数据签署流程，文档的生命周期管理与审批流程基本遵循原有的文档流程，通过一些步骤的并行，从而缩短整个文档审批周期。
2)电子化工作流程具有一定的自动化能力，能够进行自动通知和分发任务给相应的参与者，从而减少非增值性工作量，前一步骤的完成会自动触发下一步骤的开
始，即下一步的操作人员会在其个人工作单中收到任务指示，从而大大提高文档传递的有效性。
3)应该完整记录签署过程中产品数据和产品结构的演化以及相关参与者的名称、签署的意见、签署的时间等重要信息;评审人和批准人以电子的方式将自己意见和建议反映出来，并及时反馈给设计人员，从而做到任何变更有据可寻。
4)电子化工作流程中各活动的参与者应该可以在执行前动态指定，工作流程中的各活动可以根据需要委派给他人。
5)可以通过文档生命周期状态的查询和流程监控功能，迅速了解文档进行的状态
1.4.3工程变更管理
由于各种不确定因素的影响，如市场需求变化、产品开发人员疏忽以及产品使用中的问题等原因，对现有产品数据进行更改是难免的。在PLM中，工程变更是对PLM所管理的预发布阶段和发布阶段的产品数据的更改。工程变更管理的目的一方面是保证产品数据的一致性，避免因使用老版本或正在变更中的产品数据而出差错，另一方面是要保证对产品数据修改必要性认证、修改的正确性认证以及修改操作有据可查性。
工程变更的管理分成三个部分：
1)变更申请审批：用户或工作人员因某些原因提出更改申请，企业对变更申请进行确认，必要时则同意申请。
2)变更执行：针对变更申请内容，产品负责人给出变更申请中提出问题的处理意见，并指定专人负责产品数据的修改。变更执行人员按预先定义的流程完成产品数据的修改。对产品数据的更改指定流程是为了保证更改的正确性。
3)变更发布：一方面需要将变更的消息发送到所有的相关人员，另一方面系统要对数据库相应数据更新。这是为了保证数据的一致性，同时让与被变更数据相关的所有用户都能够及时采取相应的措施，减少变更所带来的影响。
另外，系统还提供对工程变更进行跟踪、查询、分类和统计等功能。不同企业可以根据各自产品数据的特点和管理的要求，制定不同的变更流程。在系统中所有变更中的数据都要有明显的状态标志，以避免错误地使用变更中的数据。
图2.10 文档变更申请业务流程图
流程需求如下：
1)提出变更申请
▲对文档有阅读权限的人，可以对最新版本处于“审批完成”状态的文档提出变更申请。启动变更申请流程后，文档变更申请人需要做如下工作：
▲必须填写“变更原因”
▲默认变更申请批准者为文档审批流程中的审核人，但可以由变更申请人修改；对于没有审核人的文档类别，变更申请批准者没有默认值，如果不指定，应该不能完成变更申请任务，且系统给出提示信息。
▲指定修订者，如不指定变更修定者，则系统默认为变更申请本人。
2)批准变更申请申请人完成“提出变更
▲申请”任务后，在批准者的工作表中出现与该变更相关的“批准”任务。
▲批准者可以看到变更申请的相关信息：如要变更的文档编号、名称、变更原因、申请人、修订者。
▲批准者对变更申请进行批示：驳回、否决或同意，对于否决或驳回，必须写明原因。
3)执行变更申请
▲变更申请被批准后，文档的大版本升级，且升级后的第一个版本和升级前的最后一个版本，文件内容一样。比如申请变更文档的版本为A.5，变更申请被批准后，系统自动生成一个版本为B.1的文档，B.1和A.5的物理文件相同。
▲在文档变更时，文档的上一版本的变更原因将会写在下一个版本的“说明”项中。如A.5版本发生变更，其变更流程中的变更原因将自动在B.1版本的“说明”项中显示。
▲系统给修订者赋予升级后文档的修改权限(比如上面的B.1版本)，在修订者的工作表中出现“修改”任务。修订者通过更新文档，提交新版本，完成“修改”任务。
▲修订后的文档使用当前该类文档对应的编组和生命周期，并走对应审批流程。
1.4.4项目管理
项目管理(Project Management)是在项目实施过程中对其计划、组织、人员及相关数据进行管理和配置，对项目的运行状态进行监视，并完成计划的反馈。PLM项目管理定位于产品开发的过程管理，是建立在工作流程管理基础上更高层次管理，项目管理与过程管理的主要区别在于：过程管理通常只是面向一个具体的对象(如图纸、文档等)的状态管理，主要解决对该对象内部数据流的影响，管理粒度很细；而项目管理的范围则广泛得多，它围绕着某一工作目标的实现，进行任务划分、任务排序、任务调度、任务执行结果评估等工作，决不仅仅限于管理一个具体对象，但是通常只涉及任务的人员指派，任务的期限指派，项目资源的分配等粗线条，对内部数据流的涉及深度不及过程管理，管理粒度一般要粗于过程管理。
图2.11说明了PLM系统中项目管理与工作流管理之间的关系。PLM中的项目可以划分为层次形式的子任务，而定义子任务的主要依据是详细的产品结构图，因为，项目的任务结构在一定程度上是产品结构的反映。每处理完一个任务就得到了产品开发过程中的一个阶段成果，为此需要在逻辑上规定一个处理的顺序。
在项目任务结构中的每一个任务都对应了一个相应的工作流，因此项目的完成依赖着工作流管理系统的支持。每一个过程都由一个项目小组完成，并且有自己的项目日历。可以根据需要给项目小组的成员分配相应的活动，而项目小组的成员能否接受所分配的活动则取决于其个人的日历。具体的项目活动可以是生成、更改或使用产品数据。
由一个工作步骤或者一项活动所形成的结果，可以作为另一个工作流的某个工作步骤的基础。当一个工作流结束以后，在产品模型中就增加了一个新的零部件，这样，产品的结构随着项目的进展变得越来越完整。当项目结束时便得到了完整的产品数据。通过PLM系统的项目管理模块，可以将一个产品开发项目及其有关的数据结构化成为一个面向对象的项目模型。利用这个网络式的项目模型，可以确保对项目进行全面的监视和控制。
图2.11 项目管理、过程管理和数据管理的集成
工作流管理系统对整个产品的形成过程进行控制，用以支持和改善所有与产品形成过程有关人员的协同工作，从而从整体上提高工作效率。因此在PLM中，工作流管理模块需要从以下三个方面来支持项目管理的实现。
1)工作流管理模块将面向任务的项目组中属于不同部门的员工联系起来，每一个员工按其专业领域扮演固定的角色，项目负责人按照不同的过程结构，将不同的人员分配给不同的活动。所有与该过程步骤有联系的PLM系统用户，都可以通过PLM项目管理模块得到自己的任务清单。
2)工作流管理模块定义项目流程。工作流管理不仅可以用于控制产品形成过程的各个阶段，还可以对完整的过程链进行控制，该过程链包括了一系列的阶段性标志(项目里程碑)，如产品开发、实验、生产、发放、应用、维护和报废处理等。工作流管理模块定义和维护项目实施、评审、更改、中止和结束等模板，项目经理根据具体情况，从流程模板中选取本项目要使用的流程，确定流程各个节点和项目任务的对应关系，并且规定每个节点(即任务)的操作人员。
3)工作流流管理模块还可以为项目任务数据对象赋予流程。当任务中的业务对象被赋予流程时，流程用于控制该业务对象的流转过程，工作流管理模块根据各环节的操作自动将业务对象推进到下一环节。若任务中有其他相关文档被赋予了流程，只有当所有被赋予流程的文档走完相应的流程后，该任务才能够提交，继续走下一步项目流程结点(即任务结点)。
1.4.5产品生命周期、工作流程、项目以及业务对象之间的关系
在PLM中，业务流程的运行通过工作流实例来完成，包括了为实现共同的商业目标而协同开展的一系列活动，而这些活动又可分解成任务，任务是工作流过程建模的基本单位。因此，一个工作流实例通过把一系列活动依时序和逻辑关系相互连接，依据组织规则在角色之间传递、处理、执行、挂起、或终结。
工作流实例的载体又被称为主业务对象(Primary Business Object，PBO)，用户通过创建主业务对象，关联生命周期，并生成工作流实例。与产品相关的如部件(part)、文档(document)、BOM等称作评审对象或者参考，它们都被直接绑定到PBO上，也就是说将PBO作为评审、参考对象的另一载体。
对于PBO和评审、参考对象，根据业务规则建立生命周期模板，定义合适的阶段和关口；对于整个业务流程，根据功能模块可划分为不同的子过程，然后将子过程与PBO的阶段和关口进行一一对应[18]。PLM中产品生命周期、工作流程、项目以及业务对象之间的关系，如图2.12所示。
图2.12 生命周期、IPD项目、工作流程和业务对象关系
在PLM系统开发过程中，首先对具体业务对象在生命周期模板中定义生命周期历程，包括阶段和关口，然后选择此生命周期历程的角色，通过权限控制列表指定参与人，最后在每个关口给出进阶标准。生命周期定义完成后，要对业务对象进行立项，项目的整个运行过程都在已经定义好的生命周期内展开各种活动。项目立项完成后，要对整个生命周期中阶段和关口来划分工作流实例，每个生命周期阶段或关口都对应分解完成的工作流子过程。当工作流实例启动时，系统自动的将生命周期的角色与项目角色映射，再将项目角色通过二次映射，将参与人或群组赋予工作流实例各种任务的执行者。
因此在整个PLM系统中，工作流与文档管理、变更管理、项目管理以及生命周期状态管理紧密相关，是业务数据流动的载体，是PLM系统的重要支撑模块。
1.5面向PLM的工作流管理系统功能模型
前文通过对工作流系统的组成以及PLM系统中工作流管理需求分析，明确了工作流管理系统在PLM系统中的应用功能，因此本节建立了面向PLM的工作流管理系统功能模型，如图2.13所示，该模型将工作流管理系统作为PLM系统架构的一部分，实现了工作流管理系统和PLM其他模块的紧密集成，可以将结构复杂的过程定义分解成相对简单的生命周期阶段工作流，并可以实现灵活的访问权限控制以及工作流参与者角色解析，实现对文档管理、产品结构管理、变更管理、项目管理等模块的支持，满足了企业对产品全生命周期管理的需求。下面分别介绍该功能模型中的主要功能模块。
图2.13 PLM系统的工作流管理功能模型
1.5.1过程建模工具
建模工具通过图形化的操作界面实现工作流过程模型的定义、修改、删除和批量导入导出标准XML文件的功能，并支持将模型文件编译生成动态库技术，即模型文件在使用之前会编译成模型动态库，一个过程模型对应会生成一个模型动态库。
其优点如下：
①提供了良好的对外接口特性，可以支持用户在建模时自己编写标准C#代码或引用外部系统提供的业务组件，从而使工作流系统可以拥有复杂的业务逻辑和良好的可扩展性；
②改变了加载模型文件定义信息的方式，由传统的从数据库中加载转变为系统反射调用动态库文件来读取向关信息，减少了数据库的访问次数，提升了系统的处理性能。工作流定义的对象以及对象之间的关系如图2.14所示。
1)工作流定义(过程模型)：过程模型反映的是企业的一个经营过程。它一般包括诸如名称、版本号、过程启动和终止条件、系统安全、监控信息等一系列基本属性。
2)活动：活动相当于经营过程中的任务，主要反映完成企业经营过程需要执行哪些功能操作。它一般包括活动名称、类型、活动的前后条件、调用约束参数等。
3)迁移条件：迁移条件对应于企业经营过程中的业务规则和操作的顺序，主要负责为过程实例的推进提供导航依据。主要包括工作流过程条件、执行条件和通知条件。
4)工作流相关数据：工作流相关数据是工作流引擎执行任务推进的依据。主要包括数据名称、数据值等。
5)角色：角色主要描述企业经营过程中参与操作的人员和组织单位。主要包括角色的名称、组织实体、角色的能力等。
6)外部应用程序：外部应用程序主要描述用于完成企业经营过程所采用的工具或手段。主要包括应用程序的名称、类型、路径以及运行参数等。
过程定义元模型的核心是活动。工作流定义与活动、工作流相关数据之间是一对多关系，即一个工作流定义由多个活动与多个工作流相关数据组成。活动、角色、工作流相关数据、需要激活的应用程序、转换条件之间都是多对多关系。如一个活动可以引用多个角色，一个工作流数据可以被多个活动使用。
1.5.2工作流客户端应用
客户端是普通用户用来访问工作流系统的主界面，实现了工作流服务与客户应用之间的接口，包括过程实例管理功能，过程状态管理功能，任务项列表任务项处理功能，数据处理过程，过程监控功能，其它的管理功能等。
1.5.3外部被调用的程序
工作流引擎可以通过调用外部系统提供的接口来实现特定的业务流程，实现了工作流引擎和直接调用的应用程序之间的接口，包括通信建立，活动管理功能，数据处理等功能。
1.5.4工作流管理工具
系统管理与监控主要包括资源控制，过程实例的管理，状态管理，审核管理等。管理工具提供系统中流程、应用管理、工作流实例、活动实例等相关的查看及管理功能。
1.5.5工作流引擎
作为工作流管理系统的核心，在企业经营过程中，它实际上是企业的任务调度器，并且还在某种程度上是企业的资源分配器。引擎提供了过程实例执行的运行环境，主要完成以下功能：
1)对过程定义进行解释：通过读取模型文件和反射调用模型动态库，获取过程定义相关数据，为过程的实例化做好必要的数据准备。
2)启动过程实例：通过对过程定义的解析，并判断满足过程实例启动条件后，启动过程实例。同一个过程模型可生成不同的过程实例，并且互不干扰。如文档审批流程，不同的文档可以同时启动各自的审批流程，在流程引擎的控制下独自运行。
3)为过程和活动的执行进行导航：根据过程定义和工作流相关数据，为过程实例的运行进行导航，如根据人工节点的任务处理人选择的路由进行后续的路由选择，或者通过设置自动节点，由程序根据流程的运行变量信息来进行后续的路由判断，决定并行或串行执行后续活动，或者根据所需激活的应用程序信息启动相应的应用程序等等。
4)对过程实例进行监控：提供控制、管理和监督工作流过程实例执行情况的功能，包括过程实例和节点实例的创建、激活、挂起、终止的操作。图2.15和图2.16分别描述了流程实例和活动实例各个状态之间的转换。
图2.15 流程实例状态转换图
流程实例包括以下几种运行状态：
▲未开始：表示一个过程实例已经生成，但该过程实例并没有满足开始执行的条件。
▲准备运行：该过程实例已经开始执行，但是还不满足开始执行第一个活动并生成一个任务项的条件。此时用户可以调用引擎的接口更改设置流程的实例信息。
▲运行中：表示流程已经处于正常的执行状态中，一个或多个活动已经开始执行；
▲已暂停：该过程实例正在运行，但处于暂停状态，除非有一个“恢复”的命令使该过程实例回到运行中状态，否则所有的活动都不会执行。
▲异常：表示流程因程序或逻辑等的原因出现错误，导致工作流出现异常。可以重新启动该流程来恢复流程的运行。
▲已完成：该过程实例满足完成的条件，工作流管理系统将执行过程实例完成后的操作，并删除该过程实例。
▲已终止：指该流程在正常结束前因错误或人为的原因而被迫终止(如出现错误或者异常情况)，工作流管理系统将执行补救措施，并删除该过程实例。
图2.16 活动实例状态转换图
活动实例包括以下几种运行状态：
▲未开始：表示该节点还没有被实例化。
▲运行中：该活动实例已经被激活，正在运行;
▲已暂停：因系统管理员监控或等的操作，使节点处于暂停状态，节点的活动处于静止状态。可以通过恢复操作使系统恢复到运行态。
▲异常：指表因程序或逻辑等的原因而使节点实例出现异常。可以通过重新启动该节点实例来恢复节点的运行。
▲已完成：该活动已经执行完毕，工作流管理系统将进行活动结束后的导航工作，激活后续符合启动条件的活动。
在任务状态改变时必须遵循如下业务规则：进程状态为“已暂停”，不能使用节点的“恢复”功能恢复“已暂停”的节点的状态为“运行中”。
5)维护工作流控制数据和工作流相关数据，在应用或用户间传递工作流相关数据工作流在执行过程中要维护不同过程和活动实例的内部状态信息，以及用于协调和恢复的各种检查数据和恢复/重起信息，还包括用户传送的必要的相关数据。
6)与外部资源交互完成各项活动：工作流执行服务通过两种途径完成与外部资源和用户的交互：客户应用接口和直接调用应用接口方式。对于客户应用方式，工作流引擎通过任务项列表管理器对任务的执行进行管理。任务列表管理器可以根据不同的任务类型，来让用户进入不同的任务处理界面，从而可以利用各种任务处理界面的不同的业务功能。
在任务执行完成后，系统会修改相关任务项的状态，如设置完成标记，另外系统还会检索该任务项所对应的节点的任务项是否全部处理完成，若全部处理完成则系统会自动触发该任务项对应的节点实例的完成操作。当然，在用户提交完成任务项的时候用户可以自定义各种条件逻辑判断，如果判断不满足，则系统可以阻止用户提交任务项。
1.6本章小结
本章首先介绍了工作流系统的组成，然后分析了PLM系统中生命周期状态管理、文档流程管理、变更管理和项目管理的主要功能及其对工作流管理的需求，建立了面向PLM的工作流管理系统功能模型，并研究了其中的主要功能模块。
