用例图使用户 与开发者交流的一种重要的方式，是对用户需求的一种描写叙述。开发者从用户的角度总体上理解系统的功能。
用例图主要有三种元素：參与者（Actor）。用例。以及用例图中对象间到的关系。当中关系有包括、扩展是用例图中特有的，泛化在其它类图中相同存在。
包括:当能够从两个或两个以上的用例中提取公共行为时，应该使用包括的关系来表示它们。当中这个提取出来的公共用例成为抽象用例。而把原始用例成为基本用例或基础用例。当中“<<include>>”是包括关系的构造型，箭头指向抽象用例。
比如，在机房收费系统中“注冊学生信息”和“充值”两个用例都须要操作员或者管理员登陆。为此，能够定义一个抽象用例“用户登陆”。用例“注冊学生信息”和“充值”与用例“用户登陆”之间的关系就是包括关系。
如图
有时当某用例的事件流过于复杂时，为了简化用例的描写叙述，我们也能够抽象出一个基用例，来包括这些颗粒的用例
作用：当多个用例须要使用同一段事件流时。抽象成为公共用例，能够避免在多个用例中反复地描写叙述这段事件流。也能够防止这段时间流在不同用例中的描写叙述出现不一致。
当须要改动这段公共的需求时，也仅仅要改动一个用例，避免同一时候改动多个用例而产生的不一致和反复性工作。
另外，当某个用例的事件流过于复杂时，为了简化用例的描写叙述。也能够将某段事件流抽象成为一个被包括的用例。
2、扩展关系
假设一个用例明显地混合了两种或者两种以上的不同场景，即依据情况可能发生多种分支，则能够将这个用例分为一个基本用例和一个或多个扩展用例。这样可能会使描写叙述更加清晰。扩展用例为基用例加入新的行为。
扩展用例能够訪问基用例的属性，因此他能依据基用例中扩展点的当前状态来决定是否运行自己。而扩展用例对基用例不可见。
如机房收费系统中“维护学生信息”操作时假设发现信息有误或者更新则须要使用“改动学生信息”用例完毕更新，所以用例“查询上机记录”和“导出EXCEL”之间的关系就是扩展关系。“<<extend>>”是扩展关系的构造型，箭头指向基本用例。
如图
包括关系和扩展关系的联系和差别
联系：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例。然后通后过不同的方法来重用这个公共的用例，以降低模型维护的工作量。
差别：扩展关系中基本用例的基本流运行时，扩展用例不一定运行，即扩展用例仅仅有在基本用例满足某种条件的时候才会运行。
包括关系中基本用例的基本流运行时。包括用例一定会运行。
3、泛化
当多个用例共有一种类似的结构和行为时。能够将他们的共性抽象成为父用例，其它的用例作为泛化关系的子用例。在用例的泛化关系中。子用例是父用例的一种特殊形式。它继承了父用例的全部结构、行为、关系。当中三角箭头指向父用例。假如在机房收费系统的注冊能够通过本地注冊和网上注冊。则
用例图如
相同。一般用户，操作员，管理员之间也存在泛化的关系
如图
转：UML中扩展和泛化的差别
泛化表示类似于OO术语“继承”或“多态”。UML中的Use Case泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case。并将不可合并部分单独成各自的子Use Case；包括以及扩展过程与泛化过程类似，但三者对用例关系的优化側重点是不同的。例如以下：
●泛化側重表示子用例间的相互排斥性；
●包括側重表示被包括用例对Actor提供服务的间接性；
●扩展側重表示扩展用例的触发不定性；详述例如以下：
既然用例是系统提供服务的UML表述。那么服务这个过程在全部用例场景中是必定发生的。但发生依照发生条件可分为例如以下两种情况：
⒈无条件发生：肯定发生的；
⒉有条件发生：未必发生，发生与否取决于系统状态；
因此，针对用例的三种关系结合系统状态考虑，泛化与包括用例属于无条件发生的用例，而扩展属于有条件发生的用例。进一步。用例的存在是为Actor提供服务。但用例提供服务的方式可分为间接和直接两种，根据于此，泛化中的子用例提供的是直接服务。而包括中的被包括用例提供的是间接服务。相同，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。
另外一点须要提及的是：泛化中的子用例和扩展中的扩展用例均能够作为基本用例事件的备选择流而存在。
