MagicGrid 知识手册(四)
Modeler
1 实现域
1.1 简介
在定义了整个系统的解决方案架构并选择了最佳系统配置（通过权衡分析）之后，系统就可以实现了。此时，您应该开始将系统视为真实的，不再是抽象的，就像您在问题域和域所做的那样。
如下表所示，MagicGrid 框架仅覆盖了部分实现域。该方法定义了正在实现的系统的物理需求规范，但其详细设计不是 MBSE 的一部分，也不是 MagicGrid 方法的一部分。系统的详细设计是基于模型的设计 (MBD) 的一部分，可以使用电气和机械 CAD 软件或自动代码生成工具等工具进行开发。
1.2 物理需求
它是什么？
为了能够实现一个系统，您首先需要了解该系统的详细物理需求，以便在对其进行详细设计时遵循它们。详细的物理需求基于所设计系统的解决方案架构，包括其所有子系统甚至更具体部分的解决方案架构。
物理需求规范提供给各个学科的工程师，他们负责设计正在实施的系统的不同方面。
谁是负责的人？
在典型的多学科系统工程团队中，正在实施的系统的物理需求由需求团队指定。
如何建模？
在建模工具中，物理需求规范的一项可以存储为 SysML 需求，它具有唯一的标识、名称和文本规范。物理需求必须是正式的，并按照某些准则写下来，例如，只写简短而清晰的句子；避免使用条件关键字，例如 if、except 等；使用 shall 关键字；并包括表格。有关如何编写良好的文本需求的更多信息，请参阅 INCOSE 系统工程手册。
管理物理需求类似于管理利益相关者需求和系统需求。就像它们一样，物理需求可以分类和梳理成组、子组等。SysML 支持多种需求类别，例如物理、功能和性能，仅举几例。对于分组需求，使用它们之间的包含关系。捕获分组项的 SysML 需求本身可能没有任何文本。如下图所示，该图显示了Cooling System的物理需求示例，有四组需求：Electronics & Electric，Mechanics，Thermodynamics，和 Generic Characteristics。您还可以看到，所有项目都分为功能、物理和性能需求。
物理需求应源自方案域中定义的系统、子系统或组件需求。每个物理需求必须至少涵盖系统、子系统或组件需求中的一项。为此，您可以使用从物理需求指向系统、子系统或组件需求项的 «deriveReqt» 关系。有了不同领域需求之间的派生关系，您可以轻松地从非常详细的需求追踪到非常抽象的需求，并查看哪些项目决定了其他项目的创建。为了执行此类影响分析（下游或上游），我们建议使用需求推导图(Requirement Derivation Map)的基础结构，这是建模工具中预定义的关系图之一（您可以在下图中看到一个示例）。
此外，每个物理需求都应该从方案域模型中改善一个或多个元素。为此，您可以使用从物理需求指向方案域模型中的某些结构或行为元素的 «refine» 关系。为了建立和审查这些关系，我们建议使用需求改善矩阵(Refine Requirement Matrix)的基础结构，这是建模工具中预定义的依赖矩阵之一（示例如下图所示）。如您所见，物理需求规范尚未完成，因为方案域中的某些元素尚未根据任何物理需求进行改善；例如，诊断(Diagnosing)和关闭(Off)状态。此外，在现实世界的情况下，物理需求不应该改进方案域中的任何元素。例如，PR-2.2.1 Pulley Belts和PR-2.4 Sound Level需求。在这种情况下，要么必须修改和更新方案域模型，要么必须审查和改进物理需求规范以符合方案域模型。
Tutorial
教程的步骤与steps of the S1 initial phase tutorial相当：
- Step 1. 为 S1.initial创建和梳理模型
- Step 2. 为系统需求创建图表
- Step 3. 指定系统需求
- Step 4. 建立对利益相关者需求的可追溯性
- Step 5. 建立对问题域模型其余部分的可追溯性
下一步是什么？
- 当您有正在实现的系统的物理需求时，您就可以开发系统的详细设计了。是时候切换到基于模型的设计了，以便专注于系统的不同方面，例如机械、电气和软件组件等。这些活动超出了 MagicGrid 方法的范围。
未来工作
感谢您花时间阅读 MagicGrid BoK 的第一版。您对本书的反馈非常受欢迎。在发布本书第二版之前，所有评论都将被考虑在内。此外，你们每个人都可以注册成为MagicGrid BoK第二版的评论者。请通过发送电子邮件至 magicgrid@nomagic.com 表达您的兴趣。
除了我们将获得的评论外，我们还计划扩展 MagicGrid BoK 的范围。本书的第一版是我们将 MBSE 实践工作扩展到更广泛范围的起点。本书的主要重点是向读者介绍一种新的、经过实践证明的开发系统模型的方法。然而，模型开发只是基于模型的系统工程的众多方面之一。我们希望在 MagicGrid BoK 的未来版本中解决其他方面，例如模型管理和模型使用，仅举几例。
词汇表
Action
一个 SysML 元素，可以捕获活动中系统功能的基本单元。它表示在系统运行期间执行活动时将发生的某种形式的处理或转换。动作表示为圆角矩形，名称显示为该矩形内的字符串。
Activity
一种行为 SysML 元素，可以包含一组模型元素，例如动作和流，以及表示这些元素的活动图。
Activity diagram
一种行为 SysML 图，可用于描述控制流或动作之间的输入和输出流。活动图可用于指定预期系统功能的黑盒和白盒场景，并结合状态机图来设计系统行为。
Actor
一个 SysML 元素，当它与特定上下文中感兴趣的系统交互时，它可以捕获一个人、一个组织或另一个系统所扮演的角色。但是，MagicGrid 方法建议使用block而不是actor来捕获这些概念，原因在 B3.initial 中描述。
Association
一种 SysML 关系，使您能够指定哪些actor在特定系统上下文中与感兴趣的系统交互以调用或参与用例。关联的符号是实线。
Binding connector
一种特殊类型的 SysML 连接器，用于在参数图中表示约束参数和值属性之间的相等关系，以传达约束参数接收来自该值属性的值。绑定连接器的符号是实线。
Black box / white box
黑框代表系统的外部视图。在从黑盒的角度进行系统分析时，系统是从输入和输出的角度来看待的，而不知道系统的内部结构和行为。
白框代表系统的内部视图。在从白盒角度进行系统分析期间，执行系统的功能分解以识别功能模块，也称为系统的逻辑子系统或组件。
Block
一个 SysML 定义元素，可以捕获系统结构的基本单元。模块被表示为一个矩形，在名称分隔栏中的«block»名称前面有一个元类型模块。
Block definition diagram (bdd)
一种结构化的 SysML 图，可用于定义模块的特征和模块之间的关系，例如关联、泛化和依赖关系。它根据属性和操作以及系统层次结构或系统分类树等关系来捕获模块的定义。模块定义图可用于指定系统或子系统的结构，并定义该系统或子系统的接口和约束。
Call behavior action
一种特殊类型的 SysML 操作，可以调用另一种行为：活动、状态机或交互。调用行为动作使您能够将较高级别的行为分解为一组较低级别的行为。
Composite association / Directed composition
一种特殊类型的 SysML 关联，使您能够指定一个模块是另一个模块的一部分。复合关联的符号是两个模块之间的实线，复合端有一个黑色菱形，组件端有一个空心箭头。绘制模块之间的复合关联会为出现在关系的黑色菱形端的模块创建一个part属性；part属性可以有一个名称，并由出现在复合关联的箭头端的模块输入。
Component
系统结构的基本对象。Component通常被分组为系统的子系统；它们是通过分解这些子系统来识别的。一个Component可以被捕获为模型中的一个模块。
Connector
一种 SysML 关系，用于表示 ibd 中两个part属性之间的通信。可以通过各种端口（只要这些端口兼容）在part属性之间建立连接器；例如，通过代理端口连接的两个part属性表明它们交换了一些物质、能量或数据，这些物质、能量或数据可以通过连接器通过兼容的代理端口在它们之间流动。绑定连接器的符号是实线。
Constraint block
可以捕获约束表达式（方程或不等式）的 SysML 定义元素。约束表达式使您能够约束模块的值属性。约束表达式的变量称为约束参数。这些约束参数从被约束的值属性中接收它们的值。约束模块的符号与模块的符号相同，但在元素名称前带有«constraint»元类型。
Constraint parameter
出现在约束模块的约束表达式中的变量。它被捕获为模型中约束模块的属性，并在该约束模块的参数分隔栏中表示为字符串。
Constraint property
在某些模块的上下文中使用约束模块，或者换句话说，由模型中某处定义的约束模块输入的模块的属性。它可以表示为 bdd 中该模块的约束分隔栏中的字符串，也可以表示为参数图中的圆角矩形。在这两种情况下，约束属性的名称都显示为一个字符串，后跟一个冒号，以及输入该属性的约束模块的名称；例如，mass : totalMass。
Control flow
一对动作之间的一种 SysML 关系。控制流使您能够表达在相关活动中执行操作的顺序。控制流表示为带有开放箭头的虚线。
Decision/Merge
决策(Decision)节点标志着活动中可选流程的开始。它表示为一个空心菱形，并且必须有一个输入流和两个或多个输出流。
合并(Merge)节点标志着活动中可选流程的结束。它被表示为一个空心菱形，并且必须有两个或多个输入流和一个输出流。
Exchange item
定义可以在系统内的两个结构对象之间流动的物质、能量或数据类型的概念；例如，在 ibd 中捕获系统子系统的两个part属性之间。可以将交换项目捕获为模块或信号，然后将其作为项目流分配给连接器。在这种情况下，连接器上有一个实心三角形。
Flow property
接口模块的属性。它可以有一个方向和一个类型。流属性的方向指定该属性是表示模型内结构对象的输入还是输出。
Fork/Join
分支(Fork)节点标志着活动中并发流的开始。它表示为一条线段（水平或垂直），并且必须具有单个输入流和两个或多个输出流。
集合(Join)节点标志着活动中并发流的结束。它表示为一条线段（水平或垂直），并且必须有两个或多个输入流和一个输出流。
Function
由系统或系统的某个部分执行的将输入转换为输出的任务。可以将单个功能捕获为模型中的活动。
Functional block
用于定义负责执行系统的一个或多个功能的结构对象的概念。通过执行系统的功能分解来识别功能模块。功能模块用作定义感兴趣系统结构的输入。它们也可以称为功能分解的不同层次的逻辑子系统或逻辑组件。
Functional decomposition / Functional breakdown
将系统的整体功能分解成更小的部分的一组步骤，以识别功能模块。
Graphical User Interface (GUI)
一种用户界面，允许使用图标或其他视觉指示器与电子设备进行交互，而不是仅通过命令行使用文本。
High-Level Solution Architecture (HLSA) model
方案域模型的核心。根据问题域分析的结果，它定义了所设计系统的子系统（作为单级层次结构）。HLSA 模型的目的是识别工作包，每个子系统一个工作包，并将它们分配给不同的工程团队。有关详细信息，请参阅Solution domain。
Interface
连接系统或系统的两个或多个结构对象及其环境中的对象的硬件或软件组件，用于将物质、能量或数据从一个传递到另一个。
Interface block
定义的 SysML 元素，可以包含一组流属性，这些属性将模型中捕获的某些结构对象的输入和输出定义为模块；例如，系统、子系统或组件。接口模块的符号与模块的符号相同，但在元素名称之前有«interfaceBlock»元类型。
Internal block diagram (ibd)
一种 SysML 结构图，可用于根据属性和这些属性之间的连接器来捕获模块的内部结构。模块定义图可用于指定系统上下文和系统内的交互。
Measurement of Effectiveness (MoE)
作为SoI在数值格式中的一个特征，MoE 是系统工程中广泛使用的传统术语，描述了系统在特定环境中执行任务的能力。
Model Browser
建模工具 GUI 的一个元素，表示模型存储库的内容。默认情况下，它位于建模工具主窗口的左侧。
Model-based design (MBD)
解决与设计复杂控制、信号处理和通信系统相关的问题的数学和视觉方法。
Model-Based Systems Engineering (MBSE)
建模的形式化应用，以支持系统需求、设计、分析、验证和确认活动，从概念设计阶段开始，并在整个开发和以后的生命周期阶段继续进行。MBSE 专注于创建和利用模型作为工程师之间信息交换的主要手段，而不是基于文档的信息交换。
Modeling tool
顶部安装了 SysML 插件的 Cameo Systems Modeler 或 MagicDraw。
Object flow
一对动作之间的一种 SysML 关系。对象流使您能够表达在活动执行时通过活动从一个动作流向另一个动作的物质、能量或数据。对象流表示为带有空心箭头的实线。
Package
一种可以包含其他元素的 SysML 元素。包可用于将元素梳理成具有逻辑凝聚力的组。
Parametric diagram
一种特殊类型的 ibd，它显示模块的内部结构，重点是该模块的值属性与应用的约束模块的约束参数之间的绑定。参数图可用于计算系统参数的值（通过利用建模工具的模拟能力）。
Part property
模块在另一个模块的上下文中的用法，或者换句话说，一个模块的属性，该模块的类型是在模型中的某个位置定义的另一个模块。它可以表示为 bdd 中该模块的part分隔栏中的字符串，或表示为 ibd 中的矩形。使用part属性，您可以将模型中捕获的系统的内部结构指定为模块。简化的 ibd（没有代理端口）可用于指定系统上下文中的交互；在这种情况下，系统上下文被捕获为一个模块，具有由捕获感兴趣系统的模块输入的part属性。
Presentation artifact
系统模型的某些片段或方面的可视化表示。它可以是图表、矩阵、地图或表格。演示工件用作模型或数据编辑器的数据输入。
Proxy port
模块的一种属性，由模型中某处定义的接口模块输入。它表示由该模块表示的结构对象边界处的点，外部实体可以通过该点与该结构对象进行交互。换句话说，它是在另一个模块的上下文中使用接口模块。代理端口始终表示为模块或part属性图块上的一个小矩形，通常用箭头装饰以指示代理端口是用于接收系统、子系统或组件的输入，还是提供输出。
Requirement
一个 SysML 元素，可以捕获翻译或表达需求的基于文本的语句。它可用于捕获利益相关者的需求，或在模型中指定系统需求和详细的物理需求。
Sequence diagram
一种行为SysML图，可用于描述模块的各部分如何通过操作调用和异步信号相互交互。
Signal
可用于捕获交换项目的 SysML 元素。
Smart manipulator toolbar
一个图形用户界面的建模工具。当在图窗口上选择元素的符号时，它会出现。
Stakeholder
对系统或系统拥有满足其需求和期望的特征具有权利、份额、主张或利益的个人或组织。
Stakeholder needs
从感兴趣的系统的各个利益相关者那里收集的信息。此信息包括主要用户需求、与系统相关的政府法规、政策、程序和内部指南，仅举几例。单个利益相关者的需求可以被捕获为模型中的需求。
State
捕获系统状态的元素，它可以在操作期间存在于其中。状态表示为圆角矩形，其名称显示为该矩形内的字符串。
State machine diagram
一种SysML行为图，可用于指定系统内的结构如何随着时间的推移响应事件发生而改变状态。它可用于指定系统或其部分的行为。
Subsystem
较大系统中的次要或从属系统。一个子系统可以作为模型中的一个模块来捕获。
System context
确定系统外部视图的概念。它必须引入不属于系统但与之交互的元素。除了系统本身（被认为是一个黑盒）之外，特定系统上下文中的元素集合可以包括在该上下文中与 SoI 交互的外部系统和用户（人类、组织）。可以将单个系统上下文捕获为模型中的一个模块。
System
为一个或多个共同目的而组织成一个复杂整体的相互作用元素的组合。
System of interest (SoI)
正在考虑其生命周期的系统。首先从黑盒角度分析系统，然后从白盒角度分析系统，以生成系统需求规范。
Systems Engineering (SE)
在系统的整个生命周期中需要跨学科任务，以将利益相关者的需求、要求和约束转化为系统解决方案。
Systems Engineering Team
System requirements
系统、子系统或组件的设计要满足的需求。系统需求来源于利益相关者的需求，是更抽象的需求。
System under design
为产生详细系统设计的物理需求规范而设计的系统。
System under implementation
正在开发详细设计的系统。
System parameter
系统、子系统或组件的数值特征。它可以指定为捕获该系统、子系统或组件的模块的值属性。系统参数源自 MoE，可以根据系统需求进行验证。
Systems Modeling Language (SysML)
用于系统工程应用的通用建模语言。它支持广泛的系统和SoS的规范、分析、设计、验证和确认。
Trade-off
一种情境决策，涉及减少或失去一套或设计的一个质量、数量或属性，以换取其他方面的收益。简单来说，权衡是一件事增加而另一件事必须减少。
Transition
一种SysML关系，表示从一种状态到另一种状态的变化。它可以由一些事件并发触发。
Use case
一种SysML元素，可用于捕获人们对系统的期望以及他们希望通过在特定系统上下文中使用它来实现的目标。用例的符号是一个椭圆，其名称（通常是动词短语）位于该椭圆内。
Use case diagram
一种SysML行为图，可用于定义在特定系统上下文中执行的一组用例；它代表感兴趣系统的黑盒视图。它还显示并可用于在用例和系统上下文的参与者之间创建关联，以指定谁/什么负责调用或参与什么用例。
Value property
可以表示数量、布尔值或字符串的模块的属性。它在模块的值分隔栏中显示为字符串，可用于捕获感兴趣系统的效能指标（必须另外应用«moe»元类型）。
参考书目
1. Chami M., Oggier, P., Naas, O., Heinz, M. “Real World Application of MBSE at Bombardier Transportation”, SWISSED, Zurich, 2015. available at https://goo.gl/zf5uvp.
2. Delp, C., Lam, D., Fosse, E., Cin-Young Lee, “Model based document and report generation for systems engineering”, Aerospace Conference, IEEE, 2013. available at http://www.omgsysml.org/ View_Paper-IEEE_2013.pdf.
3. Estefan, J. INCOSE Survey of MBSE Methodologies, INCOSE TD 2007-003-02, Seattle, WA, USA, 2008.
4. Friedenthal, S., et al. A Practical Guide to the SysML, 4th Edition: The Systems Modeling Language. Boston: MK/OMG Press, 2011.
5. Friedland, B., Herrold, J., Ferguson, G., Malone, R. “Conducting a Model Based Systems
6. Engineering Tool Trade Study Using a Systems Engineering Approach”, 27th Annual INCOSE International Symposium, pp. 1087-1099, Adelaide, 2017.
7. Hallqvist, J., Larsson, J. “Introducing MBSE by using Systems Engineering Principles”, 26th Annual INCOSE International Symposium, pp. 512–525, Edinburgh, 2016.
8. Hoffmann, H.-P. “Systems Engineering Best Practices with the Rational Solution for Systems and Software Engineering”, Release 3.2.1, February 2011. available at https://www.slideshare.net/ billduncan/ibm-rational-harmony-deskbook-rel-312.
9. ISO/IEC/IEEE 15288:2015 “Systems and Software Engineering–System Life Cycle Processes”, Geneva, 2015.
10. Mazeika, D., Morkevicius, A., Aleksandraviciene, A. “MBSE driven Approach for defining problem domain”, 11th Conference of System of Systems Engineering (SoSE), pp.1-6, Kongsberg, 2016.
11. Morkevicius, A., Aleksandraviciene, A., Mazeika, D., Bisikirskiene, L., Strolia, Z. “MBSE Grid: A Simplified SysML‐Based Approach for Modeling Complex Systems”, 27th Annual INCOSE International Symposium, pp. 136-150, Adelaide, 2017.
12. Morkevicius, A., Bisikirskiene, L., Jankevicius, N. “We Choose MBSE: What’s Next?”, Proceedings of the Sixth International Conference on Complex Systems Design & Management, CSD&M 2015, pp. 313, Paris, 2015.
13. Morkevicius, A., Jankevicius., N. “An Approach: SysML-based automated requirements verification”, IEEE International Symposium on Systems Engineering (ISSE), pp. 92-97, Rome, 2015.
14. Object Management Group OMG Systems Modeling Language (OMG SysML), v1.5, May 2017. available at https://www.omg.org/spec/SysML/1.5/.
15. Object Management Group OMG Unified Modeling Language (OMG UML), v2.5.1, December 2017. available at https://www.omg.org/spec/UML/2.5.1/.
16. Soegaard, S. E. “Adopting MBSE using SysML in System Development–Joint Strike Missile (JSM)”, No Magic World Symposium, May 2016. available at https://vimeopro.com/user28256466/nomagic-world-symposium-2016-presentations/page/3.
17. Spangelo, S. C. et al. “Applying model based systems engineering (MBSE) to a standard CubeSat”, Aerospace Conference IEEE, 2012.
18. Walden, David, ed. INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, v.4. International Council on System Engineering (INCOSE), August 2015.
19. Weilkiens, T. Systems Engineering with SysML/UML: Modeling, Analysis, Design. Boston: MK/OMG Press, 2008.
20. Zachman, J. A. “A framework for information systems architecture”, IBM Syst. J., vol. 26, no. 3, pp. 276-292, 1987.
关于作者
Aiste Aleksandraviciene
Aiste 是 OMG® 认证系统建模专家 (OCSMP)。她在 No Magic Europe 工作了八年，目前担任解决方案架构师的职位。
她的专长领域是 MBSE，特别关注需求管理。她负责向 No Magic 客户介绍 MBSE 的三大支柱：语言 (SysML)、方法 (MagicGrid) 和工具（No Magic 软件和集成）。在与雷诺-日产、Leica Geosystems、Bombardier Transportation 和 Kongsberg Defense & Aerospace 等国际知名客户合作时，她提供培训、工具演示并参与提供定制解决方案。Aiste 还负责通过组织 MBSE 网络研讨会、制作和维护培训材料以及撰写论文（单独或与她的同事合作）来传播 MBSE 文化。她是多个 MBSE 会议和其他公共活动的演讲者。
在加入解决方案架构师团队之前，Aiste 曾担任文档经理，并拥有超过五年的技术作家经验。在制作 No Magic 产品的技术文档时，她积累了很多编写技术文本的经验，这对她制作 MagicGrid BoK 有很大帮助。
Aiste 拥有考纳斯科技大学（立陶宛）的信息系统工程硕士学位。
Aurelijus Morkevicius, Ph.D.
Aurelijus 是 OMG® 认证的 UML、系统建模和 BPM 专家。目前，他是 No Magic Europe 解决方案部门的负责人。
他在基于模型的系统和软件工程（主要基于 UML 和 SysML）和防御架构（DoDAF、MODAF、NAF）方面具有专长。Aurelijus 与通用电气、庞巴迪运输、德国铁路、采埃孚、福特、BAE 系统、西门子和宝马等公司合作。他还是当前 OMG UAF（以前称为 UPDM）标准开发小组的联合主席和主要架构师之一。他代表 INCOSE 和 NATO 的 No Magic 公司。
此外，Aureljus 还积极参与教育活动。 他在考纳斯理工大学教授企业架构课程；他于 2013 年在同一所大学获得了信息学工程博士学位。Aurelijus 还是多篇文章的作者，并在多个会议上发表演讲。
Aiste Aleksandraviciene
Aurelijus Morkevicius, Ph.D.
MagicGrid®
Book of Knowledge
A Practical Guide to Systems Modeling
using MagicGrid from No Magic
Language editor Nina K Pettis
Designed by Skaidra Vaicekauskiene
Cover Design David Fiegenschue, Fig Design
Published and printed by
Vitae Litera, UAB
Savanoriu av. 137
LT-44146 Kaunas, Lithuania
www.tuka.lt | info@tuka.lt
