UML用例图

由参与者（Actor）、用例（Use Case） 以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。
其中用例和参与者之间的对应关系又叫做通讯关联（Communication Association）。

用例图的作用

用例图是需求分析中的产物，主要作用是描述参与者与和用例之间的关系，帮助开发人员可视化地了解系统的功能。借助于用例图，系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。

用例图的构成元素

用例图的构成元素又四个：参与者（角色）、用例、系统边界、元素之间的关系

参与者(Actor)——与应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。
用例(Use Case)——用例就是外部可见的系统功能，对系统提供的服务进行描述。用椭圆表示。
系统边界——系统边界是指系统与系统之间的界限。用方形框+系统名称表示。
- 元素之间的关系
用例图中的关系有四种：关联、泛化、包含、扩展

关系类型	说明	表示符号
关联	参与者与用例之间的关系
泛化	参与者之间或用例之间的关系
包含	用例之间的关系
扩展	用例之间的关系

参与者

参与者（Actor）是指存在于系统外部并直接与系统交互的人、系统、子系统或类的外部实体的抽象。每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参与者。

参与者间的关系

由于参与者实质上也是类，所以它拥有与类相同的关系描述，即参与者与参与者之间主要是泛化关系（或称为“继承”关系）。
泛化关系是指把某些参与者的共同行为提取出来表示成通用行为，并描述成超类。泛化关系表示的是参与者之间的一般或特殊关系，在uml图中，使用带空心三角箭头的实现表示泛化关系，箭头指向超类参与者。

系统边界

系统边界是指系统与系统之间的界限。通常所说的系统可以认为是由一系列相互作用的元素形成的具有特定功能的有机整体。系统同时又是相对的，一个系统本身又可以是另一个更大系统的组成部分，因此，系统与系统之间需要使用系统边界进行区分。
系统边界在用例图中用方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。

用例

用例（Use Case）是参与者（角色）可以感受到的系统服务或功能单元。它定义了系统是如何被参与者使用的，描述了参与者为使用系统所提供的某一完整功能而与系统之间发生的一段对话。
用例最大的优点就是站在用户的角度上（从系统的外部）来描述系统的功能。它把系统当作一个黑箱子，并不关心系统内部是如何完成它所提供的功能的，表达了整个系统对外部用户可见的行为。

用例的特征：

用例必须由某一个参与者触发激活后才能执行，即每个用例至少应该涉及一个参与者。如果存在没有参与者的用例，则可以考虑将这个用例并入其他用例之中。
用例表明的也是一个类，而不是某个具体的实例。用例所描述的是它代表的功能的各个方面，包含了用例执行期间可能发生的各种情况。
用例是一个完整的描述。

用例的粒度：
用例的粒度是指用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的越少。

粗粒度	细粒度

用例规约：
用例图只是在总体上大致描述了系统所提供的各种服务，让人们对系统有一个总体的认识。但对于每一个用例，还需要详细地描述信息，以便让别人对于整个系统由更加详细的了解，这些信息包含在**用例规约（Use Case Specification）**中。

简要说明（Brief Description）
简要说明是指对用例作用和目的的简要描述。
事件流（Flow Event）
事件流包括基本流和备选流。基本流描述的是用例的基本流程，是指用例“正常”运行时的场景。备选流描述的时用例执行过程中可能发生的异常和偶尔发生的情况。
用例场景（Use-Case Scenario）
同一个用例在实际执行的时候会有很多不同的情况发生，称之为用例场景，也可以说用例场景就是用例的实例，用例场景包括成功用例场景和失败场景。
特殊需求（Sepcial Requirement）
特殊需求是指一个用例的非功能性需求和设计约束。特殊需求通常时非功能性需求，包括可靠性、性能、可用性和可扩展性等。
前置条件（Pre-Condition）
前置条件是指执行用例之间系统必须所处的状态。例如，前置条件是要求用户有访问的权限，或是要求某个用例必须已经执行完。
后置条件（Post-Condition）
后置条件是指用例执行完毕后系统可能处于的一组状态。例如，要求在某个用例执行完后，必须执行另一个用例。

用例之间的重要关系

1. 包含

包含关系指用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。
在UML中，包含关系是通过带箭头的虚线段 + << include >>字样来表示的，箭头由基础用例（Base）指向被包含的用例（Inclusion）。

主要由以下两种情况需要用到包含关系：

多个用例用到同一段的行为，则可以把这段共同的行为单独抽象成一个用例，然后让其他用例来包含这一用例。
当某一个用例的功能过多、事件流过于复杂时，也可以把某一段事件流抽象成一个被包含的哟管理，以达到简化描述的目的。

添加和修改会员信息后需要预览会员信息，用以检查添加和修改操作是否正确完成。

包含关系的两个优点：

提高了用例模型的可维护性，当需要对公共需求进行修改时，只需要修改一个用例而不必修改所有与其有关的用例。
不但可以避免在多个用例中重复的描述同一段行为，还可以避免在多个用例中对同一段行为描述不一致的现象。

2. 扩展

在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例（Extension）。原有的用例叫做基础用例（Base），从扩展用例到基础用例的关系就是扩展关系。
一个基础用例可以拥有一个或者多个扩展用例，这些扩展用例可以一起使用。需要注意的时：在扩展关系中是基础用例而不是扩展用例被当做例子使用。
在UML图中，扩展关系是通过带箭头的虚线段 + << extend >> 字样来表示的，箭头指向基础用例。

扩展关系与包含关系的不同点如下：

在扩展关系中，基础用例提供了一个或者多个插入点，扩展用例为这些插入点提供了需要插入的行为。而在包含关系中，插入点只能有一个。
在扩展关系中，基础用例的执行并不一定会涉及到扩展用例，扩展用例只有在满足一定条件下才会被执行。而在包含关系中，当基础用例执行完后，被包含用例是一定会被执行的。
即使没有扩展用例，扩展关系中的基础用例本身也是完整的。而对于包含关系，基础用例在没有没有被包含用例的情况下就是不完整的存在。

基础用例是“身份验证”，扩展用例是”修改密码“。在一般情况下，只需要执行”身份验证“用例即可。但是如果登录用户想要修改密码，这时就不能执行用例的常规动作。如果取修改”身份验证“用例，势必增加系统的复杂性，这时就可以在基础用例”身份验证“中增加插入点，这样用户向修改密码时，就执行扩展用例”修改密码“。

3. 泛化

用例的泛化是指一个父用例可以被特化成多个子用例，而父用例和子用例之间的关系就是泛化关系。
在用例的泛化关系中，子用例继承了父用例所有的结果、行为和关系，子用例是父用例的一种特殊形式。此外，子用例还可以添加、覆盖、改变继承的行为。
在UML中，用例的泛化关系是通过一个三角箭头从子用例指向父用例来表示的。

泛化关系的使用场景：
当系统中有两个或者多个用例存在行为、结构和目的方面存在共性时，就可以使用泛化关系。这时，可以用一个新的（通常也是抽象的）用例来描述这些共有部分，这个新的用例就是父用例。

银行有两种存款方式，一种时柜台存款，一种时ATM存款。在上图中，银行柜台存款和ATM存款都是存款的一种特殊方式，因此“存款”为父用例，“银行柜台存款”和“ATM存款”为子用例。

泛化关系和包含关系的区别:

在用例的泛化关系中，所有的子用例都有相似的目的和结构，注意它们是整体上的相似。而用例的包含关系中，基础用例在目的上可以完全不同，但是它们都有一段相似的行为，它们的相似是部分的相似不是整体的相似。
用例的泛化关系类似于面向对象中的继承，它把多个子用例中的共性抽象成一个父用例，子用例在继承父用例的基础上可以进行修改。但是子用例和子用例之间又是相互独立的，任何一个子用例的执行都不受其他子用例的影响。而用例的包含关系是把多个基础用例中的共性抽象为一个被包含用例，可以说被包含用例就是基础用例中的一部分，基础用例的执行必然引起被包含用例的执行。

用例图实例

销售员用例图
仓库管理员用例图
采购员用例图
会计用例图
系统管理元用例图

用例图的含义