SysML 用例图（Use Case Diagram）

1、什么是用例

用例一直被视为一种根据系统的使用来捕获系统需求的机制，它指定了系统的预期行为（什么），而不是使其发生（如何）的确切方法。因此，它是系统的黑盒视图，非常适合用作系统上下文图。

用例一旦确定，就可以进行文本和可视化表示（即用例图，Use Case Diagram）。用例建模的一个关键概念是它帮助我们从最终用户的角度设计系统。 通过指定所有外部可见的系统行为，它是一种以用户的方式传达系统行为的有效技术。

2、认识用例图

2.1、用例图主要模型元素

用例图传递了一系列的用例，那么在SysML中用例图如何表述呢？图1是一个SysML用例图示例，展示了四种主要的模型元素：

• 1）系统边界框（System Boundary）：矩形框表示，用于定义系统的范围。
• 2）参与者（Actor）：人形图标或带有<>关键字的矩形图标都可以表示参与者，一般习惯于使用人形图标。参与者可能是用户，也可能是其他系统，本用例图包含四个参与者。
• 3）用例（Use Case）：椭圆形图标，并带有用例名称。本用例图包含 2 个用例。
• 4）参与者与用例间的关系（Association）：无箭头实线。

2.2、用例之间的关系

• 1）用例间的关系之泛化（generalization）
• 用例间的泛化关系表示一种继承，是从抽象到具体的一种演化。子类型的用例继承父用例的内容，并在此基础上进行重新定义或添加新的父用例不具备的关系或行为。在SysML中，泛化关系采用带空三角箭头的实线表示。如图2所示。

• 2）用例间的关系之包含（include）
• 包含（include）关系在SysML中的标识法是带有箭头的虚线，并注有<include>关键字。“被包含” 的用例位于关系的尾端，即箭头端。

• 用例间的包含关系表示的是：当某用例被触发时，其包含的用例也会执行。被包含的用例作为其他用例的一个组成部分存在。
• 注意： 包含关系虽然表达了用例间的组成关系，但用户切记不要急于包含关系对系统做功能分解。这是用户在使用用例建模时经常出现错误。用例不是功能，用例使用功能而已。因此基于用例实现功能分解是不合适的。另外，到底什么时候定义包含用例？包含用例的定义不是必然的。创建包含用例的原则是当多个用例具有一些公共的子行为时，一般会将这些公共行为创建为包含用例。而且，这些往往不是在系统设计的初始迭代就做的事情，而是系统建模开始时，仅构建基础用例，并对用例进行详细的说明（例如，定义用例说明书），随着用例的不断明确，公共子行为自然显现出来，此时再定义包含用例时合理的。
• 3）用例间的关系之扩展（extend）
• SysML中用例扩展（extend）关系的标识法是带箭头的虚线，并注有<extend>关键字。扩展用例位于扩展关系的尾端（非箭头端）。扩展关系表述的是一种可选的公共行为。当用例触发时，它的扩展用例是可选的执行（与包含用例不同）。

• 扩展关系表述的是对可选行为的建模。当多个用例具备通用的可选行为时，可以将这些通用行为重构为扩展用例。

2.3、参与者之间的关系

SysML还支持参与者间的泛化关系，表示方式带有空三角箭头的实线，父类型位于箭头端。同样，泛化关系所表达的含义同样适用于参与者间的泛化关系。泛化意味着继承，泛化意味着抽象，子类型会继承父类型的上下文。

2.4、用例与场景之间的关系

场景是用例执行的路径，用例从开始执行到结束可以定义为一个 “场景”。由此，用例和场景间是 “一对多” 的关系。场景有很多，不仅仅局限于用例执行成功的场景，当然也包括用例执行过程中出现的各种异常场景。

当描述用例的场景时，发现某个用例的成功的场景太多，则这要引起注意，可能是用例定义的粒度太大，导致成功场景（执行路径）太多。因此，要适当拆分，尽量保证单个用例有一个主要的成功场景。

3、用例图设计

3.1、如何识别参与者

通常，人们通过识别参与者来开始需求获取过程是最容易的。 以下问题可以帮助您确定系统的参与者：

• 1）谁在使用系统？
• 2）谁来安装系统？
• 3）谁启动系统？
• 4）谁维护系统？
• 5）谁关闭系统？
• 6）还有哪些系统在使用这个系统？
• 7）谁从这个系统中获取信息？
• 8）谁向系统提供信息？
• 9）目前有什么事情会自动发生吗？

3.2、用例图设计原则

• 1）首先构建基础用例，并细化用例说明书；
• 2）切记禁止使用用例实现功能分解（用例不是功能，用例调用功能）；
• 3）使用包含用例重构多用例的公共行为（必然执行）；
• 4）使用扩展用例重构多用例的可选的公共行为（可选的执行）；
• 5）大型系统的顶层基础用例典型的为 10 ~ 15 个，单个用例的用例场景数为 5 ~ 25 （来自IBM Harmoney SE）。
• 6、非成功场景超过 5 个，则重构为 “Exception use case”，并与主用例链接（来自IBM Harmoney SE）。
• 6）用例一般不包含系统性能以及UI；

4、总结

对于系统工程师来说，设计用例图是一种极为常见的建模活动。用例图是一种黑盒视图，通过向读者传递一系列的用例以及相关的参与者，对系统对外提供的服务或系统具备的行为进行建模。用例间具有泛化、扩展、包含三种关系。通过包含和扩展关系可以对系统通用行为进行重构。

通常情况下，我们在实际项目中还可以利用SysML用例图来帮忙捕获系统需求。