本节介绍建模的关键概念以及将在本书其余部分使用的口语——系统建模语言,也就是众所周知的SysML。
准确理解建模的含义,以及为什么要把建模放在首位是很重要的。
准确理解SysML是什么以及不是什么,也很重要。因为目前存在许多对于SysML相关概念的误解,并且关于它如何与MBSE相适应也有很多困惑。例如,最常见的误解之一就是认为SysML与MBSE是同一个东西!
在开始正式讨论之前,我们应该认识到目前存在许多种不同类型的建模,正如本书前面讨论的那样。为了便于本书进行讨论,当本章和后续内容中使用术语 建模(modeling) 时,它指的是可视化建模,也就是说,口语的基本内容是图表。
MBSE的核心是进行建模,因此对有关MBSE的一些关键概念进行良好定义和充分理解是至关重要的。首先必须要理解建模的需求。
需要建模的根本原因可以追溯到另一个问题中,即为什么必须进行系统工程?系统工程有三个弊端,如第1章中所讨论的。现在我们将重新审视这三个弊端,但这次的重点是建模为什么以及如何有助于解决这些问题。
系统工程的第一个弊端是系统所表现出来的复杂性,无论它是本质的,即系统固有的,还是偶发的,即由与方法相关的人、流程和工具引起的。
建模有助于解决复杂性问题,因为它所创建的视图可以将复杂程度直观地进行展示,更重要的是可以体现出复杂性具体存在于模型中的哪些位置。管理和控制复杂性的关键是要能先识别它。对于固有复杂性来说,确定了复杂性就可以限制并控制对系统中复杂性最明显的部分的依赖。对于偶发复杂性来说,确定了复杂性就可以对其进行合理化和最小化,以将复杂性保持在尽可能低的水平。
系统工程的第二个弊端是缺乏对生命周期各个阶段的理解。建模也有助于解决这一弊端,因为在对各种类型的信息进行建模时,可以应用两个非常简单的规则。规则1:如果模型易于生成,则意味着源信息明确且易于理解。在这种情况下,模型可以极其自然地从源信息中提取出来,整个建模活动非常快速和直接。规则2是对规则1的补充。如果模型很难生成,并且存在很多歧义、不确定性和缺失信息,那么源信息就很模糊且不易于理解。此时,模型很难从源信息中抽象出来,整个建模活动非常耗时和费力。
系统工程的第三个弊端被认为是不同干系人之间的沟通不顺畅。建模可以通过两种途径来解决这个问题。第1章已经对高效且有效的沟通如何需要一种通用语言进行过讨论。实际上,既需要一种口语,也需要一种领域特定语言。建模有助于实现这两者——符号的选择是口语,本体的定义是领域特定语言。接下来的两小节将更详细地探讨这些内容。
因此,建模有助于解决系统工程的三大弊端。这也解释了为什么MBSE是实现系统工程本身的强大方法。下一小节将介绍如何开始定义模型。
前面的内容将模型定义为对系统的抽象。抽象是对系统的表示,此时会使用图形或图标来作为介质。由于模型是系统的抽象,因此它必然是简化的系统,这意味着它不会包含系统的所有信息。模型也必须是系统的简化,因此与系统相关的信息将不包含在模型中。这并不是说模型是错误的或不完整的,当然前提条件是模型中已经包含了所有相关和必要的信息。
这里有一个潜在的风险,那就是可能会丢失相关信息。尽管我们没有办法100%保证不会丢失任何信息,但是通过流程集和框架的形式来使用良好且可靠的MBSE方法,可以大大降低遗漏这些信息的风险。
作为系统的抽象,模型被定义为由许多视图、一个需求和一组已定义好的信息组成,且每个视图都有一个目标受众。每个观点的定义是确保没有相关信息遗漏的关键。
接下来关于定义模型的内容是所有视图都必须与其他视图保持一致。这点非常重要。如果对那些不一致的视图进行建模,得到的就只是图片的集合而不是模型。对彼此一致的视图进行建模,就能生成模型。建模时一致性是王道,这一点再怎么强调也不为过。
使用一个好的表示法是很重要的,比如SysML。因为它会在表示法中提供一些机制,这些机制可以证明那些用于可视化视图的图表是否一致。
在创建模型时,理解模型总是具有 结构 和 行为 这两个 方面 是非常重要的。下面来详细看看这两方面的内容:
❍结构: 模型的结构定义了模型的内容——模型中的主要元素是什么,这些元素之间的关系是什么,以及每个元素的作用。结构还允许从类型(系统元素的类型)和概念(系统元素的组成)层面出发对系统进行分层。系统元素之间的关系和元素本身一样重要,这是系统思维的核心原则。
❍行为: 模型的行为定义了模型的方式。在这里要关注事情发生的顺序,在什么条件下发生,以及时间限制是什么。结构允许将模型分层,但行为往往适用于分层结构的一些特定层级。此外,关系是动态的,而不是静态的。
每个模型都具有与之关联的结构和行为,这说明存在构成模型的结构视图和行为视图。由于模型中的所有视图必须是一致的才能将其视为模型,这意味着模型的结构和行为方面必须彼此一致。
本书使用的符号是SysML,它描述了九种不同的图表,可用来对模型的结构和行为进行可视化。
关于应该在生命周期的哪个点(哪里)和在什么情况下(什么时候)建模,经常有很多争论。这两个问题的答案很简单。
建模应作用于生命周期的任何阶段,只要符合以下情况:
❍ 系统中存在未知的、未管理的或不受控制的复杂性,即弊端1。
❍ 需要对系统的某些方面进行了解,即弊端2。
❍ 需要与干系人进行有效和高效的沟通,即弊端3。
至于在什么条件下或什么时候应该进行建模,答案就是 只有当建模可以增加价值的时候 才去执行。
最后一点很抽象,但很关键。作为MBSE内容而执行的每个活动都必须增加价值并有助于系统的成功实现。如果不是,那么就不应该去做!有时候执行了很多次建模后会得出这样的结论:由于不会再增加任何价值,所以应当停止建模。这种结论也是非常有必要的。使用有效的框架可以解决这个问题。因为每个视图存在的缘由已经确定,只要人们遵守该框架,就不会在没有明确需求或利益的情况下创建任何视图。