概述
用例图（Use Case Diagram）是由软件分析需求分析到实现的第一步，描述了人们希望如何使用一个系统；用例图显示了谁将是相关的用户、用户想要系统提供的服务，以及用户需要为系统提供的服务，便于软件开发人员最终实现这些元素。
UML中的用例图描述了一组用例、参与者以及它们之间的关系，因此用例图包括以下 3 方面内容：（1）用例（Use Case）；（2）参与者（Actor）；（3）参与者、用例之间的关系，泛化关系、包含关系、扩展关系等。
用例图也可以包含注解和约束；用例图还可以包含包，用于将模型中的元素组合成更大的模块；有时，还可以把用例的实例引入到图中；参与者用人形图标表示，用例用椭圆形符号表示，连线描述它们之间的关系；用例图模型如下图所示：
参与者（Actor）
参与者概述
参与者（Actor）是系统外部的一个实体（可以是任何的事物或人），它以某种方式参与了用例的执行过程；参与者通过向系统输入或者请求系统输入某些事件来触发系统的执行。
每个参与者可以参与一个或多个用例；它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分描述参与者。
参与者不一定是人，也可以是一个外部系统，该系统与本系统相互作用，交换信息外部系统可以是软件系统，也可以是个硬件设备，例如在实时监控系统中的数据采集器，自动化生产系统上的数控机床等。
通常可以将参与者分成3大类：系统用户（参与者为真实的人）、与所建造的系统交互的其他系统（参与者为其他系统）和一些可以运行的进程（参与者为可以运行的进程。
参与者确定
获取用例前要先确定系统参与者，按照以下问题来寻找系统参与者：
（1）谁或为什么使用该系统；
（2）交互中，它们扮演什么角色；
（3）谁安装系统；
（4）谁启动和关闭系统；
（5）谁维护系统；
（6）与该系统交互的是什么系统；
（7）谁从系统获取信息；
（8）谁提供信息给系统；
（9）有什么事发生在固定时间。
在建模参与者过程中，记住以下要点：
（1）参与者对于系统而言总是外部的，因此它们在你的控制之外；
（2）参与者直接同系统交互，这可以帮助定义系统边界；
（3）参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或特定的事物；
（4）一个人或事物在与系统发生交互时，可以同时或不同时扮演多个角色；例如，某研究生担任某教授的助教，从职业的
角度看，他扮演了两个角色——学生和助教；
（5）每一个参与者需要有一个具有业务一样的名字，在建模中，不推荐使用诸如NewActor这样的名字；
（6）每个参与者必须有简短的描述，从业务角度描述参与者是什么；
（7）像类一样，参与者可以具有分栏，表示参与者属性和它可接受的事件；一般情况下，这种分栏使用的并不多，很少显示在用例图中。
参与者联系
在用例图中，使用了泛化关系来描述多个参与者之间的公共行为。若系统中存在几个参与者，它们既扮演自身的角色，又扮演更具一般化的角色，那么就用泛化关系来描述它们。这种情况往往发生在一般角色的行为在参与者超类中描述的场合。特殊化的参与者继承了该超类的行为，然后在某些方面扩展了此行为。
参与者之间的泛化关系用一个三角箭头来表示，指向扮演一般角色的超类，如下图所示：
用例（Use Case）
用例的概念
用例是对一个系统或一个应用的一种单一的使用方式所作的描述，是关于单个活动者在与系统对话中所执行的处理行为的陈述序列。
用例是一个叙述型的文档，用来描述参与者（Actor） 使用系统完成某个事件时的事情发生顺序。
用例是对系统的用户需求（主要是功能需求）的描述，用例表达了系统的功能和所提供的服务。
图形上，用例用一个椭圆来表示，用例的名字可以书写在椭圆的内部或下方。用例的 UML 图标如下图所示：
注意：
每个用例都必须有唯一的一个名字以区别于其他用例。用例的名字是一个字符串，它包括简单名（simple） 和路径名（path name）。图4-7所示左边的用例使用的是简单名。用例的路径名是在用例名前加.上它所属包的名字。下图中右边的用例使用的是路径名，用例Maintenance （续借）是属于事务包（Business） 的。
用例的识别
在识别用例的过程中，通过以下的几个问题可以帮助识别用例：
（1）特定参与者希望系统提供什么功能；
（2）系统是否存储和检索信息，如果是，这个行为由哪个参与者触发；
（3）当系统改变状态时，通知参与者吗；
（4）存在影响系统的外部事件吗；
（5）是哪个参与者通知系统这些事件。
用例和事件流
事件流的目的是为了用例的逻辑流程建立文档，此文档详细描述系统用户的工作和系统本身的工作。
可以通过一个清晰的、易被用户理解的事件流来说明一个用例的行为。这个事件流包括用例何时开始和结束，用例何时和参与者交互，什么对象被交互以及该行为的基本流和可选流。
用例与参与者的关系
关联关系
参与者与用例之间通常用关联关系来描述。参与者与用例之间的关联关系使用带箭头的实线来表示，如下图所示：
泛化关系
一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化。用例间的泛化关系和类间的泛化关系类似，即在用例泛化中，子用例表示父用例的特殊形式。子用例从父用例处继承行为和属性，还可以添加行为或覆盖、改变已继承的行为。当系统中具有一个或多个用例是一般用例的特化时，就使用用例泛化。
在图形上，用例间的泛化关系用带空心箭头的实线表示，箭头的方向由子用例指向父用例。如下图所示：
包含关系
包含（include）指的是其中一个用例（称作基础用例）的行为包含了另一个用例（称作包含用例）的行为。基础用例可以看到包含用例，并依赖于包含用例的执行结果。但是二者不能访问对方的属性。
在 UML 中，包含关系表示为虚线箭头加<>字样，箭头指向被包含的用例，如下图所示：
扩展关系
一个用例也可以被定义为基础用例的增量扩展，这称作扩展关系。扩展关系是把新行为插入到已有用例的方法。基础用例提供了一组扩展点（ Extension points）， 在这些扩展点中可以添加新的行为，而扩展用例提供了一组插入片段，这些片段能够被插入到基础用例的扩展点中。
在UML中，扩展关系表示为虚线箭头加<>字样，箭头指向被扩展的用例（即基础用例），如下图所示：
