第一，用例图概念
要了解用例图，首先了解下用例，也就是use case。什么是用例呢，简单来说就是在确定项目需求时，不展现系统内部结构的情况下对系统功能的描述，不过一个use case描述的是整个系统功能的一部分，这一部分一定要是在逻辑上相对完整的功能流程。
用例图是UML用例建模的一种，也是UML建模的基础，它主要用于描述用户或者系统内部的功能需求与行为。灵活的使用用例图，可以让描述的需求或者行为清晰的表达其该有的含义。
用例图是从系统的外部看系统的功能的，它并不描述系统内部对功能的具体实现，使得用户能够理解如何使用这些元素，并且使得开发者能够实现这些元素。用例图中的用例和参与者是分别位于系统内外的。
用例图是被称为参与者的外部用户所能观察到的系统功能的模型图，它呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统后者类的功能进行建模。
用例图战士了用例之间以及同用例参与者之间是怎么样相互联系的。用例图用于对系统、子系统或者类的行为进行可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。
用例图将系统中的用户分出工作状态的属性和工作内容，方便建模，防止功能重复和多余的类。用例图定义了系统的功能需求，它是从系统的外部看系统功能，并不描述系统内部对功能的具体实现。
第二，用例驱动
在实际的软件项目中，一个软件要实现的功能都是通过用例来获得的。接下来所有的分析、设计、实现、测试都是由用例来驱动的，即以实现用例为目标，这就是所谓的用例驱动。
用例驱动的原理告诉我们，我们如果要解决问题领域就要归纳出合理的抽象角度(用例),为这些用例描述出可能的特定的场景，并找到这些场景的事物、规则和行为。
需求时使用Use Case来表达的，而界面是在Use Case的辅助下设计的，很多类是根据Use Case发现的，测试实例是根据Use Case来生成的，包括整个开发的管理和任务分配，也是依据Use Case来组织的。
因此，如果一个工程用例图画不好，那么之后的分析、设计、实现和测试都会受到不同程度的影响，我们所研究问题的领域也会受到限制。
第三，用例图的等级
用例图可以分为三个等级：
(1)概述级：对总体功能进行了描述
(2)用户级：将系统功能分成了不同的功能模块
(3)子功能级：对角色、功能模块的要求更具体，划分的更细致
第四，用例图的组成
用例图的组成分别为:参与者(actor)、用例(use case)、关系、系统边界
第五，用例图的具体组成
(1)参与者：用例的触发者，触发者可以是用户，也可以是事件代理人。所谓事件代理人就是给系统自动设置的定时功能操作，当到达一定时间，系统会自动执行相应的功能。
(2)用例：对系统功能的描述。
(3)关系：描述的是参与者和用例之间的连接。
第六，关系
(1)泛化：起始、目的相同，实现方式不同，使用空心三角，指向公用
(2)包含：大用例分成小用例，小用例是大用例的组成部分，使用虚线箭头，大指向小，即include
(3)扩展：大用例分成小用例，但是小用例不是大用例的基本组成，使用虚线箭头，小指向大，即extend
第七，用例表
我们不仅可以使用用例图来表达，还可以使用用例表来表达。用例表并不属于UML规范，它的作用是能够更加详细的阐述一个用例的行为，但是在直观方面不如用例图来的直观。
下面是用例表的几个表项：
(1)编号：自由填写
(2)名称：用例名字
(3)活动者：用户或者角色
(4)优先级：自由编制，也可以使用高中低这种方式来表达
(5)描述：简单的描述本用例，重点说明活动者的目的即可
(6)前置条件：列出执行本用例前必须存在的系统状态，比如必须录入什么数据，必须具备什么权限等等。注意除非必要情况，不要写类似于"登陆系统"等每个用例几乎都需要具备的前置条件。
(7)基本流程：说明在正常情况下，最常用的流程，通常是活动者和系统之间交互的文字描述。
(8)结束状况：说明在正常结束的情况下的用例结果。
(9)可选流程1-n:说明和基本流程不同的其他可能的流程
(10)异常流程：说明出现错误或者其他异常情况时和基本流程的不同之处
(11)说明：包括其他的业务规范等说明
第八，用例表的基本格式
(1)用阿拉伯数字来进行编号
(2)活动者的操作顶格写
(3)系统的操作空两格写