MBSE建模学习之七：用例和用例图的说明

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

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

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

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

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

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

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

（3）用例表示的事情必须由执行者发起，不存在没有执行者的用例。 用例不是“功能”。在MBSE的模型中，“功能”（Function）一般对应的元素类型是“活动”（Activity）。当进行系统的功能分析的时候，以及对功能进行分解，建立系统中多层的功能、子功能元素，应该使用“活动”而不是用例。

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

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

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

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

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

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