基于模型的系统工程（MBSE）宣告了一个全新沟通与实时模型协作时代的到来。它带来了一个核心理念：模型不再是一柜子文档，而是一台能运转的机器。 这台‘机器’能够承担实际工作，如验证需求、针对复杂数学与物理方程生成参数化仿真、运行可执行状态机、仿真业务流程与决策逻辑、根据评审意见迭代更新模型，还能自动生成配套文档。这些优势的实现，既得益于 Enterprise Architect 的强大功能，也归功于建模时使用了一种标准化的共享语言——系统建模语言（Systems Modeling Language），通常简称为 SysML。
SysML 让人类和机器都能读懂模型——人类负责贡献创造力、工程智慧和设计，而机器则负责处理那些枯燥且容易出错的任务（比如验证），承担繁重的体力活（比如生成参数化仿真和进行假设分析），以及执行一些相对琐碎的日常工作（比如搜索和生成报告）。
掌握这门建模语言并非无需付出成本，但学习过程完全可以轻松顺畅，不必经历挫败，也无需部分怀疑论者口中所谓的 “语言天赋”。Enterprise Architect 也会成为你学习这门语言的好帮手，它不仅内置了许多辅助学习的功能，还提供了一个丰富且完备的模型模式库，助你轻松上手，确保你从一开始就能创建出符合行业最佳实践的模型。
当你开始使用Enterprise Architect时，你会立即轻松融入一个庞大的国际用户和从业者社区，他们日复一日地使用该工具，规范、设计、实施并支持用于解决现实问题的系统工程模型。许多问题和机遇复杂且看似难以解决，但可以通过建模者协作，应用SysML来表达和解决问题。
Enterprise Architect通过其丰富的桌面和云平台无缝促进这种协作，确保模型既稳健又富有表现力，这不仅是单个工程师和其他利益相关者共同协作的结果，无论他们说什么自然语言、使用什么设备或身处世界何地。
5.1 语言架构
系统建模语言（SysML）本质上是一组常规符号，允许人类与工具就系统工程进行交流。它是一项国际标准，定义并描述了一种通用的系统工程建模语言。Enterprise Architect 是全球领先的工具之一，实现了该标准，使系统工程师能够应用所谓的基于模型的系统工程方法。此外，Enterprise Architect还提供支持工程实践和管理中各种辅助方面的工具功能。我们将在整个指南中探讨这些有用且高效的工具功能。
SysML 基于另一标准——统一建模语言（UML），自90年代末以来被软件工程师采纳和使用。这很重要，因为许多系统工程项目涉及系统和软件两个方面，因此系统工程师和软件工程师能够相互理解模型，从而提高透明度、错误发生率降低和语言结构互通，从而降低系统故障或出现故障的可能性。这幅维恩图展示了两种标准之间的关系。SysML重复使用用例图、活动图和时序图。
需求驱动
系统建模语言（SysML）的创建是基于用户需求;SysML 的设计响应了系统工程统一建模语言征求建议书中的需求。本文件规定了UML在系统工程（SE）领域的定制化，并要求这种定制应支持对各种系统的建模，这些系统可以包括硬件、软件、数据、人员、流程和设施。文件中写道：
“UML的系统工程定制应支持复杂系统的分析、规格、设计和验证，具体包括：
Enterprise Architect的设计者详细阅读了这些文档及由此产生的SysML规范，创建了一个复杂且极易用的工具，实现了所有这些需求，并增加了丰富的附加功能，以确保组织的工程和业务成功。
要让语言变得有用且相关，它必须根据用户社区的需求不断演变。为此，SysML 规范会定期更新，Sparx Systems 团队也不断更新和扩展 Enterprise Architect，以确保其符合不断演进的标准，更根本地满足用户社区的多样化需求。
统一建模语言的重用与扩展
系统建模语言（SysML）建立在统一建模语言（UML）之上。UML已被对象管理组（OMG）批准并采纳，OMG继续作为规范的管理者。2005年，国际标准化组织（ISO）也将UML作为认可的ISO标准发布。该语言为建模软件中心系统提供了规范。SysML 语言可追溯到2001年，起源于一个开源规范，但当国际系统工程理事会（INCOSE）开始与 OMG 合作时，OMG 于2006年采纳了 SysML 的最终版本。
在许多方面，SysML理论上是更原始的语言，因为它是一种通用建模语言，而UML则更为专业化，专为建模软件为中心的系统设计。然而，历史和语言的起源颠覆了这一立场。实际上，SysML 是利用 UML 配置文件系统创建的，是 UML 的一个扩展子集。这意味着 SysML 并未完全采用 UML，同时还定义了一些额外的语言结构。我们在前一节看到的维恩图用数学方式描述了这两组交集的语言构念。
Enterprise Architect 对 SysML 规范的实现高度合规，开发者与规范紧密合作，并与行业专家、思想领袖及各行业的系统工程社区保持持续沟通。这造就了一个世界级的工具，不仅实现了规范，还提供了多种额外工具，如可执行状态机、参数化仿真、甘特图、看板、思维导图、战略模型以及数百个其他功能。
此外，系统工程与软件工程问题及解决方案在多个学科中持续增加，从铁路系统到航空系统、能源系统等。Enterprise Architect因其强大的功能支持这两个学科，同时也作为建筑工具的优势而具有独特优势。
用包分区
包是该语言中划分的基本单元，旨在防止循环依赖。该语言被正式划分为一组模型元素，这些元素逻辑上被分组，使语言用户能够将这些元素理解为一组语言单元。
它们也是用户定义模型中的基本结构单元，作为一种通用机制，用于根据用户定义的因素对元素进行分组。形式上，它们可以用来指定命名空间，这在某些建模构造中非常重要，比如定义XML模式或代码生成。包可以在浏览器窗口或图示中创建和查看，两个位置都提供了不同的处理包的方式。图表有助于可视化显示包内容，或描述包之间存在的关系。
Architect 提供了多种方式在图中显示包，帮助用户理解包与其包含的元素和图之间的结构关系。当包裹被包含在图表中时，工具允许用户从多种显示选项中选择，并可更改区间可见性以显示包裹内容。在这张图中，作者想展示两个在极不可能发生碰撞时具有意义的包内容。在元素区间可视化中已选择“显示包内容”选项，清楚显示每个包包含哪些元素。
同样的软件包及其内容可以在浏览器窗口中查看，但需要记住，虽然可以在报告等出版物中包含这些图表，但浏览器窗口的内容在这些文档中是看不到的。
互操作性与模型交换
Enterprise Architect 是领先的 SysML 工具之一，具备必要的功能，但设计者意识到，组织需要使用多种工具来完成二十一世纪每个组织面临的复杂业务和工程任务。为确保重要的工程和业务信息能够与其他工具和平台交换，系统提供了丰富的模型交换支持，符合ISO 10303-233数据交换标准，以支持其他工程工具之间的互操作性。该功能基于UML XMI交换能力实现，该功能在工具包层支持，允许任何包及其包含的层级与其他合规工具交换。
Enterprise Architect 更进一步，提供了与多种业务、项目管理、分析和项目交付工具的交换机制。这在建模工具层面实现，支持使用CSV文件格式交换电子表格中的数据，以及文字处理机中的文本。参考数据如优先级、状态、复杂性、约束等列表，以及词汇表、角色与作者、日历等数据，都可以从仓库导入和导出。
在地理位置几乎是每个项目和举措的重要环节中，地理空间信息构成了关键数据集。Enterprise Architect 提供与领先的地理空间建模工具的数据交换，使得两个原本分散且异构的数据集能够共同查看和管理。
5.2 关键语法概念
SysML和其父语言UML一样，是一种视觉语言，其中图表是语言通信策略的核心。尽管该语言的重点在于这种可视化编码和思想传递，但它也具备文本表达思想的功能，这对视觉机制来说是重要的补充。许多元素，如需求元素，具有视觉形式，但需求的细节则写在称为需求“文本”的属性中，如图所示。
Enterprise Architect 也经过精心设计，尊重不同用户处理信息的方式。设计团队与其用户社区紧密合作，意识到有些用户更适合图表可视化，另一些则更适合文本。Enterprise Architect 中的许多工具都是为这类不同类型的用户设计的。例如，在需求管理领域，用户通常更熟悉文档和电子表格的工作。为此，Enterprise Architect 提供了多种视图，用户可以切换到这些视图，通过这些界面录入、编辑和管理需求。其中一个工具是规范管理器，它提供了一种灵活且熟悉的方式，从基于文档的视图和电子表格视图中处理需求，使需求能够轻松地查看、创建和管理。
5.3 模型、图表、元素与视图
模型
“模型”这个词被过度使用且意义过多。有些人用模型来表示整个模型库，而另一些人则用它来指代完整模型库的一个部分。本质上，模型是模型库中的结构性划分。
图表
SysML 规范定义了九种图表类型。这是标准列表，SysML还定义了每个图中通常使用的元素。许多新手甚至一些有经验的用户并不知道，尽管这些元素列表描述了某种图表类型的常用元素，但这并不妨碍建模者在这些图表中使用其他元素。事实上，在同一图中使用多种元素类型可以形成一个富有表现力的模型，并使来自不同学科的利益相关者和工程师能够理解模型之间的图示间联系。
在本节我们还将了解到，规范建议将若干“通用”模型元素纳入任何图示中，包括注释、约束和依据。该图展示了一系列元素类型，包括模块、用例、需求和测试用例，所有元素都在一张模块定义图（BDD）表示。
如前所述，系统建模语言规定了九种不同类型的图表。
元素
前面介绍的这九种图表各自都有明确的规范，旨在传达工程机遇或解决方案的某个特定方面；例如，参数图旨在就是专门用来展示方程是如何构建的。然而，有许多类型的元素是模型项目通用的，可以出现在任何类型的图表上。这些元素通常被用于向模型添加重要的批注，或者帮助解释模型的某个特定方面。它们包括注释、约束、依据和视图等元素。在这张图中，一位一直在查看模型的利益相关者添加了评论，以对模型中的某一部分提出疑问。
虽然Enterprise Architect高度符合SysML规范，但它拥有许多协作功能，允许管理此类评论，例如通过其讨论功能。这使得讨论能够与构成模型的具体元素分开进行。这张屏幕图片展示了通过讨论功能添加的同一评论，该功能允许回复和其他多种协作工具。
回复者也可以发送模型邮件，邮件中可能包含指向EA元素或图示的链接，如图所示。
当用户打开邮件时，可以跟随链接打开链接中提到的图表。这是一种有用的机制，允许动态和实时地引用和访问建模信息，而非静态文档中的图像。这张图展示了打开链接时工具中会显示的图表。
连接不同建模领域的元素是Enterprise Architect作为团队和学科统一平台的巨大优势之一，这一点在业务战略与工程、软件开发与工程之间的关系中尤为明显。结果是一个一致且协调的模型，显著减少了不同团队间接缝导致的断层可能性。
视图
从根本上讲，系统是为利益相关者构思、分析、设计和构建的。系统工程师收集利益相关者的关注点和诉求，并应用分析来制定需求和约束条件。这些信息作为分析和设计的输入，以及系统交付前进行验证和核查。利益相关者需要能够可视化其利益在工程流程各阶段如何被满足，这种可视化可以通过视图和视点来实现。视图和视点的概念在ISO-42010（前身为IEEE-1471）中有明确阐述，SysML规范的编写则与ISO-42010标准保持一致。有许多常用的视点，包括：
视点是构建一个视图的规则或规范，旨在满足特定利益相关者的需求、利益和关切。视图是利益相关者从特定视点看到的内容，它应使利益相关者能够直观地了解系统中与他们相关的部分，同时滤掉或隐藏那些不感兴趣的系统方面。
除了 SysML 规范中描述的视图和视点元素形式的形式机制外，EA还拥有多种工具，帮助创建和管理视点、视图和表示。有多种工具可用于创建模型库中元素的不同视图；这些包括工作集和模型视图。工作集允许将一组图表、矩阵、模型库及其他项目作为一组保存并重新打开，这在与不同利益相关者群体协作时非常有用。
模型视图可用于创建元素的分组视图，无论它们在浏览器窗口中的位置如何。还有一些工具可以隐藏或遮蔽图表的部分内容，使其对特定受众更具吸引力。通过改变元素的外观（包括使用图像）可以改变图的外观，图表过滤器可以过滤或隐藏元素。文档引擎可以直接从模型生成高质量的出版物，格式为 pdf 或 docx。
