用例图
用例图(Use Case Diagram)是用户与系统交互的最简表示形式，展现了用户和与他相关的用例之间的关系。通过用例图，人们可以获知系统不同种类的用户和用例。用例图也经常和其他图表配合使用。
用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。
用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。有时，可以将用例的实例引入到图中。用例图模型如下所示，参与者用人形图标来标识，用例用椭圆来表示，连线表示它们之间的关系。
一．参与者（Actor）
1．参与者的概念
参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。参与者由参与用例时所担当的角色来表示。在UML中，参与者用名字写在下面的人形图标表示。
每个参与者可以参与一个或多个用例。它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。
参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。
第一类：参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。
第二类：参与者是其它的系统。这类位于程序边界之外的系统也是参与者。
第三类：参与者是一些可以运行的进程，如时间。当经过一定的时间触发系统中的某个事件时，时间就成了参与者。
２．确定参与者
在获取用例前首先要确定系统的参与者，开发人员可以通过回答以下的问题来寻找系统的参与者。
（1）谁将使用该系统的主要功能。
（2）谁将需要该系统的支持以完成其工作。
（3）谁将需要维护、管理该系统，以及保持该系统处于工作状态。
（4）系统需要处理哪些硬件设备。
（5）与该系统那个交互的是什么系统。
（6）谁或什么系统对本系统产生的结果感兴趣。
在对参与者建模的过程中，开发人员必须要牢记以下几点。
（1）参与者对于系统而言总是外部的，因此它们可以处于人的控制之外。
（2）参与者可以直接或间接的与系统交互，或使用系统提供的服务以完成某件事务。
（3）参与者表示人和事物与系统发生交户时所扮演的角色，而不是特定的人或者特定的事物。
（4）每个参与者需要一个具有业务一样的名字，在建模中不推荐使用类似“新参与者”的名字。
（5）每一个参与者要必须有简短的描述，从业务角度描述参与者是什么。
（6）一个人或事物在与系统发生交互时，可以同时或不同时扮演多个角色。
（7） 和类一样，参与者可以具有表示参与者的属性和可以接受的事件，但使用的不频繁。
３．参与者之间的关系
因为参与者是类，所以多个参与者之间可以具有与类相同的关系。在用例视图中，使用了泛化关系来描述多个参与者之间的公共行为。如果系统中存在几个参与者，它们既扮演自身的角色，同时也扮演更具一般化的角色，那么就用泛化关系来描述它们。这种情况往往发生在一般角色的行为在参与者超类中描述的场合。特殊化的参与者继承了该超类的行为，然后在某些方面扩展了此行为。参与者之间的泛化关系用一个三角箭头来表示，指向扮演一般角色的超类。这与UML中类之间的返还关系符号相同。
二用例（Use Case）
1．用例的概念
简介：
概念
-
名称
-
简单描述
-
事件流
-
关系
-
活动图和状态图
-
Use Case 图
-
特殊需求
-
前条件
-
后条件
２．识别用例
用例图对整个系统建模过程非常重要，在绘制系统用例图前，还有许多工作要做。系统分析者必须分析系统的参与者和用例，他们分别描述了“谁来做”和“做什么”这两个问题。
识别用例最好的方法就是从分析系统的参与者开始，考虑每一个参与者是如何使用系统的。使用这种策略的过程中可能会发现新的参与者，这对完善整个系统的建模有很大的帮助。用例建模的过程是一个迭代和逐步精华的过程，系统分析者首先从用例的名称开始，然后添加用例的细节信息。这些信息由简短的描述组成，它们被精华成完整的规格说明。
在识别用例的过程中，通过回答以下几个问题，系统分析者可以获得帮助。
（1）特定参与者希望系统提供什么功能。
（2）系统是否存储和检索信息，如果是，由哪个参与者触发。
（3）当系统改变状态时，是否通知参与者。
（4）是否存在影响系统的外部事件。
（5）哪个参与者通知系统这些事件。
３．用例与事件流
用例分析处于系统的需求分析阶段，这个阶段应该尽量避免考虑系统实现的细节问题。但是要实际建立系统，则需要更加具体的细节，这些细节写在事件流文件中。事件流的目的是为用例的逻辑流程建立文档，这个文档详细描述系统用户的工作和系统本身的工作。
虽说事件流很详细，但其仍然是独立于实现的方法的。换句话说，事件流描述的是一个系统“做什么”而不是“怎么做”。事件流通常包括：简要说明、前提条件、主事件流、其它事件流和事后事件流。
（1） 简要说明。每个用例应当有一个相关的说明，描述该用例的作用，说明应当简明扼要，但应包括执行用例的不同类型的用户和通过这个用例要达到的结果。
（2）前提条件。用例的前提条件列出用例之间必须满足的条件。例如，前提条件是另一个用例已经执行或用户具有运行当前用例的权限。但并不是所有用例都有前提条件。
（3）主事件流和其它事件流。用例的具体细节在主事件流和其它事件流中描述。事件流是从用户角度描述执行用例的具体步骤，关注系统“做什么”，而不是“怎么做”。主事件流和其它事件流包括：用例如何开始和结束、用例如何与参与者交互、用例的正常流程（主流程）、用例主事件流（其它事件流）的变体和错误流。
（4） 事后条件。事后条件是用例执行完毕后必须为真的条件。例如，可以在用例完成之后设置一个标识，这种信息就是事后条件。与前提条件一样，事后条件可以增加用例次序方面的信息，如果要求一个用例执行完后必须执行另一个用，那么就可以在事后条件中说明这一点。当然，并不是每个用例中都有事后条件。
三用例间的关系
用例除了与参与者发生关系外，还可以具有系统中的多个关系，这些关系包括包含关系、扩展关系和泛化关系。应用这些关系的目的是为了从系统中抽取出公共行为和其变体。
1．关联关系（Association）
关联关系描述参与者与用例之间的关系，它是用于表示类的挂系的关联元类的实例。在UML中，关联关系用箭头来表示。
关联关系表示参与者与用例之间的通信。不同的参与者可以访问相同的用例，一般说来它们和该用例的交互是不一样的，如果一样的话，说明它们的角色可能是相同的。如果两中交互的目的也相同，说明它们的角色是相同的，就可以将它们合并。
２．包含关系（Include）
虽然每个用例的实例都是独立的，但是一个用例可以用其它的更简单的用例来描述。这有点像通过继承父类并增加附加描述来定义一个类。一个用例可以简单地包含其它用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这被称作包含关系。在这种情况下，新用例不是初始用例的一个特殊例子，并且不能被初始用例所代替。在UML中，包含关系表示为虚线箭头交<<include>>字样，箭头指向被包含的用例。
包含关系把几个用例的公共步骤分离成一个单独的被包含用例。被包含用例称作提供者用例，包含用例称作客户用例，提供者用例提供功能给客户使用。用例间的包含关系允许包含提供者用例的行为到客户用例的事件中。
包含关系使一个用例的功能可以在另一个用例中使用，如下所述。
（1）如果两个以上用例有大量一致的功能，则可以将这个功能分解到另外一个用例中。其它用例可以和这两个用例建立包含关系。
（2） 一个用例的功能太多时，可以用包含关系建模两个小用例。
要使用包含关系，就必须在客户用例中说明提供者用例行为别包含的详细位置。这一点同功能调用有点类似。事实上，它们在某种程度上具有相似的语义。
３．扩展关系（Extend）
一个用例也可以被定义为基础用例的增量扩展，这被称作扩展关系，扩展关系是把新的行为插入到已有的用例中的方法。同一个基础用例的几个扩展用例可以在一起应用。基础用例的扩展增加了原有的语义，此时基础用例而不是扩展用例被作为例子使用。在UML中，扩展关系表示为虚线箭头加<<extend>>字样，箭头指向被扩展展的用例。
基础用例提供了一组扩展点，在这些新的扩展点中可以添加新的行为，而扩展用例提供了一组插入片片段，这些片段能够被插入到基础用例的扩展点上。基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。事实上，基础用例即使没有扩展用例也是完整的，这点与包含关系有所不同。一个用例可能有多个扩展点，每个扩展点可以出现多次。但是一般情况下，基础用例的执行不和涉及到扩展用例，只有特定的条件发生，扩展用例才被执行。扩展关系为处理异常或构建灵活的系统框架提供了一种有效的方法。
４．泛化关系（Generalization）
一个用例可以被特别列举为一个或多个用例，这被称为用例泛化。当父用例能够被使用时，任何子用例也可以被使用。在UML中用例泛化与其它泛化关系的表示法相同，用一个三角箭头从子用例指向父用例。
在用例泛化中，子用例表示父用例的特殊形式。子用例从父用例处继承行为和属性，还可以添加、覆盖或改变继承的行为。如果系统中一个或多个用例是某个一般用例的特殊化时，就需要使用用例的泛化关系。
用例建模技术
一．对语境建模
对于一个系统，会有一些事物存在于其内部，而一些事物存在于其外部。存在于系统内部的事物的任务是完成系统外部事物所期望的系统行为，存在于系统外部并与其进行交互的事物构成了系统的语境，即系统存在的环境。在UML建模中，用例图对系统的语境进行建模，强调的是系统的外部参与者。对系统语境建模应当遵循以下的方法：
（1）用以下几组事物来识别系统外部的参与者：需要从系统中得到帮助以完成其任务的组；执行系统功能时所必须的组；与外部硬件或其它软件系统进行交互的组；为了管理和维护而执行某些辅助功能的组。
（2）将类似的参与者组织成泛化/特殊化的结构层次。
（3） 在需要加深理解的地方，为每个参与者提供一个构造型。
（4）将参与者放入到用例图中，并说明参与者与用例之间的通信路径。
二．对需求建模
需求就是根据用户对产品功能的期望，提出产品外部功能的描述。需要分析所要做的工作是获取系统的需求，归纳系统所要实现的功能，使最终的软件产品最大限度的贴近用户的要求。对系统需求建模可以参考以下的方法。
（1）识别系统外部的参与者来建立系统的语境。
（2）考虑每一个参与者期望的行为或需要系统提供的行为。
（3）把公共的行为命名为用例
（4） 分解公共行为，放入到新的用例中以供其它的用例使用：分解异常行为，放入新用例中以延伸为主要的控制流。简而言之，就是确定提供者用例和扩展用例。
（5） 在用例视图中对用例、参与者和它们之间的关系进行建模。
用例建模实例
用例图中可以有5种关系类型。
Assoication - 参与者和用例之间的关联
Generalization - 演员的概括
在两个用例之间扩展
包括在两个用例之间
用例的泛化
让我们详细看看这些关系。
1. Actor与用例之间的关联 (Assoication)
这个很简单，并且存在于每个用例图中。很少有事情需要注意。
参与者必须与至少一个用例相关联。
actor可以与多个用例相关联。
多个actor可以与单个用例相关联。
2. 演员的泛化 (Generalization)
一个actor的泛化意味着一个actor可以继承另一个actor的角色。后代继承了祖先的所有用例。后代具有一个或多个特定于该角色的用例。
3. 用例之间的泛化 (Generalization)
一个用例的泛化意味着一个用例r可以继承另一个actor的角色。后代继承了祖先的所有用例。
4. 扩展两个用例之间的关系
许多人在用例中混淆了扩展关系。顾名思义，它扩展了基本用例并为系统增加了更多功能。使用<< extend >>关系时，需要考虑以下几点。
扩展用例取决于扩展（基础）用例。在下图中，如果没有“存款资金”用例，“计算奖金”用例没有多大意义。
扩展用例通常是可选的，可以有条件地触发。在图中，您可以看到扩展用例仅针对超过10,000的存款或年龄超过55的情况触发。
扩展（基础）用例必须是有意义的。这意味着它应该是独立的，不能依赖于扩展用例的行为。
拓展例子：查询上机记录，附加了一个导出Excel的功能，所以属于拓展。
5. 包括两个用例之间的关系
包含关系表明包含的用例的行为是包含（基础）用例的一部分。这样做的主要原因是在多个用例中重用常见操作。在某些情况下，这样做是为了简化复杂的行为。使用<< include >>关系时很少考虑。
如果没有包含用例，基本用例是不完整的。
包含的用例是强制性的，不是可选的。
例子：用例“注册学生信息”和“充值”与用例“用户登陆”之间的关系就是包含关系。b和a本质不一样，就是做b之前一定要做a，那a和b就是包含。
ATM例子：
这是ATM的用例图模板。在学习UML时，ATM系统被广泛用作例子。ATM用例图是非常经典和流行的UML示例之一。让我们来看看。在此示例中，作为ATM用户的客户被建模为actor。提取现金，转移现金，向慈善机构捐款，支票余额和结算账单等主要功能都被模拟为用例。所有这些用例都包含Login用例。这意味着它们都包含与Login用例建模相同的登录功能。登录用例通过两个用例进一步扩展。这可以模拟登录过程中可能发生的异常情况。
参考文章：（根据以下文章取其精华，去其糟粕，并修改了其中我认为不对的地方）
【1】用例图介绍
【2】用例图的5种关系类型
【3】用例关系