一、用例图的简介
用例图，展现了一组用例、参与者（actor）以及它们之间的关系。用例图从用户角度描述系统的静态使用情况，用于建立需求模型。
二、用例图中的因素
（一）参与者（Actor）
在系统外部与系统直接交互的人或事物。需要注意以下两点：
1）参与者是角色而不是具体的人，它代表了参与者在与系统打交道的过程中所扮演的角色。所以在系统的实际运作中，一个实际用户可能对应系统的多个参与者。不同的用户也可以只对应于一个参与者，从而代表同一参与者的不同实例。
2）参与者作为外部用户（而不是内部）与系统发生交互作用，是它的主要特征。
（二）用例（Use Case）
系统外部可见的一个系统功能单元。系统的功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。
（三）子系统(Subsystem)
用来展示系统的一部分功能，这部分功能联系紧密。
三、用例图的关系（Relationship）
常见关系类型有关联、泛化、包含和扩展。
以上各关系在uml图中的表示方式，如下表所示：
a. 关联(Association)
表示参与者与用例之间的通信，任何一方都可发送或接受消息。
【箭头指向】：指向消息接收方
b. 泛化(Inheritance)
就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。
【箭头指向】：指向父用例
c. 包含(Include)
包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。
【箭头指向】：指向分解出来的功能用例
d. 扩展(Extend)
扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。
【箭头指向】：指向基础用例
四、用例图中的关系 的区别：
条件性：泛化中的子用例和include中的被包含的用例会无条件发生，而extend中的延伸用例的发生是有条件的；
直接性：泛化中的子用例和extend中的延伸用例为参与者提供直接服务，而include中被包含的用例为参与者提供间接服务。
对extend而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。
对Inheritance而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系。
五、用例注意点
1.清楚地定义系统的边界（即判断哪些功能属于该系统）
2.防止用例过多（粒度）
3.从执行者的角度命名用例
4.描述正规程度
5.避免执行者的名字不一致
6.避免执行者和用例之间的关系太复杂（若过复杂，则添加新的执行者）
7.用例大小恰当
8.用例描述混乱
六、用例图的主要属性
（一） 事件流
1.用例执行时角色与系统的交互过程；
2.分为基本流（用例中常规和预期路径的描述）和备选流（受影响后执行其它的路径）
（二）前置条件
（执行的前提条件）什么条件下开始执行一个事件流
（三）后置条件
用例结束后系统的状态
七、粒度
在绘制一个系统的用例图时，到底画多少用例，多少用例比较合适那，往往在绘制一个系统的用例图时一层用例是不够的，往往需要画好几层，那么问题就来了，我这个用例到底画到第一层中，还是第二层中那，这时有一个判断标准——粒度，用例越多，粒度越大，一般用例在10——50个为宜。
不同阶段使用的粒度不同：
1.业务建模阶段：一个用例能描述一个完整的事件流
2.用例分析阶段：一个用例能描述计算机与用户人员能完成一次成功的交互过程
3.用例的开发量的时间在一周左右为宜
八、范围
分为：概述级、用户目标级、子功能级
九、图例（以机房收费系统为例）
（一）一般用户
（二）操作员
（三）管理员
