SysML实践指南第二版（中文翻译：刘亚龙）第二章 基于模型的系统工程概述

1. 基于模型的系统工程

基于模型的系统工程(MBSE)应用系统建模作为系统工程过程的部分描述在第1章，支持开发系统的分析、规格说明、设计、和验证。MBSE的一个主要构建是开发系统的一个连贯模型。这种方法提高规范和设计质量，促进系统规范和设计构件的重用,提高与开发团队之间的交流。

本章汇总不需要强调一个特定的建模语言、方法、或工具的MBSE概念，为SysML提供详细的语境。MBSE与传统的基于文档的方法的对比是使用MBSE的动机且更能显示出它的价值。本章也讨论了有效的建模准则。

1. 1. 基于文档和基于模型的方法对比

下面的章节对比基于文档的系统工程方法和基于模型的系统工程方法。

1. 1. 1. 基于文档的系统工程方法

传统上,大的项目执行系统工程活动已经采用了基于文档的系统工程方法，参考第1.2节。这种方法被执行通过生成文本规范和设计文档,以硬拷贝或电子文件格式,并随后在客户、用户、开发者、和测试者之间进行交换。系统需求和设计信息被表示在这些文档和绘图中。系统工程强调的被放置在控制文档中，并确保文档和绘图是有效的、完整的、和一致的、并且开发的系统符合该文档。

在基于文档的方法中,一个特定系统、它的子系统、和它的硬件和软件组件的规格说明常常被描绘在一个分层的树中,称为规范树（specification tree）。系统工程管理计划(SEMP)记录，系统工程过程如何使用在项目中，与工程学科如何一起工作来开发文档需要的内容来满足规范树中的需求。系统工程活动被计划通过预估时间和生成文档需要的工作,并且过程随后被测量通过文档的完整性状态。

基于文档的系统工程典型的依赖于运行构想的文档，来定义系统如何被使用支持任务或目标的需要。功能分析被执行来分解系统功能,并分配它们到系统的组件。绘制工具被使用来捕捉系统设计,诸如，功能流程图和原理方框图。这些图被存储作为独立文件并包含在系统设计文档中。工程权衡分析和分析被执行，并记录通过许多不同的学科来评估和优化可选的设计并分配性能需求。分析可以被支持通过个体分析模型对应性能、可靠性、安全性、质量属性、和系统的其它方面。

需求可追跟踪性被建立并维护在基于文档的方法中，通过跟踪需求在规范树中的不同层级的规格说明之间。需求管理工具被使用来解释需求包含在规范文档中并捕捉它们到一个需求数据库中。需求和设计之间的可追溯性被维护通过标识系统或子系统的部分，其满足需求,和/或验证过程被使用来验证需求,并随后反映这在需求数据库中。

基于文档的方法是严格的，但有一些基础限制。完整性、一致性、和需求、设计、工程分析、和测试信息之间的联系，由于这些信息在多个文档之间传播，评估变得非常困难。这使理解系统的一个特定方面和来执行必要的可追溯性和评估变更的影响变得非常困难。这也导致系统层级需求和设计与底层的硬件和软件设计之间脆弱的同步。同时也使对于系统的一个演变、系统设计的变体的维护、重用系统需求和设计信息变得非常困难。同时,系统工程工作的过程基于文档状态,其反映系统需求和设计的质量可能是不充分的。这些限制可能导致效率底下和潜在的质量问题，常常出现在集成和测试过程中,或更糟在系统被交付给客户之后出现。

1. 1. 1. 基于模型的系统工程方法

在电子和机械设计和其它学科中，基于模型的方法已经实践了许多年。机械工程从画图板转化到更熟练的2维和随后3维计算机辅助设计工具开始于1980年代。电子工程从人工电路设计到自动电路板生成和电路分析在一个相似的时间段。使用图形化模型来表示软件在一个在编程语言之上的抽象层的计算机辅助软件工程变得大众化在1980年代。软件开发使用建模正变得越来越被广泛采用，特别是自从1990年统一建模语言（UML）的出现。

基于模型的方法变得越来越流行在系统工程中。1993年 Wayne Wymore[31]年提出MBSE概念。随着计算机处理能力、存储容量和网络技术的发展、和需要强调的系统工程标准的形成，产生了一个显著的机会来推进MBSE实践的状态。期望MBSE以其它工程学科类似的方式变成标准实践。

“基于模型的系统工程(MBSE)是建模的形式化应用来支持系统需求、设计、分析、验证、和确认活动开始在概念设计阶段并持续贯穿开发和随后的生命周期阶段”[32]。MBSE着力促进系统工程实践活动，系统工程实践传统上被执行使用基于文档的方法，并且逐步增强了规范和设计质量,系统规范和设计构件的重用,和开发团队之间的通讯。系统工程活动的输出是系统的一个连贯的模型(即,系统模型),重点被放在模型的演化和细化上使用基于模型的方法和工具。

1. 1. 1. 1. 系统模型

系统模型通常被生成使用一个建模工具并包含在一个模型库中。系统模型包含系统的规格说明、设计、分析、和验证信息。模型包含表示需求、设计、测试用例、设计原理模型元素、和它们的内部关系。图2.1显示系统模型作为一组互联的模型元素集，表示系统的关键方面正如定义在SysML中,包含它的结构、行为、参数、和需求。包含在模型库中的模型元素之间的多个交叉联系，使系统模型将能聚焦在系统的不同视角上。

图2.1在SysML中，系统模型表示示例

系统模型的一个主要使用是满足它的需求的一个系统设计，并支持需求分配到系统的组件。图2.2描述系统模型如何被使用来指定系统的组件。系统模型包含组件互联和组件之间的交互接口，并且组件必须执行相关功能,与组件性能和物理特征相关。组件的文本需求也可被绘制在模型中并追溯到系统需求。

图 2.2 系统模型被使用来明确说明系统的组件

在这方面,系统模型被使用来指定组件需求，并可以被使用作为系统设计者和子系统和/或组件开发者之间的一个协议。组件开发者接收组件需求，组件需求是有用的对它们来说，或者通过一个模型数据交换机制或通过提供从模型自动生成的文档。以一种相似的方式，组件开发者可以提供信息关于组件设计如何满足它的需求。一个系统模型的使用提供一种机制来明确说明，和集成子系统和组件到系统,并维护系统和组件需求之间的可追溯性。

系统模型也可与工程分析和仿真模型集成来执行计算和动态执行。如果系统模型被直接执行,系统建模环境必须增强带有一个执行环境。模型执行的一个讨论被包含在第18.1.3节。

1. 1. 1. 1. 模型库

组成系统模型的模型元素被存储在一个模型库中，并通过图形化标志绘制在图上。建模者使用建模工具生成、修改、和删除个体模型元素和它们之间的联系在模型库中。建模者使用图上的标志来进入模型信息到模型库并且查看来自模型库的模型信息。规格说明、设计、分析、和验证信息先前绘制在文档中现在被捕捉模型库中。模型可以被查看在图或表中或通过查询模型库生成的报告。视图能帮助理解和分析同一系统的不同方面。文档可以持续服务作为一种有效方式来报告信息,但在MBSE中,文本和图形信息包含在文档中被生成从模型。实际上,许多建模工具有一个灵活的并且自动文档生成功能，其可以明显减少构建和维护系统规范和设计文档的时间和成本。

模型元素对应需求、设计、分析、和验证信息是可追溯的通过它们之间的相互联系,即使它们被表示在不同的图上。例如,一个发动机在一辆汽车的系统模型中可以有许多联系与模型中的其它元素。它是汽车系统的部分,连接到变速箱、满足一个动力需求、执行一个功能转化油料为机械能、和有一个重量属性，其贡献到车辆的总重量。这些联系是系统模型的组成部分。

建模语言规定了约束关系可以存在的规则。例如,模型应该不允许一个需求包含一个系统组件或一个活动来生成输入而不是输出。附加的建模约束可以被实施基于使用的方法。施加约束方法的一个例子可能是，所有的系统功能必须被分解，并被分配到系统的一个组件。建模工具被期望来增强约束在模型被构建的时刻,或通过运行模型检查程序根据建模者的方便性并提供违反约束条件的报告。

模型提供更细粒度的控制信息超过一个基于文档的方法可用的,其中这个信息可以被传播贯穿许多文档和联系没有显式定义。基于模型的方法提倡规格要求、设计、分析、和验证过程的严谨性。也明显增强了需求可追溯性的质量和时间，并且评估影响超过了基于文档的方法。

系统工程试图来衔接系统的片一起形成一个协调一致的整体模型。MBSE必须支持这个系统工程的基础聚焦。特别是,越来越强调系统模型的作用，其提供了一个集成框架对应其它工程学科生成的模型，包括硬件、软件、测试、和许多专业工程学科，如可靠性、安全性和安全性的模型。这将在第18章中讨论的，作为整体讨论的一部分，系统模型将被集成到一个系统开发环境中。

1. 1. 1. 1. 转变到MBSE

模型和相关的图技术已经被使用作为基于文档的系统工程方法的部分好多年,并包含功能流程图、行为图、原理方框图、N2图、性能仿真、和可靠性模型等。然而,模型的使用通常已经被限制范围来支持特定的分析类型或选择的系统设计方面。个体模型没有集成到一个连贯的整体系统模型中,且建模活动没有集成到系统工程过程中。基于文档的系统工程到MBSE的转变是一个巨变，从强调控制系统相关的文档转变到控制系统的模型。MBSE集成系统需求、设计、分析、和验证模型以一种连贯的方式解决系统的多个方面,而不是一个分离的个体模型。

MBSE提供一个机会来解决基于文档的方法的许多限制，通过提供一个更严格的方法来捕捉和集成系统需求,设计,分析,和验证信息,并促进这些信息在整个系统的生命周期的维护,评估,和通讯。MBSE的一些潜在的益处包含在下面:

• 提高沟通效率
  1. 在整个开发团队和其它利益相关者之间，共享对于系统的理解
  2. 从多个角度集成系统视图的能力
• 降低开发风险
  1. 随时进行需求验证和设计验证
  2. 开发系统更准确的成本预估
• 提高质量
  1. 更完整、无歧义、可验证的需求
  2. 需求、设计、分析、和测试之间更严格的可追溯性
  3. 增强设计完整性
• 增加可生产性
  1. 需求和设计变更的快速影响分析
  2. 权衡空间更有效的浏览
  3. 重用已经存在的模型支持设计演进
  4. 减少集成和测试过程的错误和时间
  5. 自动文档生成
• 在整个生命周期使用模型
  1. 支持对操作者进行关于系统的使用培训
  2. 系统的诊断和维护支持
• 增强知识传送
  1. 已经存在的设计和历史设计的捕捉
  2. 信息的有效存取和修改

当实施使用恰当的方法和工具时，MBSE可以提供附加的严格性在规范和设计过程中。然而,这种严格不是没有代价的。明显的,转变到MBSE强调了需要前期在过程,方法,工具,和培训上的投资。期望在这种转变过程中,MBSE将结合基于文档的方法被执行。例如,一个大型的复杂的历史系统的更新严重依赖于历史文档,并且仅有系统的部分可以被建模。方法和建模工作范围的仔细裁剪是必须的来满足一个特定项目。转变到MBSE的考虑被讨论在第19章。

1. 1. 建模原则

下面的章节提供一些关键建模原则的一个简短的概述。

1. 1. 1. 模型和MBSE方法定义

模型是可以被实现在物理世界一个或多个概念的一种表示。它通常描述一个感兴趣的领域。一个模型的一个关键特征是它是感兴趣的领域的一个抽象，不包含建模实体的所有细节。模型可以被抽象通过数学和逻辑表示,以及更具体的物理原型。更抽象的表示方法的表达形式可以是一个图形化标志的组合,诸如，节点和圆弧在一个图像上或一个几何表示上,和文本,诸如，文本语句在一种编程语言中。一个模型的一个通用例子是一座建筑的蓝图和一个缩小比例的物理模型。建筑的蓝图是一个或多个被建造的建筑的一个明确说明。蓝图是一个抽象，它不包含任何建筑的细节,诸如，它的材料的详细特征。

系统模型表示在SysML中类似一个建筑蓝图，其明确说明一个系统将被实施。代替一个系统的一个几何表示,SysML模型表示行为、结构、属性、约束、和系统的需求。SysML有一个语义基础，其明确说明模型元素类型和它们之间的联系可以出现在系统模型中。构成系统模型的模型元素被存储在一个模型库中并可以被图形表示。如果一个执行环境支持仿真，一个SysML模型也可被仿真。

方法是一组相关的活动、技术、和约定，其实施一个或多个过程并通常被支持通过一组工具集。基于模型的系统工程方法是一种方法，其执行系统工程过程的所有或部分,并生成一个系统模型作为它的主要构件之一。

1. 1. 1. 建模一个系统的目的

对于一个特定项目的一个系统的建模目的必须被明确的定义根据建模工作的期望结果,利益相关者、谁使用结果、和结果如何试图被使用。建模的目的使用来确定建模工作的范围根据模型的广度、深度、和真实度。这个范围应该被平衡与可用的计划、预算、技巧等级,和其它资源。理解目的和范围提供建立实际期望对应建模工作的基础。建模一个系统的目的可以强调系统工程过程的不同方面或支持其它生命周期的使用,包含下面的:

• 描绘一个已经存在的系统
• 明确说明和设计一个新的或修订的系统
  1. 表示一个系统概念
  2. 指定和验证统需求
  3. 综合系统设计
  4. 指定组件需求
  5. 维护需求的可追溯性
• 评估系统
  1. 进行系统设计的权衡分析
  2. 分析系统性能需求或其它质量属性
  3. 验证系统设计满足它的需求
  4. 评估需求和设计变更的影响
  5. 预估系统成本(例，开发、生命周期)
• 培训用户关于如何操作或维护一个系统
  1. 1. 建立准则来满足建模要求

准则可以被建立来评估一个模型如何很好的满足它的建模目的。然而,必须首先区分一个好的模型和一个好的设计。您可以有一个不好的设计但有一个好的模型或一个好的设计不好的模型。一个好的模型满足的预期的目标。一个好的设计基于如何很好的设计满足它的需求和扩展它与质量设计设计原则一致。例如,您可以有一把椅子的一个好的模型，其满足模型的预期目标通过提供一个椅子设计的准确表示。然而,椅子的设计可以是一个不好设计，如果不具备结构的完整性。一个好的模型提供可视性来辅助设计团队标识问题并评估设计质量。选择MBSE方法和工具应该配备一个专业团队来开发一个好的模型和一个好的设计。

下面的问题的回答可以被用来评估模型的有效性和模型衍生的质量属性。质量属性依次可以被用来建立偏好的建模实践。建模工具可以被用来检查模型质量,诸如，是否模型是格式良好的。

1. 1. 1. 1. 模型的范围是充分的满足它的目标?

正如先前描述的，假设目标被明确定义,模型的范围被定义根据它的广度、深度、和真实度。模型范围明显影响支持建模工作的资源需要的层级。

模型广度：对于目标，模型的广度必须是充分的。通过确定系统的那个部分需要被建模,并且模型的扩展能解决系统需求。这个问题被特别关联到大的系统，在其中您不需要建模整个系统来满足项目需要。如果新功能添加到一个已存在的系统,您可以仅选择性的聚焦在那些支持新功能的部分进行建模。在一个汽车设计中,例如,如果强调新需求对应燃油经济性和加速,建模可以聚焦在传动系关联的元素上,而很少聚焦在制动和转向子系统上。

模型深度: 对于目标，模型的深度必须是充分的。通过确定系统设计的层次，模型必须包括。一个概念设计或初步设计的迭代，模型可以仅解决一个高层级的设计。在汽车的例子中,初步设计迭代可以仅建模系统到发动机黑盒层次,反之如果发动机是详细建模的主题,一个详细设计迭代可以包含建模发动机组件。

模型的真实度：对于目标，模型的真实度必须是充分的。通过确定需要进行层级设计的详细程度。例如，一个低级真实度的行为模型可以是充分的通讯一个简单的动作顺序在一个活动图中。如果行为模型试图将被执行，附加的模型细节被需要,但这个附加的细节可以被添加到理解系统响应的层级。作为另外一个例子,当建模接口时,一个低级真实度模型可以仅包含逻辑接口描述,相反一个高级的真实度模型可以建模消息结构和通讯协议。最后,详细的时间信息可以被需要来建模系统性能。

1. 1. 1. 1. 模型关联到它的范围是完整的?

建模将被完成根据它的广度、深度、和真实度，一个必须的条件是必须匹配它定义的范围。其它完整性准则可以关联到模型的其它质量属性(例，是否命名约定已经被正确应用)和设计完整性准则(例，是否所有设计元素被追溯到需求)。有关MBSE的测量讨论在第2.2.4节，可以被用来建立附加的完整性准则。

1. 1. 1. 1. 模型格式良好，模型约束可以被附加上去?

一个好的格式的模型符合建模语言的规则。例如,在SysML中，原则上不允许一个需求包含一个系统组件,尽管其它关系被允许在组件和需求之间，诸如，满足关系。建模工具应该增强约束实施通过建模语言规则或提供一个违规情况的报告。

1. 1. 1. 1. 模型是一致的?

在SysML中,一些规则被构建在语言中来确保模型一致性。例如,兼容性规则可以支持类型检查来确定是否接口是兼容的或是否单位制在不同的属性上是一致的。附加的约束可以被实施通过使用的方法。例如,一种方法可以施加一种约束，它的逻辑组件可以仅被分配到硬件、软件、或操作过程。这些约束可以被表示使用对象约束语言(OCL)[33]并增强通过建模工具。

增强约束辅助维护整个模型的一致性,但它不阻止设计的不一致性。一个简单的例子可以是，2个建模者命名相同的组件使用2个不同的名称，通过一个模型检查者被解释作为不同的组件。这种类型的不一致性，表面上很容易通过审查和报告生成。然而,不一致性的可能性在提高，当多个人员工作在相同的模型上时。

一个很好定义的模型约定和学科过程的组合可以减少这种情况发生的可能性。

1. 1. 1. 1. 模型是可以理解的？

有许多因素驱动基于模型的方法和建模和建模样式，可以贡献到可理解性。一个关键贡献因素增强可理解性是有效的使用模型的抽象。例如,当描述一辆车的功能时,你可以描述一个顶层功能，如“驾驶汽车”或提供一个更详细的功能描述，如，“打开点火开关,使齿轮转动，踩下油门踏板”等等。一个可理解的模型应该包含多层级的抽象，表示不同层级的细节，并相互关联。正如将被描述在后续的章节，分解的使用、详细说明、分配、视图、和其它建模方法在SysML中被使用来表示不同层级的抽象。

另外一个可理解性的影响因素是关联信息在图上有它们自己的表示。常常，有许多详细的模型,但仅选择的信息被关联到一个设计的特定方面的通讯。信息在图上可以被控制通过使用工具功能来隐藏不必要的信息和仅显示信息关联到图的目的。再一次,模型审查的目标是来避免信息重载。

其它因素贡献到建模约定的使用是可理解的，并扩展那个模型是自描述的描述在下一节。

1. 1. 1. 1. 建模约定被记录并且连贯的?

建模约定和标准是关键的来确保一致的表示和样式贯穿整个模型。这包含建立命名约定对应每种类型的模型元素、图名称、和绘图内容。命名约定可以包含语言的文体方面,诸如，何时使用大写和小写,何时在名称中使用空格。约定和标准也应该考虑工具施加的约束,诸如，字母数字和特殊字符的使用限制。建议为每种图的类型建立一个模板，如此可以确保协调的样式。

1. 1. 1. 1. 模型是自描述的，根据提供的充分支持信息?

如果引用是一致的，符号和描述的使用在整个模型中可以帮助来提供增值信息。这可以包含设计决策的原理，为脆弱问题或解析困难区域提供模型元素的附加的文本描述。这使模型能长期维护和使与其它人员进行交流时更有效。

1. 1. 1. 1. 模型与其它模型集成?

系统模型可能需要来集成与电子、机械、软件、测试、和工程分析模型。这种功能被确定通过特定的方法、实施工具、和使用的建模语言。例如, 从使用SysML的系统模型传递信息到使用UML的一个软件模型的方法可以被定义，对应特定的方法、工具、和交换标准。通常,这被解决通过建立一个协商一致的建模信息表示，可以很好的与使用者交流信息,诸如，硬件和软件开发者、测试者、和工程分析人员。模型和工具的集成方法被讨论在第18章。

1. 1. 1. 基于模型的测量

测量数据收集、分析、和报告可以被使用作为一种管理技术贯穿开发过程来评估设计质量和过程。这被使用来评估技术、成本、和计划状态和风险,并来支持正在进行的项目计划和控制。基于模型的测量可以提供有用的数据，其可以衍生自一个表示在SysML中的系统模型来帮助回答下面的问题。随着时间的推移，数据可以被收集，通过对数据的大量附加的观察进行趋势评估和分布统计。

1. 1. 1. 1. 设计的质量是什么?

测量可以被定义来测量一个基于模型的系统设计的质量。这些测量中的一些传统上已经被使用在以文档为中心的设计测量中,诸如，评估需求满足、需求验证、和技术性能。其它测量可以包含指标,例如,设计如何被很好划分。

SysML模型可以包含明确的联系，其可以被用来测量扩展的需求被满足。模型可以提供的粒度通过识别模型元素满足特定需求。需求可追溯性可以被建立从任务层级需求向下到组件层级需求。其它SysML关系可以被使用以一种相似的方式来测量，那个需求已经被验证。这个数据可以被直接捕捉从模型或不直接从一个需求管理工具，被集成与SysML建模工具。

SysML模型可以包含关键属性，其被监测在整个设计过程中。典型的属性可以包含性能属性,诸如，恢复时间、物理属性(例，重量)、和其它属性(例，可靠性和成本)。这些属性可以被监控使用标准技术性能测量(TPM)技术。模型也可以包含属性之间的参数关系，说明它们可以如何被影响作为一个设计决策的结果。

设计划分可以被测量根据设计的层级凝聚和耦合。耦合可以被测量根据接口的数量或根据不同模型部分之间的更复杂的依赖关系的测量。凝聚测量的定义非常困难,但测量一个组件的扩展可以执行它的功能，不需要请求获取外部数据。面向对象的封装概念反映了这个概念。

1. 1. 1. 1. 设计的过程和开发尝试是什么?

基于模型的测量可以被定义来评估设计过程通过建立设计的完整性准则。在先前的章节中，质量属性的参考模型是否完整相对于建模工作的定义范围。评估设计完整性是必须的,但不充分。需求满足性来测量设计质量，也可以被使用来评估设计完整性。其它测量可以包含已经被完成用例场景或逻辑组件分配到物理组件的数目的百分比。从一个系统工程的角度看,系统设计完整性的一个关键测量是扩展到的那个组件已经被明确说明。这个测量可以被度量根据组件接口、行为、和属性规范的完整性。

其它测量的评估过程包含扩展到的那个组件的需求已经被验证并集成到系统中,并扩展的那个系统已经被验证来满足它的需求。测试用例和验证状态可以被绘制在模型中，并被使用作为这种评估的一个基础。

1. 1. 1. 1. 完成设计和开发的预估工作是什么来?

系统工程成本模型(COSYSMO)被使用来尝试来执行系统工程活动的预估成本。这个模型包含规模和可生产性参数,其中规模预估工作量多少,和可生产性参数被应用来到一个实际进行工作的劳动预估。

当使用基于模型的方法时,规模参数可以被标识在模型中，根据不同类型的建模构件的数目，可以包含下面的:

# Model elements

# Requirements

# Use cases

# Scenarios

# States

# System and component interfaces

# System and component activities or operations

# System and component properties

# Components by type (e.g., hardware, software, data, operational procedures)

# Constraints

# Test cases

测量也应该计数这些模型元素之间联系,诸如，被满足的需求数量、被验证的需求数量、被实现的用户案例、被分配到的模块的活动数目、和已经被执行的分析的数目。

MBSE规模参数被集成到成本模型中。参数可以与它们关联的复杂性因素有关。例如,一个用例的复杂性可以被指定通过参与交互的参与者的数目。附加的因素将被考虑是重用的和已存在模型的修改，和生成新的模型的数目。

随着时间的推移，规模和可生产性参数需要被收集和确认，建立统计学上有意义的数据并评估与成本关系，来支持准确的成本估算。然而,MBSE早期的使用可以标识明显地贡献到建模工作的规模参数，并使用这个数据进行局部预估，和来评估随着时间生产性的提高。

1. 1. 1. 其它基于模型的测量

先前的讨论的是基于模型的测量的一些样本，它们可以被定义。许多其它测量也可被衍生从模型,诸如，随着时间需求和设计变更数量的稳定性、或潜在缺陷率。测量也可被衍生来建立尺度从它来测量MBSE益处，描述在第2.1.2节,诸如，生产性的提高随着MBSE应用的实践逐渐提高。这些测量应该被定义并捕捉来支持MBSE的业务情形。第19.1.1节包含一个附加的测量关联部署MBSE在一个组织中。

1. 1. 小结

像许多其它工程学科一样，系统工程实践正从基于文档的方法转变到基于模型的方法,诸如，机械和电子工程已经进行过的。MBSE提供明显潜在的好处是：增强规范和设计质量和一致性、规范和设计构件的重用、并增强开发团队之间的交流、整体提高质量、可生产性、并降低开发风险。MBSE的重点是来生成和控制一个连贯的系统模型,并使用这个模型来规范和设计系统。建模可以支持许多目的,诸如，表示一个系统概念或明确说明系统的组件。一个好的模型满足它的预期目标,并且模型的范围在建模工作约束的资源内应该支持它的目标。一个模型的质量属性,诸如，模型一致性、可理解性、和格式良好的、和建模约定的使用、可以被用来评估一个模型的有效性并驱动优选最佳的建模实践。MBSE测量可以被用来评估设计质量、进度和风险、并支持管理开发工作

1. 1. 问题
2. MBSE和基于文档的方法之间的主要区别是什么?
3. MBSE优于基于文档的方法的一些关键点是什么?
4. 一个系统模型的模型元素存储在哪里?
5. 模型的那个方面可以被用来定义模型的范围?
6. 什么构成一个有效的模型?
7. 一个有效模型的一些质量属性是什么?
8. 好的模型和好的设计之间的不同是什么？
9. MBSE测量可以帮助回答的问题的例子是什么?
10. 什么是可能的规模参数，其可以被用来预估一个MBSE工作?