用例图（Use case)用于描写叙述用户需求，从使用者角度展现系统的功能。多用于软件开发需求分析阶段的分析工作和软件測试阶段提供測试根据。
基本组成元素
| 图符 | 名称 | 英文 | 简述 |
 |
參与者 | Actor | 与系统进行交互的人或者物。 位于系统外部，如：管理员 |
 |
用例 | Use case | 详细实现的功能与需求的集合 |
 |
关联关系 | Unidirection Association | 一个物体的存在知道还有一个物体 |
 |
包括关系 | Dependency or instantiates | 用例之间功能的包括。一个用例 可能包括多个用例（必填） |
 |
扩展关系 | Dependency or instantiates |
某个用例的扩展（功能的扩展） |
 |
泛化关系 | Generalization | 继承关系（功能的继承与扩展） |
 |
凝视体 | Note | 描写叙述性字体 |
 |
凝视连接 | Anchor note to item | 连接凝视 |
 |
边界 | Border | 划分系统范围，系统拥有明白界限 十分重要 |
作图步骤：
1.明白边界。一个庞大的系统必然设计的元素是多方面的，仅仅有明白了边界，才干展开用例分析。详细边界找寻我们能够參考这篇博客：http://blog.csdn.net/beijiguangyong/article/details/6226242
2.确定參与者。參与者在系统外围，仅仅有明白參与则，才干对系统用户需求和系统功能展开设计。
3.用例设计。
用例设计要始终站在使用者的角度思考用户需求，包含用例的名字都要体如今使用者的角度。用例描写叙述的是需求或者功能，一般採用动宾短语。
4.确定关系。
在当中较难区分的是扩展与包括关系。
包括是一种从属关系，必定会发生的事，命名规则及其相近。而扩展则强调功能的补充，不一定要发生。比如：
对于看病用例，普通情况下都是会吃药的，仅仅有病情严重的情况下才输液，这样吃药是属于包括关系。输液属于扩展关系；基本查询功能中，必需要进行账户输入，而不一定要进行Excel打印，因此，账户输入是包括关系。而excel打印属于扩展关系。
5.用例描写叙述与用例说明。用例图为系统设计人员与用户之间提供了良好的沟通桥梁，必要的描写叙述不可缺少。
6.界面美化问题。
一个好的project师一定会将图做的清晰可见，这样才干更好的表达自己的意图。
动手操作
总结
UML作图包括了大量的逻辑思考与规范说明。希望在日后一点点的学习中不断总结不断深入了！