用例图（UseCaseDiagram）:主要用于描述系统的行为及各种功能之间的关系，是描述参与者（Actor）与用例以及用例与用例之间关系的图。
用例图=参与者+用例+关系
用例图最常用来描述系统以及子系统。
通俗的来说：用例图与具体实现并不关联，从用户和外部系统的角度，分析和考察系统的行为，并通过参与者者与系统之间的交互关系描述系统对外提供的功能特性。
参与者可以是人或其他外界系统。
参与者时用力的启动者，参与者处于用例的外部并且能够初始化一个用例并参与用例的执行过程，但它并不是系统的一部分。
每个参与者可以参与一个或多个用例。
表示方式：
UML2.O表示参与者的方法：
发现参与者，可以根据以下问题来寻找系统的参与者：
谁或什么在使用系统；
交互中，他们扮演什么角色；
谁安装系统；
谁启动和关闭系统；
谁维护系统；
与该系统交互的是什么系统；
谁从系统获取信息，谁提供信息给系统；
参与者对于系统而言是外部的，它们在系统控制之外。
参与者直接同系统交互，可以帮助定义系统边界。
参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或事物。
一个人和事物与系统发生交互时，可以扮演多个角色。例：某个研究生担任某教授的助教，从职业的角度看，他扮演了两个角色----学生和助教。
每个参与者需要有一个具有业务语义的名字。
每个参与者必须有简短的描述，从业务角度描述参与者是什么。
参与者可以具有分栏，表示参与者属性和它可接受的事件。
参与者可以使用用泛化关系来描述多个参与者之间的公共行为。
用例是一组动作序列（业务工作流程）的描述，系统执行该动作序列为系统的参与者产生一个可观察的结果。
用例反映用户的需求。
用例是一个叙述型的文档，用来描述一个参与者使用系统完成某个事件时的事情发生顺序。（描述参与者与系统的交互）
用例是系统的使用过程，是对系统的用户功能需求的描述，用例表达了系统的功能和所提供的服务。
识别用例的方法：从分析系统的参与者开始，考虑每个参与者是怎样使用系统的。
以下几个问题可以帮助识别用例：<1>特定参与者希望系统提供什么功能；<2>系统是否存储和检索信息，若是，这个行为由哪个参与者触发；<3>当系统改变状态时，通知参与者吗；<4>存在影响系统的外部事件吗；<5>是哪个参与者通知系统这些事。
是参与者与用例之间最简单常用的关系
把几个用例的公共步骤分离成一个单独被包含用例；包含用例称为客户用例，被包含用例称为提供者用例。
用例A包含用例B，将A称为基用例，B称为被包含用例。
包含关系表示基用例会用到被包含用例。被包含用例的事件流在基用例的某个点处插入到基用例的事件流中。
包含关系表示：
基用例被连接在虚线箭头的尾部，箭头指向被包含用例，并在虚线处添加一个《include》标签以表示扩展关系。
使用场景：
如果两个用例有大量一致功能，则可以将这个功能分解到另一个功能。其他用例可以和这个用例建立包含关系；
一个用例的功能太多时，可以用包含关系建模两个小用例。
扩展使得每个用例可以通过扩展用例向基用例中添加额外的行为来扩展基用例的功能。
用例A扩展了用例B，那么A称为扩展用例或子用例，B表示为基用例。
扩展用例A的事件流在一定的条件下按照相应的扩展点插入到及用例中，这就需要在及用例中定义一至多个已命名的扩展点。（这和继承关系不一样）
选用扩展关系可以把一些可选的操作独立封装在另外的用例中，避免基用例过于复杂。
扩展用例被连接在虚线箭头的尾部，箭头指向基用例，并在虚线处添加一个《extend》表示扩展关系。
泛化关系是两个用例或两个参与者之间的关系。
泛化关系其实可以通俗理解为面向对象关系中的继承。将拥有一种类似的结构和行为的多个用例中的共性抽象为父用例，子用例继承父用例中的所有。
用实线加上空心的箭头表示，其中子用例被连接在箭头的尾部，箭头指向父用例。
相同点：
都是两个用例之间的关系。（只有泛化关系不仅可以表示两个用例，还可以是两个参与者之间）
不同点：
（1）条件性：
包含关系是无条件的
扩展关系是有条件的
（2）插入原则：
包含关系中被包含用例的事件流一定插入到及用例中去。
扩展关系可以根据一定条件来决定是否将扩展用例的事件流插入到基用例事件流。
（3）插入点：
包含关系中插入点只有一个。
扩展关系的插入点可以有多个。
需求：一个系统中的每个功能都有它的所属范围。并且在决定参与者、设计一个系统、子系统或某个部件的时候，划分系统边界对于决定系统的规模和分配责任是十分重要的。
系统边界（SystemBoundary）的表示：
UML中使用矩形框来表达系统的边界，在矩形框的左上方防止系统的名字。