一、概念
用例图（Use Case Diagram）：主要用于描述系统的行为及各种功能之间的关系，是描述参与者（Actor）与用例以及用例与用例之间关系的图。
二、用途
- 用例图显示谁将是相关用户、用户希望系统提供什么服务以及用户需要为系统提供的服务。
- 用例图最长用来描述系统以及子系统。
三、用例图组成元素
1、参与者（Actor）
- 参与者可以是人或其他外界系统
- 参与者是用例的启动者，参与者处于用例的外部并且能够初始化一个用例并参与用例的执行过程，但它并不是系统的一部分
- 每个参与者可以参与一个或多个用例
发现参与者：
- 谁或什么在使用系统
- 交互中，他们扮演什么角色
- 谁安装系统
- 谁启动和关闭系统
- 谁维护系统
- 与该系统交互的是什么系统
- 谁从系统获取信息，谁提供信息给系统
- 参与者对于系统而言是外部的，它们在系统控制之外。
- 参与者直接同系统交互，可以帮助定义系统边界
- 参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或事物
- 一个人和事物与系统发生交互时，可以扮演多个角色。
- 每个参与者需要有一个具有业务语义的名字
- 每个参与者必须有简短的描述，从业务角度描述参与者是什么
- 参与者可以具有分栏，表示参与者属性和它可接受的事件
- 参与者可以使用泛化关系来描述多个参与者之间的公共行为
- 用例是一组动作序列的描述，系统执行该动作序列为系统的参与者产生一个可观察的结果
- 用例反映用户的需求
- 用例是一个叙述型的文档，用来描述一个参与者使用系统完成某个事件时的事情发生顺序（描述参与者与系统的交互）
- 用例是系统的使用过程，是对系统的用户功能需求的描述，用例表达了系统的功能和所提供的服务
识别用例的方法：从分析系统的参与者开始，考虑每个参与者是怎样使用系统的
- 特定参与者希望系统提供什么功能
- 系统是否存储和检索信息，若是，这个行为由哪个参与者触发
- 当系统改变状态时，是否通知参与者
- 是否存在影响系统的外部事件
- 是哪个参与者通知系统这些事儿
3、关系
（1）关联关系（Association）
是参与者与用例之间最简单常用的关系
（2）包含关系（Include）
把几个用例的公共步骤分离成一个单独被包含的用例；包含用例成为客户用例，被包含用例成为提供者用例。
用例A包含用例B，将A成为基用例，B成为被包含用例。
包含关系表示基用例会用到被包含用例。被包含用例的事件流在基用例的某个点处插入到基用例的事件流中。
包含关系表示方式：
基用例被链接在虚线箭头的尾部，箭头指向被包含用例，并在虚线处添加一个<<include>>标签以表示扩展关系。
使用：
- 如果两个用例有大量一致功能，则可以将这个功能分解到另个一功能。其他用例可以和这个用例建立包含关系。
- 一个用例的功能太多是，可以用包含关系建模两个小用例。
扩展使得每个用例可以通过扩展用例向基用例中添加额外的行为来扩展基用例的功能。
用例A扩展了用例B，那么A成为扩展用例或子用例，B表示为基用例。
扩展用例A的事件流在一定的条件下按照相应的扩展点插入到基用例汇总，这就需要在基用例中定义一至多个已命名的扩展点。（和继承关系不一样）
选用扩展关系可以把一些可选的操作独立封装在另外的用例中，避免基用例过于复杂。
表示方式：
扩展用例被链接在虚线箭头的尾部，剑斗指向基用例，并在虚线处添加一个<<extend>>表示扩展关系。
（4）泛化关系（Generalization）
泛化关系是两个用例或两个参与者之间的关系。
泛化关系其实可以通俗理解为面向对象关系中的继承。将拥有一种类似的结构和行为的多个用例中的共性抽象为父用例，子用例继承父用例中的所有。
表示方式：
用实线加上空心箭头表示，其中子用例被链接在箭头尾部，箭头指向父用例。
*扩展关系和包含关系的区别
相同点：
- 都是两个用例之间的关系（只有泛化关系不仅可以表示两个用例，还可以是两个参与者之间）
- 条件性
- 包含关系是无条件的
- 扩展关系是有条件的
- 插入原则：
- 包含关系中被包含用例的事件流一定插入到基用例中去
- 扩展关系可以根据一定条件来决定是否将扩展用例的事件流插入到基用例事件流
- 插入点：
- 包含关系中插入点只有一个
- 扩展关系中插入点可以有多个
@机房收费系统用例图
感谢阅读，顶一个吧！