以下图例皆使用了在线UML制图网站 Freedgo Design，其访问地址为： https://www.freedgo.com

freedgo Design 是一个多种类型图表的在线绘制软件，让您创建阿里云架构图腾讯云架构图 PostgreSQL云架构图 AWS系统部署图软件架构图, UML，BPMN，ERD，流程图，UX设计图,ANT DESIGN，思维导图，图表。可以做到注册用户免费使用。

** 具体参考在线制图网站关于UML设计图例： http://www.feedgo.com/showcase.html **

用例图

用例描述了用户如何使用系统来实现特定的目标。用例图由系统、相关的用例图和参与者组成，并且将它们相互联系起来.
用例图可视化的描述如下:

System: 要实现什么;
Actor：谁在使用系统；
用例: Actor想到实现什么；

因此，用例图是通过从用户的角度捕获需求来开发正确的系统。

UML中的实现

用例图描述了一系列动作或事件步骤，通常定义了参与者和系统之间为实现某种目标而进行的交互。
用例图可以有效的识别、阐述系统需求。
用例由系统和用户之间一系列可能的交互组成，这些交互定义了要实现的功能以及可能遇到的任何错误的解决方案。
虽然用例本身可能会深入到每一种可能性的许多细节(例如，事件和场景的流程)，但是用例图可以帮助提供系统的更直观的视图，提供系统实际必须做什么的简化和图形化表示。

用例图具有以下特征:

功能需求
系统与参与者之间交互的模型
描述一个主要的事件流(主要场景)和可能的其他异常流(可选)，也称为路径或用户场景

用例图的符号

用例定义外部参与者和系统之间的交互，以达到特定的目标。用例图包含四个主要组件：

Actor

参与者通常是根据角色定义的参与系统的个人。Actor可以是用户或其他外部系统。

Use Case

用例描述了参与者如何使用系统来实现特定的目标。用例通常由用户发起，以实现描述实现目标所涉及的活动、步骤过程。

RelationShip

参与者和用例之间的关系

System Boundary

系统边界定义了系统与外部世界边界。

用例图作用

用例是获取和记录黑盒功能需求的强大技术。
因为用例很容易理解，并且提供了一个很好的方法来与客户和用户交流，因为它们是用自然语言编写的。
用例可以通过将问题划分成主要的用户特征(即用例),并从用户的角度指定应用程序来帮助管理大型项目的复杂性。
通常由序列图表示的用例场景涉及多个对象和类的协作，用例图有助于识别将对象和类粘合在一起的消息(操作和所需的信息或数据参数)。
用例为更高级模型的验证(即参与者和一组协作对象之间的交互)和随后的功能需求验证(即白盒测试)提供了良好的基础。
用例驱动的方法为项目跟踪提供了可追踪性，其中关键的开发活动，例如实现、测试和交付的用例，从用户的角度实现了目标和目的。

用例图的使用

用例图的开发步骤如下：

确定系统的参与者(用户角色)。
对于每一类用户，确定与系统相关的用户所扮演角色。
确定用户要求系统执行哪些操作来实现这些目标。
为每个目标创建用例。
构建用例。
对用户进行优先排序、审查、评估和验证

注意:为了更加“敏捷”的使用用例图，不要详述所有用例，而是对它们进行优先排序，您应该根据开发阶段在不同的细节层次上细化用例

用例图设计也可以：将用例逻辑分类的包绘制到相关子系统中

用例图结构

UML定义了用例之间关联的三个原型:

`<<include>> Use Case`

使用<<include>>是在您完成对所有主要用例之后。

`<<extend>> Use Case`

扩展用例实际是基础用例的一个替代过程。<<extend>>用例通过在基本用例序列中概念性地插入额外的动作序列来实现这一点。

`Abstract and generalized Use Case`

通用用例是抽象的。它无法实例化，因为它包含不完整的信息。抽象用例的标题用斜体显示

例子

这个例子描述了几个业务用例(目标)的模型，它代表了一个餐馆(业务系统)和它的主要参与者之间的交互。
在第一轮中确定了基本用例之后，也许我们可以在第二轮用<<extend>>和<<include>>进一步构建这些用例，

如下图所示:

业务用例图

业务用例是用无技术术语描述的，它将业务流程视为一个黑匣子，并描述其业务参与者使用的业务流程，
而普通用例通常在系统功能级别描述，并指定系统为用户提供的功能或服务。
换句话说，业务用例代表了在当前情况下如何手动完成工作，它不一定是由系统完成的，也不打算在目标系统的范围内自动完成。

用例图例子