MagicGrid 知识手册(一)
Modeler
译者注：该手册原文是由NoMagic公司发行的针对MBSE的MagicGrid方法论介绍，主要以其公司的MagicDraw软件为使用对象，采用SysML语言，提供了MagicGrid方法框架及一个详细的分步教程。本人主要是在学习使用MagicGrid方法论时觉得有所困难，所以对该手册进行了粗翻，部分专业术语可能不标准，更多可参考《SysML精粹》这本书以及NoMagic公司官网信息，评论区置顶有英文原手册下载链接，欢迎大家一起学习进步。
正文如下：
Aiste Aleksandraviciene
Aurelijus Morkevicius, Ph.D.
MagicGrid® 知识手册
使用MagicGrid进行系统建模的实用指南
翻译by海尔赛姆
Kaunas, 2018
Copyright© 2018 by No Magic, Inc.
未经No Magic, Inc的事先书面许可，不得以任何形式或任何方式复制本出版物的任何部分。所有其他商标均为其各自所有者的财产。
Enrique Krajmalnik 的前言
在过去三年中，产品的设计方式发生了重大变化。随着智能产品和交付系统的出现，对敏捷产品开发的需求从未如此强烈。公司现在正在研究如何将设计和构建作为产品生命周期的一个组成部分。工具不再是事后的想法，系统工程不再是由几乎没有可追溯性或更改控制的文档和电子表格主导的次要实践。向具有系统模型通用标准符号的集成工具的过渡正在进行中，将系统工程的严谨性提升到一个新的水平。基于模型的系统工程 (MBSE) 是新范式的核心。
MagicGrid Book of Knowledge (BoK) 侧重于从业者如何实施 MBSE。 开发 MagicGrid 的目的是提供一个框架，该框架可以轻松采用、实施和修改，以随着您的建模和系统工程实践而增长。本书教您如何使用 No Magic 软件来设计和优化当今和未来的系统和产品。 这是多年研究的结晶，我很自豪能够将 No Magic 这个名字放在这一努力的背后。
感谢让这一切成为现实的 No Magicians，特别是我们的解决方案团队，他们与客户进行了数千小时的接触，以学习、消化、开发和教授这个框架。我还要感谢我们的合作伙伴和客户，他们在发布之前为这项工作的同行评审做出了贡献
— Enrique Krajmalnik,
CTO, No Magic, Inc.
Aurelijus Morkevicius 的前言
MagicGrid BoK 是一种独特的、基于模型的系统工程体验。本书描述了从头到尾开发系统模型的百万种可能的直接方法之一。它回答了您可能遇到的所有问题，从“为什么”开始到“如何”结束，当今可用的信息来源很少能回答这个问题。
当我10年前开始 MBSE 培训和咨询时，我想到的第一件事是缺乏使用 SysML 开发系统模型的明确方法。每个客户都在以不同的方式开发模型。此外，每位顾问都使用不同的方法来培训客户这门学科。SysML 曾经（现在仍然）因为与方法无关而受到批评，这应该不足为奇。除了在 No Magic 内部发起内部讨论，并开始以框架的形式收集和总结我们的经验，以便使用某种“普通”SysML 构建系统之外，别无他法。首先是框架，然后是适应语言。我确信这是与 SysML 100% 一致的唯一方法。扩展和定制是可能的；然而，它们不是必需的。
在收集知识的同时，我在当地一所大学做了一些科学研究，以证明我的想法是正确的。 我与 No Magic 的团队一起撰写了几篇论文，并在全球各种活动中发表了多次演讲和教学，例如 INCOSE 国际研讨会、INCOSE 当地分会活动和 No Magic 世界研讨会，等等。媒体的宣传和很多积极的反馈，使我有了信赖感和自信去致力于MagicGrid的工作。
在与来自不同行业的多个客户合作后，我同意这个问题没有单一的统一方法，也不可能有一个。 每个行业和每个客户都有自己的特点，我们已经考虑到了这一点。MagicGrid 已经发展成为最佳实践的基础和集合，可以对其进行修改或扩展以支持特定的客户需求。这种方法中获得的专有技术深受 INCOSE 手册、ISO/IEC/IEEE 15288、统一架构框架（以前称为 UPDM）和开发工作的影响。影响我们工作的公司包括庞巴迪运输公司、康斯伯格国防和空域公司、福特汽车公司、约翰迪尔公司、BAE 系统公司，以及我个人和No Magic 团队成员和同事近年来一直与之合作的许多其他公司。
我很自豪除了 MagicGrid 框架之外，我们还设法整理了一个详细的分步教程，并将其作为书籍和电子书出版。请注意，这本书只有在您的帮助下才能变得更好。请不要犹豫与我们联系并提供您的反馈，以使本书的第二版变得更好。
我希望这本书将成为所有在黑暗中航行的 MBSE 实践者的灯塔，为那些在阳光下航行的人带来微风。
— Aurelijus Morkevicius, Ph.D.
Author of the Idea
Head of Solutions, No Magic, Inc.
贡献者
- Andrius Armonas, Ph.D. andrius.armonas@nomagic.com
- Barry Papke, barry.papke@nomagic.com
- Donatas Mazeika, donatas.mazeika@nomagic.com
- Nerijus Jankevicius, nerijus@nomagic.com
- Rokas Bartkevicius, rokas.bartkevicius@nomagic.com
- Saulius Pavalkis, Ph.D. saulius.pavalkis@nomagic.com
- Zilvinas Strolia, zilvinas.strolia@nomagic.com
审稿人
- Antonio Tulelli
- Arnaud Durantin
- Atif Mahboob
- Bernhard Meyer
- Bryan K. Pflug
- Carmelo Tommasi
- Christian Konrad
- Darius Silingas
- David D. Walden
- Gauthier Fanmuy
- Himanshu Upadhyay
- Holger Gamradt
- James Towers
- Jonathan Jansen
- Macaulay Osaisai
- Oliver Nagel
- Olivier Casse
- Paolo Neri
- Pierfelice Ciancia
- Raymond Kempkens
- Sagar Nirgudkar
- Sven Degenkolbe
- Thomas Eickhoff
- Timo Wekerle
- Toshihiro Obata
- Ulf Koenemann
前言
1.1 为什么是这本书？
任何理论都需要实践。当公司提供有关如何在实践中使用它的全面说明时，该方法就会变得有用。No Magic 为MBSE提供的MagicGrid 方法也不例外。这是写这本书的主要原因。
所以如果你是 MBSE 的新手或者想学习一种新的 MBSE 方法，这本书适合你。如果您想学习如何将 No Magic 软件与 SysML 和新的 MBSE 方法结合使用，这本书是为您准备的。如果您需要全面的指导，这本书是为您准备的，并通过对易于理解的现实世界系统建模的案例研究来说明。
如果您熟悉 UML/SysML 和用于 MBSE 的 No Magic 软件的基本概念，则本书更易于阅读；即一般称为建模工具的Cameo Systems Modeler或MagicDraw，上面安装了SysML插件。
1.2 为什么是 MagicGrid？
在与国防、汽车、航空航天和医疗保健等各个行业部门的组织合作时，出现了为 MBSE 开发新方法的想法。他们需要一种明确的方法来使用 SysML 开发系统模型，SysML 是 MBSE 的事实上的语言，由国际系统工程委员会 (INCOSE) 定义。但是，当时市场上有很多MBSE方法，而且现有的方法过于抽象，无法解决现实世界的问题。实践还表明，每个行业和每个客户都有自己的特点，不能在不对其进行任何修改或扩展的情况下使用标准方法。
MagicGrid 方法是通过总结众多 MBSE 采用项目的经验而发展起来的，它是最佳实践的基础和集合，可以修改或扩展以支持特定的客户需求。
该方法在实践中完全适用，原因如下：
- 它与“简朴的”SysML 完全兼容。不需要针对 SysML 的任何扩展。
- 它清楚地定义了建模过程，该过程是基于系统工程过程的最佳实践。
- 它与工具无关，只要该工具支持 SysML。
1.3 MagicGrid 101
正如标题所示，MagicGrid 方法基于框架，可以表示为 Zachman 风格的矩阵（见下表），旨在指导工程师完成建模过程并回答他们的问题，例如“如何组织模型？”、“建模工作流程是什么？”、“在该工作流程的每个步骤中应该生成哪些模型工件？”、“这些工件如何链接在一起？”等等。
如您所见，该方法包括系统模型中问题域、方案域和实现域的定义。它们与 ISO/IEC/IEEE 15288 定义的过程保持一致，如下所示：利益相关者需求开发过程中的问题域、体系结构定义过程中的方案域以及设计定义过程中的实现域。每个域都表示为 MagicGrid 框架的一个单独的行。代表问题域的行分成两部分，以表示应该通过从黑盒和白盒的角度查看感兴趣的系统 (SoI) 来定义问题域。代表方案域的行分成许多内部行，以表示可以在多个详细级别中指定系统的解决方案架构。代表实现域的行没有拆分，也没有像上面的行一样完全突出显示，以传达此域中除需求规范之外的所有内容都不是 MBSE 的一部分，因此出现在 MagicGrid 方法的范围之外。
每个定义域包括要在模型中考虑和捕获的系统的四个不同方面。这些方面与 SysML 的四大支柱相匹配，即需求、行为、结构和参数。它们表示为矩阵的列。
某些行和列交叉处的单元格表示系统模型的一个视图，它可以包含一个或多个演示工件。 演示工件可以是框图、模型、分布图或表格。
虽然框架中没有传达，但可以为单个问题提供多个解决方案架构。在这种情况下，会进行权衡分析以选择最佳解决方案进行实现。请注意，权衡分析以及专业工程和集成测试不包含在本书中。然而，这些是 MagicGrid 方法的可能扩展，将包含在本书的未来版本中。
1.4 案例分析
在本书中，建模方法适用于车辆气候控制系统 (VCCS) 的规范和设计。所提出的实际解决方案的技术准确性和可行性并不是高优先级。
1.5 如何阅读这本书
在阅读本书时，重要的是要理解它并不会取代建模工具文档本身，它旨在补充。
本书的结构与 MagicGrid 框架的布局相对应。它分为三个主要章节，每个章节都描述了单个域中的建模工作流程。它们是问题域（包括黑盒视角和白盒视角子章节）、方案域和实现域。你应该连续阅读它们。
每章由多个小节组成。小节以相关域的单元格命名。这些小节的顺序定义了该域中的建模工作流。有些小节以后缀命名，例如“initial”和“final”，表示相关单元中的建模分为两个阶段，该单元的呈现工件在final阶段交付；例如，B3. System Context: initial和B3. System Context: final，而B2. Use Cases介于两者之间。每一小节都包括一个简要的概述，来解释单元中建模的目的、谁负责建模、如何建模以及后续单元是什么。
每个小节（除了少数）由多个子小节组成，这些子小节提供了如何在相关单元中建模的综合说明。因此，它们都以模板“Step X”作为前缀，其中“X”代表步骤序列号。一个子小节提供了问题的答案，例如“做什么？”、“为什么要做？”和“如何做？”。按照这些说明从头到尾自己创建 VCCS 的示例模型。
一些子小节包含标有符号的信息框。这些框旨在为您提供更多信息、更智能建模的提示和技巧，或对更详细信息源的引用。
所有关键字和首字母缩略词都在词汇表中定义。
1.6 如何提供反馈
我们感谢读者对本书下一版本的任何反馈。给我们发送电子邮件至 magicgrid@nomagic.com。
