1. 用例图定义
通俗的说，当要弄清一个项目的大概需求时，往往可以从以下两个问题来思考：
- 谁在使用这个系统？（系统用户都有哪些？）
- 通过这个系统这些人能做什么？（用户使用这个系统具体做什么？）
用例图便是用来回答以上两个问题的。
理解了上面说的，用例图的定义就很清楚了：
用例图主要用于以一种可视化的方式描述客户的对系统的功能需求
2. 用例图的组成
在分析系统时，应该先思考什么角色会用这个系统，然后逐一思考不同的角色对系统有什么需求。
用例图有四个部分：1. 参与者(Actor)，2. 用例(Use case)，3. 系统边界，4. 关系
1) 参与者(Actor)
参与者是与用户交互的人或物。首先包括我们的开发系统用户，除此之外，与我们开发的系统有关联的其他系统也算是参与者。
在UML图中，我们用一个小人表示参与者。
2) 用例(Use Case)
用例表明系统能做什么事情，是外部可见的(参与者可以感受到的)系统服务或功能单元。
用椭圆表示用例。
用例中的文字描述一般是动宾结构(动词+名词)
3) 系统边界(System Boundary)
指系统与系统之间的界限，只框住了用例，没有框住执行者的方框叫系统边界，框的上部注明本系的名字。把系统边界以外的同系统相关联的其他部分称为系统环境。
需要注意的是：一般使用一个全局的用例图来宏观表达系统的需求，这个宏观的用例图需要画出系统边界。
4) 关系
用例图中的关系有4种：关联，泛化，包含和扩展。
如下表所示：
a. 关联(Association)
表示参与者与用例之间的通信，任何一方都可发送或接受消息。
【箭头指向】：指向消息接收方。uml中用直线表示。
b. 泛化(Inheritance)
就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；
子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。
【箭头指向】：指向父用例
c. 包含(Include)
包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。类似于在过程设计语言中，将程序的某一段算法封装成一个子过程（函数、方法），然后再从主程序中调用这一子过程。
如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一个用例中，其他用例可以和这个用例建立包含关系。
【箭头指向】：指向分解出来（即被包含）的功能用例
-
例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那添加、修改以及删除都要在用例详述中描述，过于复杂；如果分成添加用例、修改用例和删除用例，则划分太细。这时包含关系可以用来理清关系。
-
注意：如果使用了包含关系，包含用例所代表的功能都是基用例功能中必须要实现的功能（比如下图中维护信息这一用例不能缺失删除信息这一功能），是基础用例功能的组成部分。
d. 扩展(Extend)
扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能，是基用例功能的补充，不是基础用例功能的一部分。只有在特定的条件发生，扩展用例才被执行。
【箭头指向】：指向基础用例
- 例如：下图中，满减活动和买一送一活动都不是买电器这一用例所必须拥有的功能用例。
参考资料：