用例图,即用来描述什么角色通过某某系统能做什么事情的图，用例图关注的是系统的外在表现，系统与人的交互，系统与其它系统的交互。
用例图的作用：用于需求分析阶段，描述用户的需求，是开发者和用户共同商讨，最后达成共识。
用例图有三种构成元素,分别是:角色，用例，关系
值得注意的是，角色可能是人，也可能不是人，而是另外的一个系统，本系统与另外一个系统交互的话，可以将另外一个系统画成某某角色。
分析角色时需要考虑的内容：
（1）有哪些直接使用系统的人
（2）涉及到哪些维护人员
（3）使用哪些外设
（4）相连的其他系统
（5）还有哪些人和事物对这个系统产生的结果感兴趣
用例：即系统具有的功能，在用例图中用椭圆圈表示，圈里用文字描述该用例，一般为动宾短语。
值得注意的是，某个用例不一定是只属于一个角色的，有些用例是同时属于多个角色的，即被多个角色“共享”。
关系：即角色与用例之间的关系，在用例图中用线条表示
执行者和用例的关系：关联，依赖，泛化
线条有两种：无箭头的，有箭头的。
有箭头的线条，表示角色与系统交互的过程中，数据的流向，如果箭头指向用例，就说明角色需要往系统输入数据，如果箭头指向角色，说明系统往角色输出数据。没有箭头的线条，则没有明确表示数据的流向。
用例图主要用来描述“用户、需求、系统功能单元”之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。
【用途】：帮助开发团队以一种可视化的方式理解系统的功能需求。
用例图所包含的元素如下：
1. 参与者(Actor)
表示与您的应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。
2. 用例(Use Case)
用例就是外部可见的系统功能，对系统提供的服务进行描述。用椭圆表示。
3. 子系统(Subsystem)
用来展示系统的一部分功能，这部分功能联系紧密。
4. 关系
用例图中涉及的关系有：关联、泛化、包含、扩展。
如下表所示：
a. 关联(Association)
表示参与者与用例之间的通信，任何一方都可发送或接受消息。
【箭头指向】：指向消息接收方
b. 泛化(Inheritance)
就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。
【箭头指向】：指向父用例
c. 包含(Include)
包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。
【箭头指向】：指向分解出来的功能用例
d. 扩展(Extend)
扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。
【箭头指向】：指向基础用例
e. 依赖(Dependency)
以上4种关系，是UML定义的标准关系。但VS2010的用例模型图中，添加了依赖关系，用带箭头的虚线表示，表示源用例依赖于目标用例。
【箭头指向】：指向被依赖项
5. 项目(Artifact)
用例图虽然是用来帮助人们形象地理解功能需求，但却没多少人能够通看懂它。很多时候跟用户交流甚至用Excel都比用例图强，VS2010中引入了“项目”这样一个元素，以便让开发人员能够在用例图中链接一个普通文档。
用依赖关系把某个用例依赖到项目上：
然后把项目-》属性 的Hyperlink设置到你的文档上；
这样当你在用例图上双击项目时，就会打开相关联的文档。
6. 注释(Comment)
包含(include)、扩展(extend)、泛化(Inheritance) 的区别：
条件性：泛化中的子用例和include中的被包含的用例会无条件发生，而extend中的延伸用例的发生是有条件的；
直接性：泛化中的子用例和extend中的延伸用例为参与者提供直接服务，而include中被包含的用例为参与者提供间接服务。
对extend而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。
对Inheritance而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系；
注意问题：
应该清晰的定义系统边界
防止用例过多
应该从执行者的角度来命名用例
用例描述正规程度
避免执行者的名字不一致
避免执行者和用例之间关系太复杂
注意用例的大小是否恰当
避免用例描述混乱
区分用例分解和功能分解
避免客户不能理解用例的情况发生
有些场合，用用例来描述需求是不合适的