一、是什么？
用例图是指由参与者、用例以及关系组成的用于对系统、子系统、类进行描述功能的静态视图。用例图是大家了解系统的第一个关口。人们通过一个用例图能够了解一个系统将会做些什么。主要用于需求分析阶段，由开发者和用户共同完成。
二、用例图基本要素
参与者：
参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人也可以是物，还可以是时间或其他系统等等。有一点需要引起注意。参与者不是指人或事物本身，而是表示人或事物本身所扮演的角色。（参与者实际上也是类）
用例：
用例是参与者想要系统做的事，对于用例的命名我们可以对用例取一个简单的，描述性的名称。一般是带有动作性的词语。任何用例都不能在缺少参与者的情况下独立存在，同样，任何参与者也必须要有与之关联的用例。
三、参与者之间的关系
由于参与者实质上也是类，所以它拥有与类相同的关系描述，即参与者与参与者之间主要是泛化关系。泛化关系的含义是把某些参与者的共同行为提取出来表示成通用行为，并描述成超类。泛化关系表示的是参与者之间的一般/特殊关系。 在需求分析阶段，我们经常遇到的一个问题就是用户权限问题，以机房收费系统为例，一般用户有查看学生基本信息的操作。而操作员除了具有一般用户的功能之外，还有注册充值等功能。在这个例子中可以发现，操作员是一种特殊的一般用户。他们拥有一般用户的所有权限，此外他们还有自己独有的权限。这里我们可以进一步把一般用户和操作员之间的关系抽象成泛化关系。下图中的一般用户是父类，操作员是子类。通过泛化关系，可以有效地减少用例图中通信关联的个数，简化用例模型，便于关系。
四、用例间的关系：
为了减少模型维护的工作量，保证用例的可维护性和一致性，可以在用例之间抽象出四种关系。即关联（correlation）、包含（include）、扩展（extend）、泛化（generalization）。
关联：表示参与者与用例之间的交互，通信途径 ，关联有时也用带箭头的实线表示，这样的表示能够鲜明地表示
发起用例的是参与者。
包含：包含是指用例可以简单的包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。包含关系本质上是比较特殊的依赖关系。在UML中，包含关系是通过带箭头的虚线段加<<include>>字样来表示。箭头由基础用例（Base）指向被包含用例（inclusion）。
包含关系代表着基础用例会用到被包含的用例，具体来讲就是将被包含用例的事件流插入到基础用例的事件流中。在处理包含关系时，具体的做法就是把几个用例的公共部分单独抽象出来成为一个新的用例。主要有两种情况需要用到包含关系。第一是一个用例的功能过多，事件流流过于复杂，第二是当多个用例用到同一段行为时，可以把这段行为单独抽象成为一个用例，后让其他用例来包含这一用例。
扩展：在一定条件下把新的行为加入到已有的用例中，获得新用例成为拓展用例，原有的用例成为基础用例，从拓展用例到基础用例就是拓展关系。一个基础用例可以拥有一个或多个拓展用例。这些拓展用例可以一起使用。在UML中，拓展关系是通过带箭头的虚线段加<<extend>>来表示的，箭头指向基础用例。如下图所示。
泛化：泛化指的是一个父用例可以被特化为多个子用例，父用例与子用例之间的关系就是泛化关系，在用例的泛化关系中子用例继承了父用例所有的结构、行为和关系。子用例是用用例的一种特殊形式。子用例还可以添加、覆盖、改变继承的行为。在UML中用例的泛化关系是通过一个带有空心三角箭头的直线从子用例指向父用例来表示。
例如，在图书管理系统中，借阅者查找图书的用例就是可以用泛化关系来表示，我们将精确查找和模糊查找泛化为查找图书。查找图书为父用例，具体的查找方式为子用例。
五、总结：
用例图是软件需求分析到最终实现的第一步，它描述了人们如何使用一个系统。用例视图能够表示谁是相关的用户，用户希望系统提供什么样的服务，以便于用户更容易理解这些元素的存在，一张图胜过千言万语。借助用例图，系统用户、系统分析人员、系统设计人员能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。