| 引言
对于系统工程师来说，设计用例图是一种极为常见的建模活动。用例图是一种黑盒视图，通过向读者传递一系列的用例以及相关的参与者，对系统对外提供的服务或系统具备的行为进行建模。在详细讨论SysML的用例图之前，我们先来了解一个非常关键的概念
- 用例。
什么是用例？
用例，英文为 “Use Case”，不同的书籍或论文资料对于 “用例” 有不同的定义，本文引用《Writing
Effective Use Case》一书中关于用例的描述：
A use case captures a contract between the stakeholders
of a system about its behavior. The use case describes
the system’s behavior under various conditions as
it responds to a request from one of the stakeholders,
called the primary actor. The primary actor initiates
an interaction with the system to accomplish some
goal. The system responds, protecting the interests
of all the stakeholders. Different sequences of behavior,
or scenarios, can unfold, depending on the particular
requests made and conditions surrounding the requests.
The use case collects together those different scenarios.
通俗的说，“用例” 是系统行为的黑盒描述，其阐述的是参与者（可能是用户，也可能是其他系统）的意图或对系统行为的期望，从参与者的角度对系统应该具备的行为进行建模。
用例表达方式？
用例可以采用基于模型和基于文本的方式进行表达。文本方式是传统的但广泛应用的方式，用户可以采用特定格式的文本段落或表格对用例进行详细描述。模型方式是未来的主要趋势，例如用户可以通过UML/SysML的模型图如用例图、活动图、时序图等对用例进行描述和细化。
不管基于哪种方式，用例的名称典型地会采用动词短语进行描述，例如 “存钱”、“取钱”、“发布文档”、“创建用户”等，这种概要性描述能够
“大致” 说明参与者的意图或者参与者希望系统执行的行为，虽然传递的信息非常关键但是有限，设计者不可能单从这些动词短语获取完备的信息。作为一种补充，一般会采用
用例说明书 （对于模型来说，可能是时序图、活动图等模型）对用例进行说明。典型地，我们可以采用基于文字的方式表达用例说明书。
《Writing Effective Use Case》一书中提供了示例形式，可以参考下图：
不同的文字表述形式的样式可能不太相同，具体选择哪种样式取决于用户。
初识SysML用例图
我们说，用例图传递了一系列的用例，那么在SysML中用例图如何表述呢？下面先睹为快。如下图所示，这是一个
“Security System” 系统的SysML用题图。图头部是SysML通用的头部结构，其中图类型为
“uc”，即用题图。用例图的内容区域部分展示了四种模型元素：
系统边界框：矩形框表示，用于定义系统的范围。
参与者：人形图标或带有<<actor>>关键字的矩形图标都可以表示参与者，一般习惯于使用人形图标。参与者可能是用户，也可能是其他系统，本用例图包含四个参与者。
用例：椭圆形图标，并带有用例名称。本用例图包含 2 个用例。
参与者与用例间的关系：无箭头实线。 
用例间的关系之泛化（generalization）
用例间的泛化关系表示一种继承，是从抽象到具体的一种演化。子类型的用例继承父用例的内容，并在此基础上进行重新定义或添加新的父用例不具备的关系或行为。在SysML中，泛化关系采用带空三角箭头的实线表示。如下图：
用例间的关系之包含（include）
包含（include）关系在SysML中的标识法是带有箭头的虚线，并注有<<include>>关键字。“被包含”
的用例位于关系的尾端，即箭头端。 
用例间的包含关系表示的是：当某用例被触发时，其包含的用例也会执行。被包含的用例作为其他用例的一个组成部分存在。
注意： 包含关系虽然表达了用例间的组成关系，但用户切记不要急于包含关系对系统做功能分解。这是用户在使用用例建模时经常出现错误。用例不是功能，用例使用功能而已。因此基于用例实现功能分解是不合适的。另外，到底什么时候定义包含用例？包含用例的定义不是必然的。创建包含用例的原则是当多个用例具有一些公共的子行为时，一般会将这些公共行为创建为包含用例。而且，这些往往不是在系统设计的初始迭代就做的事情，而是系统建模开始时，仅构建基础用例，并对用例进行详细的说明（例如，定义用例说明书），随着用例的不断明确，公共子行为自然显现出来，此时再定义包含用例时合理的。
用例间的关系之扩展（extend）
SysML中用例扩展（extend）关系的标识法是带箭头的虚线，并注有<<extend>>关键字。扩展用例位于扩展关系的尾端（非箭头端）。扩展关系表述的是一种可选的公共行为。当用例触发时，它的扩展用例是可选的执行（与包含用例不同）。
扩展关系表述的是对可选行为的建模。当多个用例具备通用的可选行为时，可以将这些通用行为重构为扩展用例。
参与者间的关系
SysML还支持参与者间的泛化关系，表示方式带有空三角箭头的实线，父类型位于箭头端。同样，泛化关系所表达的含义同样适用于参与者间的泛化关系。泛化意味着继承，泛化意味着抽象，子类型会继承父类型的上下文。
用例与场景的关系
场景是用例执行的路径，用例从开始执行到结束可以定义为一个 “场景”。由此，用例和场景间是 “一对多”
的关系。场景有很多，不仅仅局限于用例执行成功的场景，当然也包括用例执行过程中出现的各种异常场景。
当描述用例的场景时，发现某个用例的成功的场景太多，则这要引起注意，可能是用例定义的粒度太大，导致成功场景（执行路径）太多。因此，要适当拆分，尽量保证单个用例有一个主要的成功场景。
用例图设计原则
首先构建基础用例，并细化用例说明书；
切记禁止使用用例实现功能分解（用例不是功能，用例调用功能）；
使用包含用例重构多用例的公共行为（必然执行）；
使用扩展用例重构多用例的可选的公共行为（可选的执行）；
大型系统的顶层基础用例典型的为 10 ~ 15 个，单个用例的用例场景数为 5 ~ 25 （来自IBM
Harmoney SE）。
非成功场景超过 5 个，则重构为 “Exception use case”，并与主用例链接（来自IBM
Harmoney SE）。
用例一般不包含系统性能以及UI；
小结
用例图是一种黑盒视图，表征系统对外部参与者的可见行为或服务。用例间具有泛化、扩展、包含三种关系。通过包含和扩展关系可以对系统通用行为进行重构。 |
