自己在画用例视图的时候，总要在用例间的关系问题上费很多的时间，虽然用例之间的关系无外乎泛化、包含和扩展三种，但还是经常会在用例间关系属于哪一种的问题上产生迷惑，索性集中分析整理一下，以后再迷惑的时候，找出来看看。
首先从原则上来讲，用例相互之间
都是独立、并列的，它们之间并不存在着从属的关系。然而，之所以要将它们之间定义泛化、包含和扩展等关系，主要是为了体现用例之间的业务联系。这三种关系
的一个共性就是：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通过不同的方法来复用这个公共的用例，以减少模型维护的工作量。
1、这三种关系是如何来区分的
呢？一般来讲，可以用is a 和 has a来判断使用那种关系，泛化和扩展表示的是用例之间的is a 关系，包含关系表示的是用例之间的has
a 关系；而扩展关系和泛化关系相比又多了扩展点的概念，就是说，一个扩展用例之能够在基本用例的扩展点上进行扩展。
2、分别就这三种关系进行分析说明：
（1）泛化关系：
一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化。用例间的泛化关系和类间的泛化关系类似，即在用例泛化中，子用例表示父用例的特殊形式，子用例从父用例处继承行为和属性，还可以添加行为或覆盖，改变已继承行为。
当系统中具有一个或多个用例是较一般用例的特化时，就使用用例泛化。
举例：
理解：基本用例是一般的抽象的，而泛化用例则是特殊的具体的；同时，泛化用例在抽象的概念上和基本用例相同。如上面例子：基本用例Search
Person，泛化用例Search Teacher和Search Student，Search Person
（找人）是一个一般的抽象的概念，而Search Teacher （找老师）和 Search
Student（找学生）相对而言就是特殊的具体的概念了，将（找人）具体化特殊化了。然而就（找老师）和（找学生）这两个泛化用例的抽象的概念上来讲还
是“找人”，也就是说一个人在找老师或者找学生的时候，也可以说他在找人，因为老师和学生都是人。
（2）包含关系：
使用包含用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基本用例复用。基本用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基本用例的事件流中。基本用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。基本用例执行时，一定要执行包含用例。
举例：
理解：如果单独使用一个“注册用户管理”用例来描述业务的话，不能够很好的描述注册用户管理都有哪些内容，计算
机无法将注册用户管理员的业务模拟出来，所以在系统用例阶段，用“注册用户管理”include“增删改查用户信息”来表示这个实现关系，有利于详细分析
模拟“注册用户管理”这一行为的细节，不至于混淆；同时，如果有多个类似于“注册用户管理”这样的用例，可以让“增加用户信息”和“增加XX信息”等等用
例来继承一个抽象出来的“增加数据”用例。
如图：
（3）扩展关系：
将基用例中一段相对独立并且可选的动作，用扩展用例加以封装，再让它从基用例中声明的扩展点上
进行扩展，从而使基用例行为更简练和目标更集中。基本用例不必知道扩展用例的任何细节，仅为其提供扩展点，事实上基本用例没有扩展也是完整的，这一点和包
含关系不同，一个用例可以有多个扩展点，每个扩展点也可以出现多次，通常情况下基本用例不会涉及到扩展用例的行为，只有在特定的条件发生时，扩展用例的行
为才被执行，也就是说基本用例执行时，扩展用例可执行也可以不执行。
举例：
理解：借了图书馆的书，到期了还书，这很正常，“还书”用例就可以描述，但是如果逾期还书呢？在逾期的情况下就要交纳罚金，虽然也是“还书”，可是它多了一个“交纳罚金”当然如果你在期限之内还书，交纳罚金就不会发生。在这里扩展点就是：逾期还书。
