MBSE学习详细汇总介绍

1.MBSE是什么？有什么用？怎么学习？

 “MBSE”是“基于模型的系统工程”的英文“Model-Based Systems Engineering”的首字母缩写。从字面意思能看出MBSE这个概念有三个核心的概念“系统”、“系统工程”、“基于模型”。 

在没有使用MBSE技术之前，“系统工程”工作成果就是一堆的“文档”。这些文档也是电子化的，只不过它们都是“非结构化”的数据，不能称为“模型”数据。相比“基于文档的系统工程”方法，MBSE方法具有很多优势。

 MBSE技术已经成为系统工程师必须掌握的基本知识。有些单位甚至要求设计师持证上岗。至于怎么学习MBSE技术，最简单的方法，那就是找一个软件来直接上手使用。结合自己的产品，一边用、一边学。不管是要学习还是课题，都可以了解智睿思维的MBSE软件——MBSES，目前CSDN中很多学习科普类文章都是来源于智睿思维官网。

2.模块（Block）

MBSE主要的建模语言UML/SysML是面向对象的语言。SysML（Systems Modeling Language，系统同建模语言）是对UML（Unified Modeling Language，统一建模语言）的扩展。在UML中最重要的概念是“类”（Class）。SysML中，对“类”进行了扩展，称为“模块”（Block）。MBSE的建模工作，可以说就是把要设计的系统及其各部分抽象为“模块”的过程。模块的主要用途是说明系统的架构。这个“模块”可以代表任何级别的产品。模块与模块之间可以有继承关系（或称泛化关系，父类泛化子类，子类继承父类）、组合或引用关联关系等等。

3.属性（Property）

“属性”（Property）是一种元素，它表示类的一个属性（attribute），或者一个关联（Association）的成员端（memberEnd）；或者某些情况下同时都是。

先说说“Property”这个词的翻译，我们习惯把它翻译为“属性”，这个和“attribute”的翻译相同。“attribute”不是UML中的一种元素，它只是普通的一个词语；另外，“类”（Class）有“Attributes”这个属性，也就是它的所有“Property”。所以UML类图中，表示方框的“类”有分区的名称是“attributes”。为了区分“Property”和“attribute”，有些书中把“Property”翻译为“特性”。不过，在程序员中，已经很习惯把“Property”称为“属性”。所以我们还是按习惯把“Property”翻译为“属性”。两者区别不大。真要说相同和区别的话，如第一段中对“Property”的定义，就是当“Property”是一个类的“attribute”的时候，可以说两者相同，指的是同一个概念；当“Property”仅仅是一个关联关系两端的成员（memberEnd）时，这时候不能叫“attribute”。

产品的组成是有层级关系的。结合产品的模型，“属性”这个概念可以理解为下层产品的实例在上层产品实例中的名称及其它定义。“属性”可以指父级产品中具体的某一个下级产品，也可以指类型相同的一组产品。“属性”的类型除了具体的产品，也可以只是一个数据类型。在SysML标准中，表示产品的“模块”（Block）主要有四种类型的“属性”。“部件”（parts）、“引用”（references）、“值属性”（value properties）、“约束属性”（constraint Properties）。“部件”的类型一定是另外一种“模块”，而且聚合类型是“组合”；“引用”属性的类型也必须是“模块”，而且聚合类型是“共享”或无；“值属性”的类型是“值类型”（ValueType）;“约束属性”的类型必须是“约束模块”（ConstraintBlock）。

4.行为（Behavior）

“行为”（Behavior）是一种通用的动态模型元素。具体的行为元素主要包括“活动”（Activity）、“状态机”（StateMachine）和“交互”（Interaction），它们分别以“活动图”、“状态机图”和“序列图”的方式说明一个行为的过程。这三种图的具体说明我们将在后期的文章中进行说明，这里先讲讲通用行为的概念，以及行为和作为系统结构说明的元素“模块”、需求说明的元素“需求”之间的关系。

“行为”是系统状态随时间变化过程的描述。“行为”代表系统的一种功能，它有输入、输出，它的功能就是把输入转换为输出。在这个转换过程中，可能伴随系统本身状态参数的变化。在设计一个系统的时候，很重要的工作就是设计系统有什么功能、怎么实现这些功能。所以，进行系统行为模型的分析是建模工作的关键内容之一。在对一个新产品进行建模的时候，一般是遵从“需求分析”—“功能分析”（行为分析）--“架构设计”这个大的基本过程。“需求分析”阶段，通过建立系统“功能需求”元素（FunctionalRequirement，它是SysML标准中一个扩展的需求元素）确定功能目标。然后通过建立相应的行为元素及其图形细化这些功能需求（功能需求只能通过一个行为元素来满足）。最后在确定系统架构模型时，将这些行为分配给具体的“模块”（作为模块的“拥有行为”）。

“行为”元素可以放在模型中专用的一个包下面，也可以直接放在具体的某个“模块”下面。

在UML语言中，“行为”也是一个“类”（Class）。相应的在SysML语言中，具体的行为元素（活动、交互和状态机）都是类的扩展元素“模块”(Block)。UML\SysML标准遵循了面向对象的设计概念，这世界上一切都是“对象”（Object）。“对象”是类的实例，也就是说世界上的一切对象都是某个类的实例。“行为”也是一个类，行为的一次“执行”就是这个类的实例。当然，行为是一种特殊的类，它有类的基本特征：可以有属性和操作，而且它还多出来很多描述动态过程的东西（具体的行为元素描述动态过程的方法不同，具有的子元素不同）。可以说“行为”元素是在“类”的基础上增加了描述动态过程的内容。

在SysML标准中，三种具体的行为元素“活动”、“状态机”和“交互”都是“模块”，所以它们可以像模块一样进行分解，把一个复杂的行为分解成小的、局部的或共用行为元素。这个过程也可以对应为设计分析中的“功能分解”过程。上层的行为元素和下层的行为元素都有各自的图形，例如在一个上层“活动图”中，通过一个“调用行为动作”，调用下层的活动元素（或其它行为元素）。

5.活动（Activity）

活动（Activity）是一种行为（Behavior）元素，它是行为元素的子类。首先活动是一个“类”（class）。SysML中，它也是一个模块（block），所以它有“类”的特征，可以有属性、方法，还可以有下层的“行为”元素，形成一个多层嵌套的行为模型。其次，活动是一个“行为”元素，有输入参数和输出参数。活动元素的特殊之处在于它可以包含各种可以说明一个行为过程的元素，包括“动作”（Action）、控制流（ControlFlow）和对象流（ObjectFlow），以及其它说明控制逻辑的节点。

活动可以用来说明系统的功能，活动以及它包含的子活动元素、活动中的动作元素，可以形成一个系统的功能结构树。在进行系统的功能分析的时候，它是重要的说明元素。

作为一个行为元素，活动可以作为一个模块（Block）的拥有行为，用于说明一个模块的功能。此外，活动也可以作为其它行为元素的更具体的说明。如，对一个用例（UseCase）进行更详细的说明，可以把活动元素作为用例的拥有行为（用例也是一种行为类BehavioredClassifier，可以拥有行为）进行说明；活动也可以作为状态机中的状态（State）的内部行为，或系统处于某个状态时进行的工作；活动也可以作为状态转移（Transition）的影响（effect），说明状态转移时发生的行为。

在“智睿思维基于模型的软件”（MBSES）中，你可以为一个模块增加拥有行为的时候，增加一个活动元素。也可以直接在一个包中增加一个活动元素。

UML\SysML是面向对象的语言，活动是一个说明具体行为过程的元素。可以说活动和它的活动图是用UML\SysML语言写的一段系统运行过程的“程序”。这段“程序”要有运行的语境（Context），也就是活动的过程可以读写的变量的范围。这个语境就是活动所属的模块。如果活动没有所属模块，那它自己就是自己的语境。在活动的过程中，可以读写它的语境中的属性（Property）、可以调用所属语境的其它行为（通过一个调用行为动作）。当然也可以调用（通过一个“调用操作动作”）另外一个模块的操作（Operation）、接收（Reception）,但必须通过当前模块的一个部件（part）属性或引用（reference）属性。这是面向对象语言的“封装”性原则所规定的，这个原则使我们定义的系统模型中功能调用关系是清晰的、范围可控的。

6.交互(Interaction)和序列图

交互（Interaction）是一种具体的行为元素，它用对象之间消息传递的方式说明行为发生过程的顺序和互相传递的信息。对交互进行说明的图主要是序列图（Sequence Diagram, 在UML标准中还有使用时间图、通讯图或交互概览图对其进行说明，SysML标准只使用序列图）。

作为一种行为，交互也是具有行为的基本特征：具有输入参数、返回参数；它可以作为一个模块（Block）或其它行为类目（BehavioredClassifier）的拥有行为（OwnedBehavior）;它可以作为一个操作（Operation）、接收（Reception）的“方法”（Method）；

和活动（Activity）一样，交互同时也是一个模块（Block）。一个复杂的交互行为可以进行分解。在上层的交互行为中，通过一个“交互使用”（InteractonUse）元素表示对下层或其它交互的调用。

作为行为，交互的发生一样需要规定发生的语境（Context）。如果交互是某个模块的拥有行为，则这个模块是交互行为的语境；否则它自己是它的语境。说明交互的序列图中的元素都是它的语境范围内的元素。

7.状态机（StateMachine）和状态机图

状态机（StateMachine）用于表示事件驱动的行为。在状态机图中，用系统的不同状态之间事件驱动的转移机制来说明一系列的行为发生过程。它一般作为一个模块（Block）的类目行为（ClassifierBehavior）。类目行为是一个类（如模块）从开始工作，一直到结束的整个过程的行为。一个模块只有一个类目行为。它也可以作为模块的一个普通的拥有行为（OwnedBehavior），表示模块的一种功能。

和活动（Activity）一样，状态机同时也是一种模块（Block）元素。一个复杂的状态机行为可以进行分解。在上层的状态机行为中，通过一个“子机状态”（SubmachineState）元素表示对下层或其它状态机的调用。

作为行为，状态机的发生一样需要规定发生的语境（Context）。如果状态机是某个模块的类目行为或拥有行为，则这个模块是状态机的语境；否则它自己是它的语境。状态机中的状态的内部行为（entry、do及exit）如果没有明确的语境，则它们的语境是这个状态机的语境。

状态机是通过状态机中的状态（State）以及状态是如何转换的来说明系统的行为过程。状态机中的状态（State）和转移（Transition）不像活动图中的动作（Action），它们本身并不说明究竟这个行为是如何把一个输入的信息（或其它物质）转为输出的信息（或其它物质）。（动作—Action中，可以通过语句或专用的动作类型来说明对象的生成、变换或删除等）但是，在状态和转移中可以包含其它行为（如一个活动），它可以用它包含的行为来说明具体是转换的细节。状态机更像是把系统的行为串联起来的一种作用，它着重展现的是系统在这个行为之间所处的状态，以及状态是在什么时机，或通过什么机制来转换的（这个时机被定义为触发器，这个机制是触发器的事件）。所以它适合作为系统的整个工作过程的总体说明，例如用来说明系统工作的任务阶段说明。

8.用例（UseCase）和用例图

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

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

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

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

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

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

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

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

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

9.需求（Requirement）和需求图

需求（Requirement）是一个系统必须或应该满足的能力或条件。当设计一个产品的时候，最初产生的设计概念或要求都是用文字描述和交流的。这些文字化描述的需求最终需要落实到每个设计细节。SysML通过建立文字化的需求元素，以及这些需求元素和系统中其它设计元素（表示功能的行为、表示架构的模块等）的关系，以实现设计过程对中文字化需求的跟踪分析。这种跟踪分析的工作包括需求实现情况的分析（需求覆盖分析）、变动之后对设计的影响分析（需求变更分析）等等。

        根据需求说明的对象不同，需求分为“利益相关者需求”和“系统需求”。“利益相关者需求”是反映利益相关者需要的表述，是从用户或其它使用系统的相关人员（包括维护人员、市场人员等）的角度，系统应该向他们提供什么。“系统需求”是系统将要做什么以及必须做到什么程度的表述，是从实现的角度，主要讲给内部设计人员的。需求分析的过程，是先有利益相关者需求，然后经过分析、总结，才产生系统需求。

10.参数图（ParametricDiagram）及其仿真

参数图是SysML增加的一种专门用于系统参数计算的图。参数图本质上是一个特殊的内部模块图，它主要表示模块的约束中的参数和模块的属性之间绑定关系。这里“绑定”的意思，可以理解为变量的“代入”。参数图中通过绑定连接器把值属性和约束的约束参数连起来，参数图仿真的时候就把值属性的值代入到约束的表达式方程中进行计算，并把计算结果返回到对应的属性。不过这个“属性值”和“约束参数值”代入计算、结果再返回到“属性值”的概念，是通过仿真过程类型的实例化、属性（property）生成“槽”（slot），对“槽”赋值来实现的。以下我们通过参数图中的各种元素的意义、仿真的实际过程来说明这个原理，以及如何进行仿真。

11.包图（PackageDiagram）及模型扩展

包图是定义模型架构的图。模型的架构主要是通过“包”（Package）来组织的。包图的代表元素是一个“包”元素（元素-Element，是指模型中任何一种数据），图中定义的元素默认的命名空间就是这个包。除了“包”之外，包图的代表元素也可以是一个“模型”（Model）、“模型库”（ModelLibrary），或者是一个“概要文件”（Profile）元素。

包图经常用来定义整体的模型架构，也就是模型的层级关系。这种情况下，包图中一般显示的元素是各层级的“包”或其它作为类型的元素。也可以在包图中直接定义各种类型元素，例如通用的“模块”（Block）、“值类型”（ValueType）、“接口模块”（InterfaceBlock）等。这时候，包图和模块定义图的作用并没有太大差别（模块定义图的代表元素一般也是一个包）。在智睿思维基于模型的系统工程软件中，你只需要切换包图的默认图形工具栏为模块定义图的工具栏，就可以在包图中添加各种类型。另外，包图也可以定义扩展标准模型元素的构造型，为标准元素添加建模时的构造型属性。

12.MBSE方法论及MagicGrid方法

方法论，即方法的理论。宏观上讲，是人们认识世界、改造世界的方法的理论。MBSE方法论，是如何应用建模语言，按照什么样的流程建立系统模型，以实现建模目的一套通用的理论方法。每种MBSE方法，涉及到用什么建模语言、建模流程、模型的基本架构等等。而且，由于MBSE的建模方法要通过软件工具实现，所以和具体的软件工具也是紧密相关的。首次提出方法论的公司、机构也都希望自己的方法能够成为行业的主流方法，并不排斥其它公司的软件实现自己提出的方法。所以，同一种方法是可以在多个软件中应用和实现的。MBSE方法论是MBSE技术三大支柱之一。

MagicGrid是No Magic公司(被达索收购)提出的基于SysML的MBSE方法论。Magic Grid建模方法基于SysML语言，支持SysML语言的建模工具都可采用。

MagicGrid建模方法基于框架来表达，框架可以表示为一个矩阵表格（这个矩阵表格的方法来源于体系工程的提出者Zachman提出的表格。智睿思维基于模型的系统工程软件已经支持DoDAF等体系工程建模）。