统一建模语言（UML）为描述面向对象系统定义了一系列的标准符号。使用UML增强了领域专家、工作流专家、软件设计者和其他不同背景的专家之间的交流联系。UML可以在普遍的场合使用，对工作流系统的用户而言很直观。除了这些，UML符号具有准确的语义，也就是说可视化的工作流描述可以作为软件规约。本文侧重讨论了如何使用UML来描述工作流治理系统，如何跟踪从业务流程到面向对象软件设计的描述信息，如何用UML可交互工件来结构化项目知识库。
在本文中，我们先来讨论工作流产品的软件设计者和用户对一种通用语言的需要，然后再来介绍如何使用统一建模语言（UML）描述一般的工作流概念，最后希望和搭建一起探讨如何把面向对象软件规约与工作流系统的描述联系起来。
下面我们先来描述一个企业在实现新工作流治理系统时的通常情形：
顾问与用户一起描述一个软件解决方案所支持的企业业务流程。开发队伍获得顾问的描述，但是他们很难理解业务术语，发现其中描述了太多的信息以至于难以用来实现此系统。开发者从技术观点来撰写系统规约，当把这个系统规约呈现在用户面前时，由于过于专业，以至于用户难以理解。然而为了进行下一步的工作，双方被迫接受了这个系统规约。
这种方式很轻易导致系统无法达到用户的需求。用户、顾问和开发者通常都不是用同样的语言，这样的交流问题导致难以保证业务流程所有部分很好沟通，并转换为技术性的软件规约。另外，因为使用此系统的实际用户很难全部理解技术性的系统规约，使软件系统变得难以使用。
其挑战性在于能用一种既准确又友好的方法来为业务流程和业务系统建模。用来描述业务流程的每一个符号对用户来说很直观，并有确定的语义，因此开发者可以用它作为一般的描述，甚至用来精确的描述软件系统规约。
UML有着丰富和复杂的符号来描述软件系统。这些符号也许太丰富以至于不直观、不友好。然而，恰当地用UML来描述工作流治理系统有两大好处。首先，UML是软件界公认的符号标准；第二，UML也可用在不需要实现细节的一般场合。在显示的UML图与那些领域专家已经在使用的图在直观上很相近，另外，它们的语义有精确的定义。如有必要，可出于软件设计的目的给同样的图增加具体的实现细节。
业务系统的描述由流程和静态结构的描述组成。流程最直观的模型就是一个活动或任务的序列，按照顺序完成以到达某个目标。因此，UML的序列图和活动图很适用于友好、准确、具体地描述业务流程，如组织图之类的静态结构，没有实现细节，可以用UML的静态结构图描述。图形化的实现细节往往会误导那些不精通UML的人。例如，导航箭头经常错误地表示方向，最好是仅用UML表示选项的某一特定子集。例如，把元素互相嵌套来表示组装比用实心菱形表示关联要好。用文字来描述各种属性，而不用UML符号，例如《refine》就比带三角形的虚线好理解得多。
工作流概念映射到UML概念
这里介绍了用UML来描述工作流概念的例子。这仅仅提供了一个一般的指导，如何把工作流概念映像成UML，具体的细节很轻易从UML的语义和符号指南[7]得到。工作流治理系统的每个结构都能用合适构造型的UML符号来描述。
图1 用UML表示业务对象、业务流程、团队角色
图1显示了用UML描述业务流程、业务对象、团队角色。业务对象在UML中用类和对象表示。类描述没有特性（identity）的业务对象，如发票(invoice)；对象描述有特性的业务对象，比如编号为VM4/55的发票(VM 4/55: invoice)。业务流程1用用例和用例实例来描述，用例根据目标、职责、前置条件和后置条件来描述；用例对象是具体的事件序列。工作流是自动化的业务流程，用带有构造型 的用例或用例实例描述。在UML中用类和对象描述团队角色（team roles），用类来描述团队角色的类型，对象描述担任该角色的具体工人（worker）。所有的符号可以用相应的构造型来修饰，如 、和 。每一个构造型都可以用文字或一个特定的图标表示。
假设业务流程是在业务系统中的业务对象、角色和其他的实例之间协作完成的。请参看具体介绍“跟踪业务流程到软件设计”。
图2 UML的静态结构图描述团队结构
图2显示了一个团队结构的例子。团队的角色用对象实例表示，为每个角色指定了雇员数量。一个客户满足团队（Customer Satisfaction Team）有三个开发员、两个测试员、一个产品经理和一个人担任用户角色。角色组叫做客户满足团队（Customer Satisfaction Team），用包符号表示。角色组也可能被表示成对象——作为角色的组装（composition）。假如团队表示为对象，团队和角色之间的关系为组装关系，那么根据UML元模型概念，一个特定的角色实例不能同时属于多于一个团队。假如团队表示为包，特定的角色实例可以同时属于几个团队。
图3 UML序列图描述业务流程的实例
图3描述了业务流程的实例。角色客户(customer) 下了一份定单，然后销售(sales)部门中的某个工人确认此定单。假如定单有效，此工人调用另一业务流程“公司运输物品（company ships an item）”的实例。这个类型的图在UML表示法指南中没有明确的提到，然而，它符合UML的元模型。在对象生命线顶部的符号代表分类器角色，如图3中的角色、对象角色和用例角色。
图4 UML用例图描述业务流程之间的静态关系
图4是UML用例图，描述了业务流程之间的静态关系。业务流程描述组织(organization)与角色客户（customer）的协作。注重在UML的1.1版本中，用例不能相互联系而总是由角色发送信号触发。这给建模环境带来困难，一个用例在运行期间，当非凡条件出现时，另一个用例也开始启动。在这种情况下，角色通过与另一个用例的联系初始化此用例而不需发出任何特定的开始信号。例如，假如客户的请求被评估为有效，用例公司运输物品（company ships an item）被组织中的对象触发。这个用例实例不直接由客户触发，希望下一版本的UML将减少用例间有关联系的限制。
UML用例图不轻易表达出用例实例的顺序，例如，首先客户请求一项物品，然后公司将传送此物品，最后客户付款。一个解决的方法就是在用例间使用约束{PRecedes}或依靠关系 。类似的关系同样存在于OML（OPEN modeling language），参看[3]，Robert C. Martin建议使用要害字follows替代precedes，参看[6]。这样替代的原因是依靠关系 与依靠关系的指向相反，依靠关系 指向通常的依靠方向——从依靠元素指向独立元素，至于哪一个更直观仍是个未解决的问题。然而，带约束或依靠的图仍然是静态结构图，并不描述特定场景。
图5 UML序列图描述业务流程和执行者（Actor）之间的交互
角色可以通过非凡顺序启动用例的方法来使用系统。像这样的场景——用例实例序列——可以用顺序图或协作图描述，参看图5和图6。对照对象交互图，场景被描述为消息序列，用例交互图把场景描述为用例序列。这个图仅仅是由其他场景的实例组成的一个场景的UML图。在图5中消息调用（invoke）表示用例构造器和映射为从角色到用例的信号。根据每个用例的最开始操作，如调用请求（invoke request）, 调用运输（invoke shipment）和调用付款（invoke payment），可以命名这些消息，除了这些消息之外，用例交互图能表示角色与系统间其他消息的交互，并描述了用例与角色的全部交谈。
图6 UML交互图描述业务流程和角色之间的交互和关系
用例协作图也描述业务流程实例组成的一个场景。不象用例序列图，用例协作图描述用例实例和角色实例之间的用例关系和消息交互。用例协作图如图6所示。
图7 UML活动图描述业务流程的答应的顺序
用例交互图描述的仅仅是由用例实例组成的一种典型场景。因此它不能表达用例实例所有答应的顺序，属于用例包的用例实例所答应的顺序可以在用例包生命周期内具体说明。用例包的生命周期可用静态图、Backus-Naur范式（BNF）(请参看[4]如何使用BNF指定生命周期。)的活动图表示，在这些状态中，活动状态或BNF声明映射为用例包中的用例。用例包生命周期是用例包行为的准确描述，然而它难以正确表达，尤其在复杂的用例中。用例交互图很轻易表达，但它描述的仅仅是由包中用例组成的某一典型场景。
图7是UML活动图，描述了用例包订单治理（order management）的生命周期。在活动图中的活动与图4、5、6中的用例相对应。
注重UML元模型没有定义任何从状态或行为状态到用例实例的映射，这种映射可以在开发过程进行，与Martin和Odell方法相似，其中子系统的每个状态都指明子系统中的一个候选类。参考[5]。然后，其他开发过程可能以其它方式定义用例包生命周期。例如，用例包生命周期的目的在用例包的范围内可被指定为子系统接口操作答应的顺序。统一建模语言（UML）为描述面向对象系统定义了一系列的标准符号。使用UML增强了领域专家、工作流专家、软件设计者和其他不同背景的专家之间的交流联系。UML可以在普遍的场合使用，对工作流系统的用户而言很直观。除了这些，UML符号具有准确的语义，也就是说可视化的工作流描述可以作为软件规约。本文侧重讨论了如何使用UML来描述工作流治理系统，如何跟踪从业务流程到面向对象软件设计的描述信息，如何用UML可交互工件来结构化项目知识库。
在本文中，我们先来讨论工作流产品的软件设计者和用户对一种通用语言的需要，然后再来介绍如何使用统一建模语言（UML）描述一般的工作流概念，最后希望和搭建一起探讨如何把面向对象软件规约与工作流系统的描述联系起来。
下面我们先来描述一个企业在实现新工作流治理系统时的通常情形：
顾问与用户一起描述一个软件解决方案所支持的企业业务流程。开发队伍获得顾问的描述，但是他们很难理解业务术语，发现其中描述了太多的信息以至于难以用来实现此系统。开发者从技术观点来撰写系统规约，当把这个系统规约呈现在用户面前时，由于过于专业，以至于用户难以理解。然而为了进行下一步的工作，双方被迫接受了这个系统规约。
这种方式很轻易导致系统无法达到用户的需求。用户、顾问和开发者通常都不是用同样的语言，这样的交流问题导致难以保证业务流程所有部分很好沟通，并转换为技术性的软件规约。另外，因为使用此系统的实际用户很难全部理解技术性的系统规约，使软件系统变得难以使用。
其挑战性在于能用一种既准确又友好的方法来为业务流程和业务系统建模。用来描述业务流程的每一个符号对用户来说很直观，并有确定的语义，因此开发者可以用它作为一般的描述，甚至用来精确的描述软件系统规约。
UML有着丰富和复杂的符号来描述软件系统。这些符号也许太丰富以至于不直观、不友好。然而，恰当地用UML来描述工作流治理系统有两大好处。首先，UML是软件界公认的符号标准；第二，UML也可用在不需要实现细节的一般场合。在显示的UML图与那些领域专家已经在使用的图在直观上很相近，另外，它们的语义有精确的定义。如有必要，可出于软件设计的目的给同样的图增加具体的实现细节。
业务系统的描述由流程和静态结构的描述组成。流程最直观的模型就是一个活动或任务的序列，按照顺序完成以到达某个目标。因此，UML的序列图和活动图很适用于友好、准确、具体地描述业务流程，如组织图之类的静态结构，没有实现细节，可以用UML的静态结构图描述。图形化的实现细节往往会误导那些不精通UML的人。例如，导航箭头经常错误地表示方向，最好是仅用UML表示选项的某一特定子集。例如，把元素互相嵌套来表示组装比用实心菱形表示关联要好。用文字来描述各种属性，而不用UML符号，例如《refine》就比带三角形的虚线好理解得多。
工作流概念映射到UML概念
这里介绍了用UML来描述工作流概念的例子。这仅仅提供了一个一般的指导，如何把工作流概念映像成UML，具体的细节很轻易从UML的语义和符号指南[7]得到。工作流治理系统的每个结构都能用合适构造型的UML符号来描述。
图1 用UML表示业务对象、业务流程、团队角色
图1显示了用UML描述业务流程、业务对象、团队角色。业务对象在UML中用类和对象表示。类描述没有特性（identity）的业务对象，如发票(invoice)；对象描述有特性的业务对象，比如编号为VM4/55的发票(VM 4/55: invoice)。业务流程1用用例和用例实例来描述，用例根据目标、职责、前置条件和后置条件来描述；用例对象是具体的事件序列。工作流是自动化的业务流程，用带有构造型 的用例或用例实例描述。在UML中用类和对象描述团队角色（team roles），用类来描述团队角色的类型，对象描述担任该角色的具体工人（worker）。所有的符号可以用相应的构造型来修饰，如 、和 。每一个构造型都可以用文字或一个特定的图标表示。
假设业务流程是在业务系统中的业务对象、角色和其他的实例之间协作完成的。请参看具体介绍“跟踪业务流程到软件设计”。
图2 UML的静态结构图描述团队结构
图2显示了一个团队结构的例子。团队的角色用对象实例表示，为每个角色指定了雇员数量。一个客户满足团队（Customer Satisfaction Team）有三个开发员、两个测试员、一个产品经理和一个人担任用户角色。角色组叫做客户满足团队（Customer Satisfaction Team），用包符号表示。角色组也可能被表示成对象——作为角色的组装（composition）。假如团队表示为对象，团队和角色之间的关系为组装关系，那么根据UML元模型概念，一个特定的角色实例不能同时属于多于一个团队。假如团队表示为包，特定的角色实例可以同时属于几个团队。
图3 UML序列图描述业务流程的实例
图3描述了业务流程的实例。角色客户(customer) 下了一份定单，然后销售(sales)部门中的某个工人确认此定单。假如定单有效，此工人调用另一业务流程“公司运输物品（company ships an item）”的实例。这个类型的图在UML表示法指南中没有明确的提到，然而，它符合UML的元模型。在对象生命线顶部的符号代表分类器角色，如图3中的角色、对象角色和用例角色。
图4 UML用例图描述业务流程之间的静态关系
图4是UML用例图，描述了业务流程之间的静态关系。业务流程描述组织(organization)与角色客户（customer）的协作。注重在UML的1.1版本中，用例不能相互联系而总是由角色发送信号触发。这给建模环境带来困难，一个用例在运行期间，当非凡条件出现时，另一个用例也开始启动。在这种情况下，角色通过与另一个用例的联系初始化此用例而不需发出任何特定的开始信号。例如，假如客户的请求被评估为有效，用例公司运输物品（company ships an item）被组织中的对象触发。这个用例实例不直接由客户触发，希望下一版本的UML将减少用例间有关联系的限制。
UML用例图不轻易表达出用例实例的顺序，例如，首先客户请求一项物品，然后公司将传送此物品，最后客户付款。一个解决的方法就是在用例间使用约束{precedes}或依靠关系 。类似的关系同样存在于OML（OPEN modeling language），参看[3]，Robert C. Martin建议使用要害字follows替代precedes，参看[6]。这样替代的原因是依靠关系 与依靠关系的指向相反，依靠关系 指向通常的依靠方向——从依靠元素指向独立元素，至于哪一个更直观仍是个未解决的问题。然而，带约束或依靠的图仍然是静态结构图，并不描述特定场景。
图5 UML序列图描述业务流程和执行者（Actor）之间的交互
角色可以通过非凡顺序启动用例的方法来使用系统。像这样的场景——用例实例序列——可以用顺序图或协作图描述，参看图5和图6。对照对象交互图，场景被描述为消息序列，用例交互图把场景描述为用例序列。这个图仅仅是由其他场景的实例组成的一个场景的UML图。在图5中消息调用（invoke）表示用例构造器和映射为从角色到用例的信号。根据每个用例的最开始操作，如调用请求（invoke request）, 调用运输（invoke shipment）和调用付款（invoke payment），可以命名这些消息，除了这些消息之外，用例交互图能表示角色与系统间其他消息的交互，并描述了用例与角色的全部交谈。
图6 UML交互图描述业务流程和角色之间的交互和关系
用例协作图也描述业务流程实例组成的一个场景。不象用例序列图，用例协作图描述用例实例和角色实例之间的用例关系和消息交互。用例协作图如图6所示。
图7 UML活动图描述业务流程的答应的顺序
用例交互图描述的仅仅是由用例实例组成的一种典型场景。因此它不能表达用例实例所有答应的顺序，属于用例包的用例实例所答应的顺序可以在用例包生命周期内具体说明。用例包的生命周期可用静态图、Backus-Naur范式（BNF）(请参看[4]如何使用BNF指定生命周期。)的活动图表示，在这些状态中，活动状态或BNF声明映射为用例包中的用例。用例包生命周期是用例包行为的准确描述，然而它难以正确表达，尤其在复杂的用例中。
用例交互图很轻易表达，但它描述的仅仅是由包中用例组成的某一典型场景。
图7是UML活动图，描述了用例包订单治理（order management）的生命周期。在活动图中的活动与图4、5、6中的用例相对应。
注重UML元模型没有定义任何从状态或行为状态到用例实例的映射，这种映射可以在开发过程进行，与Martin和Odell方法相似，其中子系统的每个状态都指明子系统中的一个候选类。参考[5]。然后，其他开发过程可能以其它方式定义用例包生命周期。例如，用例包生命周期的目的在用例包的范围内可被指定为子系统接口操作答应的顺序。
