图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}或依赖关系 <<precedes>> 。类似的关系同样存在于OML（OPEN modeling language），参看[3]，Robert C. Martin建议使用关键字follows替代precedes，参看[6]。这样替代的原因是依赖关系 <<follows>>与依赖关系<<preceds>>的指向相反，依赖关系<<follows>> 指向通常的依赖方向——从依赖元素指向独立元素，至于哪一个更直观仍是个未解决的问题。然而，带约束或依赖的图仍然是静态结构图，并不描述特定场景。
图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声明映射为用例包中的用例。用例包生命周期是用例包行为的准确描述，然而它难以正确表达，尤其在复杂的用例中。用例交互图很容易表达，但它描述的仅仅是由包中用例组成的某一典型场景。
文章来源于领测软件测试网 https://www.ltesting.net/
