用例图概述

用例图通过描述用户使用系统提供的某种服务实现一个目标的方式来说明系统的需求。用例图中的元素包括：“用例（UseCase）”，它表示系统提供的功能或能力；“执行者（Actor）”，表示一类用户，或者其它的外部系统、环境对象；“主题（Subject）”，代表系统。图中的主要关系是“执行者”和“用例”之间的关联关系，称为“通讯路径”，表示执行者和主题之间发生的通信，以实现与用例相关的功能。

用例图中的主要元素“用例”和“执行者”都是一种类目（Classifier，所有类的基类）。这些“类目”一般是放在系统模型的一个包中。所以，用例图代表的元素（用例图的外框）一般是一个“包（Package）”。建立用例图，在模型浏览器中选择一个“包”元素，然后在它下面建立一个用例图，用例图中新增加的“用例”、“执行者”默认是挂在这个包下面。系统中每级产品都可以进行用例分析，而每级产品都可能有很多个用例。系统级的用例称为顶层用例。

下图是一个车辆系统的用例图（来自SysML1.6标准附录D图D.05），图中包括“操作车辆”、“保险车辆”、“注册车辆”和“维修车辆”四个用例，每个用例涉及不同的执行者，图中的方框（用例的主题）代表SUV车辆系统（HybridSUV）。

用例（UseCase）

用例（UseCase）是说明系统功能需求的一种方法。通常用一个动词短语说明系统能够做什么。用例的名称应该从用户的角度，而不是从系统的角度。或者说作为用例名称的动词短语的主语应该是用户。用例的标识法是一个椭圆形。

用例分析是开展系统详细需求分析的一个步骤。在开展系统详细需求分析时，从用户使用系统的目的、场景出发，抽取出系统的用例，也就是用一个动词短语概括出用户使用系统完成的一件事情。识别用例的时候，需要考虑用例的“粒度”。一个系统的用例的数量，可能从几个到几百个。一个用例以能够说明一件完整的事情、一个完整的事件流或者用户和系统之间一次完整的交互为宜。用例有如下几个特性：

（1）独立性。同一层次的用例不需要与其它用例交互而独立完成执行者的一个目的。用例之间没有顺序关系。有执行顺序关系的功能应该合并到一个用例中。但是同层的用例可能会有包含相同的操作，这些相同的操作可以单独提取出来作为一个用例，通过“包含”关系包含到其它用例中。

（2）用例的执行结果对执行者来说是可观测和有意义的。

（3）用例表示的事情必须由执行者发起，不存在没有执行者的用例。

用例不是“功能”。在MBSE的模型中，“功能”（Function）一般对应的元素类型是“活动”（Activity）。当进行系统的功能分析的时候，以及对功能进行分解，建立系统中多层的功能、子功能元素，应该使用“活动”而不是用例。

用例也不是“需求”。“需求”（Requirement）也是SysML语言中的一种元素，专门用于模型中需求的表示（下一篇文章我们将专门的来讲需求）。

“用例”在UML语言中也是一种“类”（BehavioredClassifier，行为类目），就是可以包含“行为”的类。“活动”是一种行为，所以“用例”可以包含“活动”（在软件中建立“活动”或其它行为元素和用例的关系，可以在模型浏览器中通过右键菜单给用例元素添加“拥有行为”）。

用例分析也是需求分析中的一个步骤，它用于对“文字”描述的“需求”进行细化。细化的方法就是建立用例自己的“行为”元素及图（除了给用例添加“活动”之外，也可以使用“交互”或“状态机”及它们对应的图来对用例进行详细的说明）。

执行者（Actor）

执行者（Actor）（也翻译为“参与者”）表示和系统有交互的用户或外部系统扮演的角色。触发用例的执行者叫做“主执行者”。参与用例的执行者叫做“次执行者”。作为执行者的“人”一般用“火柴棍人”作为模板，而外部系统一般用类似“模块”节点模板的方框，方框上面显示构造型“执行者”（actor）。

在UML语言中，执行者也是一种“行为类”（BehavioredClassifier）。所以“执行者”也可以通过“泛化”（Generalization）为用户的“角色”类型进行多层次的建模。“执行者”只能和“用例”、“模块”（UML中包括类“Class”和组件“Component”）之间建立关联关系（Association）。在“执行者”和“用例”之间的关联关系称为“通信路径”。

执行者可以有属性和行为特征。在分析和执行者相关用例的行为的时候，行为中有些活动是“用户”执行的操作，有些活动是“系统”要执行的功能。例如柜员机“取钱”用例的活动中，“插卡”是用户的活动，“输入密码”也是用户的活动；而“验证密码”、“审核余额”、“吐钱”是柜员机系统的活动。

主题（Subject）

“主题”（Subject）代表拥有用例的系统。“主题”的表示法是一个矩形框，所有用例画在矩形框的内部，所以主题又称为“系统边界”。

当建立代表系统的“模块”元素之后，可以把这个系统模块和主题关联起来，主题矩形框的上面显示系统模块的名称。

通信路径（Communication path）

“通信路径”是一个双向引用关联（Association）元素。在“MBSE建模学习之二”这篇文章中，我们在介绍模块的属性的时候，介绍过模块之间的三种关联关系。双向引用关联会为被关联的模块生成引用属性。所以“通信路径”会为“执行者”和“用例”生成对应的属性，表示“执行者”的用例是啥，以及“用例”的执行者有哪些。可以为“通信路径”两端的属性节点指定对应的属性名称。在执行者这一端的属性可以指定多重性，表示执行用例的执行者的数量范围。

用例的进一步说明

（1）基础用例

基础用例是通过通信路径和主执行者连接在一起的用例。

（2）包含用例

如果多个基础用例的行为中有相同的行为，可以为这部分行为建立一个共用的用例。这个共用的用例用一个“包含”（include）关系和基础用例连接起来（从基础用例指向包含用例），表示这个包含用例将会在基础用例中执行。如果用例不是在多个基础用例中共用，只在一个用例中使用，是没有必要建立包含用例的。

（3）扩展用例

扩展用例是一个用例在扩展点扩展出来的用例。一般是用一个“扩展”（extend）关系从扩展用例指向基础用例。如下图所示：

在这个图中，（飞船系统的）“交会对接”用例有一个“扩展点”。“交会对接”用例执行时，如果扩展条件“当自动方式失效”满足的时候，就会执行“手动对接”用例。

用例分析的示例

下面我们用一个农业采摘机器人系统的案例来说明用例分析的过程。

（1）利益相关者需求

对这个机器人系统，有如下的功能需求，表格表示如下：

（2）用例图

系统中的执行者“果农”和“果树”我们应用SysML中“模块”构造型，将其建模为“模块”。这样做的好处是“模块”扩展了“类”的属性类型，可以有接口，节点的模板可以显示图片等、各种分区等更丰富的内容，以及可以进行行为的仿真。这些对于系统“用户”的行为分析更方便。

系统的用例图如下，“采摘果实”用例是“果农”发起的一个事情。从果农的角度，这个用例将给“果农”带来收到“果实”这个目标。

（3）用例场景分析

对于“采摘果实”这个用例，我们为它增加一个“采摘果实用例场景”的活动（在模型浏览器上，选择用例，通过右键菜单添加“拥有行为”），通过这个活动的活动图，我们分析这个过程系统需要哪些功能。

在这个活动图中，每个“动作”都使用了“调用行为动作”，对应一个表示功能的“活动”。整个活动场景，表示“果农”对“采摘机器人”进行“开机”操作，然后“采摘机器人”行走到果树旁，识别成熟的果实，摘下果实，然后放入收集框，（当收集框果实达到上限）运送果实到收集点，由“果农”把果实从机器人中收集，完成一次采摘过程。活动图如下所示：

（4）设置需求的跟踪关系

通过一个需求关系矩阵，我们设置用例行为分析中的“活动”对“功能需求的”改善关系，如下图所示：