上一篇中介绍了UML中的类图，本篇笔者将与大家介绍UML中的用例图的三个方面内容：用例（UseCase）;参与者（Actor）;参与者、用例之间的关系。
之所以说用例图至关重要，是由于用户并不关心系统的实现和内部结构，只关心产品所呈现出来的外部特征动态。而用例图恰好就是描述软件产品外部特性的视图，它从用户的角度而不是从开发者的角度来描述需求，分析产品的功能和动态行为。
用例图包括三方面内容：用例（UseCase）;参与者（Actor）;参与者、用例之间的关系。用例图模型如下图所示，参与者用人形图标显示，用例用椭圆形表示，连线描述之间的关系。
参与者是系统外部的一个实体，它以某种方式参与了用例的执行过程，在UML中，通常用名字写在下面的人形图标表示。
值得注意的是：参与者不一定是人，也可以是任何的事，通常可以将参与者分为以下三类：
这一类是最常用的参与者，几乎在每个系统中。在命名这一类参与者时，应该按照业务而不是位置命名，因为一个人有可能有多重身份。
比如：汽车租赁公司的客户服务代表，通常情况下是客户服务代表，但在她有租赁行为时，就变成了客户。因此，按照业务而不是位置命名可以获得更加稳定的参与者。
在有的系统中，还需要建立与其他系统的接口，依然以汽车租赁系统为例，它可能要与外部应用程序建立练习，比如：说外部信用卡应用程序，这时候外部信用卡应用系统就是一个参与者。
对于一些参与者来说，它既扮演者自己的角色，同时也扮演更一般的角色，在案例图中用泛化关系来描述他们（此点与上一节类图中介绍的泛化关系类似）。
用例：是对系统的用户需求（主要是功能需求）的描述，用例表达了系统的功能和所提供的服务，描述了活动者与系统交互中的对话。
以汽车租赁系统为例，客户向系统发出租赁请求，并向系统中输入数据（姓名等信息），系统响应活动者的请求，进行相应的处理，并且将结果返回活动者。
每个用例都必须有一个唯一的名字以示区别，用例名字是一个字符串，包括简单名（simple）和路径名（pathname），这和类图中的类名是相同的。
用例分析处于系统的需求分析阶段，这个阶段尽量避免考虑系统实现的细节问题。但若要建立系统还需要更加具体的细节，这些细节可以写在事件流中。
这是最常使用的关系，用带箭头的实线来描述。以汽车租赁系统中的“客户”参与这以及和他交互的3个用例（预定、取车和换车）为例。
一个用例可以被列举为多个子用例，这就被成为用例泛化，这与类间的泛化关系类似。在用例泛化中，子用例表示父用例的特殊形式，可从父用例处继承行为和属性。泛化关系的图形用空心实线箭头表示，箭头指向父类。
如下图所示是汽车租赁公司用例图中的用例“预定汽车”，该用例有两个子用例“预定大巴中巴”和“预订小车”。
包含：指的是其中一个用例（称为基础用例）的行为包含了另一个用例（称为包含用例）。
基础用例包含用例并依赖包含用例的执行结果。但是二者不能访问对方的属性。包含关系的图形为虚线箭头加<
扩展用例可以被定义为：基础用例的增量扩展，它俩之间为扩展关系。
简单来说，就是当某特定条件出现时，该扩展用例的行为才会被执行。扩展关系的图形为虚线箭头加上<<
如下图，客户在还车超过了一定期限就需要缴纳罚款，其中“借车超期”为特定条件，只有该条件出现，才执行“缴纳罚款”用例行为，“还车”用例和“缴纳罚款”之间就是扩展关系。