对象级（object level）用业务对象、业务对象的职责、关系和交互来描述子系统的设计。业务对象模型（business object model）指定业务对象之间的静态关系。业务对象交互模型（business object interaction model）用业务对象之间的交互指定子系统操作的设计。工件业务对象（business object）指定业务对象的职责和业务对象接口的静态属性，如用前置条件和后置条件描述的接口操作。业务对象生命周期（business object lifecycle）指定了所允许的接口操作顺序。
图12中，设计工件描述了组织团队结构。事实上，它与描述软件子系统结构的工件没有什么太大的区别。团队的角色可以表示成UML构造型的类，工件角色（role）指定工人角色的职责及其它相关的静态属性。工件角色生命周期（role lifecycle）指定了角色的动态属性、它们的状态以及它们所响应的事件。工件角色模型（role model）指定角色之间的静态关系。成员级业务流程（member level business process）指定团队成员角色与其它团队成员角色之间的协作，见图12中的依赖关系<<协作>>。这些业务流程的实例是在工件角色交互模型（role interaction model）用角色实例之间的交互指定的，见图12中的依赖关系<<实例>>。
图12 在团队和业务流程视图中，设计工件描述了软件系统
称为团队（team）的设计工件是一个角色包，指明了团队的职责以及相关的静态属性。团队的动态属性是在工件团队生命周期（team life cycle）中指定的。工件团队模型（team model）指定了团队之间的静态关系。团队级业务流程（team level business process）指定了团队和其它团队之间的协作，见图12中的依赖关系<<协作>>。团队级业务流程的实例是在团队交互模型（team interaction level）中指定的，见图12中的依赖关系<<实例>>。团队级业务流程的实现用团队成员之间的交互以及团队成员与软件系统之间的交互来指定，如图12中的依赖关系<<实现>>。设计工件的模式可以用相似的方法应用在更高的抽象级4上。
这一节描述的设计工件的结构可以通过两种方式简化：
· 只使用设计工件的子集；
· 把紧密相关的一些设计工件结合起来，构成更大的设计工件单元。
使用设计工件的子集不会导致信息的丢失，因为UML图系统不是正交的。意思是同样的信息可以用两个或更多不同的UML图来描述。例如，两个静态结构图和对象协作图描述对象之间的关系。两个状态图和交互图描述对象之间的消息。因为同样的信息可以从几个方位来描述，开发者所提供的仅仅是设计工件的特定子集，否则此工件必须接受关于一致性的检查。
由于实际的原因，设计者可以创建一个更大的可交互工件来包含几个紧密相关的工件。例如，分类器职责和生命周期总是与某一文档相关和结合。也可以把组织、系统、子系统和类用例图结合成一个大用例图，以清晰地区别用例级。同样的，系统、子系统和业务对象静态结构和相对应的所有级别里的交互图可以结合成一个文档，也可用UML语义把静态结构图、组件、节点和每一级的用例图结合起来表示。用这种方法，设计者可以在一个大的静态结构图中表达用例、角色、子系统、业务对象、团队成员和业务流程之间的关系，然而“UML表示法指南”没有清楚地提到这样结合的静态结构图。
小 结
本文讨论了用UML表示面向对象工作流管理系统，给出了如何把典型工作流概念映射到UML概念的方法，并建议结构化设计工件，从而跟踪业务流程的定义和面向对象软件设计之间的信息。此结构展示了业务流程可表示为业务对象、团队角色和业务系统中其它实例的协作，此结构基于四种相关的设计工件的模式，这四种设计工件为分类器关系、交互、职责和生命周期。此模式可以应用于一个业务系统的不同抽象级和不同的视图，也可应用于业务和软件系统设计的其它方面。
