下载掌阅APP，畅读海量书库
立即打开
在讨论MBSE的主要概念之前，需要先了解一下几个重要的哲学观点。
首先，MBSE既不是系统工程的一个分支，也不是一个子集，而是一套完整的系统工程方法。因此，它可用于系统工程的方方面面。目前看待MBSE的一种方式是将它视为通过严格方法实现的系统工程，如图2.1所示。
图2.1 MBSE是一种系统工程
图2.1表明，MBSE实际上是系统工程的一种类型，而不是系统工程的一个子集或组成部分。我们必须非常清晰地理解这种关系。
国际系统工程委员会 （International Council on Systems Engineering，INCOSE）会定期定义系统工程未来的全球愿景。INCOSE Vision 2035（INCOSE，2022）预测到2035年，所有系统工程都将完全基于模型，这是所有数字化转型通往成功的钥匙。
那么问题就来了，MBSE究竟意味着什么？它与传统的系统工程有何不同？接下来的几节将会对这些问题进行详细的讨论。
当考虑系统工程时，请永远不要忘记系统工程的初衷，即 开发一个成功的系统 ，这一点非常重要。这句话听起来像是句废话，但它更深层的含义是指，构成系统工程的每一项活动都应有助于实现这样的目标。
与传统的系统工程相比，考虑MBSE时必须要了解的是关于系统的知识、信息和数据驻留在哪里。在传统的系统工程中，关于系统的所有知识都存在于描述系统的文档集合中。而对于MBSE，所有关于系统的知识都放在抽象系统的 模型 中，如图2.2所示。
图2.2 模型的概念
图2.2展示了“模型是对系统的抽象”这一MBSE中最基本的概念。抽象可以是系统的表达或者是简化了的系统。模型必须是系统的简化，否则它跟系统本身没有任何区别。因此，鉴于模型是系统的简化这一本质概念，模型中包含的信息也是不完整的。这也催生了“所有模型都是错误的”这一愚昧的观点。在MBSE中，模型的目的是为系统提供一个抽象，以便能够成功地实现该系统。它的目的不是包含尽可能多的信息，也不是试图捕获与系统相关的所有信息，而是获取足够使系统成功实现的相关信息。
要时刻铭记这一点，因为在模型中加入更多的信息过于容易，然而这些信息对于所有人来说没有任何用处。模型中只包含有用的信息，这点至关重要。
模型中的信息会按照特定的集合分组，这些集合被称为 视图 ，如图2.3所示。
图2.3 模型由视图组成
图2.3中的模型由一组 视图 组成，每一个视图都代表一组信息的集合。最重要的是，这些信息是为了增加整个系统工程的价值而存在的，否则就是在浪费时间。因此，为了确定一组信息是否为视图、是否为整个模型的有效部分，必须回答以下几个问题：
❍哪些干系人想查看视图？ 回答这个问题的关键在于，每个视图都需要与一组对系统感兴趣的干系人相关联。干系人的概念已经在第1章中有所介绍，并且明确地指出识别正确的干系人集合是系统工程的重要组成部分。每当请求关于系统的信息时，背后都有着确定的干系人。
❍为什么这些干系人要查看视图？ 了解每个干系人查看视图的原因非常重要。作为模型的一部分，视图必须努力为系统工程带来价值。因此，必须至少有一个干系人能够从查看视图中获得好处。
❍视图中必须包含哪些信息？ 了解完整模型之外的哪些信息必须可供干系人查看也同样重要。
对于某个视图来说，如果不能回答上述三个问题，那么显而易见，它就不是一个有效的视图，因此也不能被视为系统工程工作的一部分。以视图的形式来展示无用的信息成本非常低，所以每当需要使用视图的时候应当尝试回答这三个问题，以保证视图的有效性。
在成功回答了这三个问题后，还需要考虑第四个问题：
❍干系人希望使用什么语言来查看视图？ 在与各方干系人沟通时，必须使用干系人能够流利使用的语言进行沟通。这适用于口语和领域特定语言，本章后面将会对这些内容进行讨论。第1章已经对沟通的重要性进行了讨论，这是有效沟通发挥作用的领域之一。干系人使用的语言可能不尽相同，对应于MBSE中，这就意味着不同的干系人可能希望以不同的方式来可视化视图。
确保每个视图都经过这些问题的洗礼至关重要，否则模型中包含的信息可能无法带来任何价值，这也是与MBSE相关的一种高风险场景。
另一种与构成模型的视图相关的高风险情况是，视图之间必须保持一致性。模型的本质和定义应当是一致的。如果一组视图中的每一个视图都与其他视图一致，那么它们就是一个模型。相反，如果一组视图中的视图与其他视图不一致，那么它们就是数据。一旦模型被建立（所有视图都创造了价值并且相一致），它就会被用来作为与系统相关的所有信息的主存储库。也就是说，每当干系人想要了解有关系统的任何信息时，都可以通过访问模型以确定答案。
模型有时会被称为 单一事实来源 （Single Source of Truth）。这是一个非常重要的定义，它主要包括两方面的内容：
❍ 模型是系统的唯一表示——它是单一来源。
❍ 模型中的所有信息都是可以经过确定的、尽可能真实的，因此是单一的事实来源。
这个定义存在一些歧义，它并没有说模型只包含在一个单一的位置中，而是说尽管模型在实际使用时可能会被拆分到多个位置、数据或者工具中，但从概念上讲，模型是一个单一的实体。
可以把模型想象成一个庞大而复杂的信息集合，每个视图都类似于一个可以探究该模型的小窗口。必须提供足够多的窗口，以便使所有干系人有信心认为该模型已经被充分理解，并且可以实现一个成功的系统，或者说可以执行系统工程。
有关视图需要理解的最后一个内容是，视图可以通过多种不同的方式可视化，即可以通过任意数量的不同语言进行交流。这与使用不同语言的干系人概念相同，下文会重点进行介绍。
视图的可视化方式，对于干系人之间能否成功理解系统并进行交流至关重要。在MBSE中，每个干系人可能使用的不同语言被称为 符号 （Notation），如图2.4所示。
图2.4 符号、图和可视化
图2.4将 符号 和 图 的概念引入到系统和模型的原始定义中。
符号表示某种用于与众多干系人进行沟通的语言。该符号代表了在第1章中介绍的口头语言，或者说它代表了一种基本的沟通机制，可以用来与一组干系人进行交流。
符号包含一组图，这些图提供了该符号所使用的实际沟通机制。术语 图 在这里使用的是它最基本的意思，甚至可能不是图形化的，因为几乎任何语言都可以实现这种符号，如下所示：
❍ 符号可以是一种可视的或图形化的语言，它使用图作为其通信机制。这方面的例子包括 统一建模语言 （UML）（UML 2019）、 SysML （SysML 2017）、 SysML2.0 （SysML 2022）、 业务流程建模标注 （BPMN）（BPMN 2011）、流程图（ISO 1985）等。
❍ 符号可以是基于数学的，使用方程或某种形式化的方法作为其沟通机制。这方面的例子包括基于一阶谓词演算和集合论的语言，如 维也纳开发方法（VDM） （VDM 1998）、 Z （Z 1998）、 对象约束语言 （OCL 2014）等。
❍ 符号可以基于自然语言，使用结构化或非结构化文本作为其基本沟通机制。
符号及其图用于可视化组成模型的视图。如果将模型想象成一个庞大、复杂的信息集合，并且每个视图都类似于在该模型中打开的一个小窗口，那么可以将图视为作用在每个窗口上的不同的过滤器或透镜。就像可以使用许多不同的滤光片来改变窗户另一侧的景象一样，也可以用许多不同的方式来可视化每一个视图。
例如一个拥有大量基于文本描述的需求的视图，它也被称为需求描述视图。判断它是否是一个有效的视图，可以思考以下几点：
❍ 对需求描述视图感兴趣的干系人是需求工程师和需求经理。
❍ 需求描述视图是必要的，这样干系人既可以对需求的数量有一个总体的把握，也可以对每个需求的含义有一个简要的了解。
❍ 需求描述视图包含一组需求，每个需求都有许多与之相关的属性，比如它的名称、标识符、描述和优先级。
通过以上几点的分析，就可以确认这个视图是有效的。下一个要问的问题是：干系人使用哪种语言？这将决定他们如何交流。建模时可以使用不同的符号，例如：
❍ 需求描述视图可以使用结构化文本来可视化。每个需求是一个段落，属性是每个段落下显示的要点。
❍ 需求描述视图可以使用UML来可视化，特别是称为 类图 的图，其中每个需求都表示为一个UML 类 ，每个属性都由一个UML属性来表示。UML中的类图与SysML中的块定义图非常相似，事实上，它是块定义图的基础。
❍ 需求描述视图可以通过SysML需求图来可视化，其中每个需求都由一个SysML需求块表示，其每个属性都由一个SysML属性表示。
以上列出了在可视化同一个视图时的三种可能选项，这也说明任何视图都可以采用很多种不同的方式进行可视化。
本书将采用 SysML 用于所有给出的示例，稍后将对它做更详细的讲解。此外，本书还使用SysML作为口头语言。下文将通过介绍构成该方法的两个主要概念来补充这些概念。
当通过创建多个视图来开发模型时，以相同的方式来创建所有视图是非常重要的。这是该方法的应用场景之一，如图2.5所示。
图2.5 MBSE方法介绍
图2.5介绍了 框架 （Framework）形式的MBSE所需的部分方法，该框架由 观点 （Viewpoint）和 本体 （Ontology）组成。
需要注意一种情况，即需要确保所有相同类型的文档都拥有同样的结构和内容。例如在处理文档时，可以为文档定义一个模板，确保所有的文档都具有相同的外观和感受。而在MBSE中创建视图时，也会考虑使用某种模板。视图的模板被称为观点。观点一旦被明确定义，那么基于相同观点创建的所有视图都是一致的。
可以通过回答三个与视图相关的基础问题，并将答案进行组合来形成观点。以下是可以用来形成观点的问题：
❍ 哪些干系人对查看视图感兴趣？
❍ 他们为什么对视图感兴趣，或者说，他们意识到这将会带来什么价值？
❍ 视图中包含哪些信息？
每个观点都由这三个问题的答案组成，也就确保了基于该观点的所有视图的结构和内容是统一的。
为了确保观点与观点之间保持一致，需要建立一套共同的概念和相关术语，这些概念和术语构成了视图内容的基础。这被称为本体论，也就是在第1章中介绍和讨论过的领域特定语言。
本体是MBSE中最重要的一环，这是因为构成MBSE的所有其他元素最终都可以追溯到本体。本体将会在本章后面的内容里详细讨论。本体和观点组合在一起的时候就形成了一个框架。框架是作为完整模型的模板或蓝图而创建的。另一个常见的术语是架构框架（Architecture Framework），它为系统架构提供了模板。
建模和架构之间有千丝万缕的联系，这是一个非常复杂和烦琐的内容，远远超出了本书所涉及的范围。目前只需要这样理解这两者就足够了： 所有的架构都是模型，但并不是所有的模型都是架构。
定义方法时需要考虑的第二个内容是流程集，如图2.6所示。
图2.6 MBSE流程集介绍
图2.6将 流程集 （Process Set）的概念引入MBSE的整体方法中。流程集是单个流程的集合，这些集合被框架以多种方式使用：
❍ 流程集用来展示如何开发框架、本体以及相关的观点。
❍ 流程集用来展示如何基于框架中定义的观点来开发组成模型的视图。
框架和流程集的组合构成了MBSE的全部方法。在考虑这两部分方法时，有一些关键点需要牢记：
❍ 框架只关注于定义所产生的信息的结构、内容和一致性，而这些信息用来基于视图对模型进行开发。因此，框架可以被认为是定义了方法的“内容”：必须生成哪些信息用于开发模型？
❍ 流程集侧重于开发和使用框架所涉及的步骤。因此，流程集可以被认为是定义了方法的“方式”：框架是如何开发和使用的？
框架（内容）和流程集（方式）之间的概念分离意味着可以有许多使用相同框架的不同流程集。这一点很重要，因为不同的项目可能遵循不同的流程，这取决于项目的性质，但底层框架是相同的。例如，一个只需要几周时间的研究演示项目，它可以采用一组高层级的但技术上简单的流程来开发其模型。而在同一个组织中另一个持续多年才能完成的关键业务项目，它采用了更加详细、严格和耗时的流程。尽管这两个项目采用不同的流程集，但它们完全可能使用了同一套框架。这也就意味着两个项目生成的模型将会采用相同的框架，因此两个项目的视图具有可比性，它们之间可以进行比较和对比。
现在让我们稍作休息，好好消化一下本章到目前为止所讨论的内容。
到目前为止所讨论的内容对于理解MBSE至关重要，因此非常值得让我们停下来重新审视这些内容并额外增加一些另一个层级的内容。
本章迄今不断演进的图目前可以被分为三个组，如图2.7所示。这些内容就是为系统工程社区广为熟悉的“
MBSE in a slide
”
（Holt & Perry，2019）。
图2.7在系统工程社区中被广泛使用，以便更为直观地宣讲MBSE中的关键概念。
图2.7中所添加的三个组解释如下：
❍方法。 该组包括流程集以及由本体和观点组成的框架。框架侧重于必须为模型生成哪些信息，而流程集侧重于如何生成和使用这些信息，这一点要牢记在心。
❍目标。 该组包括系统和模型，以及与模型相关的视图。请记住，任何系统工程的目标都是开发系统。MBSE的目标也不例外，但它是通过开发模型及其相关的视图来实现的。每个视图就像是一扇窗，打开这扇窗就能看到模型中一个小而聚焦的内容。
❍可视化。 该组包括符号及其相关的图。符号是一组口头语言，用来作为系统工程的基本通信机制。每个图也可以被当作观察模型的窗口，并且可以使用滤镜来观察模型。
图2.7 添加了分组的“MBSE in a slide”
所有已经被讨论过的概念现在都可以通过与MBSE相关的 实现（Implementation） 和 合规（Compliance） 来进行扩展。
对于MBSE中的基本元素，下一步让我们看看在MBSE项目中如何以务实的方式来实现视图的可视化。此时，需要对“MBSE in a slide”进行扩展，从而引入工具，如图2.8所示。
图2.8 对“MBSE in a slide”进行扩展，引入工具
工具是MBSE的重要组成部分，它可以使MBSE的全部优势得以实现。
图2.8中的工具与其他两部分的内容有所关联：工具实现了符号和框架。下面将详细介绍这两部分的内容：
❍工具实现符号： 无论采用了哪种符号，都必须根据底层语言的语法和语义来正确使用。在选择工具时，需要注意的是不同的工具将会为符号提供不同级别的支持。例如，如果采用诸如SysML之类的图形符号工具，那么就可以使用任意一个具有基本绘图功能的工具来创建图表，如Office工具。然而使用SysML不仅仅是在页面上绘制正确的形状和线条，因为它作为语言必须遵循最基本的语法和语义。在使用好的MBSE建模工具时，语法和语义知识将被内置到工具中，因此该工具可以通过对模型运行语法和语义检查来强制使用正确的符号。当使用英语编写文本文档时，好的文本处理程序都可以对文本进行拼写和语法检查。建模工具里的语法和语义检查就类似于Office工具里的拼写和语法检查。符号是口头语言，因此工具应有助于确保这种口头语言被正确实现。选择合适的建模工具可以做到开箱即用，直接使用工具来实现口头语言。
❍工具实现框架： 由于框架占据了整个方法的绝大部分，这也就意味着工具会实现方法的大部分内容。方法可以通过将本体嵌入到工具中并且通过将一组观点（通过回答每个观点的关键问题）定义到工具中来实现。方法包含领域特定语言的本体，因此可以对工具进行定义，使其能够为系统使用该领域特定语言。此时工具无法做到开箱即用，必须将框架通过编程的方式融到工具之中。优秀的工具都能够创建配置文件，允许对工具进行定制以实现特定框架。
工具是MBSE的重要组成部分，选择一个满足项目建模需求的工具至关重要。下一小节将介绍最后一个新概念—— 合规 。
最后需要加入“MBSE in a slide”图中的概念是 合规。 当加入这个概念后，就形成了在MBSE社区中流传的完整版本的“ MBSE in a slide and a bit ”，如图2.9所示。
合规 是最后加入进来的内容，它包含 最佳实践 。在系统工程中，以严格、稳健和可重复的方式执行每项活动非常重要。这是通过证明MBSE方法符合各种最佳实践来实现的。这些最佳实践如下：
❍基于流程的标准 ，这些标准可能存在于不同的层次，例如国际标准、行业标准、内部标准等。通常，与如何执行方法有关的标准是基于流程的，所以流程集必须符合最佳实践。目前有许多基于流程的标准，系统工程中使用最广泛的标准是ISO 15288——软件和系统工程生命周期及流程（ISO 2015）。
❍基于框架的标准 ，这些标准可能存在于不同的层次，例如国际标准、行业标准和内部标准。通常，基于作为方法的一部分所必须产生的信息的标准是基于框架的，因此框架必须符合最佳实践。基于框架的标准非常多，国际标准使用最广泛的是ISO 42010——系统和软件工程——架构描述（ISO 2011）。行业标准如MODAF（MODAF 2010）、DoDAF（DoDAF 2007）和NAF（NAF 2007），以及现在用于国防工业的UAF（UAF 2017）。Zachman（Zachman 2008）也广泛用于IT行业，等等。
❍基于应用的标准， 系统工程的一些应用有它们自己的特定标准，可以用于许多不同的行业。此类标准涵盖安全性、保密性、可用性、可维护性等领域的最佳实践。
图2.9 完整版本“MBSE in a slide and a bit”
这些最佳实践只是冰山一角，当我们需要选择标准时可以起到抛砖引玉的作用。下一小节将重点介绍如何在MBSE上下文中使用迄今为止提供的信息。
只有理解了图2.7和图2.9中的概念，才能正确地理解和使用MBSE来实现系统工程。
这些图对于在组织中推行MBSE也同样重要。
这些图也可以用来表明组织或部门内当前MBSE的能力。当组织开始推行MBSE时需要找到一个着手点，而这些图以分组的方式展示了推行时需要考虑的五个主要领域。
必须强调的是，这些图不是从左到右依次阅读的，MBSE活动当然也不是以一成不变的方式来执行的。首先应该将此图作为检查表，以确定每个组中都存在哪些能力。
一旦确定了每个组的能力，就可以执行差距分析以决定需要实施哪些组，然后为每个组确定优先级。
下面通过两个常见的场景来进行说明：
❍ 一个组织决定要实施MBSE。第一步，他们选择采用SysML符号，并且购置了一些工具。这作为第一步本身并没有什么错，但是许多组织所犯的错误是认为仅仅通过购买工具就可以成功地实施MBSE。从图中可以清晰地看出，由于此时还没有合适的方法，所以无法证明其是否合规。而且由于没有合适的方法，也无法对工具进行定制以便适用于该方法。这种情况下，为了能够实施MBSE，应该先考虑合适的方法，然后再考虑是否合规。
❍ 一个组织决定要实施MBSE，并且确定使用已经在其他同类公司采用的架构框架，此外还决定ISO 15288是他们希望遵循的标准。同样，这些内容作为第一步并没有错。该组织认为它已经有了一个很好的方法，然而它将方法（架构框架）与合规（标准）弄混了。它还需要制定符合标准并且适合组织工作方式的流程集。另外，如何证明所选择的架构框架是适合于业务的性质呢？
诸如此类的问题并不一定容易解决。想要进一步深入了解这些问题，一种方法是通过了解MBSE的演进来考虑其在业务中的成熟度。这将在下一节中讨论。