MBSE系列: 方法论之OOSEM

一起学MBSE 2023年6月12日浏览：1567

本篇属于基于模型的系统工程(MBSE)专题系列第02篇内容，我们聊聊MBSE方法论之OOSEM相关内容。

阅读之前强烈建议参考之前系列文章:

为什么MBSE是系统复杂性应对之道

在上一篇MBSE开篇文章，我们聊到了MBSE基本概念及其重要性，以模型驱动开发过程是MBSE核心内容，为了建立模型我们需要相应的方法论，建模语言以及工具。今天我们主要来聊聊MBSE相关的方法论。

所谓的方法论就是以解决问题为目标的一种通用理论体系，告诉我们以什么的方式，步骤或流程去解决问题。MBSE方法论其实比较多，业界不同企业或组织提出了不同的方法论，比较常见的包括:

OOSEM
Arcadia
Harmony SE
State Analysis
Object Process Methodology (OPM)
MagicGrid
Vitech

但不管这些方法论如何变化，其本质都是基于V模型，都是从系统需求获取及定义，到系统架构设计，再到详细设计及验证等，只是不同的方法论在这个过程中侧重点以及采取的方法不完全相同而言。

当然，并不是所有的MBSE方法论在汽车行业都有应用，我会挑几个比较有代表性，且比较有借鉴意义的方法论给大家介绍。

我们今天先来来聊聊MBSE方法论之OOSEM。

OOSEM核心

面向对象的系统工程方法(Object-Oriented Systems Engineering Method, OOSEM)是INCOSE提出的MBSE方法论，其核心特点在于:

需求的捕获，以需求为基础，建立架构模型。
SE基本方法论结合面向对象(Object-Oriented)的软硬件设计方法。

所谓面对对象的方法，就和我们学习的面对对象的编程思想一致，它和面向过程的方法相对，强调类的声明，继承，接口抽象等，将具有相似特性的个体进行抽象，封装，以此来降低系统复杂性，增强复用性。

举个简单的例子:

汽车有四个轮子，这四个轮子，组成，结构，大部分特性都一致，这时候我们只需要定义车轮这样一个父类，并定义其共有属性，不同的属性我们可以通过类的实化，得到具体的实体，这个实体继承父类特性，接口，操作等，这样就可以避免建立4个类似的对象，有效降低系统复杂性，增加复用性。

一般来说，面向对象的方法其实多用于具体软件和硬件的开发，在系统阶段虽然也有涉及，但没有那么明显，所以OOSEM核心的面向对象这部分内容个人认为更适合软件或硬件开发，正是因为这样，OOSEM有助于后续软硬件的集成和验证，有效降低集成及验证的工作量，其他部分内容基本和SE方法论保持一致。

OOSEM开发活动

OOSEM主要开发活动如下图所示:

MBSE系列: 方法论之OOSEM的图1

图片来源: INCOSE

其中，斜线下方是MBSE共有的或最基本的活动，斜线上方是OOSEM主要开发活动，该过程主要包括:

Stakeholder需求获取:

收集产品利益相关者，如用户，决策者，投资者，法规等，对产品的需求，包括了功能及非功能相关的产品需求，该需求通常通俗易懂。

系统需求获取:

根据Stakeholder需求，对其进行拆分细化，导出特定系统对应的需求。

系统逻辑架构定义:

对系统进行逻辑拆分，形成子逻辑系统，逻辑组件，以满足系统需求。

系统备选物理架构合成:

描述系统物理组成及联系，包括具体的软件，硬件，便于逻辑组件映射到系统物理架构。

为了支持上述OOSEM建模过程，INCOSE最初使用UML(Unified Modeling Language)作为其建模语言，但由于UML多针对软件开发，缺少对系统开发的支持，所以INCEO在UML基础上推出了面向系统的建模语言，即SysML(Systems Modeling Language)，以此来支持复杂系统的分析、定义、设计、和验证过程。

SysML是非常重要的统一化建模语言，它定义了不同的视图类型，结构视图，需求视图，活动视图等等，每个视图包含不同的组件元素和相应的关系，例如: 关联，依赖，泛化，聚合，实现等，面向对象的建模思想也反映在建模语言中，可以很好地支持上述OOSEM建模活动。

上述提到的OOSEM活动都以UML或SysML建模为主。一般来说，:

需求获取或定义，多采用需求视图或用例图表达。
逻辑架构和物理架构多采用类图或结构视图表达架构静态关系，即组成，接口等，多采用流程图，活动图，状态图等表达架构动态关系。

具体细节在建模语言部分我们再聊。

此外，OOSEM还有一个特殊的地方，即从系统需求直接建立系统逻辑架构，根据系统需求对系统进行逻辑组件拆分，然后对逻辑架构进行应用场景分析，导出逻辑组件的功能，接口等。这和大部分MBSE方法论相比，稍微有点不同，大部分MBSE方法论都是通过对需求进行用例或场景分析，首先导出系统功能，然后依据系统功能建立逻辑架构。

其实这二者并不矛盾，很多时候逻辑组件和功能组件是等效的，很难区分。个人认为如果对系统结构组成比较熟悉，或已有逻辑架构，则可直接根据需求建立或补充逻辑架构。而对于相对比较陌生的对象，或软件为主的系统，先导出功能，依据功能建立逻辑架构更方便。

逻辑架构

OOSEM开发活动中需求的获取，架构的设计属于SE基本内容，逻辑架构的出现是一大亮点，但它并不是OOSEM的特有的过程和产物，基本上所有的MBSE均有涉及，它主要目的在于:

以我们容易理解的方式，对系统进行抽象，形成满足需求的逻辑解决方案，为后续技术实现方案的确定提供基础。

避免技术实现方式(实现条件约束)和细节的干扰，从系统化的角度对系统进行分解，组织系统功能实现。

通过逻辑抽象，逻辑架构降低了需求变更对系统设计的影响，提高系统复用性，有助于需求变更管理。

技术解决方案中立，便于不同技术的应用和评估。

那到底到底什么是逻辑架构？为了方便朋友们理解，举个简单的例子:

就拿汽车驱动系统为例，当我们从物理架构角度去看，对于传统汽车，它包括了具体的发动机，变速器，各自的控制单元等基本部件，对于电动汽车而言，它对应得就是电机，减速器等。而从逻辑架构的角度看，不管传统还是电动汽车，它们逻辑组件基本相同，都需要一个动力提供源，一个动力传递装置等，在我们还不了解发动机，电机，变速器这些具体技术实现手段前，逻辑架构其实更符合我们对事物认知的方式。

所以对于逻辑架构，我们不需要明确系统具体实现方式，属于技术解决方案中立的架构，更多的是从功能实现角度去考量应该采用哪些必要的逻辑组件去实现相应功能，这样逻辑组件在后续开发过程中，会被进一步具象化，被拆分成多个或合并成一个物理组件，这个就是所谓的逻辑架构映射到物理架构。

此外，逻辑架构的存在也符合现在电子电气架构不断集中化的趋势。随着技术发展，分布式控制单元不断被集成，这时候虽然物理架构不断发生变化，而逻辑架构却相对稳定不变，这时候可以从逻辑架构的层面入手，将其作为基线进行分析，通过逻辑架构和物理架构之类的映射关系，可以大大降低分析难度，提高系统设计的灵活性和可拓展性。

个人认为逻辑架构的出现是MBSE应对系统复杂性的重要体现之一，这也是抽象的魅力，这也是一个架构师必备技能之一。

写在最后:

MBSE方法论之OOSEM我们就聊完了 MBSE系列: 方法论之OOSEM的图2