当前位置:首页-文章-MBSESysML-正文

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):无箭头实线。
SysML 用例图(Use Case Diagram) - 第1张
图1 SysML用例图示例

2.2、用例之间的关系

  • 1)用例间的关系之泛化(generalization)
  • 用例间的泛化关系表示一种继承,是从抽象到具体的一种演化。子类型的用例继承父用例的内容,并在此基础上进行重新定义或添加新的父用例不具备的关系或行为。在SysML中,泛化关系采用带空三角箭头的实线表示。如图2所示。
SysML 用例图(Use Case Diagram) - 第2张
图2 用例之间的泛化关系
  • 2)用例间的关系之包含(include)
  • 包含(include)关系在SysML中的标识法是带有箭头的虚线,并注有<include>关键字。“被包含” 的用例位于关系的尾端,即箭头端。
SysML 用例图(Use Case Diagram) - 第3张
图3 用例之间的包含关系
  • 用例间的包含关系表示的是:当某用例被触发时,其包含的用例也会执行。被包含的用例作为其他用例的一个组成部分存在。
  • 注意: 包含关系虽然表达了用例间的组成关系,但用户切记不要急于包含关系对系统做功能分解。这是用户在使用用例建模时经常出现错误。用例不是功能,用例使用功能而已。因此基于用例实现功能分解是不合适的。另外,到底什么时候定义包含用例?包含用例的定义不是必然的。创建包含用例的原则是当多个用例具有一些公共的子行为时,一般会将这些公共行为创建为包含用例。而且,这些往往不是在系统设计的初始迭代就做的事情,而是系统建模开始时,仅构建基础用例,并对用例进行详细的说明(例如,定义用例说明书),随着用例的不断明确,公共子行为自然显现出来,此时再定义包含用例时合理的。
  • 3)用例间的关系之扩展(extend)
  • SysML中用例扩展(extend)关系的标识法是带箭头的虚线,并注有<extend>关键字。扩展用例位于扩展关系的尾端(非箭头端)。扩展关系表述的是一种可选的公共行为。当用例触发时,它的扩展用例是可选的执行(与包含用例不同)。
SysML 用例图(Use Case Diagram) - 第4张
图4 用例之间的扩展关系
  • 扩展关系表述的是对可选行为的建模。当多个用例具备通用的可选行为时,可以将这些通用行为重构为扩展用例。

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用例图来帮忙捕获系统需求。

所属专题:

本文原创,作者:Modeler。
如需转载,请注明出处:https://modelbaba.com/mbse/510.html

相关文章

换一批