用模型表示系统-Lib教程

建模和分析可以补充在生命周期后期发生的测试和评估。在一些系统中，建模和仿真可能是全面评估性能(例如，弹道导弹防御)或评估严重场景下系统性能(例如，对本土大规模杀伤性武器攻击的响应)的唯一方法。此外，高级模拟，如飞行模拟器和指挥控制中心模拟，可以是一种具有成本效益的技术，用于伴随操作系统培训的人员培训(INCOSE 2012)。

建模可以使概念具体化和形式化，提高质量、生产力、文档化和创新，以及降低系统开发的成本和风险。

建模发生在许多级别:组件、子系统、系统和系统中的系统;以及整个系统的生命周期。为了支持系统的分析、规范、设计和验证，可能需要不同类型的模型来表示系统。这个知识领域提供了用于表示系统不同方面的模型的概述。

建模是一种常见的实践，被大多数工程学科所共享，包括:

电气工程，使用电路设计模型
机械工程，使用三维计算机辅助设计模型
软件工程，使用软件设计和架构模型。

这些学科都有自己的语法和语义语言，作为该学科专业人员之间的交流手段。分析模型用于支持功率、热、结构和嵌入式实时分析。

建模标准在定义系统建模概念方面扮演着重要的角色，这些系统建模概念可以代表特定的感兴趣的领域，并允许跨感兴趣的领域集成不同类型的模型

什么是模型？

本主题提供了基本概念，例如模型和建模语言的定义，并表达了它们与建模工具和基于模型的系统工程 (MBSE) 的关系。

模型的定义

模型这个词有很多定义。以下定义将模型称为建模者感兴趣的领域的选定方面的表示：

系统、实体、现象或过程的物理、数学或其他逻辑表示（DoD 1998）；
可以在物理世界中实现的一个或多个概念的表示（Friedenthal、Moore 和 Steiner 2009）；
系统在某个特定时间或空间点的简化表示，旨在促进对真实系统的理解（Bellinger 2004）；
系统的抽象，旨在理解、交流、解释或设计该系统感兴趣的方面（Dori 2002）；
一些系统的选择性表示，其形式和内容是基于一组特定的关注点选择的；该模型通过显式或隐式映射与系统相关（Object Management Group 2010）。

在系统工程的上下文中，代表系统及其环境的模型对于必须指定、设计、分析和验证系统以及与其他利益相关者共享信息的系统工程师来说尤其重要。各种系统模型用于表示不同类型的系统，用于不同的建模目的。建模系统的一些目的在主题为什么建模？，以及不同类型模型的简单分类在模型类型主题中进行了描述。建模标准主题是指支持 MBSE 的一些标准系统建模语言和其他建模标准。

如上面第一个定义所示，模型可以具有不同的形式，包括物理、数学或逻辑表示。物理模型可以是表示实际系统的模型，例如模型飞机。数学模型可以根据加速度、速度、位置和方向来表示可能的飞行轨迹。逻辑模型可以表示描述飞机故障的潜在原因的逻辑关系，例如发动机故障如何导致动力损失并导致飞机失去高度，或者系统的各个部分如何相互连接。很明显，可能需要许多不同的模型来表示相关利益的系统 (SoI)。

建模语言

物理模型是可以感觉到和触摸的实际系统的具体表示。其他模型可能是系统或实体的更抽象表示。这些模型依赖于建模语言来表达它们的含义，如“ Ontology, Ontologies, Conceptualizations, Modeling Languages, and (Meta)Models ”（Guizzardi 2007）中所述。

就像工程学一样图纸表达了机械和建筑设计的 3D 结构，概念模型是构思、构建、设计和建造系统的手段。生成的模型是机械设计蓝图的对应物。然而，不同之处在于，虽然蓝图是物理工件的精确表示，具有精确、一致的语法和作为专业人员之间交流手段的悠久传统，但概念模型才刚刚开始朝着成为一个完整和明确的方向迈进。表示正在开发的系统。计算机协会 (ACM) (Dori 2003) 通信特别部分中的文章通过概念建模展示了系统分析和架构的抽象世界，以及如何评估、选择、

建模语言通常旨在既是人类可解释的又是计算机可解释的，并根据语法和语义进行指定。

抽象语法指定模型构造和构建模型的规则。对于像英语这样的自然语言，结构可能包括诸如动词、名词、形容词和介词之类的单词类型，并且规则指定了如何将这些单词一起使用以形成正确的句子。数学模型的抽象语法可以指定定义数学函数、变量及其关系的结构。逻辑模型的抽象语法也可以指定定义逻辑实体及其关系的结构。一个格式良好的模型遵循结构规则，就像一个格式良好的句子必须符合自然语言的语法规则一样。

具体语法指定用于表示模型构造的符号。自然语言英语可以用文本或摩尔斯电码表示。建模语言可以使用图形符号和/或文本语句来表达。例如，功能流模型可以使用由图形节点和用文本注释的弧的组合组成的图形符号来表达，而模拟建模语言可以使用诸如C编程语言之类的编程语言文本语法来表达。

语言的语义定义了结构的含义。例如，一个英语单词在定义之前没有明确的含义。类似地，表示为符号的结构，例如流程图上的框或箭头，在定义之前没有意义。语言必须赋予动词或名词的概念以意义，并且必须赋予作为动词或名词的特定词特定的意义。可以通过提供自然语言定义或通过将构造映射到其含义已定义的形式来建立定义。例如，表示 sin(x) 和 cos(x)的图形符号是使用定义良好的正弦和余弦函数的数学形式定义的。如果用 sin(θ) 和 cos(θ) 定义钟摆的位置，则可以根据这些形式来理解钟摆位置的含义。

建模工具

模型由建模者使用建模工具创建。对于物理模型，建模工具可能包括钻头、车床和锤子。对于更抽象的模型，建模工具通常是软件在计算机上运行的程序。这些程序提供了使用特定建模语言表达建模结构的能力。文字处理器可以被视为使用自然语言构建文本描述的工具。以类似的方式，建模工具用于使用建模语言构建模型。该工具通常提供用于选择符号的工具面板和用于从图形符号或其他具体语法构建模型的内容区域。建模工具通常会检查模型以评估它是否符合语言规则并强制执行这些规则以帮助建模者创建格式良好的模型。这类似于文字处理器检查文本以查看其是否符合自然语言的语法规则的方式。

一些建模工具是市售产品，而其他建模工具可以创建或定制以提供独特的建模解决方案。建模工具通常用作构成系统开发环境的更广泛的工程工具集的一部分。越来越强调对标准建模语言的工具支持，使模型和建模信息能够在不同工具之间交换。

模型与基于模型的系统工程的关系

国际系统工程理事会 (INCOSE) ( INCOSE Systems Engineering Vision 2020 2007) 将 MBSE 定义为“建模的形式化应用，以支持从概念设计阶段开始并贯穿整个开发的系统需求、设计、分析、验证和确认活动以及以后的生命周期阶段。” 在 MBSE 中，系统模型是系统工程过程的主要工件，并与系统技术基线的其他部分进行管理、控制和集成. 这与传统的以文档为中心的系统工程方法形成鲜明对比，传统的系统工程方法是管理和控制基于文本的文档和规范。利用基于模型的系统工程方法旨在显着改进系统规范和设计质量，通过在设计过程的早期发现问题来降低系统开发的风险和成本，通过重用系统工件来提高生产力，并改进通信在系统开发和实施团队中。

除了创建模型之外，MBSE 方法通常还包括模型管理方法，旨在确保模型得到适当控制，以及模型验证方法，旨在确保模型准确地表示正在建模的系统。

联合发起的 INCOSE/对象管理组 (OMG) MBSE Wiki提供了有关 INCOSE MBSE 倡议的更多信息，包括 MBSE 的一些应用以及与 MBSE 相关的一些关键主题，例如关于方法和度量以及模型管理的部分。

由国防工业协会 (NDIA) 系统工程部建模和仿真委员会编写的基于模型的工程 (MBE) 小组委员会的最终报告强调了模型的许多好处、风险和挑战—— 基于方法，并包括许多对 MBE 案例研究的参考（NDIA 2011）。

系统建模语言和方法

已经开发和部署了许多系统建模方法和相关的建模语言，以支持系统分析、设计和实现的各个方面。功能建模语言包括数据流图 (DFD) (Yourdon 和 Constantine 1979)、功能建模集成定义 (IDEF0) (Menzel 和 Maier 1998) 和增强功能流框图 (eFFBD)。其他行为建模技术包括经典的状态转换图、状态图（Harel 1987）和过程流程图。结构建模技术包括数据结构图 (Jackson 1975)、实体关系图 (Chen 1976) 和对象建模技术 (Rumbaugh et al. 1991)，它们结合了对象图、DFD 和状态图。

2008 年，Estefan 对系统建模方法、过程和工具进行了广泛调查，并将结果记录在基于模型的系统工程 (MBSE) 方法的调查(Estefan 2008) 中。该调查确定了几种候选 MBSE 方法和建模语言，可用于支持 MBSE 方法。其他建模方法可从MBSE Wiki 的 Methodology and Metrics 部分获得。建模标准部分是指支持 MBSE 的一些标准系统建模语言和其他建模标准。自 Estefan 的报告以来，已经进行了许多调查以了解基于模型的系统工程的接受度和障碍（Bone 和 Cloutier 2010、2014；Cloutier 2015）。

为什么是模型？

系统模型可用于多种用途。本主题重点介绍了其中的一些目的，并在基于模型的系统工程 (MBSE) 的背景下提供了有效模型的指标。

模型的目的

模型是可以帮助定义、分析和交流一组概念的表示。系统模型专门开发用于支持系统的分析、规范、设计、验证和确认，以及传达某些信息。建模的首要原则之一是明确定义模型的目的。模型可以在整个系统生命周期中服务的一些目的是：

表征现有系统： 许多现有系统的文档记录很差，对系统进行建模可以提供一种简洁的方法来捕获现有系统设计。然后，此信息可用于促进系统维护或评估系统以改进系统。这类似于在将其升级到新标准以抵御地震之前，创建一个带有电气、管道和结构覆盖层的旧建筑物的建筑模型。
任务和系统概念制定和评估： 模型可以在系统生命周期的早期应用，以综合和评估替代任务和系统概念。这包括清楚明确地定义系统的使命和预期为其受益者带来的价值。模型可用于通过对替代系统设计进行建模并评估关键系统参数（如重量、速度、准确性、可靠性和成本）对整体价值衡量标准的影响来探索交易空间。除了限制系统设计参数外，模型还可用于验证系统要求是否满足在进行后续生命周期活动（例如综合详细的系统设计）之前，利益相关者的需求。
系统设计综合和需求流程化： 模型可用于支持架构系统解决方案，以及将任务和系统需求流程化到系统组件。可能需要不同的模型来解决系统设计的不同方面并响应广泛的系统要求。这可能包括指定功能、接口、性能和物理要求的模型，以及其他非功能性要求，如可靠性、维护性、安全性和安全性。
支持系统集成和验证： 模型可用于支持将硬件和软件组件集成到系统中，以及支持验证系统是否满足其要求。这通常涉及将较低级别的硬件和软件设计模型与验证系统要求是否得到满足的系统级设计模型相集成。系统集成和验证还可能包括用实际的硬件和软件产品替换选定的硬件和设计模型，以逐步验证系统要求是否得到满足。这被称为硬件在环测试和软件在环测试. 模型还可用于定义测试用例（词汇表）和测试程序的其他方面，以帮助测试计划和执行。
培训支持： 模型可用于模拟系统的各个方面，以帮助培训用户与系统进行交互。用户可能是操作员、维护者或其他利益相关者。模型可以作为开发具有不同保真度的系统模拟器的基础，以表示不同使用场景中的用户交互。
知识获取和系统设计演化： 模型可以提供一种有效的方法来获取有关系统的知识并将其作为组织知识的一部分保留。这些可以重用和演进的知识为支持系统演进提供了基础，例如面对新兴的相关技术、新应用和新客户时不断变化的系统需求。模型还可以捕获产品系列。

有效模型的指标

当建模做得好时，模型的目的是明确的和明确的。可以根据模型支持这些目的的有效性来评估模型的价值。本节的其余部分以及模型类型、系统建模概念和建模标准等主题描述了有效模型的指标（Friedenthal、Moore 和 Steiner 2012）。

型号范围

该模型的范围必须能够满足其预期目的。特别是，所选的模型类型和相关的建模语言必须支持要满足的特定需求。例如，假设构建模型以支持飞机的开发。系统架构模型可以描述飞机部件之间的互连，轨迹分析模型可以分析飞机轨迹，故障树分析模型可以评估飞机故障的潜在原因。

对于每种类型的模型，应确定适当的广度、深度和保真度，以解决模型的预期目的。模型广度反映了系统需求覆盖范围，即模型必须满足功能、接口、性能和物理需求以及其他非功能性需求（如可靠性、可维护性和安全性）的程度。对于飞机功能模型，可能需要模型宽度来解决启动、起飞、飞行、着陆、断电和维护飞机环境的部分或全部功能要求。

模型的深度表示从系统上下文到系统组件的系统分解覆盖范围。以飞机为例，模型的范围可能要求它定义系统环境，范围从飞机、控制塔和物理环境，到导航子系统及其组件，例如惯性测量单元；或许还包括惯性测量单元的低级部分。

模型的保真度表示模型必须为模型的任何给定部分表示的详细程度。例如，指定系统接口的模型可能相当抽象，只表示逻辑信息内容，例如飞机状态数据；或者它可能更详细，以支持更高保真度的信息，例如根据比特、字节和信号特征对消息进行编码。保真度也可以指计算模型的精度，例如模拟所需的时间步长。

模型质量指标

模型的质量不应与模型所代表的设计质量相混淆。例如，一个人可能有一个高质量的、计算机辅助的椅子设计模型，该模型准确地代表了椅子的设计，但设计本身可能存在缺陷，以至于当一个人坐在椅子上时，它就会分崩离析。高质量的模型应提供足以帮助设计团队评估设计质量和发现设计问题的表示。

模型质量通常根据模型对建模指南的遵守情况以及模型满足其预期目的的程度来评估。建模指南的典型示例包括命名约定、应用适当的模型注释、正确使用建模构造以及应用模型重用注意事项。对于不同类型的模型，具体的指导方针是不同的。例如，使用计算机辅助设计工具开发几何模型的指南可能包括定义坐标系、尺寸标注和公差的约定。

基于模型的指标

模型可以提供大量信息，这些信息可用于技术和管理指标，以评估建模工作，在某些情况下，还可用于评估整个系统工程(SE) 工作。不同类型的模型提供不同类型的信息。通常，模型提供的信息使人们能够：

评估进展；
估算工作量和成本；
评估技术质量和风险；
评估模型质量。

模型可以捕获类似于传统的基于文档的系统工程方法中捕获的度量，但考虑到模型与文档相比更准确的性质，可能具有更高的精度。集成系统和产品开发的度量指南（Wilbur 2005）中描述了传统的系统工程度量。

可以根据模型工作相对于模型定义范围的完整性来评估模型的进度。模型也可用于根据设计满足要求或通过测试验证的程度来评估进度。当增加生产力指标时，该模型可用于估计执行所需系统工程工作以交付系统的成本。

模型可用于识别关键系统参数并根据这些参数中的任何不确定性评估技术风险。这些模型还可用于提供与其目的相关的附加指标。例如，当模型的目的是支持任务和系统概念的制定和评估时，一个关键指标可能是在指定时间段内探索的替代概念的数量。

模型类型

有许多不同类型的模型用不同的建模语言和工具集来表示。本文提供了模型类型的分类，并强调了不同的模型必须如何协同工作以支持更广泛的工程工作。

模型分类

有许多不同类型的模型和相关的建模语言来处理系统的不同方面和不同类型的系统。由于不同的模型服务于不同的目的，对模型进行分类对于根据预期的目的和范围选择正确的模型类型是有用的。

形式模型与非形式模型

由于系统模型是系统的表示，许多形式主义不同程度的表达式可以被认为是模型。特别是，人们可以画一个系统的图，并把它看作一个模型。类似地，人们可以用文本描述一个系统，并将其称为模型。两个例子都是一个系统的表示。但是，除非对这些术语的含义有某种一致意见，否则表述可能缺乏精确性，也可能含糊不清。

系统建模的主要焦点是使用由定义良好的建模语言支持的模型。虽然不太形式的表示可能有用，但是模型必须满足特定的期望，以便在基于模型的系统工程(MBSE)的范围内被考虑。特别地，初始分类将非形式模型和形式模型区分开来，这是由具有相关领域的已定义语法和语义的建模语言所支持的。

物理模型vs抽象模型

美国“国防部建模和仿真(M&S)术语表”断言“一个模型可以是一个系统的物理、数学或其他逻辑表示”(1998)。这个定义为高级模型分类提供了一个起点。物理模型是一种具体的表示，区别于数学模型和逻辑模型，它们都是系统的更抽象的表示。抽象模型可以进一步分类为描述性(类似于逻辑)或分析性(类似于数学)。图1中显示了一些示例模型。

描述模型

描述性模型描述了逻辑关系，例如定义其部件树的系统整体-部件关系、部件之间的互连、部件执行的功能或用于验证系统需求的测试用例。典型的描述模型可能包括那些描述系统的功能或物理架构，或系统的三维几何表示的模型。

分析模型

分析模型描述了数学关系，例如支持对系统参数进行量化分析的微分方程。分析模型可以进一步分为动态模型和静态模型。动态模型描述系统的时变状态，而静态模型执行不代表系统时变状态的计算。动态模型可以表示系统的性能，例如随着时间的推移飞机位置、速度、加速度和燃料消耗。静态模型可以表示系统或组件的质量属性估计或可靠性预测。

混合描述和分析模型

特定模型可能包括如上所述的描述性和分析性方面，但模型可能偏爱一个方面或另一个方面。还可以分析描述性模型的逻辑关系，并可以对系统进行推理。然而，逻辑分析提供了与系统参数的定量分析不同的见解。

特定领域的模型

描述性和分析性模型都可以根据它们所代表的领域进一步分类。以下分类部分源自关于OWL、Ontologies 和 SysML Profiles 的介绍：知识表示和建模（Web Ontology Language (OWL) & Systems Modeling Language (SysML)）（Jenkins 2010）：

系统的属性，例如性能、可靠性、质量属性、功率、结构或热模型；
设计和技术实施，例如电气、机械和软件设计模型；
子系统和产品，例如通信、故障管理或配电模型；
系统应用，例如信息系统、汽车系统、航空航天系统或医疗设备模型。

模型分类、术语和方法通常适用于特定的应用领域。例如，在对组织或业务进行建模时，行为模型可以称为工作流或流程模型，而绩效建模可以指与组织或业务流程相关的成本和进度绩效。

单个模型可能包含上述列表中的多个域类别。例如，可以为航空航天系统（例如飞机或卫星）的通信子系统的电气设计定义可靠性、热和/或功率模型。

系统模型

系统模型可以是描述性和分析性的混合模型。它们通常跨越多个建模领域，这些领域必须进行集成，以确保一致且内聚的系统表示。因此，系统模型必须提供通用系统构造和跨建模域共享的领域特定构造。系统模型可以包括多个视图，以支持规划、需求、设计、分析和验证。

Wayne Wymore 在《系统工程的数学理论：元素》（Wymore 1967）中使用数学框架形式定义系统模型的早期努力之一受到赞誉。 Wymore 建立了一个严格的数学框架，用于在基于模型的环境中设计系统。他的工作总结可以在 A Survey of Model-Based Systems Engineering (MBSE) Methodologies中找到。

模拟与模型

术语模拟，或更具体的计算机模拟，指的是随着时间的推移实现模型的方法（DoD 1998）。计算机模拟包括以可执行代码表示的分析模型、输入条件和其他输入数据以及计算基础设施。计算基础设施包括执行模型所需的计算引擎，以及输入和输出设备。从计算机模拟设计者必须做出的选择中可以明显看出计算机模拟的多种方法，其中包括：

随机的或确定的；
静态或动态；
连续的或离散的；
本地或分布式。

模拟的其他分类可能取决于正在模拟的模型的类型。一个例子是基于代理的模拟，它模拟自主代理之间的交互以预测复杂的紧急行为（Barry 2009）。还有许多其他类型的模型可用于进一步对模拟进行分类。一般来说，仿真提供了一种分析系统、软件、硬件、人员和物理现象的复杂动态行为的方法。

模拟通常与系统的实际硬件、软件和操作员集成，以评估系统的实际组件和用户在模拟环境中的性能。在美国国防界，通常将模拟称为现场、虚拟或建设性模拟，其中现场模拟是指现场操作员操作真实系统，虚拟模拟是指现场操作员操作模拟系统，建设性模拟是指模拟操作员使用模拟系统进行操作。虚拟的和建设性的模拟还可以包括循环中的实际系统硬件和软件以及来自真实系统环境的刺激。

除了表示系统及其环境之外，仿真还必须提供有效的计算方法来求解方程。模拟可能需要实时操作，尤其是在循环中有操作员的情况下。其他模拟可能需要运行得比实时快得多，并执行数千次模拟运行以提供统计上有效的模拟结果。模拟建模和分析（Law 2007）中描述了几种计算和其他模拟方法。

可视化

计算机模拟结果和其他分析结果通常需要进行处理，以便以有意义的方式呈现给用户。可视化技术和工具用于以各种可视形式显示结果，例如系统状态与时间的简单图以显示参数关系。当多个模拟执行的输入和输出值显示在响应面上，显示输出对输入的敏感度时，就会发生这种情况的另一个示例。可以执行结果的附加统计分析以提供所选参数值的概率分布。动画通常用于提供系统及其动态行为的虚拟表示。例如，

模型集成

可以开发许多不同类型的模型作为 MBSE 工作的工件。为组件设计和分析创建了许多其他特定领域的模型。为了充分实现基于模型的方法的好处，必须整合不同的描述和分析模型。 MBSE 作为跨多个领域集成的模型的作用是国际系统工程委员会 (INCOSE) INCOSE 系统工程愿景 2020 (INCOSE 2007) 的主要主题。

例如，系统模型可用于指定系统的组件。系统架构的描述模型可用于识别和划分系统的组件并定义它们的互连或其他关系。性能、物理和其他质量特性（例如可靠性）的分析模型可用于确定特定组件属性所需的值以满足系统要求。表示系统组件交互的可执行系统模型可用于验证组件需求能否满足系统行为需求。描述性、分析性和可执行系统模型各自代表同一系统的不同方面。

组件设计必须满足系统模型指定的组件要求。因此，组件设计和分析模型必须具有某种程度的集成，以确保设计模型可追溯至需求模型。电气、机械和软件的不同设计学科各自创建自己的模型，代表同一系统的不同方面。很明显，不同的模型必须充分集成以确保系统解决方案的凝聚力。

为了支持集成，模型必须建立语义互操作性，以确保一个模型中的构造与另一个模型中的相应构造具有相同的含义。该信息也必须在建模工具之间交换。

语义互操作性的一种方法是使用不同模型之间的模型转换。定义了在一个模型中的概念与另一个模型中的概念之间建立对应关系的转换。除了建立对应关系之外，工具还必须具有交换模型数据和共享转换信息的方法。在工具之间交换数据有多种方式，包括文件交换、应用程序接口 (API) 的使用和共享存储库。

使用建模语言、模型转换和数据交换的建模标准是跨建模领域集成的重要推动力。

系统建模概念

系统模型表示系统及其环境的各个方面。有许多不同类型的模型，因为它们的构建目的多种多样。有一种共同的方式来讨论许多不同类型模型背后的概念是很有用的（例如，许多建模技术能够理解系统行为，而其他建模技术能够理解系统结构）。本文重点介绍了用于建模系统的几个概念。

抽象

也许系统建模中最基本的概念是抽象，它涉及隐藏不重要的细节，以便专注于基本的特征。值得建模的系统有太多的细节，以至于无法合理地建模。除了系统可能具有的纯粹的规模和结构复杂性之外，系统在行为上也可能是复杂的，具有突发性属性、非确定性行为和其他难以描述的属性。因此，为了在计算和智力上易于处理，模型必须集中在几个重要的特征上。建模技术通过各种形式的抽象来解决这种复杂性。例如，一个模型可能假设某一特定类型的许多单个组件的结构特征都是相同的，忽略了在现实生活中发生的情况下个体之间的小顺序差异。在这种情况下，这些差异被假定为对这些组件的结构完整性建模不重要。当然，如果这个假设是错误的，那么这个模型就可能导致对结构完整性的错误信心。在建模不同的抽象级别时，有两个关键的概念被应用，它们是:视图和视点，以及黑盒和白盒建模，下面将对此进行描述。虽然这两种建模方法被广泛认可，但是不同的建模语言和工具也使用其他技术。

视图和视点

IEEE 1471 是一种架构建模标准，定义“view”和“viewpoint”如下：

视图 - 从一组相关关注点的角度对整个系统的表示。
视点 - 构造和使用视图所需的约定规范；一种模式或模板，通过建立视图的目的和受众以及创建和分析视图的技术来开发单个视图。

黑盒和白盒模型

一种非常常见的抽象技术是将系统建模为一个黑盒，它只暴露了外部观察者可见的系统特性，而隐藏了设计的内部细节。这包括外部可见的行为和其他物理特征，例如系统的质量或重量。另一方面，系统的白盒模型显示了内部结构并显示了系统的行为。为了创建每个系统组件的黑盒和白盒模型，黑盒和白盒建模可以应用到设计分解的下一个级别。模型。

概念模型

概念模型是一个系统中的一组概念，以及这些概念之间的关系(例如，视图和视点)。一个系统概念模型使用一个图类型(例如在对象过程方法论(OPM)中)或多个图类型(例如在系统建模语言(SysML)中)来描述系统的各个方面。概念模型可能包括它的需求、行为、结构和属性。此外，一个系统概念模型伴随着每个概念的一组定义。有时候，系统概念模型是使用实体关系图、对象过程图(OPD)或统一建模语言(UML)类图来定义的。

一个系统工程的初步概念(或概念)模型(系统工程概念模型)是为了支持面向对象管理组织(OMG) SysML和国际标准化组织(ISO) AP233系统工程数据交换标准(ISO)的开发的集成工作而开发的2010)。概念模型最初是以一种非正式的方式获得的;然而，模型和相关的概念被系统工程社区的广泛代表严格地审查了，包括来自国际系统工程理事会(INCOSE)、AP233和SysML开发团队的成员。

来自顶层系统工程概念模型的片段包含在图1中。该模型提供了需求、行为、结构和系统属性的概念，以及系统工程和项目管理(例如涉众)所共有的其他概念。概念模型通过定义良好的术语表(称为语义词典)进行扩充。概念模型和语义字典对用UML编写的OMG系统建模语言的需求做出了很大的贡献。

概念模型有时称为元模型、域元模型或模式，可用于指定建模语言的抽象语法（请参阅模型驱动架构 (MDA®) 基础模型 (OMG 2010 ））。已经开发了几个其他系统工程概念模型，但尚未标准化。未来的标准化工作应该建立一个标准的系统工程概念模型。随着系统工程社区继续形式化和推进系统工程实践，该模型可以随着时间的推移而发展。

将支持方面的功能集成到系统模型中

本文讨论了使用基于模型的系统工程方法和框架对系统和支持方面的功能进行集成建模。系统工程的支持方面包括：

工程管理
项目管理
需求工程与管理
风险建模、分析和管理
质量保证、测试、验证和确认
系统集成与使用
分析“-ilities”（例如，可靠性、可用性、可维护性、安全性和安保 (RAMSS)、可制造性、可扩展性、稳健性、弹性、灵活性和可演化性）

这些方面可以涉及物理方面，也可以涉及核心系统模型的功能、结构、行为、社会和环境方面。文章主要关注三个方面：

项目和工程管理
风险建模、分析和管理
需求定义和管理

背景

基于模型的系统工程方法认为系统模型不仅仅是对系统的简单描述；该模型是捕获、表示和集成上面列出的各个系统方面的中心通用基础。该模型对于系统的设计和理解以及管理其生命周期和演化至关重要。建模语言构成了系统标准化、形式化描述的基础，就像自然语言构成人类交流的基础一样。

随着系统逐渐变得更加复杂和多学科，系统的概念建模需要发展，并且对于理解复杂设计将变得更加关键（Dori 2002）。除了促进客户、设计师和开发人员之间的交流外，概念建模语言还有助于清楚地描述和记录各种领域、系统和问题，并为设计和开发阶段定义要求和约束（Wand 和 Weber 2002）。各种概念建模方法和框架证明了基于模型的分析的重要性，尽管 事实上 标准出现缓慢。虽然工程设计的某些学科，如结构分析或电路设计，已经建立了建模语义和符号，但复杂系统和过程的概念建模还没有融合到一个统一的、统一的建模框架上（Estefan 2007）。挑战不仅在于整合多个方面并支持系统生命周期的各个阶段，还在于捕捉系统的多学科性质，这导致了各种框架的创建。然而，信息系统分析范式目前是最广泛使用的，这可能是由于需要通过信息密集型应用程序和交互来集成复杂系统。

系统和项目的集成建模

本节讨论系统和项目的集成建模以及项目-系统关系（通常称为项目-产品集成）。项目管理和系统工程领域由于理解成功的项目创造了成功的系统，因此在过去的二十年中一直在携手推进。许多主要的系统工程资源都非常重视项目管理，并将其视为系统工程的关键过程和推动者（INCOSE 2012；NASA 2007；Sage 和 Rouse 2011）。将系统相关方面和概念集成到项目计划中比将项目相关方面和概念集成到系统模型中更为常见。因为项目是达到目的的手段，所以它是预期交付系统的过程。事实上，项目活动通常以其旨在促进的可交付成果（例如，“控制台设计”、“软件开发”、“硬件采购”或“车辆组装”）命名或与其一致。

与这些示例中的每一个相关的特定过程是指项目的不同阶段或阶段，以及它所应用的系统或子系统的不同成熟度级别。此外，仅在活动名称中包含系统和部件名称并不能真正将系统模型工件与这些活动相关联。总体而言，实际上不可能推导出与将由项目交付的系统的特定部分或功能相关联的活动集。项目-产品集成并不简单，因为项目模型和系统模型在传统上是完全不同的并且几乎没有接口。基于模型的项目系统集成方法遵循以系统为中心的范式，并侧重于将与项目相关的方面和概念合并到核心系统模型中，与上一段中描述的以项目为中心的方法相反。这些方面和概念包括进度、预算和资源、可交付成果、工作包、约束和以前的关系。集成的系统-项目模型应该提供有关项目活动和系统组件和能力的相互影响的有用信息。集成系统项目建模的一些示例包括：

与特定系统组件、特性或能力相关的一组项目活动。
执行设计或开发系统特定组件的任务所需的一组资源。
负责交付每个系统组件的团队或分包商。
系统组件部署活动之间预先存在的依赖关系。
与每个系统组件、特性或功能相关的成本。
为每个交付、部署、构建、发布或版本协商的系统部分。

工作分解结构 (WBS) 旨在支持在参与项目的个人和组织之间划分项目范围（工作内容）（Golany 和 Shtub 2001）。 WBS 传统上是面向组织或活动的；然而，它的主要基石之一侧重于可交付成果，它对应于系统、子系统、组件或其中一个或多个的能力或特性。提倡以可交付成果为导向的 WBS，其中高级元素对应于主要子系统，因为它可能使 WBS 更加以产品为导向（Rad 1999）。项目规划和系统建模的集成方法（Sharon 和 Dori 2009）使用对象过程方法（OPM）将系统模型与项目的 WBS 合并（Dori 2002）。

设计结构矩阵 (DSM) 是增强和分析产品和系统设计的常用方法。 DSM 可以是基于组件的、基于任务的、基于参数的或基于团队的（Browning 2001）。基于 OPM 的项目-产品模型的 DSM 从统一的 OPM 模型中派生项目活动和系统构建块的混合 DSM，考虑项目活动和系统组件之间的依赖关系，并替换两个单一的和单独的基于组件的和基于任务的 DSM 视图（Sharon、De-Weck 和 Dori 2012）。底层 OPM 模型确保模型的一致性和可追溯性。集成的项目-产品 OPM 模型包括图表和等效的自动生成的文本描述。

另一种基于模型的方法 (Demoly et al. 2010) 使用系统建模语言 (SysML) 来创建满足各种系统利益相关者（例如项目/流程经理）需求的各种视图。该方法包括面向产品和面向过程的视图。

系统和需求的集成建模

需求是描述系统的操作、功能或设计相关方面的陈述。需求定义和管理是一个重要的 SE 过程，因为它通过定义工程系统的预期功能和性能来启动和促进整个 SE 工作。与需求相关的几个挑战包括：

以结构化、受控的方式定义需求。
将这些需求跟踪到系统组件、方面和决策。
测试和验证系统是否符合这些要求。

将概念系统模型扩展到包括需求有几个显着的好处：

需求通过根据特定需求制定和证明体系结构和设计决策，为系统的体系结构和设计提供基本原理。
对内部逻辑以及需求之间的层次结构和依赖关系进行建模，可以识别和消除冗余和矛盾的需求。
负责交付各种系统组件的团队和人员通常可以负责满足特定要求。虽然拥有良好的需求工程的优势是显而易见的，但将需求直接跟踪到特定的系统工件通常是一个挑战，尤其是当需求以整体的、独立于解决方案的方式定义时。

有几种方法可以将需求合并到系统模型中，包括 SysML 需求工程和基于对象过程方法 (OPM) 的需求工程和创作。

基于 SysML 的需求工程

SysML 需求图使得以可视化的方式捕获需求及其之间的关系成为可能，这比传统编辑和管理需求的文本方式更直观。该图已添加到构成 SysML 基础的基本 UML 图集（Friedenthal、Moore 和 Steiner 2006），而不是原生 UML 图。可以在 SysML 块定义图中捕获对系统块和满足它们的工件的跟踪需求，该图主要用于捕获系统元素和组件类型之间的关系。块和需求之间的 < > 链接捕获跟踪。

基于 OPM 的需求工程

对象-过程方法论 (OPM) 是一种方法论和语言，用于复杂系统和过程的概念建模，具有双峰文本和图形表示 (Dori 2002)。 OPM 的文本表示与图形表示相协调；此外，对象-过程图 (OPD) 中的每个视觉模型构造都由对象-过程语言 (OPL) 中的正式结构化文本语句描述，该语言是自然英语的子集。 OPM 以三种可能的模式促进基于模型的需求工程、创作和规范：

OPM 可用于生成最初关注需求级别（问题域，而不是设计级别或解决方案域）的概念模型，这有助于基于模型的自动化需求生成（Blekhman 和 Dori 2011）。需求模型是解决方案中立的，它可以作为一个或多个架构解决方案的基础，以实现需求中指定的功能。
OPM 可用于生成面向需求的 OPD，其方式类似于 SysML 需求图使工程师能够将需求规范捕获为系统模型的骨架。用户定义的标记结构关系，例如“被实现”或“分配给”，提供将需求与系统模型功能（转换它们的对象和过程）相关联。这种方法类似于 SysML 需求图；但是，在单独的图表类型中使用独特的符号，需求被无缝地结合到单个系统模型中。
OPM 可用于通过将文本编写的需求跟踪到系统模型插入和工件来从正式指定的需求生成视觉系统模型（Dori 等人，2004 年）。

将风险整合到系统模型中

风险是对不确定性的负面或不利影响的表达和衡量。只要不确定性会导致多种结果，其中一些可能是负面的（不利的），一些可能是正面的，就会存在风险。一个系统面临来自其他系统或环境的风险，它也可能对其他系统或环境造成风险。系统具有这样的属性，例如：目标、目的、输入、输出、变量、参数、过程、事件、状态、子系统、接口、机制和方法。系统脆弱性是系统在这些属性中的任何一个方面受到伤害或负面影响的总可能性。类似地，系统有害性是系统伤害他人或产生负面影响的总潜力，可以体现在这些属性中的一个或多个中（Haimes 2009）。基于模型的风险分析 (MBRA) 支持结构化分析和与风险相关的过程控制。文献中提供了几种基于模型的风险分析方法。 MBRA 目前在信息技术和信息安全领域比在系统工程领域更常见；但是，其中一些方法通常也适用于复杂系统。 ISO-IEC-IEEE 协作软件开发和运营生命周期标准（ISO 和 IEC 2004）提出了一种并行的 IT 风险管理方法。这种方法包括六项主要活动： MBRA 目前在信息技术和信息安全领域比在系统工程领域更常见；但是，其中一些方法通常也适用于复杂系统。 ISO-IEC-IEEE 协作软件开发和运营生命周期标准（ISO 和 IEC 2004）提出了一种并行的 IT 风险管理方法。这种方法包括六项主要活动： MBRA 目前在信息技术和信息安全领域比在系统工程领域更常见；但是，其中一些方法通常也适用于复杂系统。 ISO-IEC-IEEE 协作软件开发和运营生命周期标准（ISO 和 IEC 2004）提出了一种并行的 IT 风险管理方法。这种方法包括六项主要活动：

规划和实施风险管理
管理项目风险概况
进行风险分析
执行风险监控
进行风险处理
评估风险管理流程

这些活动同时执行，相互影响和提供反馈，并与其他软件生命周期过程交互，例如技术管理和设计过程（ISO 和 IEC 2004）。

CORAS 方法（Fredriksen 等人 2002；den Braber 等人 2006；Lund、Solhaug 和 Stølen 2011）是一种用于 IT 安全风险建模和评估的 UML 衍生工具。该框架主要由 UML 用例 (UC) 图组成，并针对误用情况进行了扩展。为了捕捉风险来源、影响和结果，在 UC 符号中添加了额外的符号（例如，“坏演员”图标、风险资产的钱袋子）。例如，滥用图表可能包括因信息盗窃和不忠员工的分发而导致专有技术丧失法律保护的风险。对导致上述风险的安全策略不足的风险源的处理在单独的处理图中进行了说明。

基于组件的系统的定量风险评估方法（Grunske 和 Joyce 2008）支持使用模块化攻击树进行组件漏洞分析和规范。此外，它还提供攻击者分析，从而支持使用计量经济学方法来应对风险。该方法利用 SysML 作为其基础语言，特别是 SysML 块定义图和参数图，以便捕获参数关系和约束作为定义风险概况的一种手段。

系统理论事故模型和过程 (STAMP) 是一种用于安全系统和组件设计的方法 (Leveson 2011)。 STAMP 将安全问题重新表述为控制问题，而不是可靠性问题。 STAMP 针对以安全为导向的系统工程和设计以及避免和减轻危险进行了优化，特别是在复杂的社会技术系统中。还提出了基于模型的 STAMP 改编（Leveson 2004）并在各种安全关键和任务关键系统中实施，包括飞机防撞系统 (CAS) (Leveson 2004) 和弹道导弹防御系统 (Pereira, Lee,和霍华德 2006）。面向风险的系统工程 (ROSE) (Mordecai and Dori 2013) 是一种基于对象过程方法 (OPM) 的方法，用于将风险集成到系统模型中。以系统为中心， ROSE 负责在核心系统模型之上并与核心系统模型同步捕获风险层和方面，同时改进并使其免受捕获的风险的影响，并通过设计生成系统稳健性和弹性以响应各种风险构成场景。风险处理元模型包括设计阶段的风险缓解和运营阶段的风险响应。

建模标准

需要不同类型的模型来支持系统的分析、规范、设计和验证。建模标准的发展使得基于模型的系统工程(MBSE)的广泛采用成为可能。

建模标准的动机

建模标准在定义一致同意的系统建模概念方面扮演着重要的角色，这些系统建模概念可以表示特定的感兴趣的领域，并支持跨感兴趣的领域集成不同类型的模型。建模标准对于支持MBSE是非常重要的，MBSE旨在跨各种学科、产品和技术集成各种系统方面。

系统建模语言的标准可以支持跨学科、跨项目和跨组织的交流。这种交流可以减少只需要了解特定系统的从业者的培训需求，并支持系统工件的重用。与其他系统工程标准一样，标准建模语言也为推进系统工程实践提供了一个共同的基础。

建模标准的类型

许多不同的标准适用于系统建模。建模标准包括建模语言标准、模型之间的数据交换标准，以及将一个模型转换为另一个模型以实现语义互操作性的标准。每种类型的模型都可以用来表示系统的不同方面，例如表示一组系统组件及其互连和接口，或者表示一个支持性能分析或可靠性分析的系统。

以下是具有代表性的建模标准的部分列表，其中还包括通用首字母缩略词（如适用），以及关于在何处可以找到有关该主题的其他信息的参考。

系统建模语言

描述性模型 - 这些标准适用于系统的一般描述性建模：

功能流程图 (FFBD)（Oliver、Kelliher 和 Keegan 1997）
功能建模的集成定义 (IDEF0) (NIST 1993)
对象过程方法 (OPM) [ [1] ] (Dori 2002; ISO/PAS 19450:2015)
系统建模语言 (SysML) (OMG 2010a)
美国国防部架构框架 (DoDAF) 和英国国防部架构框架 (MODAF) 的统一配置文件 (OMG 2011e)
Web 本体语言 (OWL) (W3C 2004b)

分析模型和模拟 - 这些标准适用于分析模型和模拟：

分布式交互仿真 (DIS) (IEEE 1998)
高级架构 (HLA) (IEEE 2010)
Modelica（Modelica 协会 2010）
可执行统一建模语言 (UML) 模型 (FUML) 的基础子集的语义 (OMG 2011d)

数据交换标准

这些标准支持模型之间的信息交换：

系统工程数据交换应用协议 (ISO 10303-233) (AP-233) (ISO 2005)
需求交换格式 (ReqIF) (OMG 2011c)
可扩展标记语言 - (XML) 元数据交换 (XMI) (OMG 2003a)
资源描述框架 (RDF) (W3C 2004a)

通用建模标准

这些标准为建模提供了通用框架：

模型驱动架构 (MDA®) (OMG 2003b)
IEEE 1471-2000 -软件密集系统架构描述的推荐做法 (ANSI/IEEE 2000) (ISO/IEC 2007)

其他特定领域的建模标准

软件设计模型

这些标准适用于建模应用软件和/或嵌入式软件设计：

架构分析和设计语言 (AADL) (SAE 2009)
实时和嵌入式系统的建模和分析 (MARTE) (OMG 2009)
统一建模语言 (UML) (OMG 2010b)

硬件设计模型

这些标准适用于建模硬件设计：

超高速集成电路 (VHSIC) 硬件描述语言 (VHDL) (IEEE 2008)

业务流程模型

这些标准适用于建模业务流程：

业务流程建模符号 (BPMN) (OMG 2011a)

959 次浏览	4次

欢迎参加课程:
	数据建模方法与工具
	MBSE（基于模型的系统工程）
	基于 UML 和EA进行分析设计

< 首页

< 下一页