术语解释 表1 工作流管理系统术语解释 术语／缩写 解 释 过程定义 由过程定义工具所定义的一个工作流过程 过程实例 过程定义运行之后转化为过程实例，一个过程定义可以产生多个过程实例 活动 一个相对独立的工作的描述，它是过程定义的一个重要组成部分 活动实例 活动运行之后的一个实例 工作项 在一个活动实例中，工作流参与者所需执行的工作 工作项列表 一个参与者所负责的所有工作项的详细描述 信牌箱 活动之间传递信息的驿站 转移 从活动到信牌箱或从信牌箱到活动，描述信牌箱与活动之间关系的连接 工作流控制数据 表示过程实例、活动实例的状态信息 工作流相关数据 与业务过程相关的数据，工作流引擎根据它们来确定过程实例的状态转移 日志数据 系统中所有发生的事件及相应数据的记录 运行服务器 负责整个过程的运行、调度、查询及日志的记录等 过程定义状态 表示过程定义目前所处的状态，如：是否已发布等 过程实例状态 表示过程实例目前所处的状态，如：运行、挂起等 活动实例状态 表示活动实例目前所处的状态，如：运行、挂起等 工作项状态 表示工作项目前所处的状态，如：运行、挂起等 引擎 运行服务器的核心，负责过程实例的执行、调度 引擎容器 包含了多个引擎，并提供多引擎管理功能 4 工作流管理系统功能分析 前面已经介绍过，一个完整的通用工作流管理系统应当包括七个部件，这里限于篇幅的原因，只对工作流管理系统的核心部分：工作流执行子系统和工作流引擎进行分析。 工作流管理系统核心功能 工作流管理系统的核心组成部分称为工作流执行子系统，它为创建、初始化和执行过程实例提供了一个运行环境。 在一个工作流执行子系统中可以包括一个或多个工作流引擎，前者是一种集中式的实现方式，而后者是一种分布式的实现方式。分布式的实现方式又可以分为同构和异构两种不同的情况。所谓同构是指在一个运行服务系统中包含了多个兼容的工作流引擎；所谓异构是指在工作流管理系统中包含了两个以上异构的工作流执行子系统。 工作流引擎是工作流管理系统的核心软件部件。它的主要功能有：解释过程定义，控制过程实例（创建、激活、挂起、终止等），按照过程定义已确定的业务逻辑调用各项活动，为用户工作表添加工作项，维护工作流控制数据和工作流相关数据，调用应用程序，提供监督，管理和审计功能。 工作流执行子系统涉及四种数据：工作流控制数据、工作流相关数据、组织/角色模型数据和工作表。 第一种，工作流控制数据。指只由工作流执行子系统维护的内部控制数据，主要用于表示过程实例与活动实例的状态信息。 第二种，工作流相关数据。指与业务过程相关的数据，他们由应用程序或由用户通过工作项处理来产生和更新，工作流引擎根据相关数据来确定过程实例的状态转移，例如过程调度决策数据、活动间的传输数据等。 第三种，组织/角色模型数据。是描述组织结构的数据，主要用于确定工作项的执行者。 第四种，工作表。列出了与工作流参与者相关的一系列工作项。 5 建模实例 5.1 创建用例视图 用例视图从外部用户的角度捕获系统的行为。它将系统功能划分为对活动者（系统的理想用户）具有意义的事务。这些功能片被称为用例。用例通过系统与一个或多个活动者之间的一系列消息描述了与活动者的交互。其活动者包括人员、其它的计算机系统和进程。 活动者用一个小人表示，活动者的名字标在这个小人的下方。用例用一个椭圆表示，用例的名字标在椭圆中或下方，用实线与同自身通信的活动者相连接。用例视图对活动者，所感知的系统功能进行建模，目的是列举活动者和用例，显示活动者在每个用例中的参与情况。 a. 工作流执行子系统 图1表示工作流执行子系统的用例图。活动者包括WfClient（工作流客户端）、Monitor（工作流监控端）、DefinitionDB（工作流定义数据库）、EnactmentDB（工作流运行数据库）、OrganizationDB（组织机构数据库）、ApplicationDB（应用程序数据库）、WorkItemDB（工作项数据库）、ConfigFile（工作流系统配置文件）。这里，WfClient 作为接收用户交互的界面部分，将用户所作的行为，依照固定的规则，将请求送给工作流执行子系统进行处理。Monitor 作为接收系统管理员交互的界面部分，将系统管理员对系统作出的调整，发送给工作流执行子系统进行处理。其余的DefinitionDB 等活动者，负责将工作流执行子系统每一步的操作与状态记录到数据库中，以永久保存。用例包括ResourceLocate （ 资源定位）、EngineContainer （ 引擎容器）、ProcessDefLoad（定义装载）、ProcessMonitor（过程监控）、Util（公用程序）。其中，EngineContainer 通过ResourceLocate 定位所有系统所用到的资源，表EngineContainer 用例使用ResourceLocate 用例，用带有箭头的实线表示。EngineContainer 不直接与用户交互，活动者对工作流的参与都是通过ProcessMonitor 这个工作流执行子系统的入口来进行的。EngineContainer 通过ProcessDefLoad 将现有的工作流定义装入，这样才能运行该工作流，EngineContainer 用例与ResourceLocate 用例之间是使用关系。 这里仅给出用例ProcessMonitor 的具体功能分析。这些功能分析作为对ProcessMonitor 用例的注释，不在用例图上标识，只作为系统详细设计时的要点。对其余用例的分析方法与之类似。 过程监督服务器作为引擎容器的一部分，主要提供外部对引擎容器的运行状况的监督，即对引擎当前运行状况的查询。 譬如，当客户端或管理端需要了解引擎的运行状况时，首先发出一个消息请求，消息服务器接受到该消息后对消息进行解释，如果属于查询引擎的运行状况，则调用监督服务部分提供的API（应用程序接口）对引擎进行查询，然后将结果返回至请求者。 监督服务器处理的查询请求根据请求对象的不同主要有如下内容： 引擎容器运行状况的查询；各引擎运行状况的查询；过程定义信息的查询；过程实例信息的查询；活动实例信息的查询；工作项信息的查询；同步命令请求的响应。 b.工作流引擎 图2表示工作流引擎的用例图。其中的活动者包括EngineManager（引擎管理器）与LogFiles（日志文件）。EngineManager 负责控制工作流中所有元素的状态，是工作流调度的核心。LogFiles 阶段性将固定格式的文字记录为日志，用以保存。这里的用例有ProcessControl（控制过程实例）、TransitionControl（控制转移）、ActivityControl（控制活动）、WorkItemControl（控制工作项）、DanamaticModify（动态修改流程）、CreateLogfile（创建日志文件）。EngineManager 根据一定的条件，通过ProcessControl、TransitionControl、ActivityControl、WorkItemControl 与DanamaticModify，控制工作流各个组成元素的状态，以达到控制工作流的目的。 c.过程监督 图3表示过程监督用例图。其中的活动者包括EnactmentDB
文章来源于领测软件测试网 https://www.ltesting.net/
