4.1 参与者之间的关系
参与者之间可以有泛化(Generalization)关系（或称为"继承"关系）。例如在需求分析中常见的权限控制问题（如下图所示），一般的用户只可以使用一些常规的操作，而管理员除了常规操作之外还需要进行一些系统管理工作，操作员既可以进行常规操作又可以进行一些配置操作。
在这个例子中我们会发现管理员和操作员都是一种特殊的用户，他们拥有普通用户所拥有的全部权限，此外他们还有自己独有的权限。这里我们可进一步把普通用户和管理员、操作员之间的关系抽象成泛化(Generalization)关系，管理员和操作员可以继承普通用户的全部特性（包括权限），他们又可以有自己独有的特性（如操作、权限等）。这样可以显著减速少用例图中通讯关联的个数，简化用例模型，使之更易于理解。
4.2 用例之间的关系
用例描述的是系统外部可见的行为，是系统为某一个或几个参与者提供的一段完整的服务。从原则上来讲，用例之间都是并列的，它们之间并不存在着包含从属关系。但是从保证用例模型的可维护性和一致性角度来看，我们可以在用例之间抽象出包含(include)、扩展(extend)和泛化(generalization)这几种关系。这几种关系都是从现有的用例中抽取出公共的那部分信息，然后通后过不同的方法来重用这部公共信息，以减少模型维护的工作量。
4.2.1 包含(include)
包含关系是通过在关联关系上应用<>构造型来表示的，如下图所示。它所表示的语义是指基础用例(Base)会用到被包含用例(Inclusion)，具体地讲，就是将被包含用例的事件流插入到基础用例的事件流中。
包含关系是UML1.3中的表述，在UML1.1中，同等语义的关系被表述为使用(uses)，如下图。
在ATM机中，如果查询、取现、转帐这三个用例都需要打印一个回执给客户，我们就可以把打印回执这一部分内容提取出来，抽象成为一个单独的用例"打印回执"，而原有的查询、取现、转帐三个例都会包含这个用例。每当以后要对打印回执部分的需求进行修改时，就只需要改动一个用例，而不用在每一个用例都作相应修改，这样就提高了用例模型的可维护性。
在基础用例的事件流中，我们只需要引用被包含用例即可。
查询-基本事件流
1. 用户插入信用卡
2. 输入密码
3. 选择查询
4. 查看帐号余额
5. 包含用例"打印回执"
文章来源于领测软件测试网 https://www.ltesting.net/
