SysML常见问题解答-建模者

捐助

SysML常见问题解答

翻译：微微

7767 次浏览

2019-10-15

编辑推荐:

文章主要对SysML和MBSE的一些相关问题和解答进行了汇总，希望可以使您对SysML和MBSE有更深入的认识。
本文来自于sysmlforum，由火龙果软件微微编辑、推荐。

基础问题

什么是SysML？

系统建模语言（SysML）是用于系统工程应用程序的通用体系结构建模语言。

·SysML支持各种系统和系统间系统的规范、分析，设计，验证和确认。这些系统可能包括硬件，软件，信息，过程，人员和设施。

·SysML是UML 2的一种方言，被定义为UML 2概要文件。（UML配置文件是一种UML方言，它通过三种机制定制语言:原型、标记值和约束。）

·SysML是一种支持基于模型的系统工程（MBSE）的技术。

为什么要使用SysML？（SysML用于什么？）

如果您是系统工程师，并且想提高与其他系统工程师以及其他系统和业务利益相关者（例如，客户，软件工程师，电气工程师，机械工程师）的通信的准确性和效率，那么您应该考虑使用系统架构将语言标准建模为通用语言（通用语言）。

系统建模语言（SysML）已成为基于模型的系统工程（MBSE）应用程序的事实上的标准系统体系结构建模语言。SysML是UML 2的方言，它扩展了软件密集型应用程序的统一建模语言（UML）标准，因此可以成功地应用于系统工程应用程序。

以下列出了系统工程师为什么要在其关键任务工作中使用SysML和基于模型的系统工程方法的原因：

·促进整个系统开发生命周期（SDLC）各个利益相关者之间的沟通，包括System Vee模型的双方;

·捕获和管理与系统架构，分析，设计和流程有关的公司知识产权；

·促进贸易研究并比较和对比“按现状”和“未来”解决方案；

·提供可扩展的结构来解决问题；

·提供丰富的抽象来管理大小和复杂性；

·以最小的风险同时探索多个解决方案或想法；

·在系统开发生命周期（SDLC）的早期发现错误和遗漏

当然，与任何技术一样，SysML既可以正确地应用，也可以被滥用。比较SysML FAQ中的“SysML-as- beautiful - pictures”和“SysML-as- system - architecture - blueprint”使用模式的区别:SysML应该如何应用于MBSE项目?SysML通常是如何被滥用的?。

谁创建了SysML？

系统建模语言（SysML）由SysML Partners创建，SysML Partners是由系统工程专家和软件建模工具专家组成的非正式协会，由Cris Kobryn于2003 年组织，旨在创建统一建模语言（UML）的配置文件（方言），可用于系统工程应用。

由于Kobryn先前曾成功领导过UML 1.x和UML 2.0语言设计团队，因此来自INCOSE的David Oliver和Sanford Friedenthal请Kobryn领导他们的联合工作，以响应对象管理小组在2003年3月发布的UML for system Engineering RFP。 RFP于2003年3月发布。作为SysML合作伙伴的主席，Kobryn创造了语言名称“ SysML”（“系统建模语言”的缩写），设计了原始SysML徽标，并组织了SysML核心语言设计团队作为一个开源规范项目。

SysML应如何应用于MBSE项目？SysML通常被滥用吗？

随着SysML成为基于模型的系统工程(MBSE)方法的事实上的标准，SysML渐进严格的使用模式变得明显:

·最不严格和最常见的使用模式- SysML作为精美图片使用模式:这是最不正式和最不严格的SysML使用模式。不幸的是，这也是SysML被滥用的最常见方式。在SysML作为精美图片使用模式下，使用SysML表示法代替临时建模表示法（例如，Visio或PowerPoint绘图），但是对SysML格式良好及其潜在的可模拟和可执行语义的关注相对较少。因此，以SysML作为精美图片使用模式生成的SysML模型很少能够驱动动态仿真或精确指定系统架构蓝图。

·SysML作为模型仿真：此SysML使用模式是对SysML作为精美图片使用模式的重大改进，因为它强调了系统动态行为和系统参数约束的模拟。在SysML作为系统仿真模式下，至少一部分SysML行为图（活动，序列，状态机图）由行为仿真引擎执行。此外，约束传播引擎（MATLAB / Simulink，OpenModelica，SysML工具专有插件等）也可以执行某些参数图约束。对于那些希望摆脱SysML作为精美图片使用模式语言滥用的人来说，这是SysML的一种中间使用模式。

· SysML作为系统架构蓝图：此SysML使用模式是对SysML作为模型仿真模式的实质性改进，因为它扩展了后者，以包括系统架构模型（SAM）的精确而完整的规范。SAM的目的是足够精确和完整，以充当系统项目中涉及的所有工程过程的“系统架构真相”，包括系统工程师（SE），软件工程师（SWE），电气工程师（EE），机械工程师（ME）等。为了使SAM成为系统工程项目的系统架构原理，SAM必须满足所有五个C的系统架构质量（正确，完整，清晰，简洁和一致）。这是一种相对高级的SysML使用模式，通常是SysML作为模型仿真模式的自然演变。

· 最严格和最稀有的SysML的使用方式 - SysML作为可执行的系统架构：这SysML的使用方式是在SysML作为系统架构蓝图模式的重大改进，因为它扩展了后一种模式，使广大SAM行为和参数规范是可模拟的，并且可能是可执行的。在MBSE上下文中，可执行文件通常是指部分或完全自动生成系统接口，系统测试用例。

SysML和UML之间是什么关系？

简要回答：

与MBSE和工具供应商的“混搭驱动的市场”炒作相反，SysML和UML建模语言之间的区别在本质上是轻量级的、辩证的，而不是重量级的和实质性的。这是可以预料的，因为SysML最初是由系统工程师与应用UML进行软件分析和设计的软件工程师写作使用的，并且SysML被定义为UML 2的适度扩展的实用子集。（请参阅SysML FAQ：SysML和UML模型元素可以在同一个模型中组合吗？）的确，尽管SysML向UML添加了两个有用的图用法（需求图扩展了UML类图；参数图扩展了UML类和复合结构图），但是SysML从UML借用的其他图要么被大量重用而未经修改（例如，用例图，序列图，状态机图）或通过称为原型的轻量级定制进行了适度的调整，这些原型缺乏实质性的语义：例如，将类重命名为块，并为物理项流添加轻量级语法和语义;在没有真正可执行的语义的情况下向活动图添加构造型。

更详细的回答：

SysML被定义为UML 2.x的轻量级方言（Profile），UML 2.x是用于软件密集型应用程序的行业标准建模语言。（SysML配置文件是轻量级的，因为它对底层语言所做的更改在范围和程度上相对较小，只使用少量简单的构造型、标记值和约束。与重量级配置文件进行比较和对比，重量级配置文件可能会显著影响底层语言的使用方式。）将SysML定义为UML概要文件的好处是，它可以重用许多建模工具供应商已经实现的UML 2.x相对成熟的表示法和语义。将SysML指定为UML概要文件的缺点是SysML继承了许多与UML 2.x相关的问题，例如不必要的复杂符号，不精确的语义和功能失调的图互操作性标准（XMI）。

与UML相比，SysML在指定系统和复杂系统方面提供了以下优势:：

·SysML比UML更好地表达了系统工程语义（符号的解释）。它减少了UML的软件偏差，并为需求管理和性能分析添加了两种新的图表类型：分别为需求图和参数图。

·SysML比UML更小，更易于学习。由于SysML删除了许多以软件为中心的和免费的构造，因此总体语言在图类型(9 vs. 13)和总体构造中更小。

·SysML模型管理构造支持与IEEE-Std-1471-2000（IEEE推荐的软件密集型系统的体系结构描述的推荐实践）在架构上保持一致的模型，视图和视点的规范。

下面的SysML-UML 2比较表将SysML图与其存在的UML对应图进行比较。对于SysML图（例如，参数图和需求图）没有UML图对应物时，它被标记为N / A；类似地，如果UML图中没有SysML图，那么它就被标记为N/A(例如，UML 2通信图)。

什么是基于模型的系统工程（MBSE）？

基于模型的系统工程（MBSE），又名基于模型的系统开发（MBSD），是一种系统工程过程范式，强调在整个系统开发生命周期（SDLC）中将严格的架构建模原理和最佳实践应用于系统工程活动。这些系统工程活动包括但不限于需求分析，功能分析，性能分析，系统设计，行业研究，系统架构规范以及系统验证和确认（V＆V）。

基于模型的系统工程原理和最佳实践不断发展。以下是MBSE方法的其他一些理想特性：

·强调精确，完整的系统架构模型“蓝图”，通常使用具有多个视图/视点的架构框架进行组织，作为整个系统开发生命周期（SDLC）的主要工作工件;

· 促进将开放标准用于架构建模和工具互操作性（例如SysML，UML 2，XMI，AP233），其中这些开放标准用于指定系统架构模型，并在系统工程师和其他利益相关者（软件工程师，电气工程师，机械工程师，客户等）之间充当通用语言；

· 确保系统架构模型受需求驱动，以确保所有模型元素必须完全可追溯到系统和用户需求；

· 确保系统架构模型在所有模型元素都必须保持结构和功能完整性关系的范围内以架构为中心，并支持所有系统利益相关者视图和观点的完全派生可追溯性；

· 将传统的系统工程最佳实践与架构建模最佳实践相结合。

基于模型的系统工程一词及其首字母缩写MBSE在系统工程师中很流行，他们提倡使用SysML作为系统工程应用程序的标准体系结构建模语言，并且希望将其方法与模型驱动开发及其变体区分开来。倾向于以软件为中心。

SysML和MBSE之间是什么关系？

对于任何基于模型的系统工程(MBSE)方法，推荐的最佳实践是基于模型的语言、基于模型的工具、基于模型的流程和基于模型的体系结构框架的协同应用，如下面的系统体系结构四分体图所示。经过十年将SysML应用于棘手的系统工程问题的实践经验，SysML已经成为MBSE项目事实上的基于模型的语言选择。

遗憾的是，基于模型的工具、基于模型的体系结构框架和基于模型的流程的实际标准尚未出现。符合SysML语言标准的商业和开源的基于模型的工具是可用的，但是需要进行许多改进，正如您可以从MBSE工具评论web上的工具评论中看到的那样。基于模型的体系结构框架组织使用SysML定义的系统体系结构模型，只在国防应用程序中需要，在这种情况下，DoD体系结构框架(DoDAF)非常流行。支持大规模MBSE应用程序的基于模型的进程是系统架构四分体模式中最不成熟的象限，正如您可以从与MBSE Works web的SysML部分兼容的MBSE进程和方法中看到的那样。

痛苦的经验表明，MBSE项目如果不能正确地平衡系统架构的四个部分，往往会得到糟糕或混合的结果。

MBSE与其他基于模型驱动/基于模型的首字母缩写表达（MDD，MDSE，MDE，MDA，MBE，MBSD）之间是什么关系？

基于模型的系统工程（MBSE）经常与其他几个以“基于模型”或“模型驱动”开头的首字母缩写表达混淆。简单的说，基于模型的系统工程是更通用的基于模型的工程系统开发范式的子学科。MBE是一种系统开发范例，强调在整个系统开发生命周期（SDLC）中使用严格的视觉建模技术。MBSE是MBE的专业化领域，将MBE原理和最佳实践应用于系统工程应用程序。

SysML和UML模型元素可以合并在同一模型中吗？

简要回答：

理论上，SysML和UML模型元素可以协同组合在同一模型中。实际上，这是SysML Partners的开源规范项目的语言设计目标之一：

·支持SysML + UML混合语言的使用：

确保在系统工程师和软件工程师共享的模型中，可以将SysML构造与UML构造协同组合，其中前者使用SysML，后者使用UML。SysML和UML的协同组合应使需求可追溯性最大化，并使两种语言之间的语义重叠最小化。

-“SysML Language Design Goals”, SysML Partners

更详细的回答：

遗憾的是，在实践中，用户经常发现在同一个模型中组合SysML和UML模型元素是令人困惑和有问题的，就像他们发现在XMI (XML模型交换)兼容的建模工具上交换SysML和UML模型是令人困惑和烦恼的一样。看起来，对象管理组(OMG)遵循的是“语言家族”的可视化建模设计哲学，而不是主导UML 1的“统一语言”设计哲学。在1990年代末和2000年代初采用和修订。这误导和不执行设计理念导致了“Tower of Techno-Babble”反模式实现协同为用户想结合OMG最流行的可视化建模语言(UML, SysML, BPMN),它导致了一个“Meta-Babble”反模式供应商依赖不必要地复杂Meta Object Facility (MOF)和XMI可靠的模型交换。

因此，考虑到上面描述的“Tower of Techno-Babble”反模式，一个由系统工程师和软件工程师组成的团队如何指定一个能够和谐地组合SysML和UML模型元素的模型呢?以下概述了一种基于需求可追溯性依赖的传递性(特别是«satisfy»和«refine»)的技术方法，它在许多大型混合建模语言项目中被证明是有效的:

1.选择一个UML建模工具，该工具将SysML作为UML2兼容的概要文件正确地实现，并允许您用UML构造填充SysML图，用SysML构造填充UML图。

在这方面，支持SysML的UML建模工具差异很大，因为OMG规范通常将此类实现细节推迟给供应商，因此某些工具的限制性比其他工具要严格。

2.按照以下方式将您的模型组织成定义良好的视图，UML和SysML图以互补的方式组合在一起:

（有关视图符号和语义的信息，请参见SysML«view»包的构造型。）建模人员应随其选择的基于模型的系统工程（MBSE）和/或模型驱动的开发（MDD）修改以下视图及其内容,方法。

·需求«视图»:系统工程师主要负责这个视图的完整性、正确性和完整性，以及它相应的观点的定义。候选图类型内容包括但不限于以下内容:UML/SysML用例和SysML需求图。

·系统分析或功能分析«视图»:系统工程师主要负责这个视图的完整性、正确性和完整性，以及它相应的观点的定义。候选图类型内容包括但不限于以下内容:SysML块定义、内部块、参数、活动和状态机图。可以根据需要添加其他SysML图。

·系统设计«视图»:软件工程师主要负责这个视图的完整性、正确性和完整性，以及它相应的观点的定义。候选图类型内容包括但不限于以下内容:UML类、组合结构、序列、时序、状态机、组件和部署图。

…实现、测试等所需的其他视图。

3.在各个视图之间定义需求可追溯性依赖性/分配

建模团队应指定并一致地应用适当的依赖关系，以在所有视图中实现完整的需求可追溯性。您可以通过在视图内和视图间应用以下可追溯性依赖关系模式，协同实现上述互补视图之间的完全可追溯性：

需求«视图»中的可追溯性：定义功能需求和对其进行细化的用例之间的细化（«refine»）依赖性。

需求«视图»与系统分析«视图»之间的可追溯性：定义需求与满足它们的活动和块之间的满意度（« satisfy»）依赖性。（可选：按照通用的UML最佳实践，您还可以在用例与实现或改进它的任何活动之间定义实现或改进依赖性。）

系统分析«视图»和系统设计«视图»之间的可追溯性：定义在系统分析«视图»中定义的SysML块和活动与在系统设计«视图»中对其进行细化的UML类和序列之间的细化依赖关系。

跨其他视图的可追溯性：由于优化是一种传递关系，因此可以在其他视图（例如，实现，构造，部署，测试等）中进一步完善和跟踪系统设计«视图»模型元素。

为什么系统工程师需要“另一种建模语言”（YAML）？为什么DFD，FFBD，EFFBD，IDEF0 / IDEF1和UML不够用？

许多系统工程过程仍然倾向于以文档为中心，并采用多种形式的图表技术，这些技巧通常不精确且不一致。以类似于软件工程师在1990年代寻求通用建模语言（UML）来精确指定软件密集型系统的方式，许多系统工程师现在正在寻求通用建模语言来指定复杂的系统级系统，其中包括非软件组件（例如，硬件，信息，流程，人员和设施）。UML由于其软件偏见而无法进行修改而无法满足此需求。因此，UML的SysML方言的动机。

即使SysML基于UML，它也减小了UML的大小和软件偏差，同时将其语义扩展到模型需求和参数约束。后者的功能对于支持需求工程和性能分析是两项基本的系统工程活动至关重要。

谁维护SysML规范，以及如何更新？

对象管理组(OMG)已经采用并维护了OMG SysML版本的SysML规范。与任何OMG规范一样，OMG SysML的次要修订是由修订任务组(RTFs)完成的，而主要修订是由提案请求(rfp)完成的。

开源SysML和OMG SysML™之间是什么关系？

SysML最初是由工具供应商和行业领导者组成的非正式协会SysML Partners开发的，是一个开源规范。SysML合作伙伴于2005年11月向对象管理组（OMG）提交了SysML 1.0a开源规范。OMG SysML™源自开源SysML规范，并由OMG进行商标注册和维护。

SysML作为MBSE的体系结构建模语言的优缺点是什么？

尽管OMG SysML重用UML2的许多图和结构,这种新的轻量级方言(配置文件)的SysML比语言更成熟的父母因为它加剧了问题从UML 2继承并添加新问题通过引入两个新图表类型(要求和参数图)相对不成熟(v . 1。x与v. 2.y):

SYSML和UML 2通用问题（与UML 2.x父语言共享）

·语言膨胀。

对UML 2.x的普遍而公正的批评是，它非常大且复杂。尽管SysML市场情况表明SysML对系统工程师来说是一种“更小，更简单”的语言，但事实是SysML本身也遭受了语言膨胀的困扰，因为它添加了两个新的图（需求图和参数图）并大大增加了语义不精确的构造型的数量。但无法从其继承的七个UML 2图中明确排除许多冗余且以软件为中心的UML 2构造。由于SysML规范未提供有关如何将SysML模型与UML模型结合在一起的工程团队（包括软件工程师和系统工程师）的指南，因此膨胀变得更加严重。

建议：明确删除SysML不需要的UML构造。为包括软件工程师和系统工程师在内的工程团队提供有关如何将SysML模型与UML模型结合的具体指南。鼓励工具供应商支持自动翻译两种语言之间共享的图表。

·增加UML 2.x voodoo语义。

对UML 2.x的另一个普遍而公正的批评是，它的语义（包括其声称的可执行语义（又名动作语义））是模糊和不精确的。虽然SysML marketecture表明SysML支持用于指定参数约束的精确语义，但实际上SysML只为ConstraintBlock、ConstraintProperty和上下文相关的值/约束定义了模糊的自然语言语义。类似地，与连续/离散率和概率相关的活动图扩展的语义也缺乏形式精度。

建议：为参数和需求图构造和活动图扩展添加精确的语义。

SYSML特定问题（适用于SysML，但不适用于UML 2父语言）

·物理和信息（标准）接口的结构构造非常复杂且令人困惑。

在SysML v1.0-1.2中，StandardPorts，FlowPorts，提供的接口和必需的接口以及ItemFlow的语义和表示法非常复杂且令人困惑，因为它们将依赖关系与流关系相结合。遗憾的是，为解决SysML v.1.3次要修订中的新结构而制作的补丁程序（FullPorts，ProxyPorts，InterfaceBlocks）加剧了这些问题，而不是加以解决。

尽管实例规范是最近添加到SysML 1.2中的，但是对象图却没有，并且关于它们在SysML中的专门用法仍然存在许多问题。

建议：在下一个主要修订版本SysML 2.0中统一，简化和阐明物理和信息接口的语法和语义。

·实例规范定义不明确，与SysML的其余部分集成不佳。

尽管实例规范是最近添加到SysML 1.2中的，但是对象图显然是该语言的事后思考，并且从未与SysML的其余部分完全集成。

建议：将对象图添加为一流的SysML图类型，并阐明SysML和UML实例规范语法，语义和用法之间的异同。

·参数结构定义不明确，与SysML的其余部分集成不佳。

参数约束块和约束属性定义不明确，并且与其他SysML结构图的集成很差。当前有不确定的区别，即使用的是最不成熟，最麻烦的SysML图。

建议：参数图需要在下一个SysML主要版本（SysML 2.0）中进行彻底的检查。这项大修应考虑从在SysML 1.x参数图与第三方数学建模与仿真工具（例如MATLAB / Simulink，Mathematica）之间建立双向桥梁中学到的经验教训。

·需求构造不完整且令人困惑。

与需求图相关的问题包括但不限于阐明分解/包含语义，分类，定义基本属性，阐明关系语义以及减少与用例的语义重叠。

建议：将包含替换为需求分解的组合。复制依赖退休。为来源、优先级、风险、验证方法等提供额外的需求属性。

·分配关系和表不完整且内容模糊。

除了AllocateActivityPartition构造型之外，当前的规范不能利用其父语言的架构完整性分配。另外，分配和分配构造型的定义强烈地暗示了将依赖关系和流语义合并在一起，这是UML建模新手的指示(“箭头指向哪里?”)。

建议：用使用独特的符号（用关键字标记的非虚线箭头）的流替换“ 分配依赖性”。要求实现自动为AllocateActivityPartitions生成Allocate依赖关系。

·ValueType-Type集成需要简化和SI模型库。

需要阐明和简化ValueUnits与Units和QuantityKinds（以前称为Dimensions）的当前用法以及它们与UML DataTypes的集成。

建议：根据国际单位制（SI）标准简化和预定义标准SysML ValueType模型库。

学习SysML的最佳方法是什么？

学习任何一门新语言都是具有挑战性的，无论是自然语言(如日语、斯瓦希里语、英语)还是人工语言(如SysML)。由于SysML是UML 2的一种方言(配置文件)，如果您精通UML 2并理解部件、端口和连接器如何支持基于组件的设计，那么您应该能够相对快速地学习SysML方言。另一方面，如果您仅仅接触过UML 1，并且已经屈服于UML 1的最坏实践(例如，用例滥用)，那么您以前对UML 1的不良敞口可能是一种负债，而不是一种资产。

为了提高您获得SysML语言流利性的可能性，您可能需要考虑使用多管齐下的方法来学习SysML。例如，如果您有机会，您可能希望从基本的SysML实践培训开始，然后是专家指导(mentoring)的工作培训，然后是高级的SysML实践培训。为了获得最佳的学习体验，请确保您所有的SysML培训都是由在大型项目中具有广泛应用经验的专家教授的，并且包括频繁的实践会话和问答会话。

此外，您还应该阅读有关SysML技术和最佳实践的大量书籍，以便您可以从其他人的经验（和错误）中进一步受益。

您可以在本网站的课程页面上找到SysML培训资源的列表。

您可以在本网站的SysML教程页面上找到所选SysML教程的列表。

您可以在本网站的资源页面上找到相关SysML出版物的列表（包括书籍，论文和文章）。

SysML或UML是哪种语言更容易学习？

答案可能取决于您是系统工程师还是软件开发人员。如果您是系统工程师，则应该期望SysML更易于学习，因为它语言较小，并且是针对系统工程应用程序定制的。如果您是软件开发人员，则可能会更喜欢UML以软件为中心的偏见。

SysML可以用作敏捷体系结构和设计（敏捷建模）语言吗？

是的，对于敏捷架构与设计(又称敏捷建模)应用程序来说，SysML正在成为其父语言UML 2的一个有吸引力的替代方案。

为什么SysML是UML的一个有吸引力的替代?考虑SysML实际上比UML 2小。因此，它更容易学习和应用，但它比UML 2在语义上更有表现力。因此，您可以指定可视化需求和参数约束以及分析和设计工件。换句话说，SysML更敏捷，语义更强大，而UML更缓慢，语义更弱。因此，许多软件工程师和开发人员将SysML视为“更好的UML”也就不足为奇了。

SysML版本

SysML规范的当前版本是什么，我可以在哪里下载？

OMG SysML规范的当前版本是OMG SysML v。1.5，可从本网站的SysML规范页面获得，也可以从OMG网站下载。

您可以找到OMG SysMLv1.5版本更改摘要，作为对SysML常见问题解答：OMG SysML 1.5中的新内容的回答的一部分。

OMG SysML 1.5次要修订版有哪些新功能？

OMG SysML v.1.5较小修订变更摘要：

正如在较长（10年以上）系列或较小的OMG SysML 1.x较小修订中所期望的那样，OMG SysML v.1.5较小修订仅包括对该语言的细微调整。

允许通过专门化SysML Requirement构造型来定义Requirement属性和分类法。还添加了需求隔离专区标记以显示需求关系。

添加块隔室符号以显示信号接收。

毫无根据的声明：

N / A

关键评论：

不清楚为什么OMG会对OMG SysML 1.4的如此琐碎的修订感到困扰。浪费时间和精力可以更好地用于加速早就该完成的OMG SysML 2.0修订过程。

下载：

您可以从 SysML规范页面下载 OMG SysML v1.5规范以及以前版本的规范。

OMG SysML 1.4次要修订版有哪些新功能？

OMG SysML v.1.4较小修订变更摘要：

与OMG SysML v.1.3较小修订相反，后者对物理流进行了重大更改（请参阅：OMG SysML 1.3中的新增功能？），OMG SysML v1.4轻微修订仅包括对语言的较小更改。

改进了对相对层级的支持：支持对合成层级中嵌套部件的引用。添加绑定引用以指定受相同类型或值约束的连接属性。

添加了元素组以组织不具有包语义的构造。（元素组是一种绘图便利，没有明确定义的语义。）。

增强的View和Viewpoint构造。

为继承的功能，行为分隔和端口功能添加了表示法。

添加了与ISO 80000-1兼容的非标准数量和单位（QUDV）模型库。

对抽象语法进行了各种更新，对具体语法进行了改进以提高模型交换功能。

无根据的声明：

改进的OMG SysML图交换功能

批判性评论：

也许OMG v. 1.4修订任务组(RTF)试图通过确保OMG v. 1.4只包含善意的小修订来弥补OMG v. 1.3中的物理流范围渐变。然而，它们似乎补偿过度了，因为OMG v. 1.4中的许多小修订定义不清或不规范。

下载：

您可以从 SysML规范页面下载OMG SysML v1.4规范以及以前版本的规范。

OMG SysML 1.3次要修订版有哪些新功能？

OMG SysML v1.3次要修订修订摘要：

重新定义物理流：不赞成使用流规范。嵌套端口和代理端口的添加，并支持分层嵌套的接口。

与UML v.4.1.1元模型更改的架构一致性

批判性评论：

尽管UML1.x流规范是众所周知的，因为它们的无偿复杂性，它们的使用和替换由两个新的(和未经验证的)物理端口类型(嵌套端口、代理端口)在次要版本风险中混合物理流问题。对于仅仅是UML2.x的概要的OMGSysML的这种显著结构改变应当在对SysML的重大修订的范围内进行，而不是较小的修订。进一步注意到，UML和OMGSysML和UML(分别是SysML2.0和UML3.0)的主要修改都是长期的，因为OMG在十三年前通过了UML2.0，它在10年前通过了OMGSysMLv.1.0。

下载：

您可以从 SysML规范页面下载OMG SysML v1.3规范以及以前版本的规范。

OMG SysML 1.2次要修订版有哪些新功能？

OMG SysML v1.2次要修订修订摘要：

包含UML 实例，结构化活动和多个项目流符号

与单位和数量有关的值类型的改进

与UML 2.3元模型更改同步

下载：

您可以从 SysML规范页面下载OMG SysML v1.2规范以及以前版本的规范。

OMG SysML 1.1次要修订版有哪些新功能？

OMG SysML v.1.1次要修订修订摘要：

主要是针对OMG SysML v1.0的编辑性更正和错误修复。

下载：

您可以从 SysML规范页面下载OMG SysML v1.1规范以及以前版本的规范。

SysML图和建模技术

SysML图的类型是什么？

SysML规范定义了九种图表类型，这些类型在下面的SysML图表分类法图中显示，以及一种表格表示法（分配表）。在这九种图表类型中，四种图表类型被视为行为或动态（活动，序列，状态机和用例），四种图表类型被视为结构或静态（块定义，内部块，参数和包），其余图类型保留用于声明需求（Requirement）。

使用注意事项：分配表用于定义关系图类型之间的横切关系，对于检查语义良好格式规则和体系结构完整性规则都很有用。行为到结构分配的一个常见示例是通过活动分区(通常称为“泳道”)将活动图中的行为活动映射到块定义图中的结构块。结构到结构分配的一个常见示例是接口结构到实现或实现它们的块结构的映射。

SysML的“四大支柱”是什么？（SysML的基本图是什么？）

SysML的四个支柱的表达是指SysML的四个基本图：需求图，活动图，块图和参数图。该表达式是SysML Partners开放源代码规范项目主席Cris Kobryn创造的，当时他观察到SysML Partners在讨论这四个图中的功能时，有80％以上的时间是SysML Partners讨论SysML语言功能的。他进一步指出，从人工语言设计的角度来看，“活动”和“框图”支柱比其他两个支柱更为重要，因为它们基于业已证明的UML2图表技术，该技术已成功将行为（功能）集成到结构中。

结构图和行为图有什么区别？

顾名思义，结构图强调系统实体的静态结构，而行为图则强调系统实体的动态行为。

什么是SysML需求图？如何使用它？

SysML 需求图显示了视觉需求构造之间的关系，以及实现并验证它们的模型元素。

需求图可用于指定和管理系统功能和非功能需求（例如，性能）。

使用注意：指定功能需求的需求图可以在语义上与定义相似功能的用例图重叠。

什么是SysML活动图？如何使用它？

SysML 活动图显示使用控制流和数据流的系统的功能行为。

系统工程师可以通过使用活动图来指定独立于结构（窗体）的功能，而不必使用分区（Swimlanes）。

业务分析师可以使用活动图来表示业务流程。

比较和对比：SA / SD EFFBD，DFD；BPMN业务流程图。

什么是SysML块定义图（BDD），如何使用？

SysML 块定义图显示了使用称为“块”的组件的系统的静态结构，这些组件通过接口连接到其他块。块可以代表硬件，软件和“湿软件”（组织）组件。

SysML中有两种框图，它们被设计为以补充方式使用：块定义图和内部框图。

块定义图（BDD）用于定义具有外部接口的“黑匣子”组件，其中外部接口可以支持信息流（通过标准端口和接口）和物理流（通过流端口和流规范）。SysML BDD源自UML2类图。

内部框图（IBD）用于显示块组件的“白盒”透视图，其中连接器显示内部零件如何“连接”到外部接口以及彼此之间。SysML IBD源自UML2 Composite Structure图。

什么是SysML内部框图，如何使用？

SysML内部框图显示了使用内部零件（称为零件）的系统内部静态结构，这些内部零件通过连接器进行连接。

SysML中有两种框图，它们被设计为以补充方式使用：块定义图和内部框图。

块定义图（BDD）和内部块图（IBD）有什么区别？

为了理解块定义图和内部块图之间的区别，必须首先了解它们都具有SysML的基本结构元素，即块。SysML在SysML中定义了一个块，如下所示：

block：系统结构的模块化单元，封装了其内容，包括属性，操作和约束。块实质上是既可以提供信息接口又需要信息流和物理流的接口的组件。块可以递归分解为零件，其中每个零件也必须由一个块定义。

阿块定义图（BDD或BDD）显示块，它们的内容和关系；相反，内部方框图（ibd或IBD）：显示了方框的内部结构，显示了方框的各个部分，包括与系统其他部分的交互点。

使用说明：块定义图可与内部框图结合使用，以将系统结构定义为模块化组件树，例如“系统上下文”图中的“系统对系统的分解”。块定义图（BDD）将块指定为黑匣子通过内部框图（IBD）定义其白盒部件实现（实现）的表示形式。以这种方式，BDD和IBD图相互补充，并有助于递归设计技术。块定义了它们的部分，其中每个部分在封装它的块的上下文中可以具有不同的用法或角色。

有关构造和概念的信息，

请参见：UML规范实现二分法

比较和对比：UML :: Class，复合结构和组件图

什么是SysML参数图，如何使用它？

SysML 参数图是一种内部框图，它显示了块及其内部属性或零件之间的约束关系。

参数图可用于显示系统的一种结构特性（系统参数）的值变化如何影响其他结构特性的值。它们对于指定系统设计和体系结构约束非常有用，并且通常被认为对于指定使用SysML的贸易研究至关重要。

SysML参数图示例

SysML元素

块和UML类之间有什么区别？

SysML 块是SysML模型中使用的基本结构元素，是UML 类的定型（自定义）扩展，UML 类是UML对象模型中使用的基本结构元素。因此，它们在解剖结构和用法上都紧密相关，其中前者（Block）应被视为后者（Class）的扩展定制。

更具体地说，UML 类具有用于定义其内部状态的属性（即属性），用于定义与其他对象进行交互时其潜在行为的操作（即方法）和端口。定义唯一的交互点以附加提供的和必需的接口。

SysML 块通过区分各种属性（部件，引用，值）来扩展UML 类的语法和语义，并包括用于物理流的其他端口（Flow端口 [ 在SysML v.1.3中与Flow Specification一起弃用]，Full Ports，代理端口）。

块和包之间有什么区别？

在SysML及其父语言UML中，Package是一种通用的分组机制，用于组织唯一名称空间中的各种模型元素和相关图。SysML程序包能够包含任意SysML模型元素，包括（但不限于）块。

SysML块是SysML模型中使用的基本结构元素，其用法类似于使用UML类构造UML对象模型的方式。请参阅SysML FAQ：SysML Block和UML Class有什么区别？

因此，尽管SysML包可能包含（和为其提供唯一的名称空间）块和其他SysML模型元素，但SysML块不能拥有（由其组成）或包含SysML包或SysML图。

使用注意事项：SysML块和软件包可以互补使用吗？：是的，当将系统递归分解为子系统，子系统等时，以类似于递归结构分解的方式递归组织模型视图Package结构被认为是最佳实践。此技术的一种变体也适用于大型，复杂的数据结构。

什么是ValueType？SysML ValueType与UML DataType有何不同？

SysML ValueType是一种UML数据类型的原型，它可以被用来根据它们的值来输入大量的基本结构元素，这些类型还可以包括有关数量类型(通过一个带有QuantityKind标记的值)和度量单元(通过一个带有单元标记的值)的信息。

ValueTypes可以应用于SysML模型中的许多结构元素，包括以下内容：

块：值属性，操作参数和返回值，原子流端口

关联/连接器：项目流，项目属性

活动：对象节点，引脚，活动参数

约束模块：约束参数

SysML定义了三种ValueType：

原语ValueType没有内部结构(没有自己的值属性)。SysML预先定义了四种基本的ValueTypes (String、Boolean、Integer、Real)，您可以根据需要定义更多。

符号:带有原型«valueType»在名字前面的矩形。

结构化的ValueType具有内部结构，定义为值属性，可以递归嵌套。

符号:带有构造型«valueType»的矩形在名字之前，带有值属性的可选区域。

枚举的ValueType是一个文字字符串值列表，相当于一个UML枚举。

符号:带有构造型«枚举»在名字前面的矩形，带有文字字符串值的可选分隔。

因此，尽管UML限于简单且结构化的数据类型，例如«dataType» Real和«dataType» DateTime，但SysML能够使用QuantityKinds和Units指定ValueType。例如，«valueType» CelsiusTemp可以定义为«valueType» Real的子类型，其中QuantityKind =热力学温度，单位 =摄氏度。«valueType« TimeDate可以使用以下属性定义：年 [ 数量种类 =时间，单位 =年]；月 [ 数量种类 =时间，单位 =月]；…

SysML + UML 2混合语言的用法：

尽管SysML最初设计为与UML 2互补使用，其中SysML ValueTypes可以补充UML 2 DataTypes，但是SysML 1.3次要修订版已将UML 2 DataTypes与SysML ValueTypes合并。

注意，上面的更改并不排除SysML + UML 2在同一模型中的混合语言使用。但是，鼓励认真的实践者在不同的模型?视图?和/或包中系统地划分语言元素。例如，使用SysML模型元素来指定功能分析«视图»和UML 2模型元素来指定系统设计«视图»中的软件设计。

通用关系（“白色三角形”）和组合关联关系（“黑色菱形”）之间的区别是什么？

泛化(即继承)关系是两个模型元素之间的“某种”或“类型”关系，其中一个模型元素是广义的，另一个模型元素是专门化的。一个泛化关系被画成一个箭头，其中尾巴连接到专门的模型元素，一个白色的三角形箭头连接到广义模型元素。

组合关联关系是两个模型元素之间的“整体或组合”关系，其中一个模型元素是主题组件，而另一个模型元素是整个组件的一部分。一个部件关联关系被画成一个箭头，其中尾巴连接到部件元素，一个黑色菱形箭头连接到整个组件元素。

组合关联（“黑钻石”），共享关联（“白钻石”）和参考关联之间的区别是什么？

下面种关联关系的以递增的语义的顺序定义：

引用关联关系是两个模型元素之间的一种难以描述的关系，这表明在两个对象之间的交互期间，引用模型元素的一个实例可能调用操作，或者与引用的模型元素的实例进行交互。例如，如果块A与操作mumble有一个对块B的引用关联，那么块A的一个实例可能在两个对象之间的某些交互期间向块B的一个实例发送一个消息mumble。

部分关联(又称组合)关系是两个模型元素之间的“整体-部分关系”，其中一个模型元素是整个组件，而另一端是整个组件的一部分，“属于”整个组件。将部分关联关系绘制为箭头，其中尾部连接到部分元素，黑色菱形箭头连接到整个组件元素。部件关联关系表现出强大的所有权语义，如果整个部件被删除或从模型中删除，那么整个部件拥有的所有部件也将被删除。

共享关联(又称聚合)关系是上述部分关联关系的一种较弱形式。一个共享的关联关系被绘制为一个箭头，其中尾部连接到部分元素，而一个白色菱形箭头连接到整个组件元素。共享关联关系表现出弱的所有权语义，如果整个部分被删除或从模型中删除，那么整个部分拥有的所有部分都将被删除。

SysML中的“跨领域”关系是什么？如何使用它？

在SysML及其父语言UML 2的上下文中，横切关系是一种跨越图类型的关系。横切关系的一个常见例子是需求图<>关系，因为满足需求的模型元素通常可以在其他类型的图中找到(例如，块定义，活动)。

SysML如何启用需求验证和确认（V＆V）

由于系统和软件工程师通常将验证和确认一词混为一谈，因此我们首先使用Boehm的经典正式和非正式定义[Boehm 84]阐明它们之间的区别：

A.定义

验证-确定软件产品与其规格之间对应关系的真实性。（注意：此定义源自拉丁文中的“真理” veritas。还请注意，数据库和文档是适合验证以及程序的主题。）

验证-确定软件产品的适用性或价值它的运作任务。（注意：此定义源自拉丁语“ to beworth”，valere。）

非正式地，我们可以通过以下问题来定义这些术语：

验证：“我在制造产品吗？”

验证：“我要制造合适的产品吗？”

— [Boehm 84] 验证和确认软件要求和设计规范的准则

需求验证通常是系统涉众的责任，他们审查需求规范（例如SysML需求图）以确定他们定义了要构建的“正确产品”。在验证过程中检查的需求质量包括但不限于以下各项：正确性，完整性，一致性，清晰度（明确性），简洁性，可行性，必要性和优先级。

SysML对需求验证的支持： SysML通过定义需求来支持需求验证作为可以分类（例如，功能，性能，接口，设计约束），组织成层次结构（通过包含关系）和根据需要分配的属性（标记值）（例如，风险，验证方法，优先级，级别）的一流视觉建模元素努力）。

需求验证通常是系统工程师和系统分析师的责任，他们（根据[Boehm 84]）“确定”系统工程产品与其需求规范之间的对应关系。

SysML对需求验证的支持： SysML主要通过两个互补关系来支持需求验证：

·满意（«satisfy»）依赖性：客户端模型元素满足供应商要求。例如，优化子系统活动满足2.3.5优化子系统功能需求。[请参见下面的示例。]

·验证（«verify»）依赖性：客户端TestCase（«testCase»）确定是否满足了供应商要求。例如，测试子系统优化活动“ testCase”验证2.3.5优化子系统功能需求并在系统设计 “视图”中测试SmartCarController模块。[请参见下面的示例。]

另一个需求验证最佳实践是使用适当的值（例如，分析，演示，检查，测试）为需求定义一个VerifyMethod属性（TaggedValue）。

SysML工具和互操作性

有哪些SysML建模工具可用？

您可以在SysML网站上找到与当前SysML规范兼容的SysML建模工具。同时，本网站的EA工具支持SysML语言建模。

如何为我的MBSE团队或项目选择最佳的SysML建模工具？

此问题的答案将取决于您特定的MBSE团队和项目需求。

在为我的MBSE团队或项目选择SysML建模工具时，我应采用什么评估标准？

此问题的答案将取决于您的特定MBSE团队及其项目需求。

SysML高级主题

什么是模型管理，为什么重要？

模型管理是一个笼统的术语，是指使用包和相关构造来管理代表大型复杂系统的大型复杂模型的复杂性。“模型管理”对建模者很重要，因为如果她无法管理大型复杂模型的复杂性，则没有理由期望她能够管理大型复杂系统的复杂性。

模型管理使用Packages作为通用分组构造，以及Packages的以下构造型（自定义）：

包：用于组织模型元素和图的基本分组构造，这些元素定义了唯一的名称空间语义以及“导入”和“包含”关系。软件包可以嵌套和定型（即定制）以进一步组织其内容。

模型(«模型»):(系统)模型构造型组织了所有描述感兴趣的系统架构的模型元素，包括它的所有视图和子系统。

视图«视图»)/视点(«视点»):视图构造型从一组涉众(例如，客户、系统工程师、系统分析师、系统设计师、软件工程师、测试工程师)的角度(视点)组织一个模型的投影(cf. set理论投影)。模型视图符合其视点的透视图。在SysML中，视图和视点都是可以精确定义的第一类元素。

子系统(«子系统»):子系统原型分解一个模型或者它的视图来反映感兴趣的系统的逻辑或者物理结构。子系统可以是逻辑抽象或物理抽象，如果同时存在这两种类型，则应该使用原型关键字或其他一些独特的符号来区分它们。SysML和UML预先定义了«子系统»构造型;如果«子系统»构造型还没有被预先定义，用户可以定义«系统»构造型来补充«子系统»构造型。

模型库«模型库»:模型库原型组织模型元素，以便在模型中重用。

框架«框架»:框架原型将模型元素分组，这些元素打算将其他模型组织成视图，子系统，等等。框架可以遵循行业标准(DoDAF/MODAF、UPDM、TOGAF)、企业标准，或者可以特别指定。

概要文件«概要文件»:概要文件构造型组织用于自定义域、平台和过程的模型元素。这些模型元素包括原型、标记值和约束。

包的符号及其常见的构造型在下图的“ 包构造”图中显示。

UML2 / SysML包构造

SysML模型视图和ViewPoint之间有什么关系？

SysML系统模型视图(«视图»)从一组涉众(例如，客户、系统工程师、测试工程师)的角度定义模型上的投影，其中一组涉众的视角被定义为一个视角(«视图»)。在SysML中，视图和视点都是可以精确定义的第一类元素。SysML为涉众、关注点、语言、方法和用途定义了一个带有标记值(属性)的类的构造型(自定义)。模型视图符合其视点的透视图，如«符合»依赖项箭头所示。

例如，请参见下面的“ 视图和视点”图。

SysML视图和观点

如何为MBSE项目指定SysML工作工件？

免责声明:以下内容构成技术信息;它不构成法律咨询，也不构成代理-客户关系。如果你需要法律咨询，请联系律师

背景-SysML可执行系统体系结构与SysML系统工程(MBSE)技术-例如SysML语言和SysML建模工具-常常被MBSE的传道者和工具供应商夸大和低估，重要的是你能够区分真正的MBSE SysML方法提供质量的SysML系统体系结构蓝图工作工件和提供SysML的伪MBSE SysML方法。通过为您的MBSE SysML项目交付品指定与工具无关和与方法无关的技术要求，您可以帮助确保您的工程团队或承包商团队为您的项目应用真正的MBSE方法，而不是虚假的MBSE方法。

您可以考虑应用以下技术要求的一些变化来提高您的MBSE + SysML项目可交付成果的质量:

MBSE + SYSML项目可交付成果技术要求(草案)

分配到主题系统项目的系统工程团队(SE团队)应采用严格的基于模型的系统工程(MBSE)方法，该方法已被完全记录，并产生以下最小的项目可交付成果集:

1.0系统架构模型(SAM)

SE团队应该交付一个精确且完整的系统架构模型(SAM)作为其主要的项目交付物。SAM应作为所有其他系统开发生命周期(SDLC)项目可交付成果的“系统架构真相”。，当SAM与另一个项目可交付成果之间存在技术冲突时，前者将在技术上战胜后者。SAM还应演示下面小节中描述的MBSE原则和最佳实践。

1.1行业标准符合性和一致性:SAM应遵守或符合以下行业标准，这些行业标准按优先顺序列出。当行业标准之间存在冲突时，优先级较高的行业标准将占优势):

OMG SysML: SAM应该使用OMG SysML体系结构建模语言来指定，该语言是图形化地指定系统工程应用程序的事实上的行业标准。SAM应该使用OMG SysML v. 1.4或更高版本来指定，并且它必须遵循OMG SysML符号(图形语法)和语义的格式良好规则。...

包括系统工程手册和系统工程知识体系指南(SEBoK):…

ISO/IEC/IEEE 15288:2015系统和软件工程—系统生命周期过程:…

【插入相关行业的企业架构框架标准】(如DoDAF 2、TOGAF 9等)

[插入相关行业的功能安全标准](例如，ISO 26262道路车辆-功能安全)

[插入相关行业网络安全框架标准](例如，NIST改善关键基础设施框架v. 1.x)

...

1.2以架构为中心：在整个系统开发生命周期（SDLC）中，SAM必须精确，完整地定义整个系统上下文和主题系统的系统架构。系统上下文应通过明确定义系统所属的系统系统以及主题系统与之交互的所有其他对等系统，以清晰明确的方式为所有系统利益相关者定义系统范围。系统架构应准确，完整地定义，并具有足够的清晰度和细节，以便第三方自行投标和构建系统而无需其他支持材料，这将是自描述的和实用的。…

以下各节中描述了提高SAM的准确性和完整性的详细技术要求：

…

1.3企业体系结构框架一致性：SAM必须符合定义良好的企业体系结构框架模式，该模式将所有SAM元素组织到互补的SysML视图中（水平由SysML程序包合理划分的抽象层），其中所有视图都是由对所有系统涉众有意义的SysML视点（透视图）定义的。如果未在行业标准合规性和一致性中指定企业架构框架行业标准部分，SE团队应采用或采用行业标准的企业体系结构框架，或者使用视图和观点来精确，完整地定义一个

…

1.4验证和验证支持：SAM必须为所有人员提供全面的验证和验证（V＆V）支持SDLC中的SAM模型元素。完整的V＆V支持应扩展到？中指定的行业标准System Vee模型（也称为System V模型）的两侧（即“左侧”和“右侧”）。系统生命周期过程模型：SEBoK的Vee部分。与SEBoK中一样，以下子要求根据原始来源[Forsberg，Mooz和Cotterman 2005]指的是System Vee模型的“左侧”和“右侧”：

系统Vee模型的“左侧”：构成系统Vee模型“左侧”的所有工件的系统体系结构，分析和设计模型元素都应直接或间接（即，传递地）满足系统功能和非使用SysML Satisfy依赖关系在SAM的系统要求视图中指定的功能要求。通过自动从主题SAM生成适当的分配表，可以总结System Vee模型左侧所有系统需求满意度的证明。

Vee模型的“右侧”：在系统Vee模型的“右侧”上进行单元，集成以及系统验证和确认的所有白盒和黑盒测试用例，应在Vee模型的“右手”侧进行测试，验证和确认。系统Vee模型的“左侧”。所有在系统Vee模型右侧进行的系统验证和验证的演示，都应通过从主题SAM自动生成的分配记录进行汇总。

…

1.5基于模型的仿真支持：SAM必须证明对SysML行为图（活动图，序列图和状态机图）的基于模型的仿真以及对用于贸易研究应用程序的参数图的基于模型的仿真的支持

……

1.6变更影响分析支持：SAM必须证明对自动变更影响分析的支持，从而对任何系统功能需求或非功能需求的任何更改都应导致已影响（即受影响或已更改）的体系结构，分析和设计模型元素的优先列表根据主题要求的变化。…演示应包括一个或多个分配表，这些表说明需求变更及其对其他模型元素的潜在副作用（即影响）。

...

1.N独立于工具和工具，专有格式：该SAM的全部应交付的所有以下与工具无关的文档格式：XMI（XML模型交换），HTML，RTF和PDF。此外，所有SAM派生的交付物（请参阅下面的基于模型的SRS，基于模型的SDS和基于模型的ICD部分）都应随附有SAM视图或在所有相同的独立于工具的文档中派生自其的特定软件包。上面列出的格式。…

尽管有上述规定，SE团队还应提供SysML兼容建模工具的专有工具格式，该工具用于以工具无关的格式生成上述SAM和SAM派生的可交付成果。[原理：系统集成测试（SIT）团队需要访问SysML建模工具专有格式以进行质量控制，以便他们可以将模型度量标准和其他诊断有效地应用于SAM以验证其正确性和完整性。]

……

2.0基于模型的系统要求规范（基于模型的SRS）

所有系统功能和非功能要求均应以系统可自动生成或直接从中得出的系统要求规范（SRS）中以人类可读的格式精确且完整地指定。，即“ 系统架构模型”部分中指定的SAM 。 SRS至少应将所有功能需求和非功能需求定义为SysML需求图中的SysML需求元素，并且应将所有系统使用功能指定为SysML用例图中的SysML用例元素。

SysML Requirement元素和SysML Use Case元素均应使用适当的SysML关系进行分层组织（分别为Contains关系和Includes依赖关系）。应使用DeriveReqt依赖关系精确指定从现有需求生成的所有派生需求

。 SysML功能需求元素和SysML用例元素应使用SysML进行明确寻址和解决完善依赖关系。...

...

3.0 MODEL-BASED系统设计规范（MODEL-BASED SDS）

所有的系统设计应以人类可读的格式以精确和简明地指定系统设计规范而自动从生成，或者从至少直接导出（SDS），系统架构模型部分中指定的SAM 。 SDS至少应以符合或超出以下描述的严格性的方式定义所有系统和系统组件的静态结构和动态行为。

3.1系统和组件的静态结构。应分别使用SysML块定义（BDD）和SysML内部框图（BDD）将系统及其所有组件递归地指定为黑盒组件和白盒组件。系统组成结构的递归规范应从系统开始，并将下降到子系统组件，子系统子系统组件等，直到指定的Block结构是原子的（不可分解为SysML部件）为止。

所有系统设计结构组件应完全指定为SysML块，并具有完全定义的属性（零件属性，参考属性，值属性），操作和/或信号，约束，端口（标准端口，代理端口，完整端口）和接口（标准接口，接口块）。...

...

有关指定端口和接口所需的精度和完整性的更多信息，请参见基于模型的ICD部分

……

3.2系统和组件的动态行为。应通过使用SysML行为图（顺序图，活动图，状态机图）的完全集成的组合来精确，完整地指定系统及其组件的动态行为。最低限度，所有系统和组件的动态行为均应精确指定以下内容：

信息（数据）流接口交互作用：所有系统和组件信息（数据）流接口交互作用都应使用序列图精确，完整地指定，该序??列图应显示同步和异步通信序列以及适当的可选时间限制。…作为SAM架构的完整性，在静态行为图的标准接口中定义的所有操作和信号必须在动态行为模型的序列图中至少出现一次。…

物理物料流接口交互：所有系统和组件物理物料流交互必须通过至少一对匹配的模块定义图（BDD）+内部框图（IBD）中的项目流来精确而完整地定义，并且必须至少出现在一个中协作行为图（活动图或序列图）。…

系统关键事件。所有被认为是时间关键，任务关键，生命关键或其他关键的动态行为，都应由状态机图准确，完整地指定，该状态机图应与其他相关行为图（例如，时序图和活动图）正确且完全集成在一起。

…

4.0基于模型的接口控制文档（基于模型的ICD）

所有系统和系统组件接口均应在人类可读的接口控制文档（ICD）中准确，完整地指定，这些文档通常是从SAM中通常指定的工作工件直接得出的，尤其是基于模型的SDS，……

4.1信息（数据）流类型接口。ICD应通过以下方式精确且完整地指定所有信息（数据）流类型接口……

所有信息流接口都应指定为SysML标准接口，其中每个标准接口都定义为一组完全参数化的操作和/或信号，并且每个接口至少由一个块提供（由实现依赖项指定），并且由至少一个其它块（通过使用依赖关系规定）需要...

...

此外，ICD应包括序列图，显示所有接口操作和/或信号如何在至少一个序列图相互作用被用于...

...

4.2物理项目流类型接口。ICD应通过以下方式精确且完整地指定所有“物理物料流”类型的接口

……

7767 次浏览

UML概览

UML图解:用例图（Use case diagram ）

UML图解:活动图（activity diagram ）

UML图解:类图（class diagram ）

UML图解：对象图（object diagram）

UML图解：顺序图（ sequence diagram ）