1、用例图和用例模型用例图用来描述用户的需求，它从用户的角度描述系统的功能，并指出各功能的执行者，强调谁在使用系统，系统为执行者完成哪些功能。用例图概述UML 用例图是软件产品外部特性描述的视图，它从用户的角度而不是开发者的角度来描述软件产品的需求，分析软件产品所需的功能和行为。用例图主要描述了系统需要实现的功能，而忽略系统是如何实现这些功能的。用例模型由用例图组成，它是系统用例图的集合，是对系统从宏观角度的确定描述。用例模型主要用于需求分析阶段，该模型是系统开发者和系统使用者反复讨论的结果，表明了系统开发者和系统使用者对需求规格达成的共识。首先，用例模型描述了待开发系统的功能需求；其次，用例模型
2、将系统看作黑盒，仅从外部执行者的角度来理解系统；再次，用例模型驱动了需求分析之后各阶段的开发工作，影响到开发工作的各个阶段和 UML 的各个模型。一、用例图元素用例图主要用于定义系统的功能需求，它描述了系统的参与者与系统提供的用例之间的关系。用例图由以下几种元素组成：执行者、用例、关系、用例描述（1）执行者执行者（Actor）是系统的外部用户，它是与系统相关联的人或其它系统，可以是普通用户、外部硬件、其他系统。在进行用例图绘制时，首先要找出系统的执行者。一般可以从以下几个方面来考虑怎样找到系统的执行者： 谁使用系统的功能。 谁向系统提供必要的信息。 谁从系统获取信息。 谁维护、管理系统工作。
3、系统需要使用哪些外部资源。 需要与系统交互的其它系统有哪些。 其他对系统产生的结果感兴趣的人或事物。（2）用例用例是指系统中的一个功能单元，也可以将用例理解为系统功能的分解。用例的表示方法如下：（3）关系（1）关联在用例图中，用例和执行者之间的关系用一条连接二者带箭头的连线表示，如图所示，该连线称为关联。它表示了一个执行者和一个用例之间的关系。在用例图中，关联关系只用在执行者和用例之间，用例和用例之间不会存在关联关系。关联关系采用的是单箭头的连线，表示在该关联中执行者是主动的，是执行者启动的用例。如下图所示。（2）包含包含是指一个用例作为另一个用例必需的部分被使用，包含关系是依赖关系的一种。包
4、含关系用一条连接二者带箭头的虚线表示，并在虚线的上面标注include，箭头方向由基本用例指向包含用例，如下图所示。包含的使用场合：如果多个用例有大量一致的功能，可以将这个功能分解到一个用例中，其他用例和这个用例建立包含关系。一个用例功能太多，可以使用包含关系建立若干小用例。（3）扩展扩展是指一个用例扩充了另一个用例的功能，但这个扩充功能不是必需的，扩展关系也是依赖关系的一种。扩展关系用一条连接二者带箭头的虚线表示，但在虚线的上面标注的是extend，箭头方向由扩展用例指向基本用例，如下图所示。扩展关系和包含关系的区别。包含用例是一个完整的用例，它可以独立的存在，也可以单独被执行者所调用。扩展
5、用例并不是一个完整的用例，它只是由部分扩展功能组成的，它不能独立的存在，必须依赖于基本用例。（4）泛化用例间的泛化关系是指一个概念较为抽象的用例可以被一般化为一个或多个概念更为具体的用例。其中概念较为抽象的用例被称为父用例，概念更为具体的用例称为子用例。子用例是父用例的特殊形式，子用例从父用例处继承属性和行为，还可以添加、覆盖或改变继承的行为。二、用例描述为了进一步说明用例是如何完成功能的，就需要对用例进行更加详细的描述。用例描述主要用来说明执行者为了实现自己的目标与系统进行交互的过程。在用例描述中，需要对用例的主要属性进行说明。这些属性主要包括： 简要说明 前置条件 后置条件 基本事件流 其他事件流 异常事件流
