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

     

用例图概述

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

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

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

                          

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


用例(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)关系从扩展用例指向基础用例。如下图所示:

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

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

用例分析的示例

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

1)利益相关者需求

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


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

2)用例图

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

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

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

3)用例场景分析

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

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

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

4)设置需求的跟踪关系

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

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

文章来源:智睿思维MBSE

MBSE系统工程

MBSE建模学习之七:用例和用例图的说明的评论0条

    暂无评论

    MBSE建模学习之七:用例和用例图的说明的相关视频课程

    MBSE建模学习之七:用例和用例图的说明的相关案例教程

    本篇属于基于模型的系统工程(MBSE)专题系列第03篇内容,我们聊聊MBSE方法论之Arcadia相关内容,个人认为也是在汽车领域相对应用最广泛的方法论之一,非常值得学习。 阅读之前强烈建议参考之前系列文章: 为什么MBSE是系统复杂性应对之道 02 - MBSE系列: 方法论之OOSEM 在上一篇文章,我们聊到了MBSE方法论之OOSEM,包括其基本概念,建模语言,开发流程,逻辑架构的重要性等。
    Capella to SysML Bridge: A Tooled-up Methodology for MBSE Interoperability,Nesrine BADACHE, ARTAL Technologies, nesrine.badache@artal.fr,Pascal ROQUES, PRFC, pascal.roques@prfc.fr 模型到模型的转换是基于模型的系统工程 (
    1 业务流程 在系统研发尤其是复杂系统研发过程中,概念设计已经越来越显示出其重要性,因为只有真正做好概念设计,才可以摆脱逆向设计思想,采用真正的正向设计方法和手段。另外,传统的基于文件的系统工程已经难以驾驭需求定义、功能定义、架构设计、方案设计、方案权衡等过程,基于模型的系统工程为解决复杂系统的设计问题提供了有效途径,尤其是解决需求定义、功能定义、架构设计等这些概念设计必须解决的问题。 RFLP(
    基于模型的系统工程MBSE的三大支柱,大家都非常熟悉:语言、方法和工具。这里,我们介绍的ARCADIA,同时提供了一种建模语言和一种建模方法。 图1: 基于ARCADIA/Capella的MBSE三大支柱 ARCADIA建模方法 ARCADIA(架构分析和设计集成方法)是一种基于模型的系统、硬件和软件架构设计工程方法。由Thales公司于2005年至2010年期间开发,该方法经过了一个迭代过程,涉
    引言 系统工程是一种多学科和整体的方法,为复杂的工程问题开发解决方案。随着系统复杂性的不断增长,需要更加严格和形式化的系统工程实践。为了满足这种需求,以及计算机技术的进步,系统工程实践正在经历从基于文档的方法到基于模型的方法的根本性转变。在基于模型的方法中,重点从生成和控制关于系统的文档转移到生成和控制系统的一致模型。基于模型的系统工程(MBSE)可以帮助管理复杂性,同时提高设计质量和周期时间,增
    影响力
    粉丝
    内容
    获赞
    收藏
      项目客服
      培训客服
      0 0