工作流需求说明书

工作流需求说明书

1 前言

为构架完整EDM产品，更好满足特定用户需求，需要进行项目管理和工作流管理模块的开发。

此需求计划由公司内部提出，在需求讨论和编写过程中，总结PDM组在“863”项目中开发工作流原型的经验，吸收部分企业对工作流的需求意见，参照国内外同类产品的现有系统，确定了我公司开发的要求和目标。

此工作流需求说明书作为项目组内部开发指导文件。

1.1 目的

开发项目管理和工作流模块，所有的过程逻辑控制在工作流中实现，并通过项目管理进行任务分发、任务提交、过程跟踪等。工作流系统中的服务模块（如工作流引擎）基于DCOM实现，作为组件提供给系统使用。

本文档的预期读者为项目组开发人员、质量保证人员、市场销售人员及公司领导层。

1.2 范围

实现的项目管理（ProjectManage）和工作流管理（WorkflowManage）作为CEDM的两个模块，不单独包装为产品。

工作流管理实现WfMC定义的基本功能：工作流引擎、图形化定义工具、工作流客户端、工作流管理平台。但实现的功能为WfMC定义功能的子集，不考虑异构工作流系统间的交互，不考虑数据对象在工作流上的传递，不考虑工作流结点上脚本的实现。

项目管理以工作流管理为核心。项目加载工作流模板后，对任务进行描述，包括设定项目承担人、任务截止日期、任务优先级等，进行工作流的启动、流转、操作。项目管理不包括对设备等其他非人力资源的调度，不负责对项目进度排程的优化和组合。

1.3 定义、缩写词、略语

WfMC(Workflow Management Coalition)工作流管理委员会，有关工作流的国

际标准化组织。

DCOM（Distributed Component Object Model）。微软的分布式计算平台。1.4 参考资料

1.罗海滨.工作流技术综述.软件学报.2000（11）,7:899-907

2.范玉顺.基于工作流的CIMS应用集成支持系统研究.计算机工程与应用.

2000,2:9-10

3.范玉顺.工作流管理技术基础.清华大学出版社.2001.4

4.Wil.M.P. Van Der Aalst. Verification of Workflow Task Ttructures: a

Petri-net-based approach information systems. Vol.25 No.1 pp.43-69 5.Ellis C.A. Null. G.J..Modeling and Enactment of Workflow System

Application and Theory of Petri Net Lecture Notes in Computer Science 691,Berlin Springer-Verlag,1993 1-16

6.卢正鼎.面向并行工程的产品设计过程管理的抽象模型.计算机辅助设计与

图形学学报. 2000,Vol12. No.2:123-124

7.刘铁铭.基于工作流的企业过程建模与仿真. 清华大学学报. 2000 ,Vol.40

No.1:109-110

……

参考的应用系统

1.SmartTeam4.0 以色列Smart Solution公司

2.开目PDM 武汉开目公司

3.大恒PDM2.0 北京大恒公司

4.LOTUS workflow 美国IBM

5.workflo 上海新视界

2 项目概述

2.1 产品描述

系统要求实现项目管理和工作流管理两部分，重点是工作流管理，项目管理的调度通过调用工作流系统中的方法来实现。

图1 项目管理/工作流管理功能整合示意图

项目管理完成项目定义、项目分解等工作，项目任务的流程设定、过程管理、过程监控完全由工作流系统承担，在系统中，项目管理更多的作用是作为一个集成的操作界面。

项目管理和工作流管理的应用模式与CEDM系统一致，在软、硬件平台的要求上等同于CEDM系统。

2.2 产品功能

项目管理的功能比较简单，在此不再陈述。

工作流管理系统实现的功能如下：

图2 工作系统结构图

1．图形化定义工具

流程设计通过图形化的界面表达出来，清楚直观，易于理解。

●新建活动节点、条件节点

●设置活动（条件）名称、类型、内容、执行角色、前后条件、处理时间、

逻辑判断规则设定

●绘图功能：对齐、分布、移动、网格等

2．工作流管理

●过程模型初始化：提交定义好的流程模板，设定运行参数、相关人员和

处理时间

●工作流维护：修改属性、活动、角色、流转条件、执行顺序

●过程监控，跟踪活动状态

●评审和统计

3．工作流引擎

●解释工作流模板

●控制过程实例的创建、激活、挂起、终止等

●控制活动实例间的转换，包括串行或并行的操作

●提供支持用户操作的接口

●维护工作流控制数据和工作流相关数据，在应用或用户间传递工作流相

关数据

●提过控制、管理和监督工作流过程实例执行情况的功能

4．客户端应用

●启动/终止工作流过程实例

●任务列表/任务项处理（完成、终止）

●过程状态查询

●获取/返回工作流相关的数据

5．人员组织管理

利用EDM现有的组织管理模式

2.3 用户特点

项目管理和工作流管理的用户与CEDM的用户群一致，面向制造企业的设计、规划等相关部门。

2.4项目规范

为保证本次系统的开发顺利进行，特明确以下规范。

质量要求

1.质量控制。软件开发的过程严格遵守公司的软件开发规范，包括重要过

程的评审和审查。

2.文档规范。参照研发中心发布的文档格式，保证文档的正确性和严谨性。

3.编码规范。编码规范和界面风格遵守项目组制定的有关标准。

4.辅助工具。软件设计、开发过程引入CASE工具，在各阶段提交相应的

UML模型，如需求阶段提供Use Case图。

开发环境

1.应用代码的开发采用VC++6.0。

2.数据库采用SQL Server7.0。

3.采用微软DCOM平台。

3 具体需求

3.1 项目管理

项目管理实现任务分发、处理、监控等功能，同时它把工作流客户端上的很多应用集成起来，为个人提供有关项目处理的工作平台。

3.1.1 功能要求

项目管理树

在CEDM系统中，项目管理和产品结构管理以产品为中心将同时展开。一方面，在产品结构树页面中进行产品结构的创建和维护，另一方面，在项目管理页面中对同一产品进行项目展开，完成任务的分解和下达。

在项目管理中，项目维护同样以树的形式存在，并把它实现为可以和产品结构树切换的页面。

项目树维护

在项目管理树中通过树上每一个结点对应的右键功能菜单完成项目树的创建、修改、删除等操作。一个项目的根结点对应于产品结构树中的一个产品结点，通过在项目结点下创建子项目的方式逐级创建。

过程监控

提供一个任务列表查询的界面，用户登录到系统后，点击任务列表查看按钮，可以看到当前任务的提示，包括任务来源、任务说明、任务重要级别、完成期限、任务当前状态等信息的显示。任务列表的管理是由工作流引擎处理的，在这里，只提供任务列表显示功能。

流程设定

工作流模板只表示了项目中各任务结点执行时的逻辑关系，没有具体任务、任务承担人等具体信息的描述。这时要在项目树中进行工作过程模型初始化的工作，类似于对象的实例化，初始化的过程即是确定项目任务、责任人、任务完成日期、任务优先级等属性的过程。

过程模型初始化后，应允许用户进行修改和调整，即工作流过程模型的维护功能，包括修改工作流实例各个结点上的属性、活动、角色、流转条件等。

对工作流模板及其实例的所有操作方法由工作流引擎作为服务方提供，项目管理中的流程设定只作为与用户交互的客户端存在。

过程管理

工作过程模型初始化后，进入对工作流程的过程控制，包括启动/终止工作流，任务处理和内部邮件管理。启动工作流用来激活一个工作流实例，工作流引擎即对激活的工作流实例进行自动调度。终止工作流可以停止一个工作流实例的执行。

任务管理是一个任务结点在客户端的处理过程，主要是处理结果的提交，给出处理意见，处理结果作为工作流中下一步流向的判断条件，处理意见传递给流程中的下一个结点。

邮件管理提供内部邮件的收发功能，系统为用户提供收件箱，用于接收消息和邮件，发送邮件在发送消息的时候，可以把文档作为附件一起发送。

收发邮件的服务由工作流引擎提供，客户端进调用。

3.1.2 交互界面

本部分描述系统与用户交互的界面，这些交互的界面全部集中在CEDM客户端。

项目管理树

图3 系统窗口布局

产品结构树与项目管理树做成可以切换的TAB方式，产品结构树保留原有方式，点击项目管理树TAB按钮，左边区域切换到项目管理树视图。

两个视图中的数据分别独立维护，不需要对数据的交互和同步进行处理。项目树维护

项目树管理类似产品结构树的管理，项目树组织如下：

图4 项目管理树结构

项目管理树的建立逐级进行。在项目树的每个结点上，对应如下的右键功能

菜单。

图5 项目结点上的右键功能菜单

项目分解通过“创建下级项目”实现，“修改项目属性”、“删除项目”完成对项目树的维护。

在CEDM系统菜单中，增加“任务列表”、“收邮件”、“发邮件”三个菜单项。对系统的每一个用户，都可以点击任务列表查看自己当前的任务。

任务列表

任务列表向每位用户显示当前需要处理的工作，任务列表起到提示的作用，不需要编辑处理，数据从工作流引擎中得到。

任务列表的显示形式如下：

表1 任务列表

工作流程初始化

在工作流程的图形化定义工具中，只定义了工作流模板，描述了工作流程执行的先后顺序，具体信息的设定需要在工作流程初始化的时候完成。

工作流程初始化首先是加载工作流模板，在模板的列表中选择一个需要初始化的对象。选择“模板初始化”，提供图形化的界面用来设置工作结点上的初始信息。

图6 工作流初始操作

选中一个结点，可以定义如下信息：

图7 工作流结点对应的描述信息

信息类型分成四大类：基本信息、人员分配。用TAB页面分开表示。

基本信息是对结点的通用信息描述，包括结点类型、结点名称、任务描述、重要级别、完成期限等。其中结点类型、结点名称是继承模板中的信息，结点类型包括是工作结点和控制结点，结点名称与模板中的结点名称一致。

人员分配，指定此工作结点的任务承担人，并确定有关策略。任务承担人可以是一个人或多个人，或者是一个角色代表的一个工作组。策略是指一个工作结点上任务承担人合作方式，如明确是由一个人完成还是由所有人完成。

图8 人员分配对话框

工作流维护

工作流维护是把初始化后的工作流调出来修改，如更改基本属性信息，重新进行人员分配等。在这里也可以删除一个执行完毕的工作流。

处理界面类同工作流初始化，不再详述。

注意：一个工作流一旦启动，在运行的过程中不能进行工作流的维护。（如果要求这种动态维护，实现起来就太麻烦了。）

启动/终止工作流

界面简洁。在工作流实例列表中选择操作对象，选择启动，后台的工作流引擎开始对此流程调度；选择终止，结束对流程的调度。

任务处理

任务是否完成需要由任务完成人自己提交，用户选择一项任务，点击通过、不通过、返回起点等按纽进行处理。

图9 任务处理对话框

通过，工作流引擎认为此工作结点上的任务已经完成，信息处理按正常流程转移到下一个任务结点。

不通过，信息处理按出错流程转移到工作流中预定结点。

重做，当前工作结点所做工作失效，重新进行处理。

点击这三个按纽，都可以弹出处理意见对话框：

图10 任务处理意见对话框

填写处理意见时，可以粘贴附件。确定后，处理意见和附件通过邮件系统发送给流程中的下一个结点，下一个结点的任务承担人可以在收件箱中查看。

收发邮件

在系统内部，实现基本的邮件收发功能。

收邮件，给出所有收到的邮件，附件可以另存到本地，EDM能支持的文件格式可以直接浏览。

发邮件，从系统用户中选择收件人，可以发送消息和附件。

3.1.3 逻辑处理

在项目管理过程中，逻辑处理分成以下三种：

图11 项目管理树管理

工作执行

工作执行对应项目的普通员工。

图12 工作流运转流程

工作流管理

工作流管理对应由产品主管或项目主管来完成。

图13 工作流维护六流程

邮件功能

图14 邮件收发流程

3.2工作流模板定义

采用图形化的手段定义工作流的基本模板，模板中的控制和结构信息可以保存到后台的数据库引擎中去，作为工作流引擎进行流程调度的依据。

工作流模板定义作为工具集独立存在。

3.2.1功能要求

工作流模板定义通过图形化的手段实现，给用户一个直观的印象，方便用户使用。功能主要实现图形处理、结点处理、模板保存等功能。

图形处理

提供工作流图形化表示的一系列工具集，包括用鼠标拖画流程中的结点，结点之间具有方向性的连接线。

为提高画图速度，提供网格功能，鼠标自动捕捉到最近的网格点。

结点移动时，相关联的连接线能同步移动，能实现图形显示时的消隐处理。结点处理

工作流模板中的结点分成两种类型，工作结点和控制结点。

工作结点对应具体的一个工作单元，用来描述结点上所要处理的工作。在工作流初始化时，对工作结点进一步描述。

控制结点是模板中的一种辅助结点，包含控制流程的逻辑判断条件，可以降低流程处理的复杂程度。在工作流初始化时，一般不需对控制结点进一步描述。模板定义保存

图形化的模板绘制完成后，需要把其中的控制信息和结构信息保存到工作流引擎对应的数据结构中，一方面需要把模板上的信息整理归类，映射到工作流的具体数据结构中去，另一方面，需要对整个图形视图序列化保存，以变在需要的时候对图形重现。

3.2.2交互界面

工作流图形化定义界面主要体现在工作流模板的图形处理上。

整体界面布局

图15 工作流图形化定义主界面

工具条区用形象化的图标来表示，这些功能图标对应的功能应包括：画工作结点、画控制结点、结点间划连线、网格显示与关闭等。

确省地系统自动给出开始结点和结束结点。

对结点与连接线的编辑通过各自上面的右键菜单进行。

结点上附带的右键菜单

图16 工作流模板中结点对应的右键菜单

结点属性编辑框

图17 结点属性定义界面

结点类型分两种：工作结点和控制结点。

结点名称：由用户指定，如设计、校核、审定等。

结点图标可以通过选择文件对话框选择一个图标文件。

字体、对齐方式等规范结点名称的显示形式。

连接线属性描述框

图18 连接线属性编辑框

回复类型有以下几种：接受、拒绝、检查。

字体可在系统安装的字体库中选择。

线型包括可供用户选择的实体线、点划线、虚线等类型。

风格分直线、水平线、垂直线几种。

线宽用来设置连接线的宽度。

工作流模板图形化示例

图19 工作流模板示例

图中，矩形代表工作结点，椭圆代表控制结点，连接线中的恢复类型缺省为接受。

3.2.3逻辑处理

工作流模板图形化定义的逻辑处理相对简单。

图20 工作流模板图形化定义的逻辑处理图

3.3工作流引擎

工作流引擎是整个系统最核心的部分，它维护工作流实例的自动流转，并提供一系列的方法供客户端调用，实现客户端与工作流引擎的交互。

3.3.1功能要求

工作流引擎应提供如下功能：

维护工作流模板与实例

处理工作流模板上的结构信息和控制信息，保存模板实例化后的工作结点、控制结点中的属性信息。要求工作流引擎提供的这部分数据模式能有效、无歧义地对模板与实例进行记录。

工作流流转控制

包括实例的创建、激活、挂起、终止等。根据工作流模板与实例定义的逻辑，引擎能自动控制工作流的运转，处理过程中，能提供较强的容错机制。

数据传递

及时准确地把正确的信息传递给正确的人。这里信息有控制信息、处理意见、文档数据等。

收发邮件

提供收发邮件功能。完成对邮件传递、保存、后期维护等过程的管理。

任务列表管理

引擎针对系统中的每一个用户提供任务列表管理，并记录每一项任务的状态，用户对一项任务处理提交后，引擎要更新任务状态。

用户操作接口

工作流引擎需要与项目管理、工作流模板定义、工作流监控台进行大量的信息交换和数据传输，这些操作即要求工作流引擎端提供相应的接口，客户端应用程序通过调用接口实现这种交互。

这些接口符合DCOM中的IDispatch或IUnknown规格。

3.3.2交互界面

工作流引擎主要在服务端运行，不需要复杂的交互界面。在CEDM系统中，增加一条菜单项“启动工作流引擎”即可。

3.3.3逻辑处理

工作流引擎作为服务端，与用户操作没有直接的联系，这里暂不描述它的内部逻辑处理过程，这部分的逻辑模型将在概要设计和详细设计时进行处理。

3.4工作流监控台

工作流监控台作为一个独立的工具提供给用户使用，这个用户具有对所有工作流和任务具有监督和管理的权利。

3.4.1功能要求

工作流监控台提供一个集成的界面，监督系统中所有工作流实例的执行状态；查看所有员工的任务列表；管理任务列表中的历史信息。

工作流执行查看

监督员可以选定一个工作流实例，查看实例的执行情况。系统提供一个图形化的界面，显示工作流实例图，通过图标的变化说明工作完成的情况。

任务列表查看

选择系统中的任一用户，可以列出他当前的任务列表。此处任务列表的显示与项目管理中显示的任务列表一致。

历史信息统计

选择系统中的任一用户，可以列出他所有已经完成的的任务。在此基础上，可以按照多种时间段（月、季、年）和多种分类（任务说明、优先级）提供任务统计功能。

3.4.2交互界面

工作流监控台作为一个工具，具有独立的界面。

针对上述三个功能要求，提供三个操作界面。

工作流执行查看

首先列出工作流引擎中所有的工作流实例，用户选择一个，则当前的工作流实例以图形化的方式显示出来，当前正在处理的工作结点通过变换图标或颜色的方式显示出来。

图21 工作流实例运行状态

此图中表示此项工作已进行到审定阶段。

任务列表查看与统计

在系统用户列表中选择一个用户，指定显示他当前的任务列表。显示方式与项目管理中的任务列表显示一致。

在系统用户列表中选择一个用户，指定任务列表统计，任务列表中显示该用户所有已完成的任务。如果给出了限定条件，如某期段完成的任务、某种类型的任务，则只显示满足给定条件的任务列表。

3.4.3逻辑处理

工作流监控台逻辑处理相对简单，它只提供查询的功能。

图22 工作流监控台逻辑处理图

3.5 权限控制

项目管理与工作流管理的执行需要有权限控制，在创建“产品项目”结点时，指定项目的负责人，它具有对项目进行分解和管理工作流的功能。

项目主管具有如下权限：

●创建下级项目

●修改项目属性

●删除项目

●工作流程初始化

●工作流维护

●启动工作流

●终止工作流

工作流模板定义与工作流监控平台作为两个工具集独立运行，不在CEDM系统权限控制之列，考虑采用授权号的方式进行管理。

工作流引擎与CEDM服务端集成在一起，它的启动没有权限的限制。

4 设计约束

4.1 系统运行平台

系统硬件运行环境与CEDM系统要求一致。

4.2设计要求

1.采用CEDM中的体系结构，如对象的定义通过FormDesigner进行，功

能实现通过注册与菜单项相关联。

2.界面风格与CEDM系统保持一致。

3.工作流系统中的工作流引擎实现为DCOM组件，其它模块不做此要求。

4.数据设计的逻辑结构与CEDM一致。

5.工作流及邮件中附件的处理采用CEDM中的文件引擎。

6.人员组织、权限管理与CEDM中的人员权限管理实现统一。

5 风险分析

项目管理与工作流管理的开发是根据市场反馈的需求确定的，但此需求报告不是根据某一家用户的具体需求编写的，而是在综合用户的一些一向、参照同类产品的功能，由公司研发部提供的。此次开发，我们认为存在以下风险。

用户流程的模糊与多变

在与用户的交流中，大部分对工作流系统缺乏一种严格的定义，既希望工作流程能准确严谨地调度，又希望工作流系统能保持独立性和灵活性，在进行例外处理时能不受工作流程的制约。这为系统的分析带来很多的不确定性的因素。

用户流程确定后，可能频繁被修改。目前，企业管理中经常发生的业务重组导致流程变化很快，如果一个工作流正在执行过程中发生了流程变更，工作流系统难以处理。

这些情况导致工作流系统的应用不可能象图档管理应用一样有比较固定的模式和流程，从而会影响工作流系统的应用效果。

工作流引擎实现的复杂性

项目管理和工作流系统的核心是工作流引擎，绝大部分功能要在工作流引擎端实现，客户端只是与用户交互的一种手段。由于工作流调度过程中的复杂性和用户要求的灵活性，使得工作流引擎的实现变得十分困难。大部分商用的工作流系统的引擎也存在不少缺陷，很多组织与公司致力于工作流实现模式的研究和探讨。WfMC在发布的工作流规范中，也只给出工作流实现的框架，而很少涉及实现的模式和手段。在工作流模式上，有基于对话的模型、基于Petri网的模型等，在实现的手段上，也是百家争鸣，有基于消息队列、基于文件、基于数据库、基于组件与套件等多种方式。总之，工作流系统的研究和开发处理发展期，没有形成占主导地位的模式和方法。

对于复杂的工作流系统而言，我们对系统的分析、设计和规划环节存在能力不足的问题，因此，需要在项目的前期阶段慎重对待，采用多种手段保障前期工作的质量。

DCOM技术的成熟与掌握

DCOM技术作为分布式计算技术的一支主流，发展很快，在很多应用系统中得到应用。同时它的变化也很快，从COM到DCOM再到COM+，从体系结构到实现细节都不断在发展和调整。此次我们决定把工作流引擎实现在DCOM平台上，也面临熟练掌握DCOM技术的挑战。

在前期的工作准备上，项目组在DCOM技术上做了很多技术上的论证和准备工作，包括开发了一些实验系统来验证DCOM的性能，同时公司在CORBA 技术的应用上也有丰富的积累。但DCOM技术毕竟与CORBA有很大差别，公司在DCOM也缺乏开发一个实际应用系统的经验，在此问题上，需进一步投入力量，加强对DCOM的掌握程度。

公司的支持与保障