提到UML中的用例，很多人可能都会觉得很熟悉经常听说。如果问一句什么是用例，很多的回答就是用例图中的一个椭圆。用例仅仅是用例图中的一个椭圆吗？当然不是，那么用例的本质是什么呢？
1、用例发展史
为了搞清用例的本质我们首先了解一下用例技术的发展史。UML中的用例概念是由有UML之父Ivar Jacobson在60年代提出。后来Alistair Cockburn从Ivar Jacobson那里学习了用例，并且结合自己的实践对用例进行了继承和发展，提出了“基于目标的用例”。在UML形成的时候，用例UML作为一个重要的部分被纳入了UML。用例被认为是第二代面向对象技术的标志。
2、用例的本质
用例的本质并不是UML中的一个椭圆符号，而是描述系统中各个相关人员之间就系统的行为所达成的契约，它应用功能分解的方法，站在系统之外，使用文字表达系统的功能性需求。在UML中为了可视化使用一个椭圆来表示，用例的具体内容通过使用用例模板来表达。用例技术是迄今为止最为深刻、准确和有效的系统功能需求描述方法。
用例技术有如下的一些特点：用例是一种半形化的方式，它不是使用一种形式化的语言，而是使用自然语言来描述需求。但是它却明确的提出了角色和用例的概念，以及角色和用例进行通讯的规则，以及用例模板的主要内容。严格的结构和形式会使需求变得生硬、无用，没有结构和形式的需求又不易交流。这种半形式结构使得人们的创造性得以发挥，也使得系统的最终用户能够轻松的阅读；在每个用例和所有的描述层次中，都描述了错误时的系统处理。系统复杂性大部分都是处理错误情况，这样能够在需求分析阶段检测出相关的问题进行分析，而不是在以后的阶段中发现。这是我在使用用例过程中最为深刻的一点，我们在写需求的时候仅仅描述正确的用户需求，很少提及错误情况；用例提供了可以在其上处理其他项目信息的骨架，从而实现用例驱动。
3、用例与需求
很多人使用用例描述需求后，就会产生疑问用例和需求到底是什么关系。用例是需求，但并不是系统的全部需求，用例描述的只是功能性方面的需求。不要试图把所有的需求都以用例的方式表示出来。有些人认为用例可以表示所有的系统需求，因此用UML来表示那些事实上很难用用例表示的需求，这样做是不对的。用用例分析需求有如下的特点：
1. 用例从使用系统的角度描述系统中的信息，即站在系统外部观看系统的功能，而不考虑系统内部对该功能的具体实现方式。
2. 用例描述了用户提出的一些可能需求，对应一个具体的用户目标，用例可以促进与用户沟通、理解正确的需求，同时也可以用来划分系统与外部实体的界限，是面向对象系统设计的起点，是类、对象、操作的来源。
3. 用例是对系统行为的动态描述。
4、用例驱动
可能很多人都听说过数据驱动、用例驱动这样的字眼。为什么说使用UML进行软件开发是用例驱动的？因为用例代表系统中各个相关人员之间就系统的行为所达成的契约，一个软件的开发就是从分析这些工作开始的。软件的开发过程分为需求分析、设计、实现、测试等阶段，用例把所有这些都捆绑再一起，用例分析的结果也为预测系统的开发时间和预算提供依据，保证项目的顺利进行，从各个方面综合起来讲软件开发是用例驱动的。
5、用例模板
用例图只是简单地可视化描述系统，我们还需要对用例进行详细的说明。为了明确的描述用例我们需要一个用例模板，但是至今并没有统一的用例模板。用例模板的内容一般包括：简要描述、前置条件、后置条件、基本事件流、备选事件流等等。
简要描述：对用例的角色、目的的简要描述。
前置条件：执行用例之前系统必须要处于的状态，或者要满足的条件。
后置条件：用例一旦执行后系统所处的状态。
基本事件流：描述该用例的基本流程，指每个流程都“正常”运作时所发生的事情，没有任何备选流而只有最有可能发生的事件流。
备选事件流：表示这个行为或流程是可选的或备选的，并不是总要总要执行它们。
下面是一个用例模板的示例：
用例：<编号><名称>
特征信息：
用例在系统中的目标（用例目标描述）
范围（当前考虑的是哪个系统）
级别（概要任务/首要任务/子功能）
前提条件（用例执行前系统用具有的状态）
成功后继条件（用例成功执行后应具有的状态）
失效后继条件（用例没有完成目标的状态）
首要角色（与该用例关联的首要角色）
触发（启动该用例执行的系统动作）
主要步骤：
<步骤编号><动作描述>
扩展：
<有变化情况的步骤编号><条件>:<动作或另外一个用例>
变异：
<步骤或变化编号><变异列表>
相关信息：（可选）
优先级（该用例对于系统组织的关键程度）
性能目标（该用例的执行时间耗费）
频度（该用例被执行的频度）
从属用例：（可选）
下属用例：
与首要角色的联系渠道（包括交互式、静态文件、数据库等）
公开问题：（可选）
列出关于该用例的未解决的问题