本章介绍了SysML语言的概况,并提供了一个简单的指导关于如何开始使用SysML建模。并随后介绍SysML的简化版本,我们称为SysML-Lite,带有一个语言的简单示例,和如何使用一个典型的建模工具绘制模型的提示。也介绍了与描述在1.2节系统工程过程一致的简化的基于模型的系统工程(MBSE)方法。在本章结尾,探讨了学习SysML和MBSE的一些挑战。
SysML是一种通用的图形化建模语言,支持复杂系统的分析、规格说明、设计、验证、确认。这些系统可以包含硬件、软件、数据、人员、过程、设施,和其它人工元素和自然系统。语言试图来帮助指定和架构系统并明确说明它们的组件,组件随后被设计使用其它领域特定语言诸如,软件设计的UML语言和硬件设计VHDL语言和3维的几何设计。SysML试图来促进MBSE方法的应用,并生成一个聚合和一致的SysML系统模型,这种方法的好处描述在第2.1.2节。
SysML可以表示系统、组件、和实体的内容如下:
SysML包含9类图,图分类显示如图3.1中所示。所有图的类型被这里被汇总和分类,并说明它与UML图的关系:
(注:更多有关SysML信息可以被获取通过官方网址是http://www.omgSysML.org。)
图3.1 SysML 图分类
每类图对应的模型,以图形化方式表示了系统的一个特定方面,描述在第2.1.2节。模型元素的类型和相关标志(例,图元素),可以出现在一个图上被约束通过它的图类型。例如,活动图可以包含表示动作、控制流、和输入/输出流(即,对象流)的图元素,但没有图元素对应连接器和端口。作为一个结果,一种图表示一个正在考虑的模型库的一个子集,描述在第2.1.2节。表格表示,诸如,在SysML中分配表也被支持,作为图表示模型信息的一个补充。
这里介绍的SysML-Lite,作为SysML语言的简化版来帮助人们开始使用SysML建模。它包含9类SysML图中的6类,和一个可用的语言特征的子集对应每种图的类型。SysML-Lite提供一种明显的建模功能。本节提供SysML-Lite的一个简短的介绍,伴随一个简单的例子来强调SysML-Lite的特征。本节也包含帮助一个新的建模者使用一个典型的建模工具的工具提示。
SysML-Lite中的6类图说明在图3.2。每张图包含一个标题,其识别图的类型,和其它有关图的信息,解释在第5.3.2节。SysML-Lite包含的6种图的类型如下:
这个图集提供一种模型,用户使用一个替代的功能对应系统建模,覆盖许多经典的系统工程图。
图3.2 SysML-Lite包含9类SysML图中的6类和一个语言特征的子集,
SysML-Lite包含语言特征的一个子集对应6个SysML图中的每个。SysML-Lite的一些特征被表示在图3.3中。SysML语言特征的精确子集可以被采用根据需要。图也显示带有箭头的粗线,其不是语言的部分,但强调图的一些重要交叉关系。这些联系通常与经典的系统工程方法协调一致的,诸如,功能分解和分配。
包图:标签为:pkg。使用来管理包含在模型中的模型元素。在这个图中,系统模型出现在标题并包含包对应需求、行为、结构、和参数。这些包中的每个依次包含模型元素其分别被表示在需求图、活动图、模块定义图、内部模块图、参数图中。注:在模块定义图和内部模块图的模型元素都被包含在结构包中。
需求图:标签为req。表示一个单一层次的基于文本的需求,其典型是一个规范文档的部分。顶层需求命名为R1包含2个需求R1.1和R1.2。R1.1通过需求的文本属性对应到需求的文本,其可以被查找到在这个需求的规范文档中。
图3.3 SysML-Lite简化图示例
活动图:标签为act。活动图命名为A0表示System 1和System 1之间的交互。分别用表示通过点圆圈的初始节点和表示通过靶心的最终节点说明活动的开始和结束。活动指定一个简单的动作序列,开始执行动作:A1,紧接着执行动作:A2。动作:A1的输出和动作:A2的输入被表示通过矩形在动作边界上称为引脚。此外,活动分区标签为:System 1和:System 2职责是执行动作,其被封闭通过分区。动作称为:A1满足需求R1.2,被表示通过满足关系。
动作称为:A1在活动图A0中,被分解在称为A1的活动图,分解到动作:A1.1和:A1.2。这连个动作被分别执行通过:Component 1和:Component 2。活动A1的输出表示通过矩形在它的边界上对应活动A0的动作:A1的输出引脚。正如说明在活动图A0和A1中,输出是协调一致的从一个层级分解到下一个层次。
模块定义图:标签为bdd,常常被使用来描述一个系统的层次类似与一个零件树(例,装备树)。一个模块定义图被使用来定义一个系统或组件在系统层次的任何级别。模块定义图在图中显示由System 1和System 2组合构成System Context模块。System 1被进一步分解为Component 1和Component 2。System 1和Component 1模块都包含一个数值属性,可以对应一个物理或性能特征,诸如,它的重量或响应时间。
内部模块图:标签为ibd,显示System 1的组成部分如何互联。封闭的图框架表示System 1。System 1边界上的小的正方形被称为端口并表示它们的接口。System 1也被表示通过活动划分在活动A0,和组件被相似的表示通过活动划分在活动A1。
参数图:标签为par,被使用来描述属性之间的关系对应一个工程分析,诸如,性能,可靠性,或质量属性分析。在这个例子中,参数图包含一个单一约束称为Constraint 1,其对应一个等式或等式集。小的正方形在紧贴在内部表示等式的参数。系统和组件模块的属性随后可以被绑定到参数来建立一个等效关系。以这种方式,一个特定的分析可以被赋值使用系统设计的属性。通常,一个单一的约束被使用来表示一个特定的分析,并且参数表示分析的输入和输出。
在上面的图中,仅SysML语言特征的一小部分子集被说明,来说明建模系统的一些关键构件。下面是一个空气压缩机的简化模型,说明SysML-Lite图和语言特征如何被应用。
注:一些名称包含一个冒号(:)。这被描述在第4.3.12节,并被详细描述在第7.3.1节。
下面是一个使用SysML-Lite来建模空气压缩机,用于气动工具一个的例子。为了说明这个目的这个模型是高度简化的,并与显示在图3.3中的包含相同类型的图。
图3.4显示包图对应空气压缩机模型和包含包对应需求、行为、结构、和参数。模型组织如下图。
图3.4 这个包图被使用来组织空气压缩机模型使用包体对应需求、结构、行为、和参数。
Requirement包包含一组需求集,常常可被查找在一个空气压缩机的的需求规格说明书中。需求被绘制在需求图在图3.5中。顶层需求称为Air Compressor Specification包含一个压缩空气的功能需求,性能需求明确说明最大压力和最大流量, Storage Capacity需求明确说明指定存储容积,Power需求来明确说明源动力需要来压缩空气,和可靠性和可携带需求。存储容积需求的文本出现在图中, 为了减少混乱多数需求的文本没有显示。
图3.5这个需求图表示需求包包含的需求来明确说明空气压缩机的每个需求,可以包含需求文本
Structure包包含一个活动图,显示在图3.6,称为Operate Air Tool,其指定空气压缩机如何与外部系统交互包含Air Tool、Atmosphere,Operator不直接使用,被表示作为活动的分区。空气压缩机执行功能(即,动作)称为Compress Air,其有一个low pressure air输入和一个high pressure air输出。活动开始于初始节点(即,黑色填充的圆),和随后Operator执行Control Tool动作。活动完成它的执行在活动最终节点(即,靶心标志),在Control Tool动作完成执行后。Compress air动作被进一步分解在图3.9。
图3.6 这个活动图明确说明空气压缩机、操作者、空气工具和大气一起执行操作空气工具活动
Structure包包含模块定义图中表示的模块,在图3.7和图3.8中。模块定义图在图3.7称为Air Compressor Top Level包含一个模块称为Air Compressor Context,其由空气压缩机和表示用户,和顶层外部系统,和物理环境的模块组成。在这个例子中,用户是Operator,外部系统是Air Tool,和物理环境是Atmosphere。模块定义图在图3.8被称为Air Compressor System Hierarchy。Air Compressor模块在这个图中与显示在图3.7的模块是相同的,但这个图显示Air Compressor模块由组件构成,包含Motor Controller、Motor、Pump和Tank。Air Compressor,Motor,Pump和Tank包含数值属性,被使用来分析流量需求。
图3.7 这个模块定义图表示空气压缩机、操作者、空气工具、和大气作为模块。
活动图在图3.9分解动作称为Compress Air来自图3.6来明确说明Air Compressor的组件如何交互压缩空气。活动划分在活动图表示空气压缩机的组件。Motor Controller包含动作来Sense Pressure并Control Motor。Motor执行动作来Generate Torque,Pump执行动作来Pump Air,和Tank执行动作来Store Air。low pressure air输入和high pressure air输出是兼容的与Compress Air动作的输入和输出,在图3.6。这个活动被包含在行为包伴随Operate Air Tool活动。
图3.8这个模块定义图表示空气压缩机和它的组件
图3.9 这个活动图显示,空气压缩机的组件如何交互执行(图3.6中的压缩空气动作)
内部模块图称为Interconnection在图3.10中,显示Air Compressor组件如何被互联来自图3.8。图框架表示Air Compressor模块和端口在图框架上表示Air Compressor的外部接口。组件组成部分显示在内部模块图被包含在结构包伴随模块表示在模块定义图上。
模块定义图称为Analysis Context在图3.11中,被使用来定义语境对应执行流量分析。特别是,它包含一个模块称为Flow Rate Analysis,其组成约束模块称为Flow Rate Equations。该约束模块定义等式的参数和等式,但等式没有明确说明在此刻。Flow Rate Analysis也参考到Air Compressor Context来自图3.7其是分析的主题,定义Analysis Context使一个参数图将被生成对应Flow Rate Analysis模块正如显示在图3.12。图显示的Air Compressor和它的零件的数值属性包含:flow rate,箱体的volume和pressure,电机的horsepower,和泵的efficiency,和它们如何被绑定到Flow Rate Equations的参数。流量分析等式可以被解决通过一个分析工具,来确定Air Compressor和它的零件的属性值。分析语境模式被详细描述在第8.10节和在第17.3.6节。
这个空气压缩机例子说明,一个系统如何可以被建模使用SysML图和语言特征的一个子集称为SysML-Lite。即使一个简单的模型,这可以包含许多模型元素,并很快变的管理起来困难。一个建模工具被需要来有效的构建一个模型,它自身是协调的,并来管理复杂性。下面的章节描述,一个典型的SysML建模工具如何被使用来构建这个模型。
图 3.10 这个内部模块图显示,空气压缩机的组件如何被互联通过它们的端口, 使用来指定组件接口
图3.11 模块定义图被使用来指定流量分析,根据一个定义分析的等式(没显示)和参数约束模块
本节提供一种简短介绍关于如何开始建模使用一个典型的SysML建模工具。如何开始建模的问题常常出现当您第一次打开一个建模工具时。尽管每种工具可能有明显的区别,从一个用户界面视角看典型的工具分享很多共同点。作为一个结果,一旦一个建模者学习如何来构建一个SysML模型在一个工具中。它常常需要考虑用很少的时间来学习如何在另外一个工具建模。第18章包含关于SysML建模工具的一个讨论和它们的角色在一个典型的系统开发环境中,如何集成SysML建模工具与其它工具,和选择一个SysML建模工具的准则。
图3.12 这个参数图表示流量分析、和等式的参数如何被绑定到设计的属性
一个典型的建模工具的用户界面被显示在图3.13,典型的包含一个绘图区域、一个托盘 区(也称为工具箱)、一个模型浏览器、和一个工具条和菜单。绘图区域是绘制SysML图的区域域。托盘区包含图元素,被使用来生成或修改一个图。托盘区是典型的语境敏感的,出现在托盘上的图元素依赖于显示在绘图区域的图的类型。例如,如果一个模块定义图显示在绘图区域,随后托盘区将包含使用在模块定义图上的模块和其它元素,其中,如果一个活动图正在被查看,托盘区包含动作和其它元素使用在一个活动图上。模型浏览器是用户界面的第三个部分,其表示模型元素包含在模型中的一个树型层次视图。一个典型的浏览器视图显示模型元素分组进一个包层次,其中每个包出现像一个文件夹,可以展开来查看内容。一个包可以包含其它内嵌的包。工具条和菜单包含一组菜单及选项和菜单快捷方式对应的工具条,其支持不同的操作动作关联到文件管理、编辑、显示、和其它动作。
图3.13 典型的SysML建模工具示例
为了生成一个新图,一个建模者选择一种图的类型并命名它。常常有多种方式来选择一个图的类型,诸如,从一个菜单或工具条的一个图标。新图出现在绘图区域内没有任何内容。标题信息是可视并包含:图的类型、图名称、和其它有关图框架的信息。建模者随后从托盘拖拽元素到绘图区域中并命名新的元素。一旦这被执行,相应的模型元素出现在浏览器中。作为一个可选的,建模者可以直接的添加新模型元素到浏览器,和随后从浏览器中拖拽这个模型元素到图上。一个模型元素仅出现在浏览器中的一个位置,但可以出现0个,1个或多个在图上。
建模工具常常提供了在图上和模型浏览器中的向导的机制。这一点是非常重要的,由于一个大的模型可以包含成百个图,和成百上千个模型元素。大多数工具允许建模者来选择模型元素在图上,并获取请求它的维护在浏览器中。一个建模者也可选择一个模型元素在浏览器中,和请求模型元素出现图的一个列表。
在任何特定图上,建模工具允许建模者显示和隐藏选择的模型的细节。这是重要的来管理图的复杂性。建模者可以仅显示考虑的内容,这些内容对于图的目标是重要的。
如果建模者希望从图上删除一个模型元素,工具会提示建模者,是否仅从图上删除模型元素,或删除模型元素从模型库中。一个建模者也可选择来删除一个型元素通过选择模型元素在浏览器中并随后删除它。
一个建模工具有许多其它功能,这些功能使一个建模者能开发和管理一个系统模型。一旦模型元素被生成,建模者可以典型的选择模型元素和打开它的规范,其中模型元素的细节可以被添加、修改、或删除。建模者也可以在图上选择一个模型元素,并通过建模工具查询与该模型元素直接相关的其它模型元素,可以出现在特定的图的类型并显示。
值得注意的是,建模工具常常与配置管理工具连接在一起,并将模型放置在一个配置控制中。这是特别重要的,当建模在一个分布式团队中进行时,多个人员工作在相同的模型上。在这种情形下,配置管理工具将允许读和/或写权限分配给不同的用户来控制他们的存取模型的不同部分。一旦这被执行,一个建模者有读权限分配到一个模型的特定部分可以查看对应部分的模型,和一个建模者有写权限分配到一个模型的特定部分,他可以检出这部分内容并修改,修改完成后再捡入。
第18章描述SysML建模工具与许多其它工具如何集成到一个系统开发环境,包含配置管理、需求管理、硬件和软件设计、和分析工具。
下面说明如何来构建第3.3.2节的空气压缩机模型在一个典型的建模工具中。每个工具有它唯一的用户界面,和不同的建模指导和MBSE方法,支持采用不同的方式开始。然而,下面是一种表示性的起始点的示例,可以被进一步应用到特定的建模工具、建模指导、和MBSE方法中。
构建SysML模型的建模工具,建模者必须首先安装和配置。许多SysML工具也支持UML和和许多其它建模语言,所以建模者开始可能需要从它们中选择和应用SysML。一旦者被执行,一个建模者可以生成一个新项目并命名这个项目,诸如,Air Compressor项目。
正如指示在图3.13,在构建模型中,第一步是在浏览器包中生成顶层称为Air Compressor模型。建模者可以随后选择这个包在浏览器中,并生成内嵌的包对应Requirements、 Behavior、Structure和Parametrics。可选的是,建模者可以生成一个新的包图类似于显示在图3.4,通过拖拽新的包从托盘到图上并对它们命名。
建模者随后可以选择Requirements包在浏览器中,并生成一个新的需求图并且命名它为Air Compressor Requirements。一旦需求图出现在绘图区域,建模者可以拖拽新的需求从托盘到绘图区域并命名它们对应图3.5的需求。模型元素之间的关系可以随后被定义使用显示在托盘上的关系类型。在需求建模的情形下,父需求与子需求间的关系,通过连接父需求与它的每个子需求,父需求终点带有‘十’字线标志。
建模者紧接着生成顶层活动图Operate Air Tool显示在图3.6。这被进行通过选择Behavior包,并生成一个新的活动图命名为Operate Air Tool。建模者拖拽动作从托盘到活动图,伴随初始点和终点,并连接动作使用合适的流。控制流被使用来连接初始节点到Control Tool,和另外的控制流连接Control Tool到活动终点。对象流连接输入和输出对应每个活动。活动划分可以被添加。在下一步过程之后。
建模者紧接着生成模块定义图对应Air Compressor Context显示在图3.7。这被完成通过选择Structure包在浏览器中,并生成一个新的模块定义图,并命名它Air Compressor Top Level。一个新的模块可以被拖拽从托盘到一个图上并命名为Air Compressor Context。其它模块可以随后被相似的定义。Air Compressor Context和其它模块之间的组合关联可以被建立采用相似的方式,作为描述对应需求图,但使用组合关联设计提供一个黑钻石在一条线的终点。
一旦模块被定义,活动分区(即,泳道)在活动图中,图3.6可以被定义来表示这些模块。这个活动图指定Air Compressor、Operator、Air Tool和Atmosphere之间的交互执行Operate Air Tool活动。这被完成通过选择先前生成的活动图Operate Air Tool,并显示在绘图区域。建模者随后拖动活动分区从托盘到图上。为了表示一个活动分区提供一个特定的模块,建模者地打开活动分区规范,和随后选择特定的模块来表示分区。每个动作随后被放置在活动分区内部对应模块其职责是执行动作。
建模者可以随后分解系统进它的组件组成部分通过生成模块定义图显示在图3.8。这被进行通过选择Structure包,并生成一个新的模块定义图,并命名为Air Compressor System Hierarchy。新的模块可以从托盘拖拽到图上,和关系被建立以一种相似的方式正如描述对应模块定义图称为Air Compressor Top-Level。每个模块的端口可以随后被生成通过拖拽一个端口从托盘上,或可选的是,通过选择一个模块和打开它的规范,和随后添加端口。此外,模块的属性可以被生成被打开每个模块的规范在图上或从浏览器,添加一个新的属性,和命名它。在这个例子中,端口和属性在图上被包含在模型,但没显示在图上,为了进一步简化图。
建模者紧接着生成活动图来显示Air Compressor零件之间的交互,正如显示在图3.9。这个活动图被生成以一种相似的方式,正如先前的活动图Operate Air Tool。然而,这个活动被使用来分解Compress Air动作,Air Compressor执行Operate Air Tool活动。新的活动被生成通过首先确保Compress Air动作是一个特定的动作类型称为一个调用行为动作,其随后调用新的活动称为Compress Air。活动分区可以随后被从托盘拖拽到图上,和现在可以表示组件模块生成在Air Compressor System Hierarchy模块定义图上。
建模者紧接着生成内部模块图显示在图3.10。这被完成通过选择Air Compressor模块在Structure包在浏览器中,并生成一个新的内部模块图。当组合关联被先前生成,在Air Compressor和它的组件模块之间,工具应该生成新的模型元素在浏览器的Air Compressor模块下。这些元素被称为组成部分,并被使用在Air Compressor内部模块图。Air Compressor模块的组成部分被拖拽从浏览器到内部模块图,和随后互相连接通过它们的端口。组成部分的端口可以不显示在图上。许多工具需要建模者来选择组成部分,并选择一个菜单项来显示端口。一旦端口设计可视的在图上,端口可以被互相连接。建模者也可以连接组成部分不需要端口,并随后添加期望的端口。
建模者紧接着生成模块定义图在图3.11来指定约束使用在参数图。这被进行通过选择parametric包在浏览器中,并生成一个新的模块定义图并命名为Analysis Context。Flow Rate Analysis模块被生成,和Air Compressor Context模块被包含在结构包中被拖拽到图上并引用(即,白色钻石聚合)通过Flow Rate Analysis模块。新的约束模块命名为Flow Rate Equations随后被创建,并关联到Flow Rate Analysis模块使用一个组合关联。约束模块的参数被定义以一种相似的方式正如先前描述的模块的属性。等式可以被明确说明作为约束模块的部分。
建模者紧接着生成参数图显示在图3.12。约束属性键入使用Flow Rate Equations模块和一个组成部分键入使用Air Compressor Context模块被拖拽从浏览器到图上。Air Compressor Context被选择在图上,和它内嵌的组成部分和数值属性被显示在图上。不同的工具完成这以不同的方式。一旦这被执行,数值属性包含在Air Compressor、Tank、Motor和Pump可以被连接到Flow Rate Equations的约束属性的参数。
在建模工具生成这个例子是一个非常重要的第一步来学习如何建模。一旦这被理解,您可以学习附加的SysML语言特征,并学习工具的附加功能,诸如,文档生成、表格表示、图布局等功能。汽车例子在第4章的介绍,将包含剩余的3种SysML图的类型和对应语言特征,其可以服务于下一步学习过程。
此外为了学习建模语言和工具,建模者必须应用一种严格的基于模型的系统工程(MBSE)方法来健全系统工程实践,建立质量体系模型。SysML提供一种方式来绘制系统建模信息不需要实施一个特定的MBSE方法。一个选择的方法确定那个建模活动被执行、活动的顺序、并用来表示系统的建模构件的类型。例如,传统的结构分析方法可以被用来分解功能并随后分配功能到组件。可选的是,您可以应用一个用例驱动的方法,其基于场景分析和组成部分之间的交互驱动功能。2个方法可能涉及不同的活动,并生成表示系统规范和设计的不同组合的图。一些MBSE方法被记录在基于模型的系统工程方法学汇总[5]。16和17章提供两种不同的MBSE方法。
一种简化的MBSE方法的顶层活动被强调在图3.14。活动与与介绍在第1.2节的系统工程过程是协调。面向对象的系统工程方法(OOSEM)方法的一个简化版本的表示方法,被用来详细描述住宅监控安全的例子在第17章。这种方法包含一个或多个下面的明确说明和设计系统的活动的迭代:
图3.14 一个简化的MBSE方法,与描述在第1.2节的一致
其它系统工程管理活动,诸如,计划、评估、风险管理、和配置管理被执行来衔接建模活动描述在上面。详细的例子关于SysML如何可以被使用来支持一个功能分析和分配方法和面向对象的系统工程发布方法(OOSEM)被包含在建模例子分别在第16和17章。一个简化的例子被描述在下一章,其说明一些基于模型的构件被生成,当典型的应用一种MBSE方法时。
学习SysML和MBSE需要一个承诺类似与学习机械、电子、软件、和其它技术学科的建模,什么目标被期望达到。学习SysML和MBSE有以一些额外的因素贡献到它的学习曲线。特别是理解一个系统从多个视角的基于模型的系统工程方法一个主要关注,并确保集成贯穿不同的视角。在SysML中,系统的需求、行为、结构、和参数每种表示系统的不同方面,需要被单独和一起理解。
每个视角引入它自己的复杂性。例如,建模者可以表示行为在活动图来精确指定一个系统如何响应一个激励,这涉及指定系统如何执行每个用例场景的细节。这些活动图可以被集成到一个组合的系统行为中,并被绘制在一个状态机图上。行为和集成不同行为的形式表示详细过程可以是相当复杂的。
正如前面陈述的,建模者必须维护一致性从一个到另外一个视角。SysML被常常用来表示需求、行为、结构、和参数的层次。系统的一个协调模型必须确保模型元素在每个层之间的一致性。这些关系中的一些被强调在第3.3.1和3.3.2节中的例子中。额外的学科-特定视图可能交叉在需求、行为、结构、和参数视角之间,诸如,一个可靠性视图、安全性视图、或制造视图。再次强调,这种系统建模和MBSE的复杂性。
复杂性的另外一个方面是一个有效的MBSE方法不仅仅需要一种语言,诸如,SysML来表示系统,但也需要定义活动和构件的一种方法,和一个工具来实施建模语言和方法。语言、方法、和工具每个有它们自己的概念, 为了掌握和进行基于模型的系统工程的实践,这些概念必须被学习。这些技巧随后被应用到一个特定的领域,诸如,设计构件、车辆、远程通讯系统、医疗设备、和其它领域。
额外的建模挑战与扩展建模努力到大型项目相关,和在一个复杂的开发环境语境中。模型的管理挑战开始出现。可以有多个建模者在多个地点。严格的流程和相关的工具必须被设计来管理模型的变更。在一个MBSE工作中,除了SysML模型以外,有许多不同类型的模型设计,诸如,许多分析模型、硬件模型、和软件模型。不同模型和工具和其它工程构件之间的集成是使用MBSE的另外一个挑战。
基于模型的系统工程如何执行正式化的系统工程实践。学习MBSE的复杂性和相关的挑战反映在固有系统的复杂性和应用系统工程到复杂系统的开发的挑战。这些复杂性中的一些被强调在汽车设计例子中在第1.3节中。当开始MBSE的旅程,非常重要的是来设置学习MBSE预期挑战和如何来应用它到感兴趣的领域。MBSE潜在的好处描述在第2章,接受这些挑战,逐渐熟悉和应用SysML语言和MBSE方法,可以加深您对系统和系统工程的理解。
SysML是一种通用的图形化语言对应建模系统,其可以包含硬件、软件、数据、人员、设施、和在物理环境内的其它元素。语言支持需求、结构、行为、和参数的建模来提供一个系统的组件和它的环境的一个健壮性描述。
语言包含9种图的类型,每种类型有很多特征。语言的语义使一个建模者能来开发一个系统的一个集成模型,其中每种类型的图可以表示系统的一个不同视角。模型元素在一个图上可以被关联到模型元素在其它图上。图使能绘制信息到一个模型库中,并从库中来显示信息,来帮助指定需求规格、设计、分析、并验证系统。为了促进学习过程SysML-Lite被介绍,其包含9类SysML图中的6类和对应每种图的类型的一个语言特征的子集。学习如何来建模语言的子集语言在一个建模工具可以提供一个良好的基础。
SysML语言是使能MBSE的关键。语言的有效使用需要一个良好定义的MBSE方法。SysML可以被各种MBSE方法使用。本章介绍了一种简化的MBSE方法来帮助开始。
SysML使能一个系统的表示从多个视角。每个个体的视角可以是复杂的在它们自身的权限内,但确保一个协调的模型,其集成贯穿不同的视角介绍额外的挑战来学习SysML和MBSE。当学习SysML使用时,其作为一个完整的MBSE方法过程的部分,工具介绍它们自己的概念和复杂性。使用SysML正式支持MBSE实践,对应系统工程如何被执行。最终,SysML和MBSE 的挑战反映应用系统工程来开发复杂系统固有的复杂性。学习期望应该被相应的设置。
一些因素贡献到学习SysML和MBSE的挑战,和如何执行它们关联到的学习系统工程的通用挑战?