下载掌阅APP，畅读海量书库
立即打开
构建系统工程的一个关键方面是系统本身。因此，本章的第一节用与系统和接口相关的概念和术语来定义MBSE本体。这将包括识别关键术语，以及准确定义以下术语的含义：
❍系统层次结构 ：系统允许存在多少层结构？许多人会想到子系统的概念，但很少想到子系统下面可能存在的其他抽象级别。因此，需要解决每个子系统下存在多少其他级别的问题。
❍系统元素之间的交互 ：相似的系统元素之间允许哪些交互？例如，系统与系统、子系统与子系统之间的交互。
❍级别之间的交互 ：层次结构级别之间允许哪些交互？例如，系统和子系统之间的交互。
成功的MBSE的基石是拥有良好的 本体 。本体提供了 领域特定语言 ，如第2章所述，本体也为构成模型的所有视图的一致性提供了基础，这将在本节中讨论。
因此，定义系统及其系统元素的关键部分是定义MBSE本体。本体将逐步发展，并将展现如何使用本体来帮助构建 视图 。在这种情况下，这些视图将与系统及其接口相关。
当进行系统建模时，重要的是模型需要尽可能准确地表示 相关系统 ，换句话说，应精确到能够成功开发系统所必需的程度。
所有系统都有一个自然的 层次结构 ，因此，建模工作的一个重点就是确保模型中的所有元素都符合当前系统的层次结构。这是通过将系统的层次结构作为本体的一部分来实现的。在第2章中简要介绍了本体的概念，本小节将更详细地研究这一点，并将讨论在本体中获取内容的重要性，以及层次结构中的变化。
下面的讨论将从考虑最简单的层次结构开始，如图3.1所示。
图3.1 具有单一级别的简单系统层次结构
图3.1使用了SysML块定义图，展示了一个非常简单的 系统层次结构 ，其中只有一个较低的抽象级别，即子系统的抽象级别。对系统感兴趣的干系人与系统处于同一抽象级别。这可以通过以下事实推断出来：干系人和系统之间的关系是使用使两个模型元素存在于同一级别的关联来可视化的。然而，系统和子系统之间的关系使用一种组合，这意味着子系统位于比系统更低的抽象级别。
这种视觉线索在查看框图时能够很容易地被识别出来。通过识别组合（以及稍后将讨论的聚合），可以快速地识别图中存在的各种抽象级别，并轻松找到最高的级别。这很重要，因为它为阅读图提供了一个很好的起点。因此，在图3.1中，开始阅读它的位置是在抽象的最高级别，这意味着该图将被解读为：
“一个或多个干系人对系统感兴趣，每个系统都包含许多子系统。”
图3.1中存在的每个SysML建模元素都构成了MBSE本体的一部分，这一概念将贯穿全书。图3.1中的每个块代表本体中的一个元素，并通过使用<<本体元素>>构造型展示出来。图3.1中的每一个关系，在这种情况下是一个关联和一个组合，代表本体上的一个关系，并通过使用<<本体关系>>构造型直观地显示出来。整个本体由一组 本体元素 和 本体关系 组成，本书中展示的所有剩余的本体视图都将遵循这一点。
然而，从这一点开始，将显示<<本体关系>>构造型，以使图尽可能清晰易读。<<本体关系>>构造型将被省略，但可能会被视为存在。
图3.1在系统和子系统之间使用了单一的组合，这意味着系统的概念拥有组成它的所有子系统。在这里，可以通过添加新关系（在本例中为聚合）来为本体引入轻微变化，如第2章中所讨论的（见图3.2）。
图3.2 一个同时具有组合和聚合的层次结构示意图
图3.2使用SysML块定义图，显示了与图3.1相同的基本层次结构。这次引入了一种新的关系，即系统与子系统之间的聚合。
这个新添加的元素很微妙，但对整个系统结构来说可能非常重要。图3.2现在可以做以下解读：
“一个或多个干系人对系统感兴趣，每个系统包含许多自有的子系统。系统也可能由不属于系统的可选子系统组成。”
现在这意味着系统本身仍然由子系统组成，但是这些子系统可能属于相关系统，也可能属于其他系统。这允许可以在模型中实现的系统具有更大的灵活性。为了说明这一点，图3.3将考虑一些视图。
图3.3 与本体一致的简单结构分解视图
图3.3显示了一个示例视图，它基于图3.1所示的本体，因此与使用SysML块定义图的本体一致。如果图与本体一致，那么它是一个有效的视图。然而，如果图与本体不一致，那么它就仅仅是一张图片。请记住，在MBSE中，视图是作为模型的一部分而不是图片创建的，这一点至关重要。通过确保图上的每个元素都是多个本体元素或本体关系之一的实例，可以很容易地证明图与本体是一致的，如下所示：
❍ 图3.3中的 司机 是本体中干系人的一个实例。
❍ 图3.3中的 驾驶 是一个来自本体“对……感兴趣”的实例。
❍ 图3.3中的 汽车 是一个来自本体的系统的实例。
❍底盘、车身、传动系统和内饰 都是来自本体的子系统实例。
❍汽车和底盘、车身、传动系统、内饰 之间的所有组合都是本体中 系统和子系统 之间组合的实例。
由于图上的每个元素都是本体元素或本体关系的一个实例，因此它是一个有效的视图，而且同样重要的是，它确保与使用相同本体的任何其他视图保持一致，在本例中如图3.1所示。
此处的图通过使用从本体派生的构造型干系人、系统和子系统来显示其一致性。这同样适用于这些关系，但为了清晰起见，在图中省略了这些关系。
这是使用构造型来执行本体的一个很好的例子，它构成了可以使用建模工具创建的配置文件的关键特征之一。
因此图3.3与图3.1中的本体一致，也与图3.2中的本体一致。这是因为图3.3与本体的一个子集是一致的，因此仍然是一致的。图3.4并非如此。
图3.4 显示组合和聚合的示例结构分解视图
图3.4显示了与图3.3相同的基本系统，但使用SysML块定义图增加了自行车架，对其进行了增强。请注意，0...1的多样性意味着自行车架是可选的。
现在可以执行先前应用的一致性检查，以证明图是否与本体一致，如图3.2所示。
❍ 图3.4中的 司机 是本体中干系人的一个实例。
❍ 图3.4中的 驾驶 是一个来自本体“对……感兴趣”的实例。
❍ 图3.4中的 汽车 是一个来自本体的系统的实例。
❍底盘、车身、传动系统和内饰 都是来自本体的子系统实例。
❍汽车和底盘、车身、传动系统、内饰 之间的所有组合都是本体中 系统和子系统 之间组合的实例。
❍ 图中的 自行车架 是本体子系统的一个实例。
❍汽车 和 自行车架 之间的聚合是系统和子系统之间聚合的一个实例。
这表明图3.4与图3.2中的本体一致，但与图3.1中的原始本体不一致，因为系统与子系统之间的聚合仅存在于图3.2中，而没有存在于图3.1中。
这是MBSE中最重要的一点。所有视图必须与底层本体保持一致，否则它们就不是视图，因此也就不是模型的一部分。
使用基于本体的一组构造型允许一种简单的方法来快速证明与本体的一致性。从现在开始，本书中显示的所有视图将使用一组构造型，这些构造型起源于MBSE本体，将在本书的其余部分得到发展。
此时可能出现的问题是，这两种本体中的哪一种是正确的？这个问题的答案是，它们都可能是正确的，但这取决于模型中到底包含哪些信息。图3.1中的本体没有图3.2包含的信息那么多，因此不能在视图中显示那么多的信息。然而，这并不意味着它是不正确的！重要的是，在定义本体时，充分考虑每个本体元素和本体关系的含义，然后将它们纳入本体。请记住，目的不是对尽可能多的信息进行建模，而是对尽可能多的信息进行建模，以便交付一个成功的系统。
系统层次结构现在可以扩展为包括许多较低的抽象级别，如图3.5所示。
图3.5 扩展本体以包含更多层次
图3.5显示了一个扩展的本体，它使用SysML块定义图定义了几个新的层次结构级别。每个层次都由一个较高的层次和一个较低的层次来表示：
❍ 每个系统包含多个自有子系统（由SysML组合显示），并且可能由可选数量的非自有子系统组成（由SysML聚合显示）。
❍ 每个子系统包含许多自有组件集（由SysML组合显示），并且可能由可选数量的非自有组件集组成（由SysML聚合显示）。
❍ 每个组件集包含许多自有组件（由SysML组合显示），并且可能由可选数量的非自有组件组成（由SysML聚合显示）。
这将产生一组四层的系统层次结构，它们可能被允许存在于视图中。
如上一小节所述，每个层次之间的关系通过组合和聚合来显示。这允许每个级别同时拥有自有和非自有的低级元素的灵活性。这将允许更大的灵活性，但请记住，目标不是灵活性，目标是表示层次结构中必要的内容。在包含或排除本体之前，必须仔细考虑每一种关系。
这些关系的存在显示了可以在视图中可视化的合法关系。因此，任何不存在的关系在视图中都是非法的。例如，一个系统包含至少一个子系统是合法的，就像它在本体中一样。但是，以下关系是不合法的：
❍ 一个系统包含许多组件集。
❍ 一个系统包含许多组件。
❍ 一个组件包含多个子系统。
这个列表只显示了一些不合法的关系，因为它们对应的关系在本体中不存在。
因此，本体显示了可以在视图上可视化的合法本体元素和本体关系，并禁止对本体之外的任何内容进行可视化。
图3.4显示了本体的合法可视化示例。因此，它是构成整个模型一部分的有效视图。
既然已经讨论并理解了基本的系统层次结构，现在应该考虑存在于相同层次结构级别的元素之间的交互关系了。
现在已经建立了基本的层次结构，但了解层次结构各个级别之间的合法交互关系也很重要。
这些交互关系可以在图3.6的扩展本体中看到。
图3.6使用SysML块定义图，显示了各个层次上的元素是如何与每个层次上的相同元素交互的。实际上，从这张图中可以识别出五种不同类型的交互，它们分别是：
❍干系人 到 干系人。
❍干系人 到 系统。
❍子系统 到 子系统。
❍组件集 到 组件集。
❍组件 到 组件。
图3.6 显示层级之间的交互关系的扩展本体
在本体的这种情况下，图上的关联标识了构成视图的不同元素之间相互交互的点。这不仅阐明了潜在交互点的位置，而且还阐明了可能不发生交互的位置。这非常重要，因为出现在本体上的每一行都有意义。例如，此本体当前不允许以下任何交互：
❍系统 到 系统。
❍系统 到 子系统。
❍子系统 到 组件集。
❍组件集 到 组件。
这并不是一个详尽的列表，但有助于后续讨论。根据这个本体，考虑系统和其他系统之间不允许交互的事实。随之而来的问题是，这是正确的吗？在这种情况下，系统和另一个系统之间的交互由干系人和系统之间的关系来表示，因为其他系统被认为是干系人。这可能很好，但对于不同的组织，这可能不正确，在这种情况下应该添加额外的关系，例如每个系统与一个或多个其他系统交互。
重要的是要摆脱只能有一个正确定义的观念，因为不同的组织（实际上，同一组织内的不同群体）可能会以不同的方式看待相同的概念。关键是要确保本体准确地反映感兴趣组织的领域特定语言，而不是试图创建一个满足所有组织需求的本体。请注意，这些交互是在位于系统层次结构中相同抽象级别的模型元素之间的水平交互。
下一组要讨论的非法交互是存在于系统层次结构的不同级别之间的交互：系统到子系统、子系统到组件集以及组件集到组件。在此处显示的本体的情况下，相邻级别之间或任何级别之间不允许交互。这是本体的一个重要方面。人们可能倾向于在不同级别之间进行垂直交互，以及在相同级别之间进行水平交互。这本身并没有错，但是从管理模型复杂性的角度来看，几乎总是建议限制交互的数量，而不是为了它而允许所有可能的交互。
在第1章中，讨论了复杂性体现在模型元素之间的交互中。本体允许精确地管理和控制这种复杂性，因为它识别和定义了所有合法的交互，并且在本体中控制这些交互的数量和性质，这是朝着管理整个系统中的复杂性迈出的积极一步。