1) 用例图包含6个元素，分别是：参与者(Actor)、用例(UseCase)、关联关系(Association) 、
包含关系(Include)、扩展关系(Extend) 以及泛化关系(Generalization)。
2) 参与者有三大类:系统用户、与所建造的系统交互的其他系统和一些可以运行的进程。
第一类参与者是真实的人，即用户，是最常用的参与者，几乎存在于每一个系统中。命
名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。例如汽车租
赁公司的客户服务代表，通常情况下是客户服务代表，但是如果他(她)自己要租车的时候，
就变成了客户，所以，按照业务而不是位置命名可以获得更稳定的参与者。
第二类参与者是其他的系统.例如汽车租赁系统可能需要与外部应用程序建立联系，验
证信用卡以便付款。 其中，外部信用卡应用程序是一个参与者，是另一个系统。因此在当前
项目的范围之外，需要建立与其他系统的接口。这类位于程序边界之外的系统也是参与者。
第三类参与者是一些可以运行的进程，如时间。当经过一定时间出发系统中的某个事件
时，时间就成了参与者。例如，在汽军租赁系统中，到了还车的时间客户还没有归还汽车，
系统会提醒客户服务代表致电客户。 由于时间不在人的控制之内，因此它也是一个参与者。
注意：参与者之间，还存在着一般化与特殊化的关系。一般用泛化关系来表示。具体表示法
同类的泛化关系相同。
3) 用例是外部可见的系统功能单元，这些功能由系统单元所提供，并通过-系列系统单元
与一个或多个参与者之间交换的消息所表达。用例的用途是，在不揭示系统内部构造的前提
下定义连贯的行为。
在系统层，用例表示整个系统对外部用户可见的行为。-个用例就像外部用户可以使用
的系统操作。但是，它又与操作不同，用例可以在执行过程中持续接受参与者的输入信息。
4) 识别用例
识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统
的。使用这种策略的过程中可能会发现新的参与者，这对完善整个系统的建模有很大的帮助。
用例建模的过程就是一个法代和逐步精华的过程，系统分析者首先从用例的名称开始，然后
添加用例的细节信息。这些信息由简短的描述组成，它们被精华成完整的规格说明。
在识别用例的过程中，通过回答以下的儿个问题，系统分析者可以获得帮助。
(1)特定参与者希望系统提供什么功能。
(2)系统是否存储和检索信息，如果是，由哪个参与者触发。
(3)当系统改变状态时，是否通知参与者。
(4) 是否存在影响系统的外部事件。
(5) 哪个参与者通知系统这些事件。
5) 用例间的关系
用例除了与其参与者发生关联外，还可以具有系统中的多个关系，这些关系包括关联关系、
包含关系、扩展关系和泛化关系。应用这些关系的目的是为了从系统中抽取出公共行为和
其变体。
1 关联关系(Association )
关联关系表示参与者用例之间的通信。
2 包含关系(Include )
虽然每个用例的实例都是独立的，但是一个用例可以用其他的更简单的用例来描述。这
有点像通过继承父类并增加附加描述来定义一个类。 个用例可以简单地包含其他用例具有
的行为，并把它所包含的用例行为作为自身行为的一部分，这被称作包含关系。在这种情况
下，新用例不是初始用例的一个特殊例子，并且不能被初始用例所代替。在m伍中，包含
关系表示为虚线箭头加<<include> >字样，箭头指向被包含的用例。
包含关系使-个用例的功能可以在另一个用例中使用，如下所述。
(1)如果两个以上用例有大量一致的功能，则可以将这个功能分解到另 个用例中o 其
他用例可以和这个用例建立包含关系。
(2) 一个用例的功能太多时，可以用包含关系建模两个小用例。
3 扩展关系(Extend )
一个用例也可以被定义为基础用例的增量扩展，这称作扩展关系，扩展关系是把新的行
为插入到已有用例中的方法。同一个基础用例的几个扩展用例可以在一起应用。扩
展关系表示为虚线箭头加<<extend>>字样，箭头指向被扩展的用例(即基础用例。
基础用例提供了一组扩展点，在这些新的扩展点中可以添加新的行为，而扩展用例提供
了一组插入片段，这些片段能够被插入到基础用例的扩展点上。基础用例不必知道扩展用例
的任何细节，它仅为其提供扩展点。事实上，基础用例即使没有扩展用例也是完整的，这点
与包含关系有所不同。扩展关系为处理异常或构建灵活的系统框架提供了一种十分有效的方法。
4. 泛化关系(Generaliza苗。n)
一个用例可以被特别列举为一个或多个子用例，这被称作用例泛化。当父用例能够被使
用时，任何子用例也可以被使用。在UML中，用例泛化与其他泛化关系的表示法相同，用
一个三角箭头从子用例指向父用例。