编辑推荐: |
本文部分内容来自于OMG官方网站,详细介绍什么是SYSML以及SYSML的图表类型,希望对大家的学习能有所帮助。 |
|
什么是SYSML?
OMG系统建模语言™ (OMGSysML®)是一种通用图形建模语言,用于指定,分析,设计和验证可能包括硬件,软件,信息,人员,程序和设施的复杂系统。特别是,该语言提供了图形表示,其具有用于建模系统需求,行为,结构和参数的语义基础,用于与其他工程分析模型集成。它代表了
UML 2的一个子集 扩展需要满足UML™for Systems Engineering
RFP的要求,如图所示.SysML利用OMG XML元数据交换(XMI®)在工具之间交换建模数据,并且还旨在与不断发展的ISO兼容
10303-233 系统工程数据交换标准。
系统工程UML RFP由OMG和国际系统工程理事会(INCOSE)联合开发,并由OMG于2003年3月发布.RFP指定了扩展UML以满足系统工程社区需求的要求。该SysML的规格是应通过这些要求开发的不同群体的工具供应商,最终用户,学术界和政府代表。对象管理集团宣布于2006年7月6日通过,并于2007年9月推出OMG
SysML™v1.0。
SysML和UML之间的关系
为什么要使用SysML?
如果您是系统工程师,并希望提高与其他系统工程师和其他系统和业务利益相关者(例如客户,软件工程师,电气工程师,机械工程师)的通信的精度和效率,那么您应该考虑使用SysML建模语言标准作为通用语言(通用语言)。
系统建模语言(SysML)已成为基于模型的系统工程(MBSE)应用程序的事实上的标准系统架构建模语言。SysML是UML
2的一种方言,它扩展了软件密集型应用程序的统一建模语言(UML)标准,使其可以成功应用于系统工程应用程序。
谁创建了SysML?
系统建模语言(SysML)由SysML Partners创建,SysML
Partners是系统工程专家和软件建模工具专家的非正式协会,由Cris Kobryn于2003 年组织,旨在创建一种应用于系统工程的
统一建模语言(UML)的概要(方言)。
由于Kobryn之前曾成功领导过UML 1.x和UML 2.0语言设计团队,因此INCOSE的David
Oliver和Sanford Friedenthal要求Kobryn领导他们共同努力回应对象管理小组的系统工程UML
RFP于2003年3月发布。作为SysML合作伙伴的主席,Kobryn创造了语言名称“SysML”(“系统建模语言”的缩写),设计了原始的SysML徽标,并组织了SysML核心语言设计团队作为开源规范项目。
SYSML发展历史?
2004 年1 月12 日,SysML 的非正式组织向OMG
提交了SysML 语言的初步草案。
2004 年8 月2 日向OMG 提交了修改后的SysML0.8
版。
2004 年10 月11 日向OMG 提交了第二次修改后的SysML0.85
版。
2005 年1 月10 日向OMG提交了第三次修改后的SysML0.9[6]版。SysML0.9
版是一个重要的里程碑,确定了核心的系统工程图形。预计SysML1.0正式版将在2005 年的第二季度被OMG
作为标准采纳,
2005年年内工具开发商将推出SysML 的集成支持环境。
如何报告SysML问题或发出SysML更改请求?
OMG SysML的当前版本为V 1.5,OMG的SysML
V 1.6修订工作组(RTF)正在基于来自SysML的工具供应商和用户群体的反馈建议改进OMG SysML的。在OMG的SysML诉1.6
RTF的问题列表(http://www.omg.org/issues/sysml-rtf.open.html)是公开的,包括可以追溯到到2006年的问题,并分为开放和关闭的问题。
SysML的当前版本是什么?
OMG SysML规范的当前版本是OMG SysML v.1.5,可以从本网站的SysML规范页面获得,也可以从OMG网站下载。
OMG SysML v.1.5小修订版更改摘要:
正如在长期(10年以上)系列或次要OMG SysML 1.x次要修订版中应该预期的那样,OMG
SysML v.1.5次要修订版仅包括对该语言的微小调整。
- 允许通过专门化SysML Requirement构造型来定义Requirement属性和分类。还添加了Requirement
compartment符号以显示Requirement关系。
- 添加Block隔离符号以显示Signal Receptions。
下载:
您可以从 SysML规范页面下载 OMG SysML
v.1.5规范以及先前版本的规范。
什么是基于模型的系统工程(MBSE)?
其实提到 SysML,不得不提另外一个概念:系统功能 。更准确的说是
:基于模型的系统工程(MBSE)。基于模型的系统工程(MBSE),又称基于模型的系统开发(MBSD),是一种系统工程过程范例,强调严格的体系结构建模原则和最佳实践应用于整个系统开发生命周期(SDLC)中的系统工程活动。这些系统工程活动包括但不限于需求分析,功能分析,性能分析,系统设计,贸易研究,系统架构规范以及系统验证和验证(V&V)。
MBSE方法的特征 :
- 强调精确和完整的系统架构模型“蓝图”,通常使用具有多个视图/视点的架构框架组织,作为整个系统开发生命周期(SDLC)中的主要工作工件;
- 促进使用开放标准进行架构建模和工具互操作性(例如,SysML,UML
2,XMI,AP233),这些开放标准用于指定系统架构模型,并作为系统工程师和其他利益相关者(软件工程师,电气工程师,机械工程师,客户等)之间的通用语言;
- 确保系统架构模型是需求驱动的,所有模型元素必须完全可追溯到系统和用户要求;
- 确保系统架构模型以架构为中心,所有模型元素必须保持结构和功能完整性关系,并支持所有系统利益相关者视图和视点的完全派生可跟踪性;
- 将传统的系统工程最佳实践与架构建模最佳实践相结合。
SysML应该如何应用于MBSE项目?
随着SysML成为基于模型的系统工程(MBSE)的主流建模语言,几种SysML使用模式如下
:
1、SysML-as-Pretty-Pictures 这是最不正式且最不严格的SysML使用模式。不幸的是,它也是SysML被滥用的最常见方式。在SysML-as-Pretty-Pictures使用模式中,使用SysML表示法代替临时建模表示法(例如,Visio或PowerPoint绘图),但相对较少关注SysML良好性及其基本的可模拟和可执行语义。因此,在SysML-as-Pretty-Pictures模式下生成的SysML模型很少能够驱动动态模拟或精确指定系统架构蓝图。
2、SysML-as-Model-Simulation 这种SysML使用模式是对SysML-as-Pretty-Pictures模式的重大改进,因为它强调了系统动态行为和系统参数约束的模拟。在SysML-as-System-Simulation模式中,至少一些SysML行为图(活动,序列,状态机图)由行为模拟引擎执行。此外,一些参数图约束也可以由约束传播引擎(MATLAB
/ Simulink,OpenModelica,SysML工具专有插件等)来执行。对于那些试图摆脱SysML-as-Pretty-Pictures语言滥用的人来说,这是一种中间SysML使用模式。
3、SysML-as-System-Architecture-Blueprint:这种SysML使用模式是对SysML-as-Model-Simulation模式的实质性改进,因为它扩展后者以包括系统架构模型(SAM)的精确和完整的规范。SAM的目的是足够精确和完整,以作为系统项目中涉及的所有工程过程的“系统架构真理”,包括系统工程师(SE),软件工程师(SWE),电气工程师(EE),机械工程师(ME)等。为了使SAM成为系统工程项目的系统架构真理,SAM必须满足所有五C系统架构质量(正确,完整,清晰,简洁和一致)。这是一种相对先进的SysML使用模式,通常是SysML-as-System-Simulation模式的自然演变。、、、
4、SysML-as-Executable-System-Architecture:这种SysML使用模式是对SysML-as-System-Architecture-Blueprint模式的量子改进,因为它扩展了后一种模式SAM行为和参数规范可模拟,并且可能是可执行的。MBSE上下文中的可执行文件通常是指部分或全自动生成系统接口,系统测试用例。
SysML和UML之间的关系及所包含图
SysML和UML建模语言之间的差异在性质上比重量级和实质性更加轻量级和辩证。这应该是预料之中的,因为SysML最初设计用于与软件工程师合作的软件工程师使用UML进行软件分析和设计,而SysML被定义为UML
2的适度扩展的实用子集。实际上,虽然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所特有的,这些图与UML间没有关系,例如需求图。
SysML建模语言中的图模型如下图所示,可以概括为“3类9种”。SysML可以分为行为图、需求图和结构图。三类图又具体化为共计9种模型图。同时,SysML模型图与UML图存在交互。蓝色部分是SysML和UML共有的图,包括序列图、用例图、状态机图、包图,黄色部分是SysML基于UML扩展而来,包括活动图、模块定义图、内部模块图。还有一部分是SysML语言所特有的图,包括需求图和参数图。
SysML图类型
它是SysML中的基本结构单元,可用于表示硬件,软件,设施,人员或任何其他系统元素。系统结构由块定义图和内部模块图表示。块定义图描述了系统层次结构和系统/组件分类。内部模块图描述了系统的部件,端口和连接器的内部结构。包图用于组织模型。
行为图包括用例图,活动图,序列图和状态机图。用例图提供了通过系统或系统部件之间的交互实现的功能的高级描述。活动图表示活动之间的数据流和控制。序列图表示系统的协作部分之间的交互。状态机图描述了系统或其部件响应事件而执行的状态转换和操作。
SysML包括一个图形构造,用于表示基于文本的需求,并将它们与其他模型元素相关联。需求图捕获需求层次结构和需求派生,并且满足和验证关系允许建模者将需求与满足或验证需求的模型元素相关联。需求图提供了典型需求管理工具和系统模型之间的桥梁。
参数图表示对系统属性值的约束,例如性能,可靠性和质量属性,并且用作将规范和设计模型与工程分析模型集成的手段。
SysML 为系统的结构模型、行为模型、需求模型和参数模型定义了语义。结构模型强调系统的层次以及对象之间的相互连接关系,包括类和装配。行为模型强调系统中对象的行为,包括它们的活动、交互和状态历史。需求模型强调需求之间的追溯关系以及设计对需求的满足关系。参数模型强调系统或部件的属性之间的约束关系。SysML
为模型表示法提供了完整的语义。
SysML的四大支柱
以下SysML-UML 2比较表将SysML图与其中存在的UML对应图进行比较。如果没有SysML图的UML图对应物(例如,参数和要求图),则标记为N
/ A; 类似地,在UML图不存在SysML图对应的情况下,它被标记为N / A(例如,UML 2通信图)。
SysML-UML 2比较
SYSML图 |
UML图 |
目的
|
活动图(ACT或行为):一种行为图,主要关注控制流程,以及输入转化为输出的过程。 |
活动图:对系统中任何位置的流进行建模。特别是,描述正常用户交互以及替代和例外的用例中的流程由这些活动图很好地建模。 |
[行为图]活动图显示了作为控制和数据流的系统行为。
用于功能分析。
比较流程图(FBD)和扩展功能流程图(EFFBD),已经在系统工程师中常用。
|
模块定义图(BDD或bdd):一种结构图,与内部模块图及参数图互补,用于描述系统的层次以及系统/组件的分类。 |
类图:类图表示类,它们的定义和关系 问题空间中的类和实体也是解决方案空间中的详细技术实体。
定义类的属性和操作包含在此类图中。类图中的关系说明了类如何与其他类交互,协作和继承。类还可以表示关系表,用户界面和控制器。
|
结构图]模块定义图将系统结构显示为组件及其属性,操作和关系。
对系统分析和设计很有用。 |
内部模块图(IBD或ibd):一种结构图,与模块定义图及参数图互补,通过组件(Parts)、端口、连接器来用于描述系统模块的内部结构。 |
复合结构图: 在运行时模拟组件或对象行为,显示系统执行期间组件的布局,关系和实例
|
[结构图] 内部模块图显示了系统组件的内部结构,包括其部件和连接器。
对系统分析和设计很有用。 |
包图(PKG或pkg):一种结构图,以包的形式组织模型间的层级关系。 |
包图:表示系统组织的子系统和区域。它还可以模拟包之间的依赖关系,并帮助将业务实体与用户界面,数据库,安全性和管理包分开。 |
结构图]包图显示了如何将模型组织到包,视图和视点中。
对模型管理很有用。
|
参数图(PAR或par):SysML特有的图,与模块定义图及参数图互补,用于说明系统的约束。 |
|
[结构图]封装图显示结构元素之间的参数约束。对性能和定量分析很有用。 |
需求图(REQ或req):用于表述文字化的需求、需求间的关系,以及与之存在满足、验证等关系的其他模型元素。
SysML还包含了分配关系的表述,包括功能到组件的分配、软件到硬件的分配以及逻辑到物理的分配
|
|
[需求图]需求图显示了系统需求及其与其他元素的关系。
适用于需求工程,包括需求验证和验证(V&V)。
|
序列图(SD或SD):一种行为图,主要关注并精确描述系统内部不同模块间的交互, |
序列图:根据对象的时间轴模拟对象之间的交互。对象可以在这些图上具体显示,也可以是属于类的匿名对象。 |
[行为图]序列图显示系统行为作为系统组件之间的交互。
对系统分析和设计很有用。
|
状态机图(STM或stm):一种行为图,主要关注系统内部模块的一系列状态以及在事件触发下的不同状态间的转换。 |
状态机图:显示内存中对象的运行时生命周期。这样的生命周期包括对象的所有状态以及状态改变的条件。 |
行为图]状态机图将系统行为显示为组件或交互响应事件时所经历的状态序列。
对系统设计和模拟/代码生成很有用。
|
用例图(UC或uc):一种黑盒视图,是系统功能的高层描述,用于表达系统执行的用例以及引起系统执行行为的参与者。 |
用例图:从用户的角度提供系统或业务流程功能的概述。用户“使用”系统的方式是创建用例图的起点。 |
[行为图]用例图将系统功能需求显示为对系统用户有意义的事务。
用于指定功能要求。(注意潜在的语义重叠与需求图中指定的功能需求。)
|
分配表 |
|
[制图表; 不是图表]分配表显示了模型元素之间的各种分配关系(例如,需求分配,功能分配,结构分配)。
有助于促进自动验证和验证(V&V)和差距分析。
|
实例(但没有对象图) |
根据OMG SysML 1.2次要修订版,允许使用实例规范,但不允许使用对象图。 |
|
|
对象图 |
对象图 在运行时显示内存中的对象及其链接。 因此,这些对象图还有助于在实践中可视化多重性。 |
|
通信图 |
通信图显示对象在运行时如何在内存中相互通信(交互)。这些通信图在其目的方面类似于序列图;但是,他们的代表性是不同的。 |
|
组件图 |
组件图 从结构上模拟组件及其关系。 这些组件可以包括例如可执行文件,可链接库,Web服务和移动服务。这些图表为系统的架构决策增加了价值。 |
|
部署图 |
部署图对系统的硬件节点和处理器的体系结构进行建模,并提供显示软件组件所在节点的机会。 |
|
交互概述图 |
时序图模拟时间的概念以及对象状态随时间变化的方式。此外,这些图可以同时比较多个对象的状态。 |
|
配置文件图 |
配置文件图 允许创建可扩展的配置文件,这些配置文件可应用于从配置文件继承的元素。这些图表通过以受控方式扩展标准来增加价值 |
|
时序图
|
时序图模拟时间的概念以及对象状态随时间变化的方式。此外,这些图可以同时比较多个对象的状态。 |
SysML和UML模型元素可以组合在同一个模型中吗?
理论上,SysML和UML模型元素可以在同一模型中协同组合。实际上,这是SysML
Partners的开源规范项目的语言设计目标之一:
支持SysML + UML混合语言使用:
确保SysML构造可以与系统工程师和软件工程师共享的模型中的UML构造协同组合,前者使用SysML,后者使用UML。SysML和UML的协同组合应最大限度地提高需求可追溯性,并最大限度地减少两种语言之间的语义重叠。
SysML作为MBSE应用程序的架构建模语言有哪些优缺点?
尽管OMG SysML重用了许多UML2的图表和结构,但是这种新的SysML轻量级方言(Profile)远比它的语言父类成熟得多,因为它加剧了从UML
2继承的问题,并通过引入两种新的图表类型(Requirement and Parametric)增加了新的问题。图表)相对不成熟(v。1.x
vs. v.2.y):
1、 SYSML和UML 2一般问题(与UML
2.x母语共享)
语言臃肿。
- 对UML 2.x的一个普遍和公平的批评是,它是无偿的大而复杂的。虽然SysML市场营销表明SysML对于系统工程师来说是一种“更小,更简单”的语言,但实际情况是SysML本身也会受到语言膨胀的影响,因为它增加了两个新的图表(需求和参数)并且大大增加了不精确语义的刻板印象数量(请参阅下面的UML
2.x voodoo语义的增加),而未能从它继承的七个UML 2图中明确排除许多冗余和以软件为中心的UML
2结构。由于SysML规范没有提供关于如何将SysML模型与UML模型结合用于包括软件工程师和系统工程师在内的工程团队的指导,因此这种情况更加恶化。
- 建议:明确删除SysML不需要的UML构造。为包含软件工程师和系统工程师的工程团队提供有关如何将SysML模型与UML模型相结合的具体指南。鼓励工具供应商支持两种语言之间共享的图表的自动翻译。
增加UML 2.x voodoo语义。
- 对UML 2.x的另一个常见和公平的批评是它的语义,包括它声称的可执行语义(也就是动作语义)是模糊和不精确的。虽然SysML市场营销表明SysML支持用于指定参数约束的精确语义,但事实是SysML仅为ConstraintBlock,ConstraintProperty和Context-Specific
Values / Constraints定义了模糊的自然语言语义。类似地,与连续/离散速率和概率相关的活动图扩展的语义缺乏正式的精度。
- 建议: 为参数和需求图构造以及活动图扩展添加精确语义。
2、特定于SYSML的问题(适用于SysML但不适用于UML
2母语)
物理和信息(标准)接口的结构构造是无偿的复杂和混乱。
- 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)中进行彻底检查。这次大修应该考虑从SysML 1.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模型库。
SysML建模工具
一旦您决定使用SysML作为MBSE团队或项目的通用规范语言,您就会面临使用绘图工具(例如,MS
Office Visio,OpenOffice Draw,GIMP)或真正的建模工具的选择。捕获您的SysML工作工件。绘图工具和可视化建模工具之间有什么区别?虽然绘图工具可能为您提供包含SysML语法(“框和行”)的工具模板,但通常不希望强制执行SysML“簿记”操作,包括但不限于以下内容:
- 执行句法(符号)和语义良好规则;
- 支持大规模模型管理和团队建模;
- 支持双向需求可追溯性;
- 支持模拟活动和参数图
因此,如果您是小型建模,并且只对使用SysML为少量(十几个或更少)系统工程师绘制简单模型感兴趣,您可能会发现一个绘图工具,如Visio,足以满足您的需求。但是,如果您需要捕获复杂系统或系统系统的功能分析或体系结构,那么使用真正的SysML建模工具将大大受益!
比较常用的SYSML工具:
1、Papyrus SysML
Papyrus SysML是一个免费的开源建模工具,允许个人和小团队了解SysML及其MBSE功能。然而,Papyrus
SysML的功能集是有限且不成熟的,并且它还没有与更高质量的商业SysML建模工具竞争。
2、MagicDraw
MagicDraw是基于模型的系统工程(MBSE)工具的坚实选择,它严格执行语法(符号)和语义的SysML格式良好规则。MagicDraw提供专有和商业插件,可与需求管理工具(例如DOORS,PTC
Integrity)和仿真工具(MATLAB / Simulink,Mathematica)集成。
缺点:复杂的UI,特征性,活动图不能完全嵌套,并且序列图不能完全理解接口和信号的语义。
3、Rational Rhapsody
Rhapsody是一个MBSE工具,它为UML / SysML状态机图表语法和语义提供强大支持,包括状态机模拟和执行。相比之下,Rhapsody对活动和序列图的支持相对较弱。由于Rhapsody的UI不直观且过时,因此它往往是平庸的SysML绘图工具。Rhapsody提供专有插件,可与需求管理工具(例如DOORS)和仿真工具(MATLAB
/ Simulink)集成。
缺点:不直观的UI,对状态机图语法和语义的偏见,活动图不能完全嵌套,相对昂贵。
4、Enterprise Architect
EA工具 是符合OMG SysML标准并且相对易于使用的系统架构建模工具的坚实技术选择。Sparx
EA支持基本的基于模型的系统工程(MBSE)活动,例如需求可追溯性,用于分析和设计的行为(活动,状态机,序列)图的模拟,用于贸易研究的参数图的模拟以及自动文档生成。Sparx
EA为需求管理工具(例如DOORS)和仿真工具(MATLAB / Simulink)提供专有和商业插件。Sparx
EA还可以很好地与开源标准集成,用于团队建模和参数化图表模拟(Open Modelica)。
SYSML应用现状
如果您是系统工程,并希望提高与其他系统工程师和其他系统和业务利益相关者的通信的精度和效率,那么SysML是通用语言的绝佳选择。MBSE中比较重要的建模语言是SYSML语言。在航天航空,国防军工,轨道,汽车电子,医疗器械等方面应用比较广泛。
后记
希望您读了此文后有所受益。
如果您有经验乐于分享,欢迎投稿给我们。
如果您对我们的培训、咨询和工具感兴趣:
|