【SysML】用例图

系统工程实验室

墨衍会员 · AI 创作全网分发码龄10年

关注

原创最新推荐文章于 2026-03-08 00:22:46 发布 1.6k 阅读 AI 写同款· GEO 优化 ›

SysML用例图建模规范汇总 用例图建模规范阅读详情

引言

对于系统工程师来说，设计用例图是一种极为常见的建模活动。用例图是一种黑盒视图，通过向读者传递一系列的用例以及相关的参与者，对系统对外提供的服务或系统具备的行为进行建模。在详细讨论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>>关键字。扩展用例位于扩展关系的尾端（非箭头端）。扩展关系表述的是一种可选的公共行为。当用例触发时，它的扩展用例是可选的执行（与包含用例不同）。