会员登录
会员注册
4、基于事例处理的工作流管理系统的体系结构
通过上节的分析，图4给出了基于事例处理的工作流管理系统的体系结构，该体系结构与工作流管理联盟所提出的参考模型基本一致[7]。系统的逻辑设计包括过程定义、用户的角色分配、数据处理设计、表单定义、事例的授权与分配等方面。工作流执行服务中的工作流引擎是整个系统的核心，主要负责工作流过程实例的执行、事例活动的状态控制、用户事例列表的维护以及对外部资源的访问等工作。管理监控工具对运行过程中过程实例的状态进行监控与管理。工作流引擎通过代理，可以访问过程数据、用户信息和文档信息等数据库资源。客户端应用程序为用户提供一种手段，以处理过程实例运行过程中需要人工干预的任务。而被调用的应用程序是指工作流执行服务在过程实例的运行过程中所调用并对应用数据进行处理的外部应用程序(比如文档管理模块) 。图中的几个WAPI (workflow applicationpicture interface) 依赖于确定的开发平台。根据该体系结构，可以通过Lotus Domino/ Notes 中的Flow2 Mark 工作流开发平台来予以实施。
5、案例
图5 给出了基于事例处理的工程项目工作流管理系统的界面。在工作区域的上部窗口是当前正在执行或查看的流程，其中可能包含子流程。下部左边的窗口相应显示当前流程中的活动和子流程。下部右边的窗口则是与当前流程所相关的表单、文档等信息。从图中可以看出，系统当前流程为“某设计方案的变更”，其中包含一个“登记某设计方案的变更要求”的子流程和“修改某设计方案 ”、“审核新的设计方案”、“归档并分发”三项活动。对于该界面，需要说明的是: ①活动和子流程的状态可以是待办、在办、已办、略过以及重做等等，比如张三(假设为设计方人员) 对于审核新的设计方案不具有执行角色，因而对该活动可以略过; ②所打开的表单应标明哪些是强制数据、哪些是限制数据，比如设计方案审核表单中的“同意与否”应为必须填写的强制数据。
当然，壳- 核结构模型也有它的不足之处，主要体现在以下2 个方面:
(1) 壳- 核结构的定义还不是十分精确，因此需要开发人员精心地去划分系统层次，并在开发过程中摸索，总结经验。这会增加些额外的工作，尤其是刚开始的时候。
(2) 壳- 核结构模型的目的是为那些与外界联系复杂的信息系统提供简化其系统结构的途径，因而对于那些相对孤立、简单的系统，运用壳- 核结构就有点得不偿失了。
无论如何，从系统设计开始就考虑与其他系统的协作，而不仅仅是功能的可扩展，可以体现真正意上的开放系统。平台是否一致并不重要，信息技术的发展可提供足够技术去实现异构系统的协作。可以想象遵循某种原则来实现系统间协作，以致构成极富弹性的信息系统体系，应比遵循某种技术标准来实现系统的集成要灵活很多。