已剪辑自: http://www.zhiruisiwei.com/html/articles/article_001.html#main_right
MBSE技术从理论到实践，逐渐在一些企业得到应用，在国内掀起了一股热潮。究竟MBSE是什么，如何学习和应用，本文做了一个入门的简单介绍。在文章最后，列出了作者学习MBSE技术中接触到的一些参考资料，推荐给读者，希望对大家学习MBSE技术有用。
学习和应用MBSE技术，离不开软件工具的支持。可在网站服务页面下载中文版、国产化的MBSE建模软件工具：智睿思维基于模型的系统工程软件（MBSES）。
“MBSE”是“基于模型的系统工程”的英文“Model-Based Systems Engineering”的首字母缩写。从字面意思能看出MBSE这个概念有三个核心的概念“系统”、“系统工程”、“基于模型”。我们从“国际系统工程协会”（INCOSE）的出版物“系统工程手册”中摘录上面三个概念的定义如下：
“系统”（System）：系统是相互作用的多个部分组成的为完成特定目的的一个整体。从这个基本概念看，这个世界上很多东西都可以称为“系统”。但是工程技术人员的研究领域中，这个“系统”主要是指软、硬件组成的产品、平台等。这个“系统”也包括其中的流程、人员、信息、技术和设施等。至于纯“人”的社会系统则不是这个技术研究的范围。
“系统工程”（SE，Systems Engineering）：系统工程是一种使系统能够成功实现的跨学科的方法和手段。“系统工程”工作包括：在“系统”开发周期的早期阶段定义客户需求及功能，并文档化。然后进行设计综合和系统确认。同时考虑整个系统各方面的问题，包括系统运行、成本、进度、性能、培训、支持、试验、制造和销毁等。这里的“系统工程”简单说指的是产品研发过程的技术方法。
“基于模型的系统工程”（MBSE）：“支持以概念设计阶段开始，并持续贯穿于开发和后期的生命周期阶段的系统需求、设计、分析、验证和确认活动的正规化建模应用。”用通俗一点语言解释的话，MBSE就是开发一个产品、平台的时候，把产品、平台研发中涉及到的各个方面用“计算机数据模型”方式建立起来，形成一个统一的“系统模型”。
MBSE有什么用，也就是建立那个统一的计算机数据化的“系统模型”有啥用？
在没有使用MBSE技术之前，“系统工程”工作成果就是一堆的“文档”。这些文档也是电子化的，只不过它们都是“非结构化”的数据，不能称为“模型”数据。相比“基于文档的系统工程”方法，MBSE方法具有很多优势。
在INCOSE 的《系统工程手册》中，总结了以下几点MBSE的好处：
（1）改善了开发系统的利益相关者（客户、项目管理人员、系统工程师、软硬件工程师、测试人员和各专业工程学科的人员）之间的沟通。
因为MBSE是基于标准的建模语言建立的规范化说明，相当于大家交流的语言是统一的。而基于自然语言的“文档”容易在不同专业的人员之间产生歧义。而且MBSE的这个“模型化说明”在各类专业人员之间传递时候是可以通过计算机软件转换为各自专业的语言、数据，而自然语言是很难实现这个转换的。但是，这要求大家要新学习一门通用的“系统建模语言”。如果大家都不懂这门语言的话，只会产生和上面的观点相反的结果。
（2）通过使系统模型能够被从多个侧面进行观察，以及提供变更影响分析的能力， 提高了管理复杂系统的能力。
这个是说系统的同一套数据模型，可以从不同的专业角度进行浏览和分析。而且由于系统模型数据之间有相互关联关系，如果那个地方更改，可以通过关系查询到所有影响到的地方。这个对于非结构化的文档来说，是做不到，或者很麻烦。即使文档也能提供从各个专业角度的说明，但是这些文档数据之间没有关联，可以说是基于各自多套数据来源的，而不是唯一的一套数据模型。这个观点也是在说“MBSE提高了开发复杂系统的能力”。
（3）通过提供可评估一致性、正确性和完善性的无歧义的且精确的系统模型，提升了产品质量。
产品的质量问题有很多是设计问题，而这些设计问题并不简简单单是设计人员的水平问题、责任心问题，而更多是复杂过程本身不可避免的会出现的质量问题。想让所有人不犯错是不可能的，而只能是通过技术手段使人少犯错。MBSE是一种使人少犯错的技术手段，因为MBSE建立的模型可以通过计算机软件自动的检查错误。相比之下传统的文档容易隐藏错误，一个笔误可能造成严重损失。
（4）通过以更加标准化的方式捕获信息并高效地利用模型驱动方法固有的内置抽象机制，增强知识捕获及信息的复用。这会导致缩短开发周期和更低的维护成本，以改进设计。
这个观点是说系统模型数据更容易复用，比文档手段的“复制、粘贴、替换”文本效率要高。模型数据的复用，可以采取“引用”方式。而且可以建立共用的模型库，提高知识的复用率。
（5）通过提供概念清晰且无歧义的表达，提升教授与学习系统工程基本原理的能力。学会了MBSE，就掌握了系统工程的方法。
在系统工程技术结合计算机信息技术发展的过程中，其实有多种技术方向在发展。这些技术途径都可以称为MBSE。这其中主要的方法有6种：INCOSE（就是前面说的那个国际系统工程协会）的面向对象的系统工程方法（OOSEM）方法、IBM的Rational Telelogic Harmony-SE、IBM的RUP系统工程方法、Vitech MBSE方法论、JPL状态分析（SA）方法和Dori的对象过程方法（OPM）。
这里先简单说一下INCOSE的OOSEM方法。OOSEM是一种自顶向下、场景驱动建模过程，它使用SysML（系统建模语言，Systems Modeling Language）语言作为建模语言，支持系统的分析、定义、设计、和验证。该过程使用面向对象的概念和其它建模方法来构建灵活和可扩展的系统，使其能够适应技术的不断进化和需求的变更。
OOSEM过程的主要活动包括：
（1） 分析利益相关者的需求。这个工作简单说就是分析使用产品的用户的需求，就是用户最初始的想法是啥，想怎么用这个产品、需要产品有那些功能。了解用户当前情况是什么、有什么局限，未来可以有哪些提升。
（2） 分析系统需求。简单说就是产品本身应该提供那些功能，用户是如何使用产品的。在这个过程中要推导出产品的功能需求、接口需求、数据需求和性能需求。
（3） 定义逻辑架构。先将系统分解为多个逻辑组件，这些逻辑组件是暂且虚拟的一个部件，它能够满足产品的各项需求。但是具体用什么硬件或软件的方案来实现它，在下一步的物理架构设计中实现。将系统方案分为逻辑架构和物理架构两个层级，有利于减少需求和技术变化对设计的影响。
（4） 综合候选的物理架构。可能建立几个和逻辑元素相对应的物理架构，以进行对比分析，确定哪一个最合适。物理架构的元素是具体产品部件，包括软件和硬件。前面逻辑架构中的功能，有些是可以用软件来实现，也可以用硬件来实现，或者用不同型号规格的硬件来实现。
（5） 优化并评价备选方案。对上述备选的物理架构方案进行优选，利用模型的数据，进行性能、可靠性、生命周期成本、人员和其它专业工程相关的模型参数的分析，对备选方案进行优化，确定一个最终的方案。
（6） 管理需求的可追踪性。为保证需求、架构、设计、分析与验证元素之间的可追踪性，系统模型应该始终保持需求和其它元素的关系。设计过程就是一个不断填补空白需求的实现过程。当需求变动时，利用建立的需求实现关系，追踪和评估需求变更对系统设计、分析和验证元素的影响，并及时更改系统方案，使其和需求保持一致。
（7） 确认和验证系统。该活动验证系统设计满足其需求，并确认哪些需求满足利益相关者的需求。开发验证计划、程序和方法。
OOSEM的活动过程，用SysML的活动图，可以表示如下：
MBSE技术已经成为系统工程师必须掌握的基本知识。有些单位甚至要求设计师持证上岗。至于怎么学习MBSE技术，最简单的方法，那就是使用“智睿思维基于模型的系统工程软件”（MBSES）。如果有问题，可以参考软件在线手册。或者进一步关注“智睿思维MBSE”微信公众号，通过在线服务咨询客服。
如果您想系统了解一些MBSE、SysML建模的相关知识，下面列举了国内可以买得到或可以获取的书籍和技术资料。电子版的技术资料，如果您获取有困难，也可以尝试联系公众号客户，也许他有可以分享给您。
（1）《SysML精粹》，（美）Lenny Delligatti著，侯伯薇、朱艳兰译，机械工业出版社。
这本书是讲述MBSE入门技术的一本经典好书。内容浅显易懂，结合案例，对建模技术说明的很透彻。这本书出版的时间比较早。当时还是SysML1.3版的时候，现在是SysML1.6版，有些地方已经变动了。如果您发现这本书讲的和MBSES软件不一致的地方，也可能是SysML版本问题，您可以联系客服进一步解释。
推荐指数：★★★★★
（2）《SysML实践指南》，英文版名称《A Practical Guide to SysML The Systems Modeling Language》。互联网上有第二版中文翻译，英文版有电子书（第三版）。
这本书也是案例结合SysML语法介绍，还有一个章节专门讲OOSEM方法。可以说是MBSE方法论+SysML建模语言+案例的好书。
推荐指数：★★★★★
（3）INCOSE《系统工程手册》，张新国译，中英文对照，机械工业出版社。
很厚的一本书，900多页，网上有售。这本书是对整个系统工程技术的编著，其中有一个章节讲MBSE。内容不多，但是对了解MBSE在整个系统工程过程中的地位会有帮助。
推荐指数：★★★★
（4）《敏捷系统工程》，[美]Bruce Powel Douglass著，张新国 谷炼译，清华大学出版社。
全书也是讲述基于MBSE的方法，方法论基于上述IBM的Harmony SE，还结合了“敏捷开发”的概念。这本书国内网上有售。
推荐指数：★★★★
（5）《基于模型的系统工程最佳实践》，[德]Hans-Peter Hoffmann著，谷炼译，航空工业出版社。
这本书基于IBM的Harmony SE方法，结合IBM的Rhapsody软件中的案例。虽然书不厚，但是讲述内容挺复杂的一本书。
推荐指数：★★★★★
（6）《基于模型的系统工程有效方法》，[美]John M.Borky, Thomas H.Bradley著，高星海译，北京航空航天大学出版社。
也很厚的一本书，讲述了很多系统建模的实践。不过想要看懂这本书，需要先学好MBSE的基础知识。
推荐指数：★★★★
（7）《SysML for Systems Engineering 2nd Edition: A model-based approach》，Jon Holt and Simon Perry。
纯英文，没见到中文翻译版，网上有电子版。从SysML讲到MBSE，内容丰富。
推荐指数：★★★★★
（8）《基于模型的系统工程—综合运用OPM和SysML》[以]Dov Dori，杨雄 王文广王涛 李志飞译，电子工业出版社。
基于Dori（就是原书的作者）的OPM方法。这种方法主要的建模语言是OPL（对象过程语言），独立的一个标准，和SysML不同。支持这种语言的建模工具只有作者开发的工具。
推荐指数：★★★
9）《基于模型的系统工程（MBSE）方法论综述》，[美]杰弗里.A.艾，张新国译，机械工业出版社。
这本书是INCOSE的一个调研报告的翻译本。此书介绍了常用的几种系统工程方法（本文第3节说那些方法，这些方法有些来自于上述另外一本书），以及其他的系统工程的基本概念。
这本书出版的比较早，现在没有卖的了。JD上旧书价格有点离谱。网上有英文电子版。
推荐指数：★★★★★
MBSE有关标准：
有关MBSE技术，参考的标准如下。这些标准对深刻学习和理解建模技术很重要。
（1）《OMG Systems Modeling Language》1.6版。
下载地址：https://www.omg.org/spec/SysML/1.6/PDF
（2）OMG® Unified Modeling Language® (OMG UML®) Version 2.51
SysML标准只是讲述扩展的内容。对一些基本的建模知识，还是需要参考这个UML标准。
下载地址：https://www.omg.org/spec/UML/2.5.1/PDF
（3）中国国家标准汇编526 GB 28174( 2011 年制定)。可以理解为UML2.0中文版。
网上有售，网上有电子版。
已剪辑自: http://www.zhiruisiwei.com/html/articles/article_002.html#main_right
MBSE建模技术中最重要的方法就是面向对象（Object Oriented, OO）的方法。几种不同技术方法中（OOSEM、Harmony-SE、RUP、OPM），主要的也都是把整个系统当作对象来建模。“模块”（Block）是面向对象模型中最重要的概念。下面说说模块是啥、怎么来的、怎么建模。先从面向对象技术的三大特征说起。
面向对象技术有三大特征，如下：
抽象是将具有一致结构和行为的对象抽象成类。一个类就是一种抽象，它反映了与应用有关的重要性质，而忽略其他一些无关内容。从某种意义上讲，人类的知识体系就是不断“抽象”世界中的各种物体（Object，对象）、进行分类、形成的各种概念。
继承是在定义和实现一个类的时候，可以在一个已经存在的类的基础之上来进行，把这个已经存在的类（称为“基类”或“父类”）所定义的内容作为自己的内容，并加入若干新的内容。继承得到的新类称为“子类”。继承的过程是一个从一般到特殊的过程。
多态是指相同的操作或过程可作用于多种类型的对象上并获得不同的结果。不同的对象，收到同一消息可以产生不同的结果，这种现象称为多态性。多态是在子类继承父类的基础上，通过重定义方法过程从而实现不同的操作结果。
MBSE主要的建模语言UML/SysML是面向对象的语言。SysML（Systems Modeling Language，系统同建模语言）是对UML（Unified Modeling Language，统一建模语言）的扩展。在UML中最重要的概念是“类”（Class）。SysML中，对“类”进行了扩展，称为“模块”（Block）。MBSE的建模工作，可以说就是把要设计的系统及其各部分抽象为“模块”的过程。模块的主要用途是说明系统的架构。这个“模块”可以代表任何级别的产品。模块与模块之间可以有继承关系（或称泛化关系，父类泛化子类，子类继承父类）、组合或引用关联关系等等。
下面用一个简单的例子说明一下用“模块”实现面向对象技术的三大特征。
在MBSES软件中，建立一个模块定义图（如何建立解决方案、项目、包、模块定义图的软件操作过程，可以参考用户手册“快速操作指引”）。图中增加一个作为父类的模块“计算机”。当定义一个具体的计算机型号的时候，可以从这个父类继承，继承类自动具有父类的所有属性（在MBSES软件中通过属性框设置模块节点“显示继承特征”可以在继承类中显示所有继承父类的属性，这些继承属性前面有一个特殊标志“^”）。还可以添加子类特有的一些属性；或者通过“重定义”父类属性，把父类通用的属性转成子类特有属性。例如这个图中，通过重定义父类的“mo:显示器”属性，确定子类的显示器类型是更具体“24寸显示器”。
模块的各种属性、操作、关系可以显示在模块节点中的一个方框内，这些方框称为模块节点的一个“分区”（Compartment）。在MBSES软件中，模块的视图总共有超过26种分区。通过“模块”节点的右键菜单添加各类属性、操作，模块就会显示这些分区（没有这类属性，模块节点是一定不显示这个分区的；有的话，还可以通过节点对属性框中的节点显示属性设置是否显示）
模块的26种标准分区（不包括自定义分区）都有啥？列表如下：
序号 种类 分区名称
| 1. | 结构特征 | 部件(parts) | 类型是“模块”且聚合关系是“组合”的属性 |
| 2. | 结构特征 | 引用(references) | 类型是“模块”且聚合关系不是“组合”的属性 |
| 3. | 结构特征 | 值(values) | 类型是值类型(ValueType)的属性 |
| 4. | 结构特征 | 约束(constraints) | 类型是“约束属性”的属性 |
| 5. | 结构特征 | 连接器(connector properties) | 类型是关联的属性 |
| 6. | 结构特征 | 参与属性 (participant properties) | 关联模块中，和两端被关联的模块对应的属性 |
| 7. | 结构特征 | 属性(properties) | 任何类型的属性 |
| 8. | 行为特征 | 操作(operations) | 类型为操作的行为特征 |
| 9. | 行为特征 | 接收(receptions) | 类型为接收的行为特征 |
| 10. | 行为 | 类目行为(classifier behavior) | 表示模块开始工作，一直到结束的整个过程的行为。一个模块只有一个类目行为，一般是一个状态机。 |
| 11. | 行为 | 拥有行为(owned behaviors) | 模块能够提供的各种服务。拥有行为包括类目行为，但是在MBSES中拥有行为分区中不重复显示类目行为。 |
| 12. | 结构特征 | 绑定引用(bound references) | 类型是绑定引用的属性 |
| 13. | 构造型 | stereotypes) | 当构造型在分区中显示的时候，显示应用的构造型的属性 |
| 14. | 端口 | 端口(ports) | 类型是端口的属性 |
| 15. | 端口 | 完整端口(full ports) | 类型是完整端口的属性 |
| 16. | 端口 | 代理端口(proxy ports) | 类型是代理端口的属性 |
| 17. | 属性 | 流属性(flow properies) | 类型是流属性的属性 |
| 18. | 分配关系 | 分配从(allocatedFrom) | 分配关系的源端元素 |
| 19. | 分配关系 | 分配到(allocatedTo) | 分配关系的目标端元素 |
| 20. | 需求关系 | 改善(refines) | 改善的需求 |
| 21. | 需求关系 | 满足(satisfies) | 满足的需求 |
| 22. | 需求关系 | 跟踪从(tracedFrom) | 跟踪的需求 |
| 23. | 需求关系 | 验证(verifies) | 验证的需求 |
| 24. | 结构 | 结构(structure)分区 | 结构分区显示一个局部的内部模块图，显示模块的结构 |
| 25. | 命名空间 | 命名(namespace)空间分区 | 命名空间分区显示一个局部的包图，命名空间分区中的模块是当前模块嵌套类而已 |
| 26. | 图形 | 图形(image)分区 | 显示一个代表模块图形 |
这26种分区，简单的说明和用途如下：
部件分区中属性的类型也都是模块，它表示父级模块的组成部分。每个部件的工作过程在父级模块开始之后才能开始。而在父级模块工作结束后，所有部件属性都不可能再工作。一个部件只能属于某一个模块，它表示模块的内部结构。
引用属性的类型也是一个模块，不过这个子模块不是当前这个模块内部的模块。它可能位于另一个模块内部，但是当前这个模块的工作需要这个外部部件提供功能，或者向这个外部模块提供数据或信息。
值属性的类型是一个值类型（ValueTtype）。SysML的值类型在继承UML数据类型的基础上，增加了“单位”和“数量类型”属性，更适合工程上的实际应用。
约束分区中的约束一般是一个数学表达式，它表示模块各属性参数之间的数学关系。SysML扩展了约束的应用，约束分区中的“约束”也可以是一个“约束属性”。约束属性的类型是一个约束模块，约束模块中包含了可以重复使用的约束关系。也就是通过“约束属性”，把通用的数学关系放到约束模块中。进一步描述约束模块中数学关系和模块的参数之间的关系，可以用一个参数图表示。
连接器(Connector)是对应各部件之间关联关系的属性。连接器的类型是一个关联（Associattion）或关联模块（AssociationBlock）。连接器可能只是表示内部模块之间数据或信息的传送，也可以是具体的有实物的连接器产品，如电连接器、机械连接器等。
当连接器的类型是一个关联模块的时候，连接器两端连接的部件，对于连接器的类型：关联模块来说是“参与属性”。下图说明了一个关联模块中“参数属性”的例子。
这个普通属性的分区可以显示任何类型的属性，也就是属性的类型可以是任何类型，甚至可以为空。
操作表示模块可提供的一个服务。对于软件模块，对应这个类提供的方法、过程或一个函数。对于硬件模块，它表示模块可提供的方法接口，可接收参数并完成一个功能。但是UML\SysML中操作只是一个方法接口，它的实现需要通过对应方法的行为图来描述。
接收表示模块接收信号并进行处理的一个方法。接收一定对应在模型中某个地方定义的信号（Signal），它的参数和信号的属性对应。接收的调用一定是异步的，也就是一个模块向另一个模块发送信号，是不等待返回消息就继续其它工作或发送下一个信号。（同步的概念是调用另外一个模块的操作的时候，会等待返回的消息，收到返回消息才继续下面的工作）
一方面，行为表示模块可提供的一种服务，输入什么、输出什么。另外，行为有对应的行为图（活动图、序列图、状态机图）。在行为图中详细说明了模块是怎么处理输入信息（输入参数）并加工、转化为输出信息（输出参数）的。这里的“信息”表示任何物质，不止是数据。也可以没有输入、输出信息，只是表示模块的活动过程。
模块的类目行为就是表示模块从开始到结束的活动过程。一个模块只能有一个类目行为。例如用一个状态机表示设备的活动过程。这个状态机有启动、开机、待机、关机、停机等各种状态。
一个模块拥有的所有行为。一个模块可能提供多种服务或功能，每个可以对应一个行为。
绑定引用是一个引用属性，同时这个引用属性通过绑定连接器绑定到内部的一个部件。“绑定”的概念是两个值始终相等，或者是同一个对象的意思。通过绑定关系，同一个对象在两个地方使用。例如计算机中映射了另外一个计算机的一个存储空间作为本地盘符。
构造型是一种扩展标准元素功能的机制。例如定义一个表示元素作者、版本的构造型。模块构造型的属性可以显示在分区中，也可以显示在头部。通过模块属性框中节点显示属性设置。构造型属性是在设计模型时输入的，而模块的属性是在模块实例化的时候才赋值的，这个也是区分构造型属性和模块自己属性的一个方法。
端口是一个特殊的部件，它是专门用来和外界交换信息的。例如一个计算机的USB端口、提供显示信号的HDMI端口。
端口一般表示为模块边框上的小方块。也可以显示在分区中。可以通过属性框中模块节点的显示属性设置。
完整端口是我们把它当作一个独立的部件来看待的，这个部件也是一个可能具有各种属性、功能行为的一个模块。可以说完整端口是自己直接处理输入的信息、输出处理后的信息（当然处理过程也是可以调用其它内部模块的功能的）。
代理端口的类型一定是一个接口模块。代理端口通过一个绑定连接器绑定到一个内部的模块。可以说代理端口自己并没有处理信息的功能，处理信息的其实是另外一个内部模块。
流属性是具有方向的属性。流属性的方向有“进”“出”或“进出”（in, out, inout）。流属性的类型可以是值类型、模块或信号。
“分配”是SysML中定义的一个表示两个元素之间特殊关系的元素。例如可以为结构分配行为、为物理结构分配逻辑结构，为结构分配资源。
“分配从”表示一个元素被分配到了这个模块。例如一个一个活动被分配到这个模块。
“分配到”表示这个模块分配到了另外一个元素。例如一个逻辑模块分配到一个物理模块。
“改善”是表示模块和需求之间的关系，意思是这个模块的说明更详细的说明了需求。
“满足”表示模块满足了某个需求。
“跟踪从”表示这个模块跟踪回某个需求。通过跟踪关系可以知道模块设计和需求之间关系。
“验证”表示模块验证了某个需求。作为验证关系的模块，一般是一个“测试案例”元素。
结构分区显示了一个模块的内部结构。在模块节点中要显示结构分区，可以把图形工具切换到内部模块图，然后拖拽一个属性节点到模块节点上，这时候模块节点会显示结构分区。
结构分区提供了一个把内部结构和模块定义同时显示的机制。
命名空间是一个有名称属性的元素的命名空间。可以把命名空间和磁盘中的“目录”作用类似看待，不同命名空间下面的元素名称可以重复。一个元素完整的名称包括“完整的命名空间”+“::”+“名称”，这个完整的名称称为元素的“完全限定名称”。作为命名空间的元素一般是包，但是模块也可以作为命名空间元素。但是在模块命名空间下面定义的模块元素只是表示是上层模块的“嵌套类”元素，它并不表示“组成”关系。
如果把一个模块拖拽到另外一个模块上面，上层的模块会显示命名空间分区。
模块节点也可以显示一个代表模块的图片。通过节点的右键菜单“选择图片”，可以选择一个图片文件，显示在节点下方。
结构分区、命名空间分区、图形分区的示例如下（涂个颜色）：
已剪辑自: http://www.zhiruisiwei.com/html/articles/article_003.html#main_right
在MBSE的模型中，我们经常看到属性的定义中有“±#~/^*”这些符号，它们可不是运算符，理解错了要闹笑话。请大家耐住性子看下去，只有理解了系统结构建模中的“属性”，才能记住这些符号的意义。
MBSE建模工作从哪里入手这个问题，往往都是刚开始对大家造成困惑的问题。如果从学习的角度，一般是从学习模型中各类元素的概念开始，先大概了解一遍MBSE模型中都有哪些元素、有什么用处、什么时候用。然后结合一个自己工作中的项目，把建模工作做一遍。如果按照正常的产品研发过程，一般按照“需求分析”—>“方案分析”—>“确定架构”这个过程，可能会依次用到需求图、用例图、行为图（活动图、序列图、状态机图）、包图或模块定义图、内部模块图、参数图。但是我们拿来当作“作业”的项目，也可能已经完成，也不妨直接从架构建模开始，先把系统结构模型化，然后逐步完善系统的行为模型、需求模型。这样从简到繁的过程，也许是更有效的学习方法。《SysML精粹》这本书的章节顺序正是这种方式编排的（推荐阅读）。
在上一篇文章中，介绍了表示系统结构（系统的整体架构，不是指机械结构，机械结构是专业模型，用CAD软件建模）模型的元素“模块”（Block）。我们在系统模型中，多次提到“元素”（Element）这个术语，这个术语也是UML标准中的一个概念。在UML\SysML模型概念中，“元素”是最基本的概念，模型中的其它概念都是从“元素”继承的，是所有模型概念的根（Root）。所以，我们把每个模型概念都统称为“元素”。那么继续说“模块”。“模块”代表我们设计的产品，以及任何层级的产品。当我们说明这个产品的时候，用它有什么“特征”（Feature，也是UML标准中的元素）来说明它。这个“特征”分两大类，一类表示它的结构的，称为“结构特征”（StructuralFeature）；另一类称为“行为特征”（BehavioralFeature）。“行为特征”可以理解为一个产品有什么功能，它是如何工作的。我们在后续的文章中继续介绍“行为”这个概念，这里我们先说说“结构特征”。
“属性”（Property）是一种元素，它表示类的一个属性（attribute），或者一个关联（Association）的成员端（memberEnd）；或者某些情况下同时都是。
先说说“Property”这个词的翻译，我们习惯把它翻译为“属性”，这个和“attribute”的翻译相同。“attribute”不是UML中的一种元素，它只是普通的一个词语；另外，“类”（Class）有“Attributes”这个属性，也就是它的所有“Property”。所以UML类图中，表示方框的“类”有分区的名称是“attributes”。为了区分“Property”和“attribute”，有些书中把“Property”翻译为“特性”。不过，在程序员中，已经很习惯把“Property”称为“属性”。所以我们还是按习惯把“Property”翻译为“属性”。两者区别不大。真要说相同和区别的话，如第一段中对“Property”的定义，就是当“Property”是一个类的“attribute”的时候，可以说两者相同，指的是同一个概念；当“Property”仅仅是一个关联关系两端的成员（memberEnd）时，这时候不能叫“attribute”。
产品的组成是有层级关系的。结合产品的模型，“属性”这个概念可以理解为下层产品的实例在上层产品实例中的名称及其它定义。“属性”可以指父级产品中具体的某一个下级产品，也可以指类型相同的一组产品。“属性”的类型除了具体的产品，也可以只是一个数据类型。在SysML标准中，表示产品的“模块”（Block）主要有四种类型的“属性”。“部件”（parts）、“引用”（references）、“值属性”（value properties）、“约束属性”（constraint Properties）。“部件”的类型一定是另外一种“模块”，而且聚合类型是“组合”；“引用”属性的类型也必须是“模块”，而且聚合类型是“共享”或无；“值属性”的类型是“值类型”（ValueType）;“约束属性”的类型必须是“约束模块”（ConstraintBlock）。
“模块”的各种“属性”可以显示在包图或模块定义图中模块节点的“分区”（Compartment）中，以一个字符串的形式。这个字符串表示了定义“属性”的语法。“属性”完整的语法如下：
::= [] [‘/’] [‘:’ ] [‘[‘ ‘]’] [‘=’ ] [‘{‘ [‘,’ ]* ’}’]
用中文把上面的语法翻译一下如下：
<属性>定义为:[<可见性>] [‘/’] <名称> [‘: ’<属性类型>] [‘[‘ <多重性范围> ‘] ’] [‘=’ <默认值>] [‘{‘<属性修饰语>[‘, ’<属性修饰语>]*’}’]
上面语法中各部分说明如下：
：可见性，表示属性可以被访问的范围。有四种：
+：表示属性是公共的（public），可以被任何模块的行为访问。在SysML标准中所有属性都是公共的，所以在SysML图中一般是不显示可见性的。但是“模块”既可以表示一个具体的硬件产品，也可以表示一个软件的模块。当对软件进行建模的时候，也还是可以使用“可见性”这个概念。
-：属性是私有的（private），仅仅被所属模块的行为访问；
#：属性是受保护的（protected），仅仅对模块及其子类中可见；
~：相同包内可见（package），也就是同一个包中的模块都可以访问这个属性。
‘/’：导出属性的符号。导出的属性，意思是这个属性是其它属性通过计算得到的。例如正方形的“面积”属性是“长”、“宽”属性相乘“导出”的属性。导出属性的值一定是“只读”的，在模块的实例中不能被其它行为方法修改。
：属性的名称。名称也可以为空。为空的时候，可以用它的类型表示这个属性。
：属性的类型，另外一个“模块”、“值类型”或其它能作为类型（Type）的元素。类型也可以为空，表示可以是任何类型。
：多重性。多重性是指一个属性在模型中的数量范围。它的表示方法是“[lowerValue…upperValue]”，翻译一下，既“[下限值…上限值]”。例如“[0…1]”表示最少0个、最多1个；“[4…]”最少4个、最多不限；“[2]”上限、下限都是2，既必须2个；“[]”不限个数，既0到多个。
=< default>：属性的默认值；没有赋过值的话，属性就取这个值。可以没有默认值。
：属性的修饰语，可以理解为“属性”的“属性”。可能有多个修饰语，每个可能的是如下的值：
::= ‘readOnly’ | ‘union’ | ‘subsets’ |’redefines’ | ‘ordered’ | ‘unordered’ | ‘unique’ | ‘nonunique’ | ‘seq’ | ‘sequence’ |’id’|
‘readOnly’：表示属性是只读的。例如导出的属性就是只读的。
‘union’：表示属性是另外的子集属性的并集。
‘subsets’ ：表示这个属性是另外一个集合属性的子集。例如汽车“前轮”属性是“轮子”属性的子集，定义表示为“前轮:车轮{ subsets 轮子}”，表示2个前轮是汽车所有轮子属性集合中的2个。
’redefines’ ：重定义了某个属性。在上一篇文章中，我们介绍过“模块”是一种可以“继承”的“类”。作为“继承类”的模块自动拥有了“父类”的所有属性，这些父类的属性称为“继承”的属性。在继承的属性前面用符号“^”标识。继承的属性是父类的属性，不能直接修改它；如果要修改它的定义，必须新定义一个属性“重定义”它。这里“redefines 父类属性”就是这种意思。
‘ordered’：表示属性是有顺序的集合。
‘unordered’：表示属性是没有顺序的集合。
‘unique’：表示是集合的属性中，集合中每个成员都是唯一的。
‘nonunique’： 表示是集合的属性中，集合中每个成员不一定是唯一的。
‘seq’或‘sequence’：表示属性是一个有序的“袋”（bag）。换句话说，就是作为属性的集合，集合中成员是有序的、但不唯一。集合的类型，“无序、唯一”称为“组”（Set）；“有序、唯一”称为“有序组”（OrderedSet）；“无序、不唯一”称为“袋”（Bag）；“有序、不唯一”就称为“序列”（Sequence）。
‘id’：属性是作为模块的ID属性，就是唯一标识模块实例的属性。例如“产品编号”。
：属性的约束，一般用“{约束表达式}”来表示约束。
通过上面对“属性”语法的解释，再总结一下“±#~/^*”这一串符号的意思：
“±#~”：表示属性的可见性，分表表示“公共的、私有的、受保护的、包内可见”；
“/”：表示属性是导出的；
“^”：表示属性是继承的；
“*”：表示属性的多重性，显示在属性定义“名称:类型”后面的“[]”中。
除了以上UML定义的属性的基本的语法之外，SysML为属性扩展了方向特征（DirectedFeature）。方向特征有三种取值：“prov | reqd | provreqd”，翻译为“提供|需求|提供且需求”。可以为除了流属性以为的其它属性添加这个特征（流属性也有方向特征，“进|出|进出”）。“提供”（prov）表示当前这个模块提供（写入）属性值、被别的模块使用（读取）；“需求”（reqd）表示别的模块提供（写入）属性值、当前这个模块需要读取；“提供且需求”（provreqd）表示上面两种要求都有。
在MBSES软件中，属性的这么复杂的语法让每个人记住、直接输入是太复杂了一些。所以一般只是输入基本的部分：“属性名称:类型[多重性]”。其它语法部分通过属性框输入，简化了语法。属性的修饰语部分也可以通过属性框设置是否显示（对应模块元素属性框中“节点属性”—“特征属性”）。
另外，可以为属性添加构造型，增加额外的特征。例如，对于数据有分布特征的属性添加“分布属性”构造型，为属性增加分布参数。
下图显示了属性定义的示例。在示例中，“显示器”模块有三个通过关联关系生成的部件属性（screen、power-supplying和driver）。“24寸显示器”继承了“显示器”模块，所以自动有这三个部件属性。“显示器”的“产品编号”属性的类型是一个字符串，它表示产品的唯一编号，是产品的ID。“显示面积”属性是一个导出的属性，因为当显示器的“屏幕尺寸”和“显示比例”确定之后，显示面积就可以计算出来，所以不能再赋值。“24寸显示器”是从“显示器”继承的产品，它继承了显示器的所有属性（继承属性前面都有“^”符号，继承的属性在子类中不能编辑）。但是为了进一步定义“显示尺寸”这个属性，重新定义一个相同名称的属性，并重定义父类的“显示尺寸”属性。重定义父类的“屏幕尺寸”属性后，为这个属性添加了一个“正态”分布属性构造型，并设置构造型的“均值”和“标准差”属性值。
在模块定义图中（或包图中），如上篇文章所讲，“模块”节点有20多种分区，其中大部分是显示各种属性的。
除了在分区中显示属性之外，在关联关系的两端也会显示属性节点。一般情况下在一个图中不需要同时显示。
模型之间的关联关系有三种，“引用关联”、“共享关联”和“组合关联”。这三种关联生成的属性类型不同。“引用关联”两端的属性都是“引用”属性；“共享关联”两端的属性也都是“引用”属性，不过在关系末端（不是菱形箭头的端）生成的引用属性的聚合关系是“共享”；“组合关联”在关系末端（不是实心菱形箭头的端）生成的属性是“组件”（part），聚合关系是“组合”。如果关联是双向的，则两端都生成属性；如果是单向的，仅仅在箭头端生成属性。这个属性的类型，就是靠近关联端的模块。在这个关联端属性节点中，只是输入属性的名称，不需要显示类型。“共享关联”和“组合关联”在靠近菱形箭头的这一端的属性（双向关联时才会产生），默认的多重性是“[0…1]”，可以不显示；另外一端的默认多重性是“[1]”，也可以不显示。多重性是其它情况的话，都要输入、显示。例如在“显示器”模块中的三个属性（screen、power-supplying和driver）就是由“组合关联”关系生成的部件属性。
在下面这个图中，显示一个分区中的“值”属性（“price”值属性的值类型有一个单位“元”）、两个关联端的“部件”属性。“hardDisk”属性是一个“部件”属性（由组合关联产生），多重性是“[1…4]”（关联端上的多重性不显示[]，如果不是默认值1，需要通过属性框输入上、下限才会显示）。“monitor”属性是一个“引用”属性，多重性是“[1…2]”。它表示计算机可以有1~2个显示器（显示器也可以同时连接其它计算机，所以可以建模为共享聚合关系。）
仅仅在模块节点的分区中显示属性，只是显示属性本身的定义。模块的结构定义，更重要的是各个属性之间的关系。内部模块图的作用和意义就是显示一个模块的属性之间的连接关系。
在内部模块图中主要显示三种类型的属性：部件属性、引用属性和值属性。部件属性外框是实线，引用属性是虚线，值属性也是实线的方框。
方框中显示属性的定义。属性的“可见性”和各种修饰语也可以通过属性节点的属性设置是否显示。属性的“多重性”一般是显示在节点右上角。
在内部模块图中的属性节点，除了可以显示对应类型的模块的各种分区之外，还可能会显示一个“初始值”（initialValues）分区。初始值表示这个类型的模块在实例化的时候，作为类型的模块的各个属性优先取的默认值，也就是说它会取代属性定义的“默认值”。添加初始值可以通过属性节点的右键菜单“添加”—“属性值”。
在模块的内部模块图中中添加属性，和在模块定义图中在模块的分区中添加属性效果是一样的。在打开一个已有属性的模块的内部模块图时（在模块定义图中，选择模块的右键菜单“打开内部模块图”），如果这个模块以前没有内部模块图，会自动新建一个内部模块图，而且会显示已有的部件属性和引用属性。如果在已有的内部模块图显示已有的属性，可以把属性元素从模型浏览器中拖拽到内部模块图中；或者先建立一个属性节点，然后通过属性节点右键菜单“选择已有属性”来建立节点和已有属性的关联。
属性节点可以显示内部模块图代表模块的直接属性，也可以显示间接的下层属性。显示间接的下层属性的时候，属性名称用“.”分隔的多层属性名称，表示间接属性的关系。也可以直接通过嵌套的属性节点显示多层的属性。下图显示“host:主机”属性中“mainboard:主板”属性的两种方式：
内部模块图主要还是为了表示属性之间的连接关系。属性之间的连接关系，用一个“连接器”（Connector）来表示。“连接器”可以仅仅表示两个部件之间有一个关联关系，也可以表示物理的“连接器”部件。连接器上可能还传递“项目流”。“项目流”是特定类型的信息流，它是一种关系元素。项目流可以单独在模块定义图中定义，也可以在连接器上直接定义（通过连接器节点的右键菜单“选择项目流”，在选择窗口中直接增加项目流）。连接器和连接器上的项目流两端的类型和方向都必须是相容的。
如下图所示，主板通过一个“连接器”连接到显示器。在连接器靠近显示器这一端也有个“连接器端”的元素，它的“多重性”是1，表示连接器连接的显示器是1个（虽然整个计算机可能有两个显示器，但是一条连线只能连接其中的一个显示器）。在连接器中传递的“项目流”的类型是“显示信号”，它的方向从主板到显示器。“显示信号”是一个元素类型为“信号”（Signal）的信号，在后面的图中有定义。
上面是表示部件属性“mainboard:主板”和部件属性“monitor:显示器”之间通过一个连接器连接关系的模型。我们可以继续细化这个模型，其中有几个点需要细化。两个部件连接的标准是啥？通过什么接口连接？作为连接器的连线是否也需要在模型中体现？假设我们的需求是通过一条符合HDMI2.0标准的连接线连接主板和显示器。为了表达上述建模要求，在主板和显示器上分别增加一个“端口”（Port），端口的类型是一对共轭的接口模块“HDMI2.0接口标准”。我把还增加“HDIM2.0标准线”关联模块，并作为“计算机”模块中的一个连接器属性。用到的这些类型定义在下面的包图中。
添加接口和连接器类型的内部模块图如下所示。在“mainboard:主板”属性中增加一个端口，类型为接口模块“HDMI2.0”；属性“monitor:显示器”中增加一个端口，类型为共轭接口模块“~HDMI2.0”。连接器的类型可以选择为关联模块“HDMI2.0线”，两者的方向以及两端的类型必须是相同或兼容的。
已剪辑自: http://www.zhiruisiwei.com/html/articles/article_004.html#main_right
在MBSE的模型中，行为（Behavior）是一个重要的概念。前面我们主要介绍的模块、模块的属性是系统的结构模型，描述系统是如何构成的，各部分之间有什么关系。而行为是系统的功能模型，或称之为动态模型，它描述的是系统及其各组成部分是如何动态变化的。
“行为”（Behavior）是一种通用的动态模型元素。具体的行为元素主要包括“活动”（Activity）、“状态机”（StateMachine）和“交互”（Interaction），它们分别以“活动图”、“状态机图”和“序列图”的方式说明一个行为的过程。这三种图的具体说明我们将在后期的文章中进行说明，这里先讲讲通用行为的概念，以及行为和作为系统结构说明的元素“模块”、需求说明的元素“需求”之间的关系。
“行为”是系统状态随时间变化过程的描述。“行为”代表系统的一种功能，它有输入、输出，它的功能就是把输入转换为输出。在这个转换过程中，可能伴随系统本身状态参数的变化。在设计一个系统的时候，很重要的工作就是设计系统有什么功能、怎么实现这些功能。所以，进行系统行为模型的分析是建模工作的关键内容之一。在对一个新产品进行建模的时候，一般是遵从“需求分析”—“功能分析”（行为分析）–“架构设计”这个大的基本过程。“需求分析”阶段，通过建立系统“功能需求”元素（FunctionalRequirement，它是SysML标准中一个扩展的需求元素）确定功能目标。然后通过建立相应的行为元素及其图形细化这些功能需求（功能需求只能通过一个行为元素来满足）。最后在确定系统架构模型时，将这些行为分配给具体的“模块”（作为模块的“拥有行为”）。
“行为”元素可以放在模型中专用的一个包下面，也可以直接放在具体的某个“模块”下面。
在UML语言中，“行为”也是一个“类”（Class）。相应的在SysML语言中，具体的行为元素（活动、交互和状态机）都是类的扩展元素“模块”(Block)。UML\SysML标准遵循了面向对象的设计概念，这世界上一切都是“对象”（Object）。“对象”是类的实例，也就是说世界上的一切对象都是某个类的实例。“行为”也是一个类，行为的一次“执行”就是这个类的实例。当然，行为是一种特殊的类，它有类的基本特征：可以有属性和操作，而且它还多出来很多描述动态过程的东西（具体的行为元素描述动态过程的方法不同，具有的子元素不同）。可以说“行为”元素是在“类”的基础上增加了描述动态过程的内容。
在SysML标准中，三种具体的行为元素“活动”、“状态机”和“交互”都是“模块”，所以它们可以像模块一样进行分解，把一个复杂的行为分解成小的、局部的或共用行为元素。这个过程也可以对应为设计分析中的“功能分解”过程。上层的行为元素和下层的行为元素都有各自的图形，例如在一个上层“活动图”中，通过一个“调用行为动作”，调用下层的活动元素（或其它行为元素）。
前面我们说了，“行为”代表一种功能，有输入、输出，好似软件中的一个“函数”或“过程”（UML本来是用于软件建模的，在UML中一个行为确实对应编程语言中的一个函数或过程）。在定义一个行为元素的时候（例如，在模块的拥有行为分区或类目行为分区中增加一个行为），它遵从以下语法：
‘(’[]‘)’[‘:’ []][]
用中文把上面的语法翻译一下如下：
<名称>‘(’ [<参数列表>] ‘)’ [‘:’ [<返回参数列表> ] ] [ <行为约束>]
上面语法中各部分说明如下：
：行为的名称，不能为空。行为元素也是有命名空间的，如果行为直接定义在一个包下面，这个包就是它的命名空间；如果定义在一个模块下面，模块的名称就是它的命名空间。
< parameter-list>：输入参数的列表，每个参数用“,”分隔。每个参数的语法如下：
::=[] ’:’ [’[’’]’] [’=’][’{’ [’,’ ]* ’}’]
对应中文，每个参数用“方向 名称:类型[多重性]=默认值{参数属性}”这样的格式。
：’in’ | ’out’ | ’inout’ (默认’in’)，表示参数是传入、传出或同时是，“无”的话默认是传入。
：参数名称。
：参数类型。
：集合参数的话参数的数量最少、最多多少个。
= ：参数默认值。
：参数属性，有以下选项：
::= ‘ordered’ |‘unordered’ | ‘unique’ | ‘nonunique’ | ‘seq’ | ‘sequence’
‘ordered’ | ‘unordered’：表示返回的集合参数中是否是有顺序的；
‘unique’ | ‘nonunique’：表示集合中每个参数是否是唯一、不唯一的；
‘seq’| ‘sequence’：这两个选项意义相同，‘seq’ 是 ‘sequence’的缩写，表示参数是一个有序的“袋”（bag），既有序但不唯一。
此外，参数还有以下属性：
isStreaming：是否是“流”。如果是流，则在行为执行期间，这个参数可能一直有数据传入、传出，而不仅仅是在调用或完成时。
isException：是否异常值，只用于是“传出”的参数。如果“是”，则如果这个参数有值，则其它参数不会有值。
effect：影响，取值范围为“生成、读取、更新、删除”中的一种。
< return-type-list>：返回参数列表，每个返回参数用“，”分隔，每个返回参数的语法定义如下：
:= [‘[‘ ‘]’] [‘{‘ ‘}’] ]
对应中文，每个返回参数用“类型[多重性]参数属性”这样的格式。
：返回类型。和输入参数不同，返回参数没有名称，直接“类型”开头；
：多重性，表示这个参数是个集合的话，集合中每个参数最少、最多的个数；
：参数的属性，有以下选项：
::= ‘ordered’ |‘unordered’ | ‘unique’ | ‘nonunique’ | ‘seq’ | ‘sequence’
‘ordered’ | ‘unordered’：表示返回的集合参数中是否是有顺序的；
‘unique’ | ‘nonunique’：表示集合中每个参数是否是唯一的；
‘seq’ | ‘sequence’：这两个选项意义相同，‘seq’ 是 ‘sequence’的缩写，表示参数是一个有序的“袋”（bag），既有序但不唯一。
：行为的约束，一般是“{}”中一个约束表达式。
另外，行为的属性“isReentrant”(是否可重入)表示这个行为在执行的时候，是否可以再次被调用。
在行为的语法中，每个输入、输出参数既可以是单一值，也可以是一个集合。也就是一个参数的一次传递，可以传递一个值，也可以传递一组值。所以每个参数才有多重性、是否唯一、有序等等这个集合的属性。
在表示行为的语法前面，可能会有表示具体行为类型的构造型，如果«活动»、«状态机»或«交互»。
在MBSES（智睿思维基于模型的系统工程软件）中，行为的参数可以通过一个弹出窗口进行定义。参数的属性通过属性框定义。但是也可以直接在模块的行为分区中按照简化的语法“名称( 参数名称: 参数类型) 返回参数类型”定义一个行为。
在前面的文章中，我们说过“模块”有两种有关行为的分区，“拥有行为”分区和“类目行为”分区。“拥有行为”是当前这个模块中定义的行为，这些“拥有行为”是这个模块的功能，这个模块是这些行为执行时候的语境（也叫上下文，Context）。在一个行为执行的时候，除了可以使用和修改行为的输入、输出参数，还可以使用或改变作为上下文的这个模块的各种属性。例如，一个柴油发电机，具有一个“发电”的行为，在这个行为中，消耗作为输入参数的“柴油”，输出作为输出参数的“交流电”，同时会发热，改变发电机的温度。
“类目行为”是当前这个模块从开始工作到停止工作过程的一个行为过程描述。一般用一个状态机来描述。例如一个设备的“开机”、“运行”、“待机”、“停机”这些状态形成的一个设备工作过程状态机作为设备的“类目行为”。
当一个模块向其它模块提供功能的时候，必须通过这个模块的“行为特征”（BehavioralFeature）来提供，而不是直接提供行为的调用。模块的“行为特征”有“操作”（Operation）和“接收”（Reception）两种。但是在UML/SysML语言中，行为特征本身没有说明行为过程的能力，它的行为过程说明必须通过一个具体的行为元素的图形来说明。说明“操作”或“接收”具体行为过程的行为元素称为它们的“方法”（Method），同时，这个“操作”或“接收”称为对应行为元素的“定义”（specification）。一个行为元素也可以没有对应的行为特征，这时候它只能被当前这个模块的其它行为调用，不能被外部模块调用。行为和它对应的“操作”或“接收”必须参数完全对应。
下面用一个三综合试验箱功能分析的例子说明“行为”的定义和应用。
首先定义一个“三综合试验箱”的模块，这个试验箱有“震动”、“加热”、“加湿”、“冷却”的功能，当然主要的功能还是进行“三综合试验”这个功能。这些功能我们都定义为它的“拥有行为”。同时定义了一个“开始三综合试验”的操作，这个操作的“方法”对应“三综合试验”行为，它们都有一个参数“试验程序号”。当人工的方式开始试验，或者通过远程控制的方式调用这个操作开始试验，则试验箱根据“试验程序号”参数开始对应的试验程序。“三综合试验箱”模块定义如下：
“三综合试验”行为的流程用一个活动图来说明。首先根据“试验程序号”找到对应的试验程序。正式开始试验前，设备要先进行预试验步骤，把箱内温度、湿度控制到试验程序规定的起始条件。然后根据试验程序中的定义，进行“震动”、“加热”、“加湿”，“保持”一定时间，根据程序定义可能进行“冷却”。这个过程可能是个循环过程，用一个“循环节点”来表示。活动图如下所示：
已剪辑自: http://www.zhiruisiwei.com/html/articles/article_005.html#main_right
活动（Activity）是一种行为（Behavior）元素，它是行为元素的子类。首先活动是一个“类”（class）。SysML中，它也是一个模块（block），所以它有“类”的特征，可以有属性、方法，还可以有下层的“行为”元素，形成一个多层嵌套的行为模型。其次，活动是一个“行为”元素，有输入参数和输出参数。活动元素的特殊之处在于它可以包含各种可以说明一个行为过程的元素，包括“动作”（Action）、控制流（ControlFlow）和对象流（ObjectFlow），以及其它说明控制逻辑的节点。
活动可以用来说明系统的功能，活动以及它包含的子活动元素、活动中的动作元素，可以形成一个系统的功能结构树。在进行系统的功能分析的时候，它是重要的说明元素。
作为一个行为元素，活动可以作为一个模块（Block）的拥有行为，用于说明一个模块的功能。此外，活动也可以作为其它行为元素的更具体的说明。如，对一个用例（UseCase）进行更详细的说明，可以把活动元素作为用例的拥有行为（用例也是一种行为类BehavioredClassifier，可以拥有行为）进行说明；活动也可以作为状态机中的状态（State）的内部行为，或系统处于某个状态时进行的工作；活动也可以作为状态转移（Transition）的影响（effect），说明状态转移时发生的行为。
在“智睿思维基于模型的软件”（MBSES）中，你可以为一个模块增加拥有行为的时候，增加一个活动元素。也可以直接在一个包中增加一个活动元素。
UML\SysML是面向对象的语言，活动是一个说明具体行为过程的元素。可以说活动和它的活动图是用UML\SysML语言写的一段系统运行过程的“程序”。这段“程序”要有运行的语境（Context），也就是活动的过程可以读写的变量的范围。这个语境就是活动所属的模块。如果活动没有所属模块，那它自己就是自己的语境。在活动的过程中，可以读写它的语境中的属性（Property）、可以调用所属语境的其它行为（通过一个调用行为动作）。当然也可以调用（通过一个“调用操作动作”）另外一个模块的操作（Operation）、接收（Reception）,但必须通过当前模块的一个部件（part）属性或引用（reference）属性。这是面向对象语言的“封装”性原则所规定的，这个原则使我们定义的系统模型中功能调用关系是清晰的、范围可控的。
下面以一个具体的人造卫星做霍曼转移、变轨过程的活动图来说明活动图中元素及其作用和意义。
人造卫星从一个较低运行轨道转移到一个较高的运行轨道，需要两次发动机点火、加速的过程。如右图所示，人造卫星从低轨道“1”送往较高轨道“3”，先在低轨道“1”上瞬间加速，进入一个椭圆形的转移轨道“2”。卫星由此椭圆轨道的近地点开始，抵达远地点后再瞬间加速，进入另一个圆轨道（3），此即为目标轨道。
首先定义这个过程的活动元素为“执行霍曼转移”，有一个类型为“转移命令”的输入参数（命令中包含执行时间点、目标转移轨道高度），以及一个类型为“命令响应”的返回参数（返回命令是否合法的响应，这是一个“流”类型的返回参数）。定义的语法如下：
“执行霍曼转移(当前命令: 转移命令) :命令响应{流}”
对应的活动图如下（来源于《SysML精粹》图6.1，进行中文翻译。此图使用“智睿思维基于模型的系统工程软件–MBSES”制作）：
活动图中有以下几类节点，说明如下。
动作是活动中的基本功能执行单元，动作是最底层的功能单元，不能（或当前建模要求下不需要）再分解。每个动作也可以有输入（输入栓）和输出（输出栓），作为这个动作处理的数据和结果。
在活动图中，通过控制流（ControlFlow）或对象流（ObjectFow）将动作串联起来，表示动作执行的过程顺序。
在控制流或对象流中传递的数据称为“令牌”（Token）。这些令牌可以是一次一个数据的方式传递，也可能是按“流”的方式连续的传递（针对对象流）。
一个动作能够执行的条件是：
（1）动作所在的活动在执行；
（2）动作中所有连进来的控制流上都有控制令牌到达。
（3）所有输入对象流上都有足够数量的对象令牌到达，以满足相应输入栓的最低多重性要求（值栓除外，值栓不需要对象流）。
如果一个动作没有任何输入的控制流及对象流，则当所在活动开始执行的时候，这个动作就开始执行。
活动图中的具体动作节点类型有40多种，每一类动作节点有具体的用途。常用的动作类型如下：
不透明动作是用某种语言（包括自然语言，或某种编程语言）描述的一个功能。不透明动作一般用一个动词短语描述一个功能。如图中的“生成’合法命令’状态响应”节点用自然语言说明一个系统将执行的一个功能；“:{C}当前轨道半径=当前高度+地球.半径”节点用C语言的赋值语句说明了这个节点将执行的数据处理功能。
“调用行为动作”表示对另外一个行为元素（可能是另外一个具体的活动、交互或状态机）的调用。调用操作动作表示对一个模块的实例的操作的调用。这两个“调用动作”在节点中一般会显示显示一个叉的符号。如图中的“vc: 验证命令”和“ma: 测量高度”动作就是两个调用行为动作。
活动的分解，就是通过在一个活动的活动图中定义“调用行为动作”调用下层的活动来实现的。在节点中，它的文本表示语法是：
“动作名称：被调用的行为名称”
在MBSES软件中，通过节点的右键菜单“设置行为元素”来设置调用的对应的行为。在进行活动图的仿真时，遇到调用行为节点将会打开对应行为元素代表的图，并继续执行。
“调用操作动作”有一个“目标”输入栓，这个“目标”栓的实例，就是将被调用的操作所在的实例。
这两个调用动作节点，要求其它输入栓和输出栓应该和被调用的行为或操作的参数对应。
发送信号动作表示动作将生成一个某种类型的信号，并发送到指定的“目标”输入栓对象。信号的类型是在模型中某个地方定义的信号（Signal）元素。向一个对象发送信号，相当于调用了对象中和信号类型对应的“接收”（Reception）。“接收”和操作类似，只不过接收的名称和接收的信号类型相同，参数和接收类型的属性对应。对“接收”的调用都是“异步”的，意味着发送信号动作不会等待被调用“接收”对应的行为执行完，而是立即执行下一个动作。
发送信号的其它输入栓应该和信号类型的属性对应，从而作为生成信号属性的数据。
如果没有定义“目标”栓，则发送信号动作将把信号发送到当前图中对应的“接收信号动作”（接收事件动作，而且事件类型是一个信号，见下一节）。上面示例图中，“轨道半径更新”发送信号动作没有规定“目标”栓，则信号发送到当前图中的“轨道半径更新”接收事件动作。
接收事件动作的触发，除了上述动作执行的条件之外，还有一个条件就是接收事件动作的触发器事件发生。一个接收事件动作可以有多个触发器（Trigger），每个触发器有一个触发事件。触发器的事件类型有“调用事件”（当前语境对象的某个操作被调用时发生）、“信号事件”（当语境对象接收到某个类型的信号时发生）、“变动事件”（当这个事件定义的表达式的值从“false”变为“true”的时候发生）、“时间事件”（见下节说明）、“任何接收事件”（当接收到一个包含任何除信号之外的其它“对象”的消息的时候发生。通常由一个SendObjectAction –“发送对象动作”引发）。
根据接收事件的类型不同，接收事件动作显示的语法不一样。当接收事件是一个“调用事件”的时候，显示操作的定义；当接收事件是一个“信号接收事件”的时候，显示信号类型的名称（如示例图中的“轨道半径更新”接收事件动作）；当接收事件是“变动事件”时，显示“when 表达式”；当前信号类型是“时间事件”的时候，显示“at 时间点”，或“after 时间点”；当接收事件类型是“任何接收事件”时，显示“all”。
当一个接收事件动作只有一个类型是时间事件的触发器时，这个动作非正式的称为“等待时间动作”，它的节点用一个沙漏的形状来表示。
等待时间动作的时间事件，有两种时间表示方法。一种是绝对时间，用“at 具体时间”来表示；另外一种是相对时间，用“after 多少时间”表示。等待时间动作只能有一个输出的结果栓。当时间事件发生时，发生时间值被放到这个结果输出栓上。如示例图中的“at 当前命令.执行时间”，表示时间到达命令中的执行时间点的时候，时间事件触发器触发，才会执行下一步的“进入转移轨道：点火推进器”动作。
控制操作是一个构造型，它用于一个行为（一个具体活动、交互或状态机），表示这个行为具有一个复杂的逻辑，能够接收或返回一个“控制值类型”（ControlValueKind）的参数。“«控制操作»”会用于一个“调用行为动作”，表示调用的行为是对控制值类型数据的处理。“控制值类型”是一种特殊性数据，可以取值“使能”（enable）或“使不能”（disable）。一般情况下，当一个动作接收到“控制值类型”的参数的时候，根据值参数值动作进入可以执行状态或不能执行（停止执行）状态。但是一个具有“«控制操作»”构造型的调用行为动作收到“控制值类型”参数，不是停止这个调用行为动作执行，而是它会处理这个参数，而且可能根据具体逻辑返回一个“控制值类型”参数，然后传递给其它动作来控制其它动作的执行。
除了以上常用的动作类型，ＵＭＬ标准中还定义了其它30多种动作，这些动作主要是某些特殊类型对象的创建、读取、删除、销毁等操作。
控制流和对象流把动作和控制节点连接起来，表示动作发生的顺序和条件。在UML标准中，控制流和对象流都是“活动边”（ActivityEdge）的子类型；换句话说，它们都是控制边，控制边有的特征，它们都有。
控制流表示控制令牌数据的传递。在MBSES软件中，控制流用虚线表示。控制流直接把动作、控制节点连接起来。当一个动作连入的控制流有控制令牌到达的时候，这个动作才“可以”执行。控制流中的令牌可以理解为对“动作”的一次调用命令。一个动作所有的连入控制流是“与”的关系，也就是如果一个动作有多个连入的控制流，要所有控制流都有令牌到达动作才能够执行。所以，当我们表示一个循环执行的动作的时候，不能把这个动作输出的控制流又连回到这个动作，而应该在连入自己之前，和别的连入控制流（首次执行连入的控制流）用一个“合并”节点合并为一个连入的控制流。如上述活动图中“轨道半径更新”接收信号事件动作前后的合并节点和决定节点。
对象流中传输的是数据或其它定义的类型（如水流、电流等任何定义的“模块”类型或值类型）的实例对象，或者活动参数代表的对象。对象流中的“对象”令牌是动作执行中处理的内容，类似是“动作”的输入、输出参数。在MBSES软件中对象流用实线表示。
对象流必须通过“栓”（Pin）连到动作上，除非对象流中间用一个“对象节点”的方式简化两端的栓表示法。
控制流或对象流的“守卫条件”指这个边能执行的条件；例如上述活动图中验证命令之后的“决定节点”的两个输出边，“[命令是否合法=是]”和“[命令是否合法=否]”表示两个输出对象流路径的执行条件。
活动边“概率”属性表示这条边能够走过的概率；“权重”表示当这个边上需要的最小令牌数量条件，当这条活动边上通过的令牌数量满足这个权重条件的时候才会通过。当对象流上流过的对象是“流”的时候，可以定义活动边上对象通过的“比率”值，这个值应该是一个单位时间内通过的对象数量。如“0.2kg/s”。当通过的每个对象之间的时间间隔为0，则是“连续”；否则是“离散”。
对象节点对动作之间传输的对象进行定义。对象节点的类型可以是“模块”（Block）或其它数据类型。它可以代表一种数据，也可以代表我们的模型中定义的任何物质。
对象节点一般是作为一个动作（Action）的“输入栓”（InputPin）或“输出栓”（OutputPin）。“输入栓”（InputPin）或“输出栓”类似动作的输入、输出参数。
“值栓”（ValuePin）是一种特殊的输入栓，它不需要对象流传入，它的值是用定义的表达式计算的。当动作符合执行条件的时候（其它输入控制流都有控制令牌到达、其它输入栓都有对象流到达或满足最小令牌数条件），动作就从这个“值栓”的表达式中计算一个值作为输入。
对象节点本身不代表传输的对象，它是对传输对象的形态进行定义。传输的对象是对象节点类型的实例，每个实例称为一个“令牌”。在活动执行过程中，有很多个“令牌”通过连接对象节点的对象流。但并不是一有“令牌”对象到达，动作就一定执行。例如处理视频播放功能的一个动作，要等到视频数据“缓冲”到一定量才执行。对象节点的“下限”属性就是定义动作执行一次需要的最小数据量。如果对象节点不能“缓冲”，则应用“非缓存”（«nobuffer»）构造型。
“接收令牌数上限”是指当到达的令牌数量超过这个值之后，不再接收令牌。因为动作一次执行不一定把到达的令牌全部拿走（消费），消费不完令牌会积累，积累到一定量的时候，就拒绝上一环节的动作发送新的令牌。例如当调用一个http协议的服务的时候，如果post的数据量超过这个http服务接收的“最大令牌数量”时，这个服务将拒绝新的post请求，以防服务崩溃。
“覆盖”（«overwrite»）表示新到达的令牌超出对象节点规定的上限时，覆盖已有令牌而不是拒绝接收。
“可选”（«optional»）表示对象数据对于动作的执行时可选的，也就是“下限”是0。
应用了“控制”（«control»）构造型，说明传输的数据类型是“控制值”类型（见控制操作一节说明）。
如果用了“流”（«stream»）构造型，说明对象是一种“流”类型。此时，可以进一步定义“流”的参数：比率（rate）、离散或连续的。
“排序”是对象节点中的令牌是按什么顺序被动作节点消费或传送到下一个节点的。有四种顺序可选：“无序”、“有序”、“先进先出”（FIFO）和“先进后出”（LIFO）。
“包含状态”是指令牌对象的取值范围，只能在“包含状态”定义的几种状态中取值。这几种状态应该是对象节点类型的状态机中定义的状态。
除了动作上的栓，还有以下类型的对象节点：
**“活动参数节点”（ActivityParameterNode）：**对应活动的一个输入或输出参数。在示例图中，“当前命令：转移命令”是活动参数节点（一般放在活动图左边）；“：命令响应”是输出的活动参数节点（一般放在活动图下边缘，或右边缘）；
**“中心缓存节点”（CentralBufferNode）：**作为缓存作用的对象节点。
**“数据存储节点”（DataStoreNode）：**数据存储节点中的令牌对象被输出活动边拿走后，仍然会保留一份值相等的令牌对象，永远拿不完。而“中心缓存节点”中的令牌对象被取走后就没有了。但是“数据存储节点”中存储的对象按ID保存，相同ID的对象仅存储一份。
控制节点的类型主要有以下几种：
**“决定节点”（DecisionNode）：**最少一个、最多两个输入的活动边，最少一个输出的活动边。如果有两个输入的活动边，则其中一个必须是对象流，这个输入对象流的数据用于决定节点输出的对象流活动边守卫条件的判断。在示例图中有两个“决定节点”。
**“合并节点”（MergeNode）：**合并节点只能有一条输出活动边、多条输入的活动边。当任何一条输入活动边有令牌到达，则转发到输出的活动边。在示例图中有两个“合并节点”。
**“分支节点”（ForkNode）：**分支节点只有一个输入的活动边、多条输出的活动边。分支节点的输出活动边是“并行”的，相当于把一条输入活动边的令牌数据分发到全部输出活动边。分支节点可用于并行流程的建模。在示例图中，开始节点下面是一个“分支节点”，分出来的两个控制流并行发生，说明验证命令、点火推进器的那个分支，和测量高度、计算轨道半径的那个分支是并行的。
**“集合节点”（JoinNode）：**集合节点有多个输入活动边、仅仅一个输出活动边。只有所有输入活动边有令牌到达的时候，输出活动边才有令牌输出。这个和“合并节点”是不同的，合并节点输入边是“或”的关系，集合节点是“与”的关系。集合节点一般和分支节点联合使用，将分支节点分出去的多个并行流程汇聚到一个流程。
**“初始节点”（InitialNode）、“活动终止”（FinalNode）、“流终止”（FlowFinalNode）节点：**表示一个活动图的开始和结束节点，以及仅仅一个流的终止。
结构化活动节点是表示一类复杂过程的节点。结构化活动节点中包含一系列动作节点，“循环节点”、“条件节点”类似编程语言里面的“循环语句”、“条件语句”。
“循环节点”中的“设置”（setupPart）中的动作相等于循环语句中初始化循环变量的作用，“测试”（test）中的动作起判断循环条件的作用，“循环体”（bodyPart）中动作在每次循环中执行。
“条件节点”中有多组“子句”（clause）。只有当一个子句的“测试”（test）中的动作返回“true”值时，子句的“主体”（body）中的动作才能执行。
“序列节点”中包含多个动作子节点，这些动作之间不必画出节点之间的控制流，每个动作将会按序列依次执行。
这三类结构化活动节点示例如下（此图使用“智睿思维基于模型的系统工程软件–MBSES”制作）：
活动分区是具有相同特征的活动节点和活动边的一个分组。活动分区的边框用虚线表示。活动分区和结构化活动节点是完全不同的概念（虽然都是用虚线边框）。结构化活动节点本身是一个“动作”（Action），它可以有自己的输出、输出栓。但是活动分区只是一个分组或关系（如分配活动分区）。
活动分区可以代表一个模块（更通用的说可以是一个具有行为的类目，Classifier）、一个实例（InstanceSpecification）或一个属性（Property）。分区中的动作是这个模块、或者实例的类、属性的类的活动行为被调用的动作。也可以说是一个局部的活动图，这个局部的活动图的“语境”是大活动图语境（大活动图所属的模块）的部件。
不过活动分区具体代表什么元素，UML标准中并没有明确定义，也可以是其它元素。用户可以根据需要定义。在SysML标准中，定义专用的活动分区“分配活动分区”，可以为这个分区指定指定任意的元素（一般还是一个结构元素，如“部件”），表示分区中的活动元素分配到这个指定的元素。这一般应用到将代表功能的“动作”分配到结构元素“部件”。
多个活动分区水平或垂直并列的使用，用水平线或垂直线分隔，这种表示法通俗的称为“泳道”（swimlane），这样的图称为“泳道图”（可以给图增加构造型«泳道图»）。
“可中断活动分区”是一类特殊的活动分区，分区中增加了一个表示动作流程中断的“中断控制流”，这个控制流一般是某个事件引发（例如下面示例图中，用户关闭车钥匙，发送了一个“关闭钥匙”信号，引发“关闭钥匙”接收事件，然后触发中断，结束整个活动）。
如下图是一个“SUV提供动力”的活动图图（具有«泳道图»构造型）（来源于SysML1.6标准附录D图D.38，此图使用“智睿思维基于模型的系统工程软件–MBSES”制作），图中通过表示分配关系的分配活动分区“泳道”，将相应动作功能分配给SUV相应的部件。
已剪辑自: http://www.zhiruisiwei.com/html/articles/article_006.html#main_right
交互（Interaction）是一种具体的行为元素，它用对象之间消息传递的方式说明行为发生过程的顺序和互相传递的信息。对交互进行说明的图主要是序列图（Sequence Diagram, 在UML标准中还有使用时间图、通讯图或交互概览图对其进行说明，SysML标准只使用序列图）。
作为一种行为，交互也是具有行为的基本特征：具有输入参数、返回参数；它可以作为一个模块（Block）或其它行为类目（BehavioredClassifier）的拥有行为（OwnedBehavior）;它可以作为一个操作（Operation）、接收（Reception）的“方法”（Method）。
和活动（Activity）一样，交互同时也是一个模块（Block）。一个复杂的交互行为可以进行分解。在上层的交互行为中，通过一个“交互使用”（InteractonUse）元素表示对下层或其它交互的调用。
作为行为，交互的发生一样需要规定发生的语境（Context）。如果交互是某个模块的拥有行为，则这个模块是交互行为的语境；否则它自己是它的语境。说明交互的序列图中的元素都是它的语境范围内的元素。下面介绍序列图中的生命线、消息等元素的时候，总是要涉及到代表交互的语境的模块。
下面先看一个代表交互的序列图，然后说明图中元素的作用和意义。在这个图中，上面的“汽车域”（域是扩展的“模块”类型，代表特殊的模块）是下面“启动车辆黑盒”交互的语境（Contex），因为“启动车辆黑盒”交互是它的一个拥有行为。
生命线元素代表模块中的一个部件（或其它属性）的实例，这个模块是生命线所在的序列图代表的交互元素所属的模块。在上面这个图中，“HSUV: HybridSUV”是“启动车辆黑盒”交互所属的“汽车域”模块的一个部件属性；“driver: 司机”是“汽车域”的一个执行者属性。
生命线用一个下面有一条虚线的矩形框表示，矩形框称作它的“头”。这个虚线代表了生命线代表部件属性中发生事件的顺序，它总是从上到下的顺序。
生命线的“头”中显示的文本的语法说明如下：
::= ([[‘[‘ ‘]’]] [: ][]) |‘self’
中文化的语法：([<名称>[‘[‘ <选择器> ‘]’]] [: <类型 >][<分解>]) |‘自己’
一般情况下，生命线像一个属性一样，显示代表的属性的名称和类型，如“driver: 司机”，“driver”是代表属性的名称，“司机”是代表元素的类型。
“<选择器>”是可选的部分，当属性表示多个实例的时候，选择器表示其中具体那个实例。如果没有选择器，表示可以是任何一个实例。例如对一个飞机的驾驶员属性，可以用“pilot[主]:飞行员”表示飞机的主驾驶员。
可选的“<分解>”语法部分，表示这个生命线上发生的行为，可以在一个更具体的交互元素表示的序列图中显示。这个交互元素代表的行为属于生命线的类型表示的模块。在这个分解的交互元素的序列图中，当前生命线类型元素将分解为它的组成部分代表的子生命线。用关键字 “引用”（或ref）+“交互元素名称”表示。“strict”说明“分解交互元素”序列图中的子生命线的都是“严格”顺序。（有关分解的详细说明，参见UML2.5标准）。
特殊情况下，生命线也可以直接表示交互所属的那个模块，而不是模块中的属性。这时候，用一个特殊的关键字“self”（MBSES软件中可以用中文“自己”）表示。
消息代表生命线之间的通信，从发送消息的生命线指向接收消息的生命线。消息可以直接连接到生命线上，或者连接到生命线上的执行说明。
消息的发送和接收伴随着生命线上行为事件的发生，在消息发送端表示发送事件的发生；接收端表示接收事件的发生。所以在消息的两端会自动生成“消息发生说明”（MessageOccurrenceSpecification）元素。当消息的一端是连在序列图的外框，或者“组合片段”（CombinedFragment）的边框的时候，这个消息端上表示一个“门”（Gate），“门”表示交互元素或组合片段和外界的接口。
消息的“签名”（signature）属性是消息调用的操作（Operation，接收生命线的类型元素具有的操作），或者一个信号（Signale）。如果消息的通信类型是同步调用或异步调用，则签名应该是接收生命线的一个操作；如果通信种类是异步信号，则签名应该是模型中定义的一个信号元素。同时，作为接收的生命线的类型元素，也应该有一个对应的“接收”（Reception）。
在表示消息的连线上，会显示说明消息的文本标签。通用消息的语法表示为：
::= | | ‘*’
它表示消息表示为“请求消息标签”或“回复消息标签”或一个“”。“”表示任何类型的消息。“请求消息标签”或“回复消息标签”的具体语法根据消息的类型确定。
“请求消息标签”（除了回复消息以外其它各种消息）语法如下：
::= [‘(‘[] ’)’]
中文的解释：<消息名称>([<输入参数列表>])
如果消息有一个“签名”属性，则消息的名称一定和“签名”属性对应的操作或信号的名称相同。否则没有限制。
可选的“输入参数列表”是对应调用“签名”的操作时输入的参数，或者对应“签名”信号的属性（或者说对应“接收”的输入参数，因为“信号”和“接收”是对应的）。每个输入参数的语法是：
::= [ ‘=’] | ‘-’
意义：[输入参数名称=]<值>|’-‘。输入参数名称是可选的，都显示或都不显示。“-”表示一个通配符，只是表示对应一个参数，但没有指定任何值。
例如一个用户登录身份验证的消息表示为：
“login(userName=‘admin’,password= ‘1234567’)”
“login”对应系统的一个登录的操作，使用’admin’用户名及默认的’1234567’作为默认密码进行系统的登录。
如果是表示一般用户的登录，则传递的消息为：
“login(userName, password)”
这个消息表示使用用户生命线代表实例的’userName’属性值和’password’属性值作为参数进行登录。
“回复消息标签”的语法为：
::= [ ‘=’] [‘(’ [] ‘)’] [‘:’ ]
中文：[<赋值目标]=<消息名称>([输出参数列表]):<返回值>
“回复消息”是操作执行完，返回给调用生命线的数据。可选的“赋值目标”表示返回值赋值为调用生命线的某个属性。完整的例子如下：
“area=returnArea(w=width:16):96”
这个返回消息表示返回值“96”赋给了调用生命线的“arean”属性，同时，“w”作为输出参数“width”对应的变量，赋值为16。这条消息通过输出参数及返回参数，返回了两个值。
消息的分类，从两个维度进行分类。一个是按两端的事件，有以下四类（MessageKind）：
“完整”：有发送事件和接收事件。
“丢失”：有发送事件、无接收事件。它表示接收事件的对象超出了模型的范围，无法描述或无需描述。
“发现”：无发送事件、有接收事件。它表示发送事件的对象超出了模型的范围，无法描述或无需描述。
“未知”：无发送事件、也无接收事件。这种消息在最终的模型中不应该出现，只是作为临时的数据出现。
消息按调用及返回的方式（MessageSort），有以下几类：
“同步调用”：消息是一个调用操作的消息，而且是同步调用。“同步”的意思，是当调用的时候，调用过程会停下来，等待被调用操作返回消息才继续下面的动作。例如一个“登录”消息，调用“登录”操作，必须等待登录结果才继续下面的操作。
“异步调用”：消息是一个调用操作的消息，而且是异步调用。“异步”的意思，是当调用的时候，调用过程不停下来，继续执行下面的动作。
“异步信号”：凡是消息签名是“信号”，则消息就是“异步信号”。因为信号的发送，总认为是异步的。无论接收信号方是否处理信号完毕，都不影响发送方继续其它工作。
“创建消息”：表示创建一个“生命线”的实例。创建消息指向被创建生命线的“头”。
“删除消息”：表示终止另一条生命线的消息。删除消息总是指向生命线的末端，而且末端有一个“X”形的“删除发生说明”事件。
“回复”：表示调用操作之后，操作回复给调用方的消息。
各种消息的线及两端的表示符号都不同。详细情况可以参见“智睿思维基于模型的系统工程软件”中消息的表示方法，通过选择消息的不同类型，消息的表示方法会变化。
执行说明表示生命线上一个行为（Behavior）或动作（Action）的执行。执行说明显示为一个覆盖生命线的一部分的一个细窄的矩形框。在矩形框的上下两端分别表示行为或动作的开始和结束事件（用两个执行发生说明（ExecutionOccurenceSpecification）元素定义）
在UML中，执行说明是一个抽象类。具体的执行说明有两种：
行为执行说明（BehaviorExecutionSpecification）：它表示一个行为的执行。这个行为是执行说明覆盖生命线的类型的一个行为。
动作执行说明（ActionExecutionSpecification）：它表示一个基本动作（Action）的执行。这个动作是执行说明覆盖的生命线的类型的行为中的一个动作。
交互使用表示对另一个交互的引用。通过交互使用，可以对交互行为进行分解。
交互使用通过一个左上角有一个“引用”(ref)标签的方框表示，框中可以简单仅仅显示引用的下级交互的名称；也可以显示被引用交互的完整表达式。
除了上述序列图中的常用元素，对于复杂的行为过程，包括循环、并行、可选等，可以通过一个“组合片段”（CombinedFragment）来表示。
组合片段有多种操作类型。其中常用的如下：
可选（opt）：代表一系列可选的事件，如果条件（称为守卫）成立，那么就会在交互的执行过程中发生。相当于程序语言中的“if”条件语句
备选（alt）：代表两个或多个可替换的系列事件，他们会在交互的一次执行中发生。其中只能有一个条件为真的事件发生。相当于编程语言的“if…else if…else…”语句。
循环（loop）：代表一系列事件，只要条件成立，可以在交互的一次执行过程中发生多次。
并行（par）:代表两个或多个系列的事件，他们会在交互的执行过程中并行进行。
其它操作符，请参考MBSES软件的在线手册。（请关注“智睿思维MBSE”公众号，可以随时查看在线帮助手册）
包含一个约束条件，这个约束条件是对生命线的属性、当前范围的变量，或者一个状态的值进行约束。在约束条件满足的时候，继续下面的过程。
状态不变量有两种表示方式。一种是包含约束表达式的一个文本框（如下面的序列图案例中所示）；另一种是像一个状态机图中的状态一样的表示方式，中间是一个状态的名称。这个状态对应生命线的一个状态（这个状态应该也有一个“状态不变量”的约束属性，表示当对象处于这个状态时，某个属性保持不变，所以这个约束才称为“状态不变量”，例如“{状态==工作}”表示工作状态的约束）。
我们还是看一个应用了组合片段的序列图案例。这个案例是我们在“MBSE建模学习之四：活动（Activity）及活动图”中所举案例“执行霍曼转移”活动的序列图表示方式。霍曼转移的原理见这篇文章。序列图如下（来自《SysML精粹》图7.1）：
这个图代表的交互元素是“执行霍曼转移，主成功场景”，它的语境（Context）是“DellSat-77卫星”模块。这个序列图中，有三个生命线。“ps :推进子系统”和“mans :微型自主导航系统”是“DellSat-77卫星”的直接部件属性，而“fc:飞控计算机”是它的部件“通讯和数据处理子系统”的部件属性。
在这个图最外层是一个“并行”的组合片段，分成上下两个并行执行的过程（在活动图中，对应一个分支节点，分出来两个并行的流程）。
在上面的操作域中，又是一个“循环”组合片段，这个循环的组合片段中，不断的根据当前高度计算新的轨道半径，并把包含“当前轨道半径”参数的消息发送回“fc:飞控计算机”。
在下面的操作域中是一个“可选”组合片段。这个“可选”组合片段的守卫条件是“命令是否合法=true”，表示只有当到达的命令判断是合法的情况下，这个组合片段中的过程才会执行。在执行时，按从上到下顺序，首先是发回一个“响应发送(响应)”的异步消息。然后，当系统时间到达“当前命令.执行时间”约束规定的时间的时候，“fc:飞控计算机”向“ps:推进子系统”发送同步消息“点火推进器()”，使推进子系统点火。“ps:推进子系统”执行“点火”的执行说明有一个时间范围约束，规定点火的持续时间（从开始到结束）应满足“2~5分钟”。这时候卫星经过加速后进入一个椭圆的轨道。此时，最外层并行组合片段的上半部分过程一直在重新计算和更新当前轨道半径。当这个轨道半径符合状态不变量规定的条件“{当前轨道半径==当前命令.要求轨道半径}”时，“fc:飞控计算机”向“ps:推进子系统”发送第二次点火消息，卫星再次加速，进入预定的圆形轨道。
已剪辑自: http://www.zhiruisiwei.com/html/articles/article_007.html#main_right
状态机（StateMachine）用于表示事件驱动的行为。在状态机图中，用系统的不同状态之间事件驱动的转移机制来说明一系列的行为发生过程。它一般作为一个模块（Block）的类目行为（ClassifierBehavior）。类目行为是一个类（如模块）从开始工作，一直到结束的整个过程的行为。一个模块只有一个类目行为。它也可以作为模块的一个普通的拥有行为（OwnedBehavior），表示模块的一种功能。
和活动（Activity）一样，状态机同时也是一种模块（Block）元素。一个复杂的状态机行为可以进行分解。在上层的状态机行为中，通过一个“子机状态”（SubmachineState）元素表示对下层或其它状态机的调用。
作为行为，状态机的发生一样需要规定发生的语境（Context）。如果状态机是某个模块的类目行为或拥有行为，则这个模块是状态机的语境；否则它自己是它的语境。状态机中的状态的内部行为（entry、do及exit）如果没有明确的语境，则它们的语境是这个状态机的语境。
状态机是通过状态机中的状态（State）以及状态是如何转换的来说明系统的行为过程。状态机中的状态（State）和转移（Transition）不像活动图中的动作（Action），它们本身并不说明究竟这个行为是如何把一个输入的信息（或其它物质）转为输出的信息（或其它物质）。（动作—Action中，可以通过语句或专用的动作类型来说明对象的生成、变换或删除等）但是，在状态和转移中可以包含其它行为（如一个活动），它可以用它包含的行为来说明具体是转换的细节。状态机更像是把系统的行为串联起来的一种作用，它着重展现的是系统在这个行为之间所处的状态，以及状态是在什么时机，或通过什么机制来转换的（这个时机被定义为触发器，这个机制是触发器的事件）。所以它适合作为系统的整个工作过程的总体说明，例如用来说明系统工作的任务阶段说明。
状态（State）是系统处于某种工作状态一种表示方法。状态除了有一个名称外，状态的“状态不变量”（StateInvariant）属性说明了系统处于这个状态的条件。“状态不变量”是一个约束（约束通常表示为一个等式或不等式），当系统处于这个状态的时候，应该满足这个约束（约束表达式的值应该是True）。
状态并非静态的概念。当系统进入、保持和退出一个状态的时候，都伴随着行为的发生。这三种行为称为状态的“entry”、“do”和“exit”内部行为。这三种内部行为，可以仅仅是一段文字描述（对应一个不透明行为），或者具体活动（Activity）、交互（Interaction）或另外一个状态机元素。这三个行为的发生顺序是：当系统进入这个状态的时候，先执行“entry”行为；执行完毕之后，如果有“do”行为，则执行。当有一个引发状态转移的事件发生的时候，在系统离开这个状态之前，执行“exit”行为（如果此时，“do”还没有执行完，则中断“do”的执行）。
状态用一个圆角矩形表示。其中的文字用“状态名称[状态不变量表达式]”表示。在“智睿思维基于模型的系统工程软件”（MBSES）中状态的内部行为可以通过属性框设置是否显示。下图是“开机”状态的两种显示方式。
有三种具体的状态类型。这三种状态都具有以上状态的这些基本特征。其中，简单状态（SimpleState）代表一个普通的状态。组合状态是可以包含其它状态的状态；子机状态是代表另外一个状态机的状态。在进一步说明其它状态类型之前，先搞清楚状态的转移是如何发生的。
“转移”用一个带箭头的线表示系统从一个状态转换到另外一个状态。转移的发生是由系统中的触发器（Trigger）引发的。在表示转移的线上面，会显示转移的说明文字，这个文字的语法如下：
[ [‘,’ ]* [‘[‘ ’]’] [‘/’ ]]
用中文表示语法表示为：
[<触发器> [‘,’ <触发器>]* [‘[‘ <守卫条件>’]’] [‘/’ <行为表达式>]]
如上所示，一个转移，它可能有一个或多个触发器，一个守卫条件（转移的发生需要满足这个条件，这个条件也是一个约束）。当转移发生的时候，可能还有一个行为发生，称为转移的“影响”属性。这个行为可能是一个活动、交互或另外一个状态机。
一个表示转移的文字示例如下：
“按下开机键[电源状态=有电]/接通电源()” 上面的文字表示系统从关闭状态到开机状态的转移，这个转移的触发器是用户“按下开机键”事件。此时，如果也满足“电源状态=有电”这个约束条件，则转移发生。转移发生后，将进行“接通电源()”这个“影响”行为。
转移也可以有“名称”。如果有名称，在MBSES软件中会显示在最前面，并且用“:”和触发器分隔。但一般情况下，应该把转移的触发条件作为触发器写在触发器属性，而不是名称。
转移的表示方法示例如下
从上面的说明我们可以了解到，状态机中状态以及状态的转移过程都是伴随是具体行为的发生的。造成转移发生的触发器，也是由于其它行为执行过程中产生的事件引发的。下面讲讲触发器
触发器是行为中定义中的一个点，在该点上一个事件的发生可能会产生这种影响。所以，触发器总是和一个事件关联在一起的。表示触发器的字符串，直接使用它关联事件的表达式（虽然触发器也可以有名称，但是在转移中触发器的表达式是直接使用关联事件的表达式，而不用它的名称）。
在进行状态机的仿真运行的时候，需要模拟触发器的触发，才能引发状态的转移。模拟触发的动作，通过选择仿真工具栏中触发器的下拉框。此外，有些触发器是会在仿真过程中由活动中的动作引发的，如“信号事件”触发器，则会通过一个“发送信号动作”引发。这种仿真中自动引发的事件，也会引起转移的发生。
触发器的事件有5种事件类型，分别说明如下：
（1）调用事件（CallEvent）
调用事件是当作为状态机语境的模块的操作（Operation）被调用的时候发生的事件（对一个硬件来说，一个模块的操作被调用，可以理解为启动了硬件的一个功能）。当模块的操作被调用，可能会产生标识这个状态的属性或变量的变化，从而会引发状态的改变。
调用事件是用被调用操作的名称标识的，它的表示语法如下：
::= [‘(‘ ‘)’]
：被调用操作的名称
：可选的显示项，对应被调用操作的参数值。 调用事件一般通过“调用操作动作”（CallOperationAction）（见MBSE建模学习之四）引发。
(2）信号事件（SignalEvent）
信号事件是当作为状态机的语境的模块，接收到一个某种类型的信号的时候发生的事件。信号（Signal）是一种包含有属性的元素，它一般定义为一种有结构的数据类型。一个模块能够接收某种类型的信号，则应该有一个和信号对应的接收（Reception）方法来处理接收到的信号，这个接收的名称和信号名称相同，接收的参数和信号的属性对应。
定义一个信号事件，应该定义它对应的信号元素。信号事件触发器显示的是信号事件的信号名称。信号事件显示的语法如下：
::= [‘(‘ ‘)’]
:信号的名称
信号接收事件可以由“发送信号动作”（SendSignalAction）触发（见MBSE建模学习之四）。
（3）任何接收事件（AnyReceiveEvent）
任何接收事件会显示一个“all”字符串。任何接收事件表示模块接收到任何信号或操作调用的时候都会发生。但是如果这个接收有具体对应的信号事件或调用事件对应，则不会重复的发生。任何接收事件也可以由一个“发送对象动作”（SendObjectAction）引发，所以可以用任何接收事件来处理除了信号事件和调用事件之外的其它任何接收事件。
（4）变动事件（ChangeEvent）
变动事件是当模块中的属性或一个变量的值变动时，符合变动事件给出的条件，则引发这个事件。
变动事件的语法是：
::= ‘when’
即：“when”后面有个结果为布尔值的表达式，当这个表达式的值为“真”的时候，变动事件就引发。
（5）时间事件（TimeEvent）
时间事件是当系统时间符合事件定义的时间表达式的时候，事件就引发。时间表达式的定义有两种，一种是“绝对”时间，一种是“相对”时间。当时间事件的“是否是相对时间”属性等于True时，时间事件表示为“after”+ “时间量”。如“after 5s”，表示系统进入当前状态5秒之后引发此事件。当“是否相对时间”属性等于False时，时间事件表示为“at”+ “绝对时间表达式”。如“at 2021-12-24 18:00:00”；如果时间表达式中没有日期，表示每天这个时间都会发生一次。
一个转移可以有多个触发器，任何一个触发器发生，则转移就会发生。在“智睿思维基于模型的工程软件”（MBSES）中，转移的触发器定义界面如下：
在定义了“调用事件”或“信号事件”后，要通过工具栏上面的“选择操作”或“选择信号”按钮选择在模块中定义的操作或其它地方定义的信号。
组合状态是可以包含其它状态的状态。首先组合状态直接包含一个或多个“区域”（Region）元素，“区域”再包含其它的状态。
状态机也是包含一个默认的“区域”的，状态机中的状态都包含在这个区域中。在一个区域中，只有一个当前状态。不同的区域可以有各自的当前状态。不同区域中的行为是并行的。这种具有多个区域的组合状态称为“正交的”组合状态（是否正交属性=True）。
组合状态中每个区域都有自己的初始状态和终态。当进入组合状态之后，也是先从初始状态开始转移到第一个状态。组合状态中的状态可以直接转移到组合状态外的一个状态。
下图是一个系统简单的状态机图，其中“开机”状态是一个组合状态，其中包含两个状态“加载”和“工作”。
伪状态即状态机图上不是系统真实状态的节点，这些伪状态节点为了表示状态机的开始、结束、分支等等。伪状态有如下几种类型：
“初始伪状态”（InitialPseudostate）：表示状态机的开始。用一个实心圆形表示；如●。
“选择伪状态”（ChoicePseudostate）：类似活动图中的决定节点，从一个菱形节点分支出去多个转移，每个转移有各自的“守卫”条件，只有符合条件的转移才发生。
“连接伪状态”（JunctionPseudostate）：连接伪状态可以有多个“入”及多个“出”的转移。从连接伪状态“出”的转移应该具有不同的触发器及守卫条件。要记住，在一个区域中是不能有多个“当前状态”，所以从连接伪状态一次只能一个转移生效。
“分支”和“集合”伪状态：分支节点从一个状态分支到两个或多个并行状态区域；集合节点合并多个并行的区域。如下所示“分支”和“集合”的应用：
“终止伪状态”（TerminatePseudostate）：用一个来表示，表示某个分支流程的终止。
“深历史伪状态”（DeepHistoryPseudostate）和“浅历史伪状态”（ShallowHistoryPseudostate）：状态历史是和组合状态的区域相关的概念。这个概念可以跟踪从区域中退出时所处的状态配置。当从“深历史伪状态”退出区域，区域再次活动的时候，恢复到区域中最深层次的那个最后状态。当从“浅历史伪状态“退出区域时，区域再次成为活动区域，返回到区域中最顶层的那个最后状态。
“入点”（entryPoint）和“退出点”（exitPoint）：当封装一个组合状态、不允许从其中的状态直接转移进或出的时候，设置一个“入点”和一个“退出点”，只能从外部状态转移进“入点”伪状态，从“退出点”伪状态转移出。
用一个实心环形表示，代表状态机行为的结束。
下图是一个卫星“姿态控制”状态机（参考《SysML精粹》图8.1）的案例。
此图是“姿态控制子系统”的类目行为，即姿态控制子系统的整个工作过程。从初始状态开始，卫星处于“入轨”状态，执行内部行为“自旋稳定”。当轨道转移的时候，退出前执行“exit”内部行为“消自旋”，停止自旋。当轨道转移完成，进入新轨道“捕获”状态，首先“甩动量”，然后“确定姿态”；更新卫星的姿态之后，如果卫星“当前姿态规则姿态”，则转移为“在站”组合状态；否则“转向”（Slew），直到卫星“当前姿态规则姿态”。如果在“转向”状态收到“脱离轨道”命令（产生的触发器），则“姿态控制子系统”工作完毕。“在站”组合状态中常规情况下执行“维持规则姿态”行为。如果此时处于“有通讯链路”状态时，收到新的调整姿态命令（调用了“获取目标(规则姿态) ”操作产生的调用操作事件）转移到“转向”状态，继续调整姿态。如果“无通讯链路”状态超过2分钟，触发时间触发器“after 2 min”，状态转为“安全模式”（或者有“系统错误”事件也转为安全模式），跟踪太阳方位，直到“通讯链路恢复”事件发生，转入“捕获”状态。在“在站”组合状态下，收到“脱离轨道”命令事件，则子系统工作完毕，转为“终态”。
已剪辑自: http://www.zhiruisiwei.com/html/articles/article_008.html#main_right
用例图通过描述用户使用系统提供的某种服务实现一个目标的方式来说明系统的需求。用例图中的元素包括：“用例（UseCase）”，它表示系统提供的功能或能力；“执行者（Actor）”，表示一类用户，或者其它的外部系统、环境对象；“主题（Subject）”，代表系统。图中的主要关系是“执行者”和“用例”之间的关联关系，称为“通讯路径”，表示执行者和主题之间发生的通信，以实现与用例相关的功能。。
用例图中的主要元素“用例”和“执行者”都是一种类目（Classifier，所有类的基类）。这些“类目”一般是放在系统模型的一个包中。所以，用例图代表的元素（用例图的外框）一般是一个“包（Package）”。建立用例图，在模型浏览器中选择一个“包”元素，然后在它下面建立一个用例图，用例图中新增加的“用例”、“执行者”默认是挂在这个包下面。系统中每级产品都可以进行用例分析，而每级产品都可能有很多个用例。系统级的用例称为顶层用例。
下图是一个车辆系统的用例图（来自SysML1.6标准附录D图D.05），图中包括“操作车辆”、“保险车辆”、“注册车辆”和“维修车辆”四个用例，每个用例涉及不同的执行者，图中的方框（用例的主题）代表SUV车辆系统（HybridSUV）。
用例（UseCase）是说明系统功能需求的一种方法。通常用一个动词短语说明系统能够做什么。用例的名称应该从用户的角度，而不是从系统的角度。或者说作为用例名称的动词短语的主语应该是用户。用例的标识法是一个椭圆形。
用例分析是开展系统详细需求分析的一个步骤。在开展系统详细需求分析时，从用户使用系统的目的、场景出发，抽取出系统的用例，也就是用一个动词短语概括出用户使用系统完成的一件事情。识别用例的时候，需要考虑用例的“粒度”。一个系统的用例的数量，可能从几个到几百个。一个用例以能够说明一件完整的事情、一个完整的事件流或者用户和系统之间一次完整的交互为宜。用例有如下几个特性：
（1）独立性。同一层次的用例不需要与其它用例交互而独立完成执行者的一个目的。用例之间没有顺序关系。有执行顺序关系的功能应该合并到一个用例中。但是同层的用例可能会有包含相同的操作，这些相同的操作可以单独提取出来作为一个用例，通过“包含”关系包含到其它用例中。
（2）用例的执行结果对执行者来说是可观测和有意义的。
（3）用例表示的事情必须由执行者发起，不存在没有执行者的用例。 用例不是“功能”。在MBSE的模型中，“功能”（Function）一般对应的元素类型是“活动”（Activity）。当进行系统的功能分析的时候，以及对功能进行分解，建立系统中多层的功能、子功能元素，应该使用“活动”而不是用例。
用例也不是“需求”。“需求”（Requirement）也是SysML语言中的一种元素，专门用于模型中需求的表示（下一篇文章我们将专门的来讲需求）。
“用例”在UML语言中也是一种“类”（BehavioredClassifier，行为类目），就是可以包含“行为”的类。“活动”是一种行为，所以“用例”可以包含“活动”（在软件中建立“活动”或其它行为元素和用例的关系，可以在模型浏览器中通过右键菜单给用例元素添加“拥有行为”）。
用例分析也是需求分析中的一个步骤，它用于对“文字”描述的“需求”进行细化。细化的方法就是建立用例自己的“行为”元素及图（除了给用例添加“活动”之外，也可以使用“交互”或“状态机”及它们对应的图来对用例进行详细的说明）。
执行者（Actor）（也翻译为“参与者”）表示和系统有交互的用户或外部系统扮演的角色。触发用例的执行者叫做“主执行者”。参与用例的执行者叫做“次执行者”。作为执行者的“人”一般用“火柴棍人”作为模板，而外部系统一般用类似“模块”节点模板的方框，方框上面显示构造型“执行者”（actor）。
在UML语言中，执行者也是一种“行为类”（BehavioredClassifier）。所以“执行者”也可以通过“泛化”（Generalization）为用户的“角色”类型进行多层次的建模。“执行者”只能和“用例”、“模块”（UML中包括类“Class”和组件“Component”）之间建立关联关系（Association）。在“执行者”和“用例”之间的关联关系称为“通信路径”。
执行者可以有属性和行为特征。在分析和执行者相关用例的行为的时候，行为中有些活动是“用户”执行的操作，有些活动是“系统”要执行的功能。例如柜员机“取钱”用例的活动中，“插卡”是用户的活动，“输入密码”也是用户的活动；而“验证密码”、“审核余额”、“吐钱”是柜员机系统的活动。
“主题”（Subject）代表拥有用例的系统。“主题”的表示法是一个矩形框，所有用例画在矩形框的内部，所以主题又称为“系统边界”。
当建立代表系统的“模块”元素之后，可以把这个系统模块和主题关联起来，主题矩形框的上面显示系统模块的名称。
“通信路径”是一个双向引用关联（Association）元素。在“MBSE建模学习之二”这篇文章中，我们在介绍模块的属性的时候，介绍过模块之间的三种关联关系。双向引用关联会为被关联的模块生成引用属性。所以“通信路径”会为“执行者”和“用例”生成对应的属性，表示“执行者”的用例是啥，以及“用例”的执行者有哪些。可以为“通信路径”两端的属性节点指定对应的属性名称。在执行者这一端的属性可以指定多重性，表示执行用例的执行者的数量范围。
基础用例是通过通信路径和主执行者连接在一起的用例。
如果多个基础用例的行为中有相同的行为，可以为这部分行为建立一个共用的用例。这个共用的用例用一个“包含”（include）关系和基础用例连接起来（从基础用例指向包含用例），表示这个包含用例将会在基础用例中执行。如果用例不是在多个基础用例中共用，只在一个用例中使用，是没有必要建立包含用例的。
扩展用例是一个用例在扩展点扩展出来的用例。一般是用一个“扩展”（extend）关系从扩展用例指向基础用例。如下图所示：
在这个图中，（飞船系统的）“交会对接”用例有一个“扩展点”。“交会对接”用例执行时，如果扩展条件“当自动方式失效”满足的时候，就会执行“手动对接”用例。
下面我们用一个农业采摘机器人系统的案例来说明用例分析的过程。
（1）利益相关者需求
对这个机器人系统，有如下的功能需求，表格表示如下：
（2）用例图
系统中的执行者“果农”和“果树”我们应用SysML中“模块”构造型，将其建模为“模块”。这样做的好处是“模块”扩展了“类”的属性类型，可以有接口，节点的模板可以显示图片等、各种分区等更丰富的内容，以及可以进行行为的仿真。这些对于系统“用户”的行为分析更方便。
系统的用例图如下，“采摘果实”用例是“果农”发起的一个事情。从果农的角度，这个用例将给“果农”带来收到“果实”这个目标。
（3）用例场景分析
对于“采摘果实”这个用例，我们为它增加一个“采摘果实用例场景”的活动（在模型浏览器上，选择用例，通过右键菜单添加“拥有行为”），通过这个活动的活动图，我们分析这个过程系统需要哪些功能。
在这个活动图中，每个“动作”都使用了“调用行为动作”，对应一个表示功能的“活动”。整个活动场景，表示“果农”对“采摘机器人”进行“开机”操作，然后“采摘机器人”行走到果树旁，识别成熟的果实，摘下果实，然后放入收集框，（当收集框果实达到上限）运送果实到收集点，由“果农”把果实从机器人中收集，完成一次采摘过程。活动图如下所示：
（4）设置需求的跟踪关系
通过一个需求关系矩阵，我们设置用例行为分析中的“活动”对“功能需求的”改善关系，如下图所示：
已剪辑自: http://www.zhiruisiwei.com/html/articles/article_009.html#main_right
需求（Requirement）是一个系统必须或应该满足的能力或条件。当设计一个产品的时候，最初产生的设计概念或要求都是用文字描述和交流的。这些文字化描述的需求最终需要落实到每个设计细节。SysML通过建立文字化的需求元素，以及这些需求元素和系统中其它设计元素（表示功能的行为、表示架构的模块等）的关系，以实现设计过程对中文字化需求的跟踪分析。这种跟踪分析的工作包括需求实现情况的分析（需求覆盖分析）、变动之后对设计的影响分析（需求变更分析）等等。
根据需求说明的对象不同，需求分为“利益相关者需求”和“系统需求”。“利益相关者需求”是反映利益相关者需要的表述，是从用户或其它使用系统的相关人员（包括维护人员、市场人员等）的角度，系统应该向他们提供什么。“系统需求”是系统将要做什么以及必须做到什么程度的表述，是从实现的角度，主要讲给内部设计人员的。需求分析的过程，是先有利益相关者需求，然后经过分析、总结，才产生系统需求。
SysML标准附录中对需求的类型进行了扩展，五种扩展需求的说明如下：
功能需求：代表对系统的功能要求，它将被一个“行为”（如“活动”Activity））满足或改善（Refine，表示更详细的说明）。
性能需求：表示系统或系统中的部件的能力应该达到的定量要求。通常用一个约束来更具体的说明（改善），被一个表示系统或部件能力的值属性来满足。
物理需求：表示系统或部件的物理特征或物理约束，被一个表示具体结构的元素来满足。
接口需求：表示对系统或系统部件的端口的要求，被一个端口、连接器、项目流或约束属性满足。
设计约束：它表示对系统或系统中的部件给出的一个约束，例如“系统中的某类部件必须使用商业货架产品”，被一个具体的模块或部件满足。
上面所说的关系可以通过下面一个需求图来说明：
如上所述，为了实现需求跟踪和分析，SysML中定义了6种需求关系。
跟踪关系：用于建立一种可追踪的需求路径，可以被后面这几种更具体的需求关系代替（其它需求关系是从跟踪关系继承的）。
复制关系：从需求文本总是和主需求文本相同。这个关系用于同一个需求说明在不同的需求层级被重复使用的情况。从需求不用输入文本，它总是会和主需求的说明保持一致。
导出需求关系：导出的需求来源于被导出需求。一般用于建立“系统需求”和“利益相关者需求”之间的关系（请注意：这个关系应该是从“系统需求”指向“利益相关者需求”，就是箭头端是在后者，它表示“系统需求”是从“利益相关者需求”导出的。一些资料中将“导出需求”关系翻译为“继承”或“派生”都是错误的。“继承”或“派生”都是子类自动具有父类的所有特征，而导出需求关系只是表示导出的需求和来源需求之间有一个“推导”的关系，两者的描述内容可能是差距很大的）。
改善关系：用一种更具体、更详细的方式说明了被改善的需求。例如用一个用例、用例的活动场景来改善一个需求的说明。
满足关系：建立具体的设计元素实现了一个需求的关系。
验证关系：建立测试方法和需求之间的验证关系。测试方法在模型中一般是一个活动或其它的行为，SysML中建立了一种构造型“测试用例”来标记这些专门用于验证需求的行为（测试用例不是“用例”，而是具体的行为）。
下面这个模型图中举出上面所述的各种关系：
需求图是展示需求元素的图。需求图的代表元素一般是一个包，需求图中顶层的需求元素属于这个包。在需求图中最常见的表示方法是用需求包含关系把各层需求连接成一棵树。包含关系表示需求的分解关系。把一个需求逐步分解为更细、更具体的需求项目，也是需求分析的常规工作。进行需求覆盖分析的时候，如果是按组进行统计，则下层子需求全部满足了，上层需求就认为也满足了；如果是按“独立”的统计方式，则不考虑上下层需求之间的包含关系。在需求图中也可以显示其它元素，然后用其它6种关系把这个元素和需求连起来。但为了更方便的建立需求和其它元素的关系，软件工具中一般用“矩阵”表格的方式建立和显示需求和其它元素的关系。
下图是一个表示需求分解的需求图。
除了用图，软件工具中也经常提供表格的方式来显示和管理需求。表格一般也展示为一棵树的形式。如下所示上面需求的表格表示方式。
在需求表格中，还会有需求导入、导出的功能，可以和其它系统进行需求数据的交换。
在MBSE建模工作中，有多个工作阶段涉及需求。系统建模的开始工作，就是从建立利益相关者需求。经过用例分析、功能分析，进一步总结出系统需求。再经过系统架构分析，最终形成能够作为机械结构或电子电路设计输入的物理需求。
（1）建立利益相关者需求。利益相关者需求可能来源于市场调研、参考已有系统、用户的意见、合同中规定的研制要求、售后产品故障维修记录等。利益相关者需求也可能是在一个专用的需求管理系统中已存在，导入到我们系统工程建模软件中即可。而且，这些需求也未必是一开始就非常全面和完备的。我们进行需求分析的过程，也是不断补充、完善需求的过程。甚至一开始我们连一条需求都没有，通过后面用例分析才抽出来利益相关者需求也是正常的过程。
（2）建立用例。我们通过上一个文章已经了解到，用例是进行需求分析的重要工具。利益相关者需求和用例是“多对一”的关系，就是一个用例可以和多个利益相关者需求建立关系。可以用“跟踪”关系、“改善”关系，或者“分配”关系建立利益相关者需求和用例之间的关系。不建立用例和需求的关系、直接建立用例的行为和需求的关系也可以，这个和使用的方法论有关。
（3）建立用例的活动场景，开展系统功能分析。用活动图建立用例的活动场景，分析功能性的需求必要性和充分性。在这个过程中如果发现新的功能需求，补充到利益相关需求。同时，这个过程又是抽取系统需求的过程，就是分析以满足利益相关者需求为目的，系统应该提供什么功能需求。
（4）建立系统需求。从如何实现、满足利益相关者需求的角度，结合用例的活动场景分析，抽出系统需求条目。系统需求是否是可行的、充分的，也是需要在后面的架构设计过程中不断完善。在整个模型中，需求应该和满足需求的设计要素一一对应。
（5）建立满足系统需求的架构模型。
（6）提取进行机械结构、电子电路、工艺或嵌入式软件设计的物理需求。
从利益相关者需求到建立系统需求、物理需求，整个系统建模过程都是一个需求不断更具体、更细化的过程。通过系统架构的设计分析，系统性能参数的分配和分析，逐步生成子系统的需求，以及开展机械结构设计、电子电路设计的物理需求。
在整个系统建模过程中，通过建立需求和需求、需求和其它设计元素之间的关系，可以跟踪需求变动对设计的影响，统计建模工作的完成度。
例如利益相关者需求到功能分析的关系，通过一个需求改善关系矩阵，设置用例行为分析中的“活动”对利益相关者需求中“功能需求”改善关系，如下图所示：
利益相关者需求改善关系的覆盖分析，按组统计，结果是66.66%，如下所示：
查看没有被改善的需求项，可以看到，是“自主行走”需求没有进行用例及功能分析，没有改善关系。因为是“按组”统计，“总需求”下面如果有一个子需求没有被改善，就认为它也没有被改善。需求数量的统计，是包括最上层的“总需求”，所以总数是6个，2个没有改善，总的改善率是“66.66%”。
已剪辑自: http://www.zhiruisiwei.com/html/articles/article_0010.html#main_right
参数图是SysML增加的一种专门用于系统参数计算的图。参数图本质上是一个特殊的内部模块图，它主要表示模块的约束中的参数和模块的属性之间绑定关系。这里“绑定”的意思，可以理解为变量的“代入”。参数图中通过绑定连接器把值属性和约束的约束参数连起来，参数图仿真的时候就把值属性的值代入到约束的表达式方程中进行计算，并把计算结果返回到对应的属性。不过这个“属性值”和“约束参数值”代入计算、结果再返回到“属性值”的概念，是通过仿真过程类型的实例化、属性（property）生成“槽”（slot），对“槽”赋值来实现的。以下我们通过参数图中的各种元素的意义、仿真的实际过程来说明这个原理，以及如何进行仿真。
SysML的仿真方法是对“类”模型的实例化。我们建立的“模型”主要是建立了一套“类”以及它们相互的关系。在SysML中，对系统建模主要是使用“模块”（Block，是对类–Class的扩展）类。仿真过程中所谓的实例化，是生成用户建立的“模块”的实例。在模型中，用“实例说明”（Instance Specification）来表示一个实例。“实例说明”的“类目”是这个模块，“实例说明”的“槽”（Slot）对应模块每个属性。每个槽有一个“值”，这个“值”又是对应属性的类型的实例。如果属性有默认值的话，当生成槽的时候，这个默认值作为槽的初始值。如果在内部模块图中指定了属性的初始值，初始值比默认值优先。
下面这个案例中定义了“电动牙刷系统”，它有五个子系统。在这图中，我们定义了一个“可靠性指标参数容器”，所有系统和子系统都从这个容器继承，这样所有产品都自动具有了可靠性指标属性，不用每个定义了。
当“电动牙刷系统”模块实例化的时候，生成“电动牙刷系统实例”，这个实例说明中的“槽”和属性对应如下图所示：
在表示类型的“模块”中，属性是用“名称:类型=默认值”这样表示的。而“实例”中，和属性对应的每个槽是用“属性名称=值”这样表示的。在本文第一段中，我们说“属性值”的时候，实际上是指“模块”对应“实例说明”中属性对应槽的值；“把值属性的值代入到约束的表达式方程中进行计算，并把计算结果返回到对应的属性”这句话其实是把“模块的实例说明的槽的值代入到约束的表达式方程中计算，并把计算结果重新赋值给和属性对应的槽”。
在SysML中增加了“约束模块”这种元素，它的作用是保存一套通用的计算方程，这个方程可以在模型中被复用。
首先我们解释以下准备建立的约束方程的物理意义。我们建立的“可靠性指标参数容器”中的属性解释如下：
可靠度：一个0~1之间的概率值，表示系统在规定的条件下完成规定任务的概率；
任务时间：系统执行一个任务的时间，一般用小时作为单位（为了简化模型，在这案例中我们都用实数作为属性的类型，而没有定义具体值类型。以下MTBF和失效率情况相同）；
MTBF：系统平均故障间隔时间，一般用小时；
失效率：系统单位时间内发生故障的次数。
对于失效数据符合指数分布的产品（一般电子产品符合指数分布），这几个指标之间有如下关系：
（1）失效率=1/MTBF，即失效率和MTBF是倒数关系；
（2）可靠度=exp（-1失效率任务时间），“exp”是“e的指数”，即“e的（-1失效率任务时间）次方”的意思，e是自然常数。
“系统”和作为组成部分的“分系统”之间可靠度一般是按串联计算（所有分系统的功能对于系统来讲都是必不可少的，不是备份的关系）。针对我们上面建立的“电动牙刷系统”来讲，电动牙刷系统的可靠度等于各子系统可靠度的连乘，写成公式就是：
（3）“R=R1R2R3R4R5”（R对应电动牙刷系统的可靠度，R1~R5对应每个子系统的可靠度）
我们把上面三个公式建立为三个约束模块，如下图所示：
在约束模块中，“约束”属性如果是一个公式，就要用“{}”把公式括起来（否则认为是下一层的约束模块）。“约束”公式中用到的变量，只能是“参数”中定义的约束参数（约束参数本质上也是一个“属性”，可以认为约束模块是只包含约束参数属性、约束属性或约束表达式的模块）。“约束”表达式既可以是等式，也可以是不等式。如果是一个等式，在参数图仿真中把它当一个赋值语句来应用。
要计算系统的可靠度，我们需要先计算出来每个子系统的可靠度，然后使用系统可靠度计算公式来计算系统的可靠度（根据每个子系统的MTBF计算系统的MTBF：指数分布串联系统的MTBF等于所有子系统MTBF之和，再用单元计算可靠度的方法计算系统的可靠度也是可以的）。计算子系统的可靠度，使用单元可靠度计算公式、失效率计算公式。我们通过定义子系统的参数图来应用这两个公式。我们先定义一个子系统“无线充电底座子系统”参数图，如下图所示：
在这个图中，我们增加为子系统增加了两个“约束属性”，然后设置它们的类型为我们前面建立的约束模块。然后通过这两个约束属性节点的右键菜单“显示>显示/隐藏约束参数”来在约束属性节点中显示作为其类型的约束模块的约束参数。然后在图中添加“值属性”节点，并通过右键菜单“选择已有属性”设置为“无线充电底座子系统”中的值属性。其中“可靠度”、“任务时间”、“失效率”都是继承的属性，不需要修改。“MTBF”属性不“选择已有属性”，而是新增加的，它“重定义”了继承的属性“MTBF”（继承的属性前面有个符号，重定义通过属性框设置），因为我们要给它一个默认值“60000”（小时）。定义这个属性的名称、类型、默认值，可以直接在值属性节点中输入就可以，或者通过属性框设置。
图中我们还用“绑定连接器”把值属性和约束属性中的约束参数连起来。绑定连接器上显示一个“=”号，它的意思就是总是要保持两端的属性的值相等。
其它4个子系统的参数图基本相同。在“智睿思维基于模型的系统工程软件”中不需要每个子系统重新画这个参数图，只要在模型浏览器上选择这个图的节点，“复制”；再选择其它四个子系统节点，右键菜单“粘贴”，把这个图复制四份就行了。其它四个子系统中仅仅是“MTBF”属性的默认值不同，在这四个图中选择“MTBF”属性节点，通过属性框或直接修改节点中的文字修改MTBF的默认值（无线充电受电子系统的MTBF=65000，UI子系统的MTBF=58000，电路控制子系统的MTBF=48000，电动子系统的MTBF=50000）。
为模块“电动牙刷系统”建立一个计算其可靠度的参数图，将每个子系统的可靠度和系统的可靠度属性同计算系统可靠度约束公式中的约束参数绑定，通过参数图仿真计算可以计算系统的可靠度。这个参数图如下：
图中“可靠度:Real”是电动牙刷系统的属性，“s1.可靠度:Real”是图中增加值属性节点后、右键菜单“选择已有属性”时选择“电动牙刷系统”的部件属性“s1：无线充电底座子系统”的“可靠度”值属性；其它“s2~s5.可靠度：Real”也是其它四个子系统的可靠度值属性。
在模型浏览器上选择“电动牙刷系统”、右键菜单“仿真>运行”（活动当上面这个参数图打开时通过主工具栏“分析>开始”进行仿真计算），即可进行电动牙刷系统参数图仿真计算。在软件中会出现一个显示仿真结果的“变量”窗口，如下所示：
这个窗口中有“电动牙刷系统”的可靠度属性仿真结果：0.913816042044195；约束“:系统可靠度计算公式”下面有这个约束计算时用到的每个约束参数的结果。可以通过工具栏“保存该实例”将仿真结果保存到模型中。这个结果是一个类型为“电动牙刷系统”的实例，上面这个变量表中是这个实例的每个“槽”的值。
已剪辑自: http://www.zhiruisiwei.com/html/articles/article_0011.html#main_right
包图是定义模型架构的图。模型的架构主要是通过“包”（Package）来组织的。包图的代表元素是一个“包”元素（元素-Element，是指模型中任何一种数据），图中定义的元素默认的命名空间就是这个包。除了“包”之外，包图的代表元素也可以是一个“模型”（Model）、“模型库”（ModelLibrary），或者是一个“概要文件”（Profile）元素。
包图经常用来定义整体的模型架构，也就是模型的层级关系。这种情况下，包图中一般显示的元素是各层级的“包”或其它作为类型的元素。也可以在包图中直接定义各种类型元素，例如通用的“模块”（Block）、“值类型”（ValueType）、“接口模块”（InterfaceBlock）等。这时候，包图和模块定义图的作用并没有太大差别（模块定义图的代表元素一般也是一个包）。在智睿思维基于模型的系统工程软件中，你只需要切换包图的默认图形工具栏为模块定义图的工具栏，就可以在包图中添加各种类型。另外，包图也可以定义扩展标准模型元素的构造型，为标准元素添加建模时的构造型属性。
例如，下面的包图定义了MagicGrid方法论中“问题域”的模型架构（我们接下来会用几篇文章详细说明MagicGrid方法论，敬请关注公众号）
包的作用是用来组织模型中元素数据，相当于元素数据存放的一个目录。包是包中元素的“命名空间”。“命名空间”是为了唯一标识一个模型元素的空间，在一个“命名空间”中，不允许元素的名称重复。例如，在一个房子中每个人的名字是唯一的，在一层楼中每个房子的名称（编号）也是唯一的。再向上，这个大楼、小区等各层空间的名称都唯一，这样就可以建立一套唯一的路径名称。SysML中模型元素的命名原理就是这样，包含了所有各层命名空间路径的名称称为元素的“完全限定名称”（fully qualified name）,各层路径用“::”分隔。例如在上面的包图中，“电功率”模块的完全限定名称是“1 问题域::黑盒::3 系统上下文::交换项目::电功率”。 除了包之外，其它很多元素也可以用作“命名空间”。例如“模型”、“模型库”、“概要文件”和包类似，相等于一个文件夹。“模块”也是一个命名空间，它是模块中的属性或方法的命名空间。
在SysML图中显示的元素并不一定就是这个图的代表元素包含的元素。根据模型说明的需要，经常也会显示其它包中的元素。当元素的命名空间不是这个图的代表元素（默认命名空间），也没有关系能表示这个元素的命名空间的时候（例如命名空间包含关系，或者在另外一个包的内部显示），这个元素就会显示“完全限定名称”，就是包含了一长串路径的名称。有时候，显示了太长路径的名称也不利于显示和阅读模型。这时，可以建立一个“包导入”关系（公有或私有），将名称很长的元素“导入”到当前图代表元素下面。这时候，被导入的元素就只显示名称了。下面是解决方案系统架构图中显示逻辑架构中模块的例子，为了建立和显示两个架构之间的抽象映射关系（解决方案架构中模块应该都有逻辑架构的模块对应），左图是没有导入关系的视图，右图是建立了导入关系后的视图（在MBSES软件中，模型浏览器上包节点可以通过右键菜单直接建立包导入关系，也不一定要显示到图中）。
模型库是指一套通用的、可以重复使用的元素。这些元素通常用“模型库”元素作为它们的命名空间。“模型库”就是这样一种专门存放模型库元素的“包”。
在实施MBSE的过程中，需要将那些通用的、或者以后会重复使用的模型作为模型库管理起来。在新产品研制、建模的时候，引用这些通用的或已有的模型，会使建模工作起到事半功倍的效果。当然，万事开头难，刚开始应用MBSE技术需要打基础的过程。打好基础了才能见到成效。
一般企业实施MBSE，需要建立这些模型库：
（1）企业通用的值类型、单位模型库。产品的性能参数属性一般建为模块的值属性。如果这个性能参数具有专业的工程意义，需要建立对应的值类型及单位。企业建立统一的库，可以在每个项目中使用，避免重复。
建模软件中一般也有通用的库。最基础的值类型库就是SysML标准中的“基本数值类型”（PrimitiveValueTypes）库，这个库中包含最原始的数据类型，有“Real”（实数）、“Integer”(整数)、“Boolean”(布尔，值只能是True、False这样数据)、“Complex”（复数，有实部、虚部）、“String”（字符串）。更复杂的值类型，需要从这些基本数据类型继承、再定义。
在SysML标准的附录中有“ISO 80000”国际标准计量单位库，包含各专业常用的值类型和单位。（有需要这个库的用户请微信联系“智睿思维MBSE”18022886980获取）。
其它企业专用的值类型或单位，需要建立企业自己专用的模型库。
（2）专用的约束模块库。约束模块是包含可重用的参数图仿真公式的模块。企业在进行系统性能指标分析的时候，通用的约束公式可以建立为模型库，在任何项目和产品上可以使用。通用的约束模块模型库，是经过仿真验证是正确的方程。使用通用的库，避免每个人自己去花时间写公式和验证公式。
（3）通用的标准模块。这些模块是在多个项目或产品中共用的标准部件。建立一次，然后抽取出来作为模型库，可以重复使用。
为什么MBSE的技术路线有多种，而以UML\SysML建模语言的方法论和技术路线成为主流？是因为UML\SysML语言超强大的扩展能力和系统性。我们知道，SysML是从UML扩展来的，SysML本身就是一个应用于系统工程技术领域的“概要文件”。“概要文件”表示一套标准的扩展定义的模型库，是包含了一套扩展元素定义的“包”。
构建概要文件的主要元素是“构造型”。“构造型”类似一个“类”（在UML自身描述语法中，它是从类继承的概念元素），它有“属性”。定义了一个“构造型”，当把它应用在已有概念元素上，是生成一个这个构造型的实例，定义这个实例具体的值，并附加到原先这个概念元素上来给它增加新的属性或意义。
我们来看看在SysML标准中对“Block”(模块)的定义：
“Block”本质上是对类扩展的一个构造型，增加了一个“isEncapsulated”（是否封装的，True的话表示这个模块是一个黑盒子，外部的连接器只能连到它的端口上；False的话可以连接到它内部）构造型属性。当我们在图中定义一个“Block”的时候，其实是定义了一个“Class”（类）并应用了“Block”构造型。例如定义了一个“M8汽车”模块，图中显示如下：
构造型“«block»”会显示在上面，构造型的属性会显示在“{}”中。
如果对已有概要文件或原始的UML模型元素进行扩展，可以定义新的构造型。从已有构造型继承，或直接扩展UML元素。例如下面定义一个“«汽车»”构造型，定义了“设计阶段”、“类型”的构造型属性。把这个构造型应用到上面的“M8汽车”，为它增加专用的模型属性。构造型属性可以显示在专用的分区中，也可以只显示在节点的头部。
要区分构造型的属性和“模块”类本身属性的差别。构造型属性在建模的时候就确定了具体值、可以输入值和保存值。“模块”类本身的属性是在实例化的时候才有值。例如这个“M8汽车”模块，有一个“重量”的值属性，这是在对模块仿真、生成它的实例的时候才有具体值。在上面这个例子中，“类型”属性其实也可以是“汽车”类的值属性（当建模的目的是为了车辆信息的管理的时候）。但是当我们的目的是为了设计车、明确这个模型是某种类型的车（如“电动车”）的模型，它的模型会具有一些专门的特征或要求（“电动车”的模型应该有电池模块，工作原理应该用“电”来驱动）的时候，我们把它作为构造型属性。
对某种专业的应用领域，对模型标准的扩展可能还需要专门的视图、建模方法去支持。这时候可能还需要对建模软件的功能进行对应的二次开发。随着MBSE应用技术的不断发展，可能会出现很多专用技术领域的扩展UML\SysML的建模标准及软件工具。
