基于模型的系统工程（MBSE）已成为复杂系统管理和工程化的宝贵方法。它从文档中心的方法转变，使模型能够用于多种用途，包括需求规范、设计、权衡、架构、验证、确认、仿真与支持等。
这些模型起到了“保险”的作用，能够防范工程中的重大失误，并有助于降低在规范、设计、测试、实施和支持阶段的高故障成本。
当你使用Enterprise Architect进行基于模型的系统工程（MBSE）时，会开启一种全新的思考和工作方式。Enterprise Architect 是一个严谨的协作平台，允许广泛的利益相关者分享想法、问题、解决方案和实施，包括：
模型还可实时开放，供用户通过安全的浏览器界面进行查看、贡献、审查和讨论，利用协作的力量创建稳健且完善的架构和设计。
在本指南中，我们将探讨许多EA的功能，这些功能可以帮助个人工程师、团队、组织乃至整个行业领域达到创新主导且技术变革前所未有的时代所要求的实践和绩效水平。本指南将为系统建模语言提供背景介绍，并展示如何在EA中创建这些语言结构。它旨在让语言和工具的新手通过这个工程与协作平台，接触系统工程领域中所有可能的知识。用17世纪著名物理学家艾萨克·牛顿爵士的话说：
“如果我能看到比别人更远的，那是因为我曾站在巨人的肩膀上。”
Enterprise Architect提供了一个实现这一愿景的平台，通过协作功能以及诸如模拟和自动化之类的设施，工程师能够发现机会、设计解决方案并构想未来。
Enterprise Architect为系统工程师、技术架构师及其他希望将建模和仿真工作与MATLAB、Octave、OpenModelica等工具结合起来的人士提供了主要功能。JavaScript引擎中的“求解器”类和丰富的数学库为仿真能力提供了显著扩展。
1、一个四变量方程
本指南的标题暗示只有两个学科需要学习：
然而，采取这种方法时需要考虑四个方面。这就像一个包含四个未知数的方程，每个未知数都必须解决，团队才能在MBSE项目或项目中取得成功。方程中的变量为：
这四个方面并非必须立即掌握，但重要的是了解并着手研究它们，团队应培养理解它们及其相互关系的能力。例如，如何使用Enterprise Architect创建SysML需求图，应包含哪些属性，何时创建以及应与模型的哪些其他部分相关联。
MBSE方法=流程+语言+建模+工具
指南将涵盖所有这些问题，读者最终不会遇到未知变量，而是基于所学知识而确定的数值，从而解出我们最初提出的包含四个变量的方程。至此，读者将朝着扎实的工程建模实践迈出坚实的一步。
1.1 工程方法或流程
系统建模语言不依赖于任何特定的流程，可以与任何方法或流程一起使用。对于语言新手来说，这一点有时不被理解，他们期望它应具规范性，明确说明应创建哪些元素、图表和模型，以及何时创建。这种“不依赖于特定流程”的立场提供了极大的灵活性，并使该语言能够以适用于流程和底层问题或解决方案领域的方式被使用。
作为系统建模语言的一部分所定义的元素、连接器、图表以及语言定义，都是专门为让工程师能够创建以下模型而创建的：
团队用于创建、管理和传播工件的流程完全是任意的，必须在组织或团队层面进行定义。
系统工程通常需要协作或多学科的方法，团队协作以产出满足利益相关者需求的成果。任何流程两个重要方面：
然而，这两个流程显然需要接触点，以确保整体使命以及项目的目标和宗旨得到实现。
Enterprise Architect 允许使用任何类型的流程，无论它是正式定义的、标准化的还是内部定制的。Enterprise Architect 内还有一些功能，允许定义、发布和共享定制流程。
一个强有力的团队
Enterprise Architect 提供了多种工具，帮助团队无论地理位置如何，或时间和距离如何分隔，都能协作。该产品从零构建为协作平台，使工程与非工程、技术与非技术利益相关者能够在协作且集成的结构中协作。
该存储库可以基于云端，用户可以在全球任何地方安全连接，有效地创建虚拟团队。这对于一些本地缺乏专业知识或项目本身是全球性的项目来说非常重要。用户和团队可以使用讨论、聊天、审查和模型邮件等协作功能来协作。最终的结果将是协作式的架构与设计，这并非单个工程师的成果，而是众多智慧的结晶，而且其效果将超过各个部分的简单相加。
这些工具之所以有效，是因为它们能够用于对模型、元素和图表进行标注，从而使用户能够像在同一房间里的白板上共同协作那样进行工作。
模型库是另一个方便的协作工具，允许任何类型的文件被包含在仓库中，或通过超链接和/或指向其网站外部位置的URL列出。标准、规范、指南、指导、示例、导师及其他材料等文档都可以在模型库中编目。
还有多种其他工具可以促进团队合作，包括图片管理器、日历、发布、看板、项目管理功能等。本示例展示了一个看板图，可用于直观展示敏捷团队在开发系统物理或软件组件时所进行的工作内容。
1.2 建模作为一门学科
大多数人，包括系统工程师，通常觉得写一个主题的长篇描述比简明扼要的总结更容易——这类似于建模的挑战。
问题不在于包含什么，而是该省略哪些内容。
基于模型的系统工程的一个优势恰恰在于此——它鼓励工程师创建描述性强、清晰且简洁的模型。文档流程中冗长（有时还杂乱无章）的句子被清晰简洁的图表取代，清晰地描述了系统的需求、结构和行为。
有人将模特描述为一门封闭的学科，并将其视为身穿紫色长袍的炼金术士工程师所实践的“黑魔法”之一。这也导致了建模在我们大学中很少被教授，且缺乏大量相关文献，使得建模看起来像一门神秘的艺术，而非它本质上是一门可以学习的科学。
模型有多种不同类型，包括：
在本指南中，我们最关注抽象模型，因为它们是我们通常会使用Enterprise Architect和系统建模语言创建的模型。
这些模型——顾名思义——是对现实的抽象，旨在突出实体、子系统或系统中最重要的方面，同时省略从该视角来看不重要或无关的内容。
入门指南
抽象模型是以一种帮助我们推理、无需亲眼看到真实事物的方式来表现现实世界的表现。通常模型更小，是系统或其部分的简化视图。也可以创建一个只关注系统某一方面或方面的模型;例如，飞机的通信或导航系统。
建筑是一种复杂的结构，包含多种不同的系统，包括结构、电气、通风、管道、景观等。
通过构建多个模型，我们能够简化每个子系统的视图，从而更容易理解建筑的这一方面。模型本身也需要相互协调。例如，电气模型中表示的电力系统必须为通风系统中模拟的空调设备提供电力。人类利用模式需要与景观模式进行协调，以确保花园和景观能够满足居住者及其访客的休闲需求。
模型通常会被多个不同的利益相关者审视，这些利益相关者在被建模的系统部分中通常扮演着截然不同的角色。为了确保模型对特定利益相关者有用，可以创建表示从特定视角观察模型时所看到的视图。
建筑的电气模型对多个利益相关者都很有用，他们对系统的看法各不相同，包括电力系统主管、安全检查员、电工和采购人员。
定义模型的目的
对于习惯于以文档为中心方法的团队来说转向基于模型的系统工程带来了许多挑战和陷阱。最常见的陷阱是在没有清晰理解或定义模型用途的情况下开始建模。
与以文档为中心的建模方法相比，定义模型的目的比定义一套文档的目的更为困难。模型的实用性与有效性要远超文档，而且能够完成基于文档系统无法想象的工作。基于模型的方法的一些优点包括：
该图展示了如何在工具中可视化和管理可追溯性，让你看到模型各部分如何相互关联，以及元素如何形成连接图，帮助你描述和理解你的模型。
Enterprise Architect 利用了 SysML 的强大功能，以及一套专门为系统工程经理、系统工程师及其他利益相关者设计的工具，从而提供了简单而有效的途径，以利用基于模型的系统工程方法。
采用基于模型的方法还能带来其他诸多显著优势，包括确保项目和工作计划能够以严谨、高效和富有成效的方式执行，同时借助这种工具还能促进卓越和协作。
决定从哪里开始
对于刚接触基于模型的系统工程的工程师来说，建模过程可能相当令人生畏。显然，最重要的是从哪里开始建模——这在某种程度上就像是艺术家面对的“空白画布”所带来的困扰。
Enterprise Architect 为这个问题提供了令人满意的解决方案，提供了一系列可用于创建项目起点的模式，包括所有 SysML 图型类型及其对应的若干模式。
教科书通常描述一系列应按规定顺序执行的步骤，但实际上这些方案行不通，因为项目远比书中描述的通用方式复杂得多，且复杂的项目和资源依赖关系导致任务无法按规定顺序完成。
起始点通常会由用于该项目的工程方法或流程所决定，这可能是瀑布式流程、迭代式流程、两者结合的流程，或者是其他类型的流程。无论采用何种流程类型，明确了解项目目标往往是一个良好的起点，而确定受影响的利益相关者及其关切点和需求通常又是接下来的一个好步骤。
模型的连接部分
系统建模语言鼓励工程师创建一系列模型，对于那些对基于模型的系统工程还不熟悉的新手或初学者而言，这些模型可能会让他们觉得是对系统进行了割裂式的描述。实际上，SysML描述了一个模型网络，每个模型针对特定问题，但相互连接，以描述系统及其各部分的整体。
在这个图例中，我们看到了一张极具说服力的企业架构图，它通过特定的元素和连接器（即需求、活动和块，通过“分配”关系）来展示模型各部分之间的联系。这些元素可以在任意数量的图表中重复使用，而且在一个位置更改其属性会自动更新到所有情境中。利用多种功能可以快速、轻松地创建图表，并且它们可以以多种方式可视化，例如列表、表格和电子表格。这些图表可以进行筛选，也可以用图形图标替换元素，以增加非技术人员的参与度。
这正是基于模型的系统工程方法的真正优势，因为它允许系统以多种方式被观察，从完整且高层次的视角到多层分解或层级。每个层级相互关联，模型中的任何缺口或断层都能被轻易识别出来，并能找到补救方法。
确保模型质量
模型的质量最终会反映在它所代表系统的质量上。Enterprise Architect 旨在为创建和管理高质量协作模型提供平台。该软件具有许多有助于模型设计者达到所需质量水平的功能，包括以下方面：：
这张图展示了模型模式的实际应用，无论是初学者还是有经验的建模者，只需按下一个按钮，就能利用丰富的行业最佳实践模型库——全部符合SysML标准——创建结构良好的模型和图表。书中还详细解释和讨论了如何使用该图、在哪里可以获得进一步帮助等。
1.3 系统建模语言（SysML）
系统建模语言（SysML）的定义旨在以一致、高效且稳健的方式表示系统工程中的问题和解决方案或工作规划。
SysML 旨在提供简单但有效的构造，用于建模各种系统工程问题和解决方案。它可以用于多种用途，但在指定系统属性的需求、结构、行为、分配和约束方面尤其有效，以支持包括参数化分析和仿真在内的工程分析。SysML可以与多种流程和方法结合使用，如结构化、面向对象、迭代、瀑布式以及其他多种方法。
该语言经过十多年设计和增强，适用于日益复杂的系统建模。这些变化使得原本相对简洁明了的语言变得更加广泛和多样化；然而，大多数系统工程项目仍可以通过该语言的一部分（我们可称之为“核心 SysML”）来实现建模。
1.4 Enterprise Architect 建模工具
Enterprise Architect 不仅一个模型库，还是协作平台，是基于模型的系统工程项目的高效工具。它使团队成员（包括项目发起人、工程经理、客户和工程师）能够在严谨且高效的环境中协作完成项目。通过WebEA和Prolaborate，协作可以在“手机”、“平板”和笔记本电脑等移动设备上继续进行。
在信息与创新时代，我们需要一种工具来发挥其更广泛的作用，而不仅仅是用于存储信息或让用户查看图表和模型。企业架构师已经接下了这一挑战，并将其系统工程产品提升到了一个新的高度，其采用了诸如以下的工具：
使用 OpenModelica 或 Simulink 进行参数化模拟，使模型变得生动起来，能够将复杂且往往难以解决的问题以可视化的方式呈现出来并进行分析，从而支持权衡分析和工程研究。
在本例中，对控制液体在两个储罐之间流动的各因素之间的关系定义如下：
然后，可以使用先进的 OpenModelica 仿真功能对这些模型进行仿真。
协作平台
信息时代几乎在我们毫无察觉的情况下就已转变为创新时代，而如今这种转变愈发明显：团队必须以全新的、紧密协作的方式开展工作。如今，通过磁盘共享文档和文件以及使用静态图表进行工作，这些场景已不再是我们在现实生活中所能见到的了。具有响应性、强大且创新性的解决方案只能通过使用卓越工具的团队来实现，这些工具不仅能够构建模型并促进协作，还能完成实际工作。企业架构师是一个多功能的工具包，它能让团队进行协作，将来自众多相互关联的学科的最优秀人才和最有经验的人员聚集在一起。参与更新和查看模型的人员可能分布在不同的地理区域，处于不同的时区，来自不同的组织，甚至使用不同的自然语言。
此图展示了“开始”功能区中提供的部分实用协作功能。此外，通过 WebEA 和 Prolaborate 还可进行讨论和审查，这使得建模人员和非建模人员能够进行协作，从而生成更可靠且符合实际需求的解决方案。
项目管理工作台
Enterprise Architect 提供了多种工具用于管理基于模型的系统工程项目。通过这种方式，它可以作为一个项目管理工作台，用于管理工程项目。整个系统生命周期都可以在该工具中建模，从业务需求的概念化，到设计、实施、利用、支持，最终到系统的退役或处置。
有甘特图、日历、模型库、风险、缺陷、任务、工作量和指标登记等。路线图是另一个宝贵的功能，使项目经理能够可视化项目从当前状态到任意数量的过渡或未来状态的发展过程。
团队还可以通过内置的看板系统进行协同工作，这些看板允许在正在进行的过程中可视化需求、用户故事、缺陷和变更等项目。资源分配和属性（如优先级和状态）可以通过板块条目查看，并且还会显示超量限制的信息。
这一起源于日本汽车行业的成熟技术已被EA应用，极大提升团队及其项目管理的生产力。
模型仓库
Enterprise Architect 主要是一个模型存储库，支持模型从创建到退役的全生命周期管理。该仓库存储在关系数据库中，该数据库可以部署在客户端-服务器架构中，也可以作为云服务设施的一部分，无论是在本地还是非本地的云环境中。所以即使建模者会处理图表和可视化元素，这些图表都会被编码并存储在仓库数据库中。该仓库可以包含任意数量的模型，并可按企业级或项目级模型进行组织，以支持复用。
