图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（工作流运行数据库）与engineContainer（引擎容器）。用例有EngineQuery（对引擎的查询）、ProcessDefQuery（对过程定义信息的查询）、EngineContainerQuery（引擎容器运行状况的查询）、ProcessInstanceQuery（对过程实例进行查询）、ActivityInstanceQuery（对活动实例进行查询）、WorkItemQuery（对工作项进行查询）、TransitionQuery（对转移信息查询）。
这里仅对用例ProcessInstanceQuery 进行具体功能分析，对其余用例的分析方法与之类似。
ProcessInstanceQuery 是对系统中的过程实例进行查询，主要包含如下内容：取得过程实例列表：得到系统中的所有过程实例的一个列表；从过程实例列表中取得一个过程实例的信息；根据给定的过程实例编号得到该过程实例的具体信息；关闭已经打开的过程实例列表；取得系统中过程实例的各种状态的一个列表；根据给定的过程实例编号查询其状态；关闭打开的过程实例列表；取得系统中过程实例的各种属性信息的列表。
5.2 创建交互视图
交互视图描述了实现系统行为角色之间的消息交换序列。分类角色是对交互中充当非凡角色的对象的描述。交互视图提供了系统中行为在全局的描述，显示了多个角色间的控制流程。交互视图用侧重点不同的两种图来显示：顺序图和协作图。
消息指角色间的单向通信，从发送者到接收者的携带信息的控制流。消息可能带有角色间传递值的参数。
顺序图和协作图均显示了交互，但它们强调了不同的方面。顺序图显示了时间顺序，但角色间的关系是隐式的。协作图表现了角色之间的关系，并将消息关联至关系，但时间顺序由于用顺序号表达，并不十分明显。每一种图应根据主要的关注焦点而使用。
a.顺序图
顺序图表示了随时间安排的一系列消息。每个分类角色显示为一条生命线，代表整个交互期间上的角色。消息则显示为生命线之间的箭头。顺序图可以表达场景，即一项事务的特定历史。
顺序图以二维图表来显示交互。纵向是时间轴，时间自上而下。横向显示了代表协作中单个对象的分类角色。每个对象用方框表示，对象的名字在方框内部，并在名字的下方加下划线。每个分类角色表现为垂直列－生命线。在角色存在的时间内，生命线显示为虚线；在角色的过程激活时间内，生命线显示为双线。
消息显示为从一个角色生命线出发至另一个角色生命线的箭头，箭头用从上而下来的时间顺序来安排。
顺序图的一个用途是显示用例的行为序列。当行为被实现时，每个顺序图中的消息同对象的操作或状态机中迁移上的事件触发相一致。
图4 表示处理请求用例的顺序图。图中五个方框分别表示五个对象：ProcessMonitor、EngineManager、Engine、EntactmentDB、Logfiles。这个用例是由ProcessMonitor 接收用户操作，再将这些操作转换成固定的请求，发送给引擎执行而产生的。
当ProcessMonitor 接收到用户在界面上所作的操作后，将这些操作转换为固定的命令请求，发送给EngineManager。EngineManager 再根据接收到命令的类别，将命令分发给不同的Engine。Engine 则具体执行相应的命令。Engine 执行完命令后，通知EntactmentDB 修改相应的数据。接下来，Engine 再通知Logfiles 将所作的操作记录下来，以供以后查询。最后，Engine 直接将结果返回给ProcessMonitor，由ProcessMonitor将结果包装，显示给用户。
b.协作图
协作图对交互中存在意义的对象和链建模。对象和链仅在提供的上下文中存在意义。分类角色描述了对象，关联角色描述了协作中的链。协作图通过图形的几何排布显示交互中的角色。消息显示为附属在连接分类角色的关系直线上的箭头。消息的顺序由消息描述前的顺序号来表示。
协作图的一个用途是表现操作的实现。协作显示了操作的参数和局部变量，以及更永久性的关联。当行为被实现时，消息的顺序与程序的嵌套调用结构和信号传递一致。
图5表示对应于处理请求用例的协作图。这个用例是由ProcessMonitor 接收用户操作，再将这些操作转换成固定的请求，发送给引擎执行而产生的。这个协作图表现了处理请求用例所涉及的五个相关对象之间相互协作的关系。
5.3 创建状态机视图
状态机视图通过对一种对象的可能生命历史进行建模，描述了对象在时间序列上的动态行为。每个对象被认为是通过检测事件并对之响应来与外界进行通讯的孤立实体。事件表达了对象可以检测的变动－对象间的调用或显示信号、某个值的改变或时间的推移。任何影响对象的事物可以被描述成事件。真实世界发生的事情被建模成外部世界至系统的信号。
状态指就某个特定类而言，对于发生的事件具有相同性质响应的一系列对象值。换言之，同一状态的所有对象以相同的方式响应某个事件，即对于给定的所有对象在接收到同一事件时执行相同的动作。而不同状态的对象可能对相同事件具有不同的响应，执行不同的动作。
状态机包含由事件连接的状态。每个状态对对象生命期中的一段时间建模，该时间内对象满足一定的条件。当事件发生时，它可能导致迁移的激发，使对象改变至新状态。当迁移激发时，附属于迁移的动作可能被执行。状态机在UML 中显示为状态图。
在状态机视图中，状态用带圆角的长方形表示，初始状态用实心填充的圆表示，结束状态用实心填充的圆外套一个圆圈表示。
图6 表示过程实例的状态机视图。从图中可以看出，一个工作流定义的过程实例，在运行时可能有五种不同的过程，分别为初始状态、就绪状态、运行状态、挂起状态与结束状态。
一个过程实例在初始时，均为初始状态（initial state）。根据需要，某个过程实例被创建（create），成为就绪状态（Ready）。随后，用户可以
