什么是用例图？
那么说明是用例图，UML用例图是系主要形式新软件程序要求不发达。用例指定预取的行为（是什么），而不是是他发生的确切行为（如何）。一旦指定了用例，就可以用文字和视觉来表示，用例建模的一个关键概念是，它可以帮助我们从从中客户的角度去设计系统。通过指定所有外部可见的系统行为，这是一种一用户的方式传达系统行为的有效技术。
用例图的介绍
用例图通常很简单，他没有先是用例的详细信息。
- 它仅仅总结了用例，参与者和系统之间的一些关系。
- 他没有先是执行步骤一实现每一个用例目标的顺序。
注意！如果当用例超过了20个，那可能就是说明你滥用用例图了。
用例视图采用参与者和用例作为基本元素，以不同的视角展示系统的功能性需求。
用例视图是来展示参与者和用例的，因此前提条件是参与者和用例都已经获取，不过在实际中，绘制用例视图和发现用例一般都是并行的。一边发现参与者，一边绘制用例视图，而绘制过成功则有可能回头修改已经获取的参与者和用例。最终，建模者通过用例视图将获得的参与者和用例从某个角度进行展示。
下面显示了UML图层次和UML用例的位置：
注意!
- 有许多不同的UML图具有不同的用途（如您从上面的UML图树中看到的）。您可以在其他UML图表类型和文档中描述这些详细信息，并从用例中链接它们。
- 用例仅代表系统的功能需求。其他要求，例如业务规则，服务质量要求和实现约束，必须再次用其他UML图分别表示。
用例图的目的
用例图通常在开发的早期阶段使用，经常处于一下目的引用用例建模
- 指定系统的上下文
- 捕获系统需求
- 验证系统架构
- 推动实施并生成测试案例
- 由分析师和领域专家共同开发
用例图一览
| 符号说明 | 视觉表现 |
|---|---|
| 演员有人与用例（系统功能）进行交互。以名词命名。演员在商业中扮演重要角色与用户的概念类似，但是用户可以扮演不同的角色例如：教授 既可以是讲师，也可以是研究员在两个系统中扮演2个角色Actor触发用例。Actor对系统负责（输入），Actor对系统负责（输出）。 |  |
| 用例系统功能（过程-自动或手动）用动词+名词（或名词短语）命名。即做点什么每个Actor必须链接到一个用例，而某些用例可能未链接到Actor。 |  |
| 通讯链接通过用实线链接将参与者连接到用例，可以显示参与者在用例中的参与。参与者可以通过关联连接到用例，指示参与者和用例之间通过消息进行通信。 |  |
| 系统边界系统边界可能是需求文档中定义的整个系统。对于大型和复杂的系统，每个模块都可能是系统边界。例如，对于组织的ERP系统，每个模块，例如人员，薪资，会计等。可以为每个业务功能特定的用例形成一个系统边界。整个系统可以跨越所有描述整个系统边界的模块 |  |
用关系构建用例图
用例共享不同类型的关系。定义两个用例之间的关系是用例图的软件分析人员的决定。两个用例之间的关系基本上是对两个用例之间的依赖关系建模。通过使用不同类型的关系来重用现有用例可减少开发系统所需的总体工作量。用例关系如下所示：
| 用例关系 | 视觉表现 |
|---|---|
| 延伸指示“无效密码”用例可能包括（取决于扩展名中的指定）基本用例“登录帐户”所指定的行为。用带虚线的有向箭头表示。箭头的尖端指向基本用例，儿童用例连接在箭头的底部。构造型“ << extends >>”标识为扩展关系 |  |
| 包括当一个用例被描述为使用另一个用例的功能时，这些用例之间的关系称为包含或使用关系。用例包括在另一个用例中描述的功能，作为其业务流程的一部分。从基本用例到子用例的使用关系表示基本用例的实例将包括子用例中指定的行为。包含关系用带有虚线的有向箭头表示。箭头的尖端指向连接在箭头底部的子用例和父用例。构造型“ << include >>”将该关系标识为包含关系。 |  |
| 概括泛化关系是用例之间的父子关系。子用例是父用例的增强。概括显示为带有三角形箭头的有向箭头。儿童用例连接在箭头的底部。箭头的尖端连接到父用例。 |  |
用例示例
用例示例-关联链接
用例图说明了系统的一组用例，即参与者和参与者与用例之间的关系。
用例示例-包含关系
包含关系添加了基本用例中未指定的其他功能。<< Include >>关系用于将常见行为从包含的用例包含到基本用例中，以支持常见行为的重用。
用例示例-扩展关系
扩展关系很重要，因为它们显示了可选功能或系统行为。<< extend >>关系用于在扩展用例中包含来自扩展用例的可选行为。看一下下面的用例图示例。它显示了扩展连接器和扩展点“搜索”。
用例示例-泛化关系
泛化关系意味着子用例继承了父用例的行为和含义。子级可以添加或覆盖父级的行为。下图通过显示在三个用例之间连接的两个泛化连接器提供了一个用例示例。
业务用例视图
业务用例视图使用业务主角和业务用例展示业务建模的结果。大多数情况下，业务用例视图需要从业务主教和业务模型两个视角进行展示。
业务主角视图
从业务主角视角来展示业务主角在业务中使用哪些业务用例来达成业务目标。这个视角有利于线业务主角确认其业务目标是否已经齐全。
如Demo_01所示，这个视图的含义是借阅人业务主角在借书管理系统中有借阅图书和办理借阅证两个业务目标。
如果业务主角认为其所有目标都已经齐全，则认为针对此主角的业务用例定义完成。
业务模块视角
从业务模块视角来展示业务领域的业务目标，将参与了达成这一目标的业务主角与业务用例展现在这个视图中。这个视角有利于从业务的完整性角度出发。检查完成某个业务的所有业务主角和业务用例是否已经齐全了。从而来检查是否有遗漏的业务用例没有发现。
Demo_02就是业务用例视图之业务视角。
这个视图的含义是这些主角和业务用例完整的概括了结束业务的业务目标。如果这项业务能够被这些业务视角和业务用例完整的说明，则认为针对这个业务模块的业务用例定义完成。
业务用例实现视图
业务用例实现视图展现用例有哪些实现途径。
业务用例是业务需求，而业务用例实现则是业务的实现途径。从软件工程的角度说，这个视图展现了需求的可追溯特点。在实际的开发中，如果一个业务用例只有一个实现途径，那么绘制业务用例实现视图是不不是那么重要。但是如果一个业务用例有多个实现途径。则应当绘制业务用例实现视图来组织实现业务的那些业务对象和业务过程。
Demo_03他的含义就是借阅人可以到图书馆借阅，也可以通过网上借阅,两个实现途径都达到了同样的的借阅图书业务目标。
如何去识别主角？
- 谁使用系统
- 谁安装系统
- 谁启动系统
- 谁维护系统
- 谁关闭系统
- 还有那些其他系统使用此系统
- 谁从该系统获取信息
- 谁向系统提供信息
- 目前还有什么自动塔身的事情
如何确定用例
识别用例，然后基于场景的启发过程通过询问每个参与者期望的外部可见的。可观察的价值来进行，在确定了您的参与者之后，可以询问一下问题确定用例
- 参与者希望从系统中获取什么功能？
- 系统是否存储信息，那些参与者将创建，读取，更新或者是删除信息。
- 系统是否需要通知参与者系统内部的变换。
- 系统必须知道任何外部的事情发生吗？那些参与者将这些事情告知了系统。
最后小Demo - 车辆销售系统
