概述
由来
长期以来系统工程师使用的建模语言、工具和技术种类很多，如行为图、IDEF0、N2图等，这些建模方法使用的符号和语义不同，彼此之间不能互操作和重用。系统工程正是由于缺乏一种强壮的标准的建模语言，从而限制系统工程师和其他学科之间关于系统需求和设计的有效通信，影响系统工程过程的质量和效率。
为了支持基于模型的系统工程（Model Based Systems Engineering，MBSE），国际系统工程学会（INCOSE）以及对象管理组织（OMG）在对统一模型语言UML进行重用和扩展的基础上，推出一种标准的系统建模语言SysML（Systems Modeling Language），消除不同模型语言在表达法及术语上的不同，规范符号和语义。与统一建模语言（unified modeling language，UML）主导软件工程设计一样，SysML也将是统一系统工程的建模语言。
SysML在一定程度上重用UML部分元模型，同时针对系统工程对UML进行扩展，增加诸如需求、块、限制之类描述系统的元素和相关图形支持，最终确保它支持诸如DoDAF/C4ISR在内的体系结构框架标准。UML中被SysML重用的部分称为UML4SysML，SysML Profile（extensions）是扩展的部分。
基本概念
SysML是一种支持复杂系统分析、规范、设计、验证和确认的通用图形化建模语言。这些系统可能包括硬件设备、软件数据、人员、规程、设施，以及其他人造和自然系统元素。SysML能够帮助实现系统的规范定义和架构设计，并定义组件的规范。这些组件可以使用其他领域语言进行设计，比如UML进行软件设计，VHDL进行电气设计，3维几何建模进行机械设计。SysML有助于MBSE方法论的应用，创造一个内聚的一致的系统模型。
SysML能够表示系统、组件和其他对象的如下方面：
- 结构组成，关联关系，和分类
- 基于流、基于消息和基于状态的行为
- 物理和性能属性的约束
- 行为、结构和约束之间的分配关系
- 需求，以及需求到其他需求、设计元素和测试用例之间的关系
图
图是SysML中的基本结构单元，可用于表示硬件，软件，设施，人员或任何其他系统元素。系统结构由块定义图和内部模块图表示。块定义图描述系统层次结构和系统/组件分类。内部模块图描述系统的部件，端口和连接器的内部结构。包图用于组织模型。
SysML包括一个图形构造，用于表示基于文本的需求，并将它们与其他模型元素相关联。需求图捕获需求层次结构和需求派生，并且满足和验证关系允许建模者将需求与满足或验证需求的模型元素相关联。需求图提供典型需求管理工具和系统模型之间的桥梁。
参数图表示对系统属性值的约束，例如性能，可靠性和质量属性，并且用作将规范和设计模型与工程分析模型集成的手段。
包图
Package Diagram，简写为cls，用来组织模型的图形，它可以按照层次关系、图表类型和视点将模型进行分类。
需求图
Requirements Diagram，能够描述需求和需求之间以及需求和其他建模元素之间的关系。需求的描述可以有图形、表格和树形结构等各种形式，能为系统设计提供准确的需求分析和设计决策。
需求是指系统必须满足的能力或条件，一个需求能够分解成多个子需求。
活动图
Activity Diagram，用于描述工作流、业务流程，或者是将执行流分解为一系列活动和子活动的算法。活动图可以是简单活动的序列，或带有条件分支和并发的复杂系列的并行活动。泳道可以添加到活动图以显示负责执行每个活动的实体。活动图强调活动的输入输出、顺序和条件。
序列图
Sequence Diagram，用于描述对象间的消息交互序列。
状态机图
State Machine Diagram，通过状态以及状态之间的转移对离散行为建模，它把行为表示为对象的状态历史。在状态的转移、进入和退出过程中会调用活动，并指定相关的事件和守卫条件。
用例图
Use Case Diagram，描述外部参与者对系统的使用，这是通过系统向参与者提供一系列服务来实现的。用例图包括用例、参与者以及它们之间的通信，参与者可能是用户、外部系统或其他环境实体，它们和系统直接或间接交互。
块定义图
Block Definition Diagram，显示系统和系统的基本结构元素（模块，Block），以及它们之间的关系/依赖性。但是，它一般用来描述复杂系统的层次结构，而不显示模块内部的连接关系。
内部块图
Internal Block Diagram，显示块定义图所定义的系统结构的实现。包含一组套件的部件（即模块的实例），这些部件是由端口和接口彼此连接在一起的。
参数图
Parametric Diagram，简写为par，定义一组系统属性以及属性之间的参数关系。参数关系用来表示系统的结构模型中属性之间的依赖关系，说明一个属性值的变化怎样影响其他的属性值，参数关系是没有方向的，可以是基本的数学操作符，也可以是和物理系统的性质有关的数学表达式如等。参数模型是分析模型，把行为模型和结构模型与工程分析模型如性能模型和可靠性模型等结合在一起，能用来支持权衡分析，评价各种备选的解决方案。
装配图
SysML新增，是以系统部件构成的形式来描绘系统。装配图的构成元素包括部件、端口和连接器，连接器是负责连接部件，表示各部件之间的作用关系。简写为asm。不常用。
时间图
重用UML时间图，在UML中时间图并不常用。时间图描述的是系统的某个活动状态或属性值随时间的变化。简写为tim。
分类
分类有助于对一个事物加以理解，不同分类方式有不同的分类结果。
4大类
SysML中定义4大类：结构图、行为图、需求图、参数图。结构图可再细分为类图和装配图；行为图可再细分为用例图、状态机图、活动图、顺序图（序列图）和时间图。SysML共有上述9种不同的图。
用例图提供通过系统或系统部件之间的交互实现的功能的高级描述。活动图表示活动之间的数据流和控制。序列图表示系统的协作部分之间的交互。状态机图描述系统或其部件响应事件而执行的状态转换和操作。
SysML为系统的结构模型、行为模型、需求模型和参数模型定义语义：
- 结构模型强调系统的层次以及对象之间的相互连接关系，包括类和装配；
- 行为模型强调系统中对象的行为，包括它们的活动、交互和状态历史；
- 需求模型强调需求之间的追溯关系以及设计对需求的满足关系；
- 参数模型强调系统或部件的属性之间的约束关系。
SysML为模型表示法提供完整的语义。
3类9种
另有一种分类。SysML建模语言中的图模型如下图所示，可概括为3类9种。SysML可以分为行为图、需求图和结构图。三类图又具体化为共计9种模型图。SysML模型图与UML图存在交互。参考下图底部的说明。
- 实线框浅色背景：SysML和UML共有的图，包括序列图、用例图、状态机图、包图；
- 实线框浅色背景：SysML基于UML扩展而来，包括活动图、模块定义图、内部模块图；
- 虚线框浅色背景：SysML所特有的图，包括需求图和参数图。
应用现状
如果您是系统工程，并希望提高与其他系统工程师和其他系统和业务利益相关者的通信的精度和效率，则SysML是通用语言的绝佳选择。MBSE中比较重要的建模语言是SYSML语言。在航天航空，国防军工，轨道，汽车电子，医疗器械等方面应用比较广泛。
MBSE
又称基于模型的系统开发（MBSD，Model-based Systems Development），一种系统工程过程范例，强调严格的体系结构建模原则和最佳实践应用于整个系统开发生命周期（SDLC，Software Development Life Cycle）中的系统工程活动，包括但不限于：需求分析，功能分析，性能分析，系统设计，贸易研究，系统架构规范以及系统验证和确认（V＆V，Verification and Validation）
MBSE方法的特征：
- 强调精确和完整的系统架构模型蓝图，通常使用具有多个视图/视点的架构框架组织，作为整个SDLC中的主要工件；
- 促进使用开放标准进行架构建模和工具互操作性（如，SysML，UML2，XMI，AP233），这些开放标准用于指定系统架构模型，并作为系统工程师和其他利益相关者（软件工程师，电气工程师，机械工程师，客户等）之间的通用语言；
- 确保系统架构模型是需求驱动的，所有模型元素必须完全可追溯到系统和用户要求；
- 确保系统架构模型以架构为中心，所有模型元素必须保持结构和功能完整性关系，并支持所有系统利益相关者视图和视点的完全派生可跟踪性；
- 将传统的系统工程最佳实践与架构建模最佳实践相结合。
SysML应用模式
随着SysML成为MBSE的主流建模语言，几种SysML使用模式如下：
- SysML-as-Pretty-Pictures：可简称为SPP，最不正式且最不严格的SysML使用模式，也是SysML被滥用的最常见方式。在此模式中，使用SysML表示法代替临时建模表示法（如，Visio或PowerPoint绘图），但相对较少关注SysML良好性及其基本的可模拟和可执行语义。因此，在此模式下生成的SysML模型很少能够驱动动态模拟或精确指定系统架构蓝图。
- SysML-as-Model-Simulation：可简称为SMS，对SPP模式的重大改进，因为它强调系统动态行为和系统参数约束的模拟。在SMS模式中，至少一些SysML行为图（活动，序列，状态机图）由行为模拟引擎执行。此外，一些参数图约束也可以由约束传播引擎（MATLAB/Simulink，OpenModelica，SysML工具专有插件等）来执行。对于那些试图摆脱SPP语言滥用的人来说，这是一种中间SysML使用模式。
- SysML-as-System-Architecture-Blueprint：可简称为SSAB，是对SMS模式的实质性改进，因为它扩展后者以包括系统架构模型（SAM）的精确和完整的规范。SAM的目的是足够精确和完整，以作为系统项目中涉及的所有工程过程的“系统架构真理”，包括系统工程师（SE），软件工程师（SWE），电气工程师（EE），机械工程师（ME）等。为了使SAM成为系统工程项目的系统架构真理，SAM必须满足所有五C系统架构质量（正确，完整，清晰，简洁和一致）。相对先进的SysML使用模式，通常是SMS模式的自然演变。
- SysML-as-Executable-System-Architecture：可简称为SESA，这种SysML使用模式是对SSAB模式的量子改进，它扩展后一种模式SAM行为和参数规范可模拟，并且可能是可执行的。MBSE上下文中的可执行文件通常是指部分或全自动生成系统接口，系统测试用例。
优缺点
SysML作为MBSE应用程序的架构建模语言有哪些优缺点？
尽管OMG SysML重用许多UML2的图表和结构，但是这种新的SysML轻量级方言（Profile）远比它的语言父类成熟得多，因为它加剧从UML2继承的问题，并通过引入两种新的图表类型（Requirement and Parametric）增加新的问题。图表相对不成熟（v。1.x vs. v.2.y）：
SYSML和UML2一般问题
与UML2.x母语共享。
语言臃肿
- 对UML 2.x的一个普遍和公平的批评是，它是无偿的大而复杂的。虽然SysML市场营销表明SysML对于系统工程师来说是一种“更小，更简单”的语言，但实际情况是SysML本身也会受到语言膨胀的影响，因为它增加两个新的图表（需求和参数）并且大大增加不精确语义的刻板印象数量（请参阅下面的UML2.x voodoo语义的增加），而未能从它继承的七个UML2图中明确排除许多冗余和以软件为中心的UML2结构。由于SysML规范没有提供关于如何将SysML模型与UML模型结合用于包括软件工程师和系统工程师在内的工程团队的指导，因此这种情况更加恶化。
- 建议：明确删除SysML不需要的UML构造。为包含软件工程师和系统工程师的工程团队提供有关如何将SysML模型与UML模型相结合的具体指南。鼓励工具供应商支持两种语言之间共享的图表的自动翻译。
增加UML 2.x voodoo语义
- 对UML 2.x的另一个常见和公平的批评是它的语义，包括它声称的可执行语义（也就是动作语义）是模糊和不精确的。虽然SysML市场营销表明SysML支持用于指定参数约束的精确语义，但事实是SysML仅为ConstraintBlock，ConstraintProperty和Context-Specific Values / Constraints定义模糊的自然语言语义。类似地，与连续/离散速率和概率相关的活动图扩展的语义缺乏正式的精度。
- 建议：为参数和需求图构造以及活动图扩展添加精确语义。
特定于SYSML的问题
适用于SysML但不适用于UML2母语。
物理和信息（标准）接口的结构构造是无偿的复杂和混乱。
- StandardPorts，FlowPorts，提供和必需的接口以及ItemFlows的语义和符号在SysML v.1.0 - 1.2中是无用的复杂和混乱，因为它们将依赖关系与流关系混为一谈。不幸的是，用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）中进行彻底检查。这次大修应该考虑从SysML1.x参数图和第三方数学建模和仿真工具（例如，MATLAB / Simulink，Mathematica）之间构建双向桥梁的经验教训。
要求结构不完整且令人困惑。
- 与需求图相关的问题包括但不限于澄清分解/包含语义，分类，定义基本属性，澄清关系语义以及减少与用例的语义重叠。
- 建议：用组合物替换遏制以进行需求分解。退出复制依赖项。为source，priority，risk，verifyMethod等提供其他Requirement属性。
分配关系和表格不完整且含糊不清。
- 除AllocateActivityPartition构造型外，当前规范无法利用其父语言的体系结构完整性分配。此外，Allocate和Allocated构造型的定义强烈暗示混合依赖和流语义，它们表明新手UML建模者（“箭头指向哪个方向？”）。
- 建议：使用使用区别符号的流替换分配依赖关系（不是使用关键字标记的虚线箭头）。要求实现自动为AllocateActivityPartitions生成Allocate依赖项。
ValueType-Type集成需要简化和SI模型库
- 需要澄清和简化ValueTypes与Units和QuantityKinds（以前称为Dimensions）的当前用法以及它们与UML DataTypes的集成。
- 建议：根据国际单位制（SI）标准简化和预定义标准SysML ValueType模型库。
对比UML
相同：SysML的元模型理论与UML一样，是4层结构。
在应用方面，SysML是专门为系统工程开发的，而UML更多的是面向软件工程，设计初衷也是方便软件开发。
在语言结构方面，SysML是由图和元模型组成，图是语法，元模型是语义。
SysML和UML的语言结构均以包的形式来存放，各包中包括模型参数和语法机制。SysML重用UMl2.0中的大多数包以及UML2.0的语言机制，扩展新功能机制，如类包、活动包等，新增UML中没有的包，如装配包、需求包、参数包。
两者组合
SysML和UML模型元素可以组合在同一个模型中吗？
理论上，SysML和UML模型元素可以在同一模型中协同组合。实际上，这是SysML Partners的开源规范项目的语言设计目标之一：支持SysML + UML混合语言使用。
确保SysML构造可以与系统工程师和软件工程师共享的模型中的UML构造协同组合，前者使用SysML，后者使用UML。SysML和UML的协同组合应最大限度地提高需求可追溯性，并最大限度地减少两种语言之间的语义重叠。
对比
SysML和UML建模语言之间的差异在性质上比重量级和实质性更加轻量级和辩证。这应该是预料之中的，因为SysML最初设计用于与软件工程师合作的软件工程师使用UML进行软件分析和设计，而SysML被定义为UML2的适度扩展的实用子集。实际上，虽然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对13）和总结构中测量的整体语言较小。
- SysML模型管理构造支持模型，视图和视点的规范，这些规范在架构上与
IEEE-Std-1471-2000（IEEE推荐的软件密集型系统架构描述实践）保持一致。
SysML和UML间存在交集，即SysML语言中的部分图是和UML中的相应图是一致的，如用例图。SysML也有基于UML扩展而来的图，如活动图。还有一部分图是SysML特有的，如需求图。
表格比较
SYSML图 | UML图 | 目的 |
活动图（ACT或行为）：一种行为图，主要关注控制流程，以及输入转化为输出的过程。 | 活动图：对系统中任何位置的流进行建模。特别是，描述正常用户交互以及替代和例外的用例中的流程由这些活动图很好地建模。 | [行为图]活动图显示作为控制和数据流的系统行为。用于功能分析。比较流程图（FBD）和扩展功能流程图（EFFBD），已经在系统工程师中常用。 |
模块定义图（BDD或bdd）：一种结构图，与内部模块图及参数图互补，用于描述系统的层次以及系统/组件的分类。 | 类图：类图表示类，它们的定义和关系。问题空间中的类和实体也是解决方案空间中的详细技术实体。定义类的属性和操作包含在此类图中。类图中的关系说明类如何与其他类交互，协作和继承。类还可以表示关系表，用户界面和控制器。 | [结构图]模块定义图将系统结构显示为组件及其属性，操作和关系。对系统分析和设计很有用。 |
内部模块图（IBD或ibd）：一种结构图，与模块定义图及参数图互补，通过组件（Parts）、端口、连接器来用于描述系统模块的内部结构。 | 复合结构图：在运行时模拟组件或对象行为，显示系统执行期间组件的布局，关系和实例 | [结构图]内部模块图显示系统组件的内部结构，包括其部件和连接器。对系统分析和设计很有用。 |
包图（PKG或pkg）：一种结构图，以包的形式组织模型间的层级关系。 | 包图：表示系统组织的子系统和区域。它还可以模拟包之间的依赖关系，并帮助将业务实体与用户界面，数据库，安全性和管理包分开。 | [结构图]包图显示如何将模型组织到包，视图和视点中。对模型管理很有用。 |
参数图（PAR或par）：SysML特有的图，与模块定义图及参数图互补，用于说明系统的约束。 | NA | [结构图]封装图显示结构元素之间的参数约束。对性能和定量分析很有用 |
需求图（REQ或req）：用于表述文字化的需求、需求间的关系，以及与之存在满足、验证等关系的其他模型元素。SysML还包含分配关系的表述，包括功能到组件的分配、软件到硬件的分配以及逻辑到物理的分配 | NA | 需求图显示系统需求及其与其他元素的关系。适用于需求工程，包括需求验证和确认（V＆V）。 |
序列图（SD或sd）：一种行为图，主要关注并精确描述系统内部不同模块间的交互 | 序列图：根据对象的时间轴模拟对象之间的交互。对象可以在这些图上具体显示，也可以是属于类的匿名对象。 | [行为图]序列图显示系统行为作为系统组件之间的交互。对系统分析和设计很有用 |
状态机图（STM或stm）：一种行为图，主要关注系统内部模块的一系列状态以及在事件触发下的不同状态间的转换。 | 状态机图：显示内存中对象的运行时生命周期。这样的生命周期包括对象的所有状态以及状态改变的条件。 | [行为图]状态机图将系统行为显示为组件或交互响应事件时所经历的状态序列。对系统设计和模拟/代码生成很有用。 |
用例图（UC或uc）：一种黑盒视图，是系统功能的高层描述，用于表达系统执行的用例以及引起系统执行行为的参与者。 | 用例图：从用户的角度提供系统或业务流程功能的概述。用户“使用”系统的方式是创建用例图的起点。 | [行为图]用例图将系统功能需求显示为对系统用户有意义的事务。用于指定功能要求。（注意潜在的语义重叠与需求图中指定的功能需求。） |
分配表 | NA | [制图表，不是图表]分配表显示模型元素之间的各种分配关系（如需求分配，功能分配，结构分配）。有助于促进自动验证和确认（V＆V）和差距分析。 |
实例（但没有对象图） | 根据OMG+SysML+1.2次要修订版，允许使用实例规范，但不允许使用对象图。 | NA |
NA | 对象图 | 对象图在运行时显示内存中的对象及其链接。因此，这些对象图还有助于在实践中可视化多重性。 |
NA | 通信图 | 通信图显示对象在运行时如何在内存中相互通信（交互）。这些通信图在其目的方面类似于序列图。但代表性不同。 |
NA | 组件图 | 组件图从结构上模拟组件及其关系。这些组件可以包括例如可执行文件，可链接库，Web服务和移动服务。这些图表为系统的架构决策增加价值。 |
NA | 部署图 | 部署图对系统的硬件节点和处理器的体系结构进行建模，并提供显示软件组件所在节点的机会。 |
NA | 交互概述图 | 时序图模拟时间的概念以及对象状态随时间变化的方式。此外，这些图可以同时比较多个对象的状态。 |
NA | 配置文件图 | 配置文件图允许创建可扩展的配置文件，这些配置文件可应用于从配置文件继承的元素。这些图表通过以受控方式扩展标准来增加价值。 |
NA | 时序图 | 时序图模拟时间的概念以及对象状态随时间变化的方式。此外，这些图可以同时比较多个对象的状态。 |
工具
针对不同规模的项目，可选择使用简单的绘图工具（如Visio，OpenOffice Draw，GIMP）或专业的建模工具。绘图工具提供包含SysML语法（框和行）的简单工具模板，但通常不强制执行SysML Bookkeeping操作，包括但不限于以下内容：
- 执行句法（符号）和语义良好规则；
- 支持大规模模型管理和团队建模；
- 支持双向需求可追溯性；
- 支持模拟活动和参数图
如果是小型项目建模，绘图工具可以满足需求。但对于复杂系统，建议使用专业的SysML建模工具，虽然有一定的入门学习成本。
Gaphor
Gaphor是一个支持UML，SysML，RAAML和C4的支持多平台的建模工具。
MagicDraw
MagicDraw是基于模型的系统工程（MBSE）工具的坚实选择，它严格执行语法（符号）和语义的SysML格式良好规则。MagicDraw提供专有和商业插件，可与需求管理工具（例如DOORS，PTC Integrity）和仿真工具（MATLAB/Simulink，Mathematica）集成。
缺点：复杂的UI，特征性，活动图不能完全嵌套，并且序列图不能完全理解接口和信号的语义。
Papyrus
Papyrus是一个免费开源的支持UML，SysML，MARTE的建模工具，允许个人和小团队了解SysML及其MBSE功能。Papyrus SysML的功能集有限且不成熟，不足以与更高质量的商业SysML建模工具竞争。
Modelio
Modelio是一个支持UML，SysML，BPMN，ArchiMate的建模工具。
Rational Rhapsody
Rhapsody是一个MBSE工具，它为UML、SysML状态机图表语法和语义提供强大支持，包括状态机模拟和执行。提供专有插件，可与需求管理工具（如DOORS）和仿真工具（MATLAB/Simulink）集成。但对活动和序列图的支持相对较弱，界面UI不直观且过时，
缺点：不直观的UI，对状态机图语法和语义的偏见，活动图不能完全嵌套，相对昂贵
Enterprise Architect
EA工具是符合OMG SysML标准并且相对易于使用的系统架构建模工具的坚实技术选择。Sparx EA支持基本的基于模型的系统工程（MBSE）活动，例如需求可追溯性，用于分析和设计的行为（活动，状态机，序列）图的模拟，用于贸易研究的参数图的模拟以及自动文档生成。Sparx EA为需求管理工具（例如DOORS）和仿真工具（MATLAB/Simulink）提供专有和商业插件。Sparx EA还可以很好地与开源标准集成，用于团队建模和参数化图表模拟（Open Modelica）。
其他
https://www.visual-paradigm.com/cn/features/sysml-diagram-tool/
参考
