MagicGrid 知识手册(二)
Modeler
1 问题域
1.1 简介
问题域定义的目的是分析利益相关者的需求并使用 SysML 模型元素对其进行细化，以获得对 SoI 必须解决的问题的清晰连贯的描述。 如下表所示，问题域分析分两个阶段进行。 在第一阶段，SoI 被认为是一个黑盒，主要关注它如何与环境交互，而无需了解其内部结构和行为。换言之，执行 SoI 的操作分析。第二阶段，打开黑盒，从白盒的角度分析SoI，有助于详细了解系统应该如何运行。换言之，执行 SoI 的功能分析。同样重要的是要注意问题定义不包括 SoI 的物理架构。
从下表中可以看到，问题域定义的两个阶段都包括分析SoI的需求、行为、结构和参数。唯一的区别是视角。
在相关页面中，将逐步描述问题域中的建模过程。
1.2 黑盒视角
1.2.1 简介
从黑盒的角度进行问题域分析和定义是确定和指定系统应该解决的问题的第一步。在问题域定义的这个阶段，SoI被认为是一个黑盒，这意味着只分析系统的输入和输出，而不关注其外部结构和行为。而是分析了SoI、其他系统和SoI在各种系统上下文中的假定用户之间的交互。
在相关页面中逐步解释了从黑盒角度对问题域建模。
1.2.2 B1-W1.利益相关者需求:initial
它是什么？
单元格代表从系统的各个利益相关者收集的信息。此信息包括主要用户需求、与系统相关的政府法规、政策、程序和内部指南等。
在这个单元的初始阶段，利益相关者的需求被捕获。这可以通过采访利益相关者、给他们问卷、在专业小组中讨论需求或研究以不同格式编写的文件来完成。虽然引出的信息是原始的，但不需要特别重写。但是，它需要在问题域模型的其他单元格中进行分析和改善。这些改进随后用作指定系统要求的基础（参见 S1.initial）。因此，可以说系统需求源自利益相关者的需求。
为了拥有完整的问题域模型，您需要执行由该单元的最后阶段确定的任务。 也就是说，您需要在利益相关者需求和问题域模型的其余部分之间建立可追溯性关系，以传达 SoI 的行为和结构元素如何改善利益相关者需求。
谁是负责人？
在典型的多学科系统工程团队中，利益相关者需求的获取和分析由需求团队执行。
如何建模？
可以直接在建模工具中捕获利益相关者的需求，或者可以从其他工具和格式中导入它们，例如：
- 需求管理工具（例如，IBM® Rational® DOORS®）
- 电子表格（例如，Microsoft Excel 文件）
- ReqIF 文件（包含从其他工具导出的数据，即 IBM® Rational® DOORS®、PTC Integrity Modeler、Polarion® REQUIREMENTS™ 或 Siemens Teamcenter）
在建模工具中，可以将单个利益相关者需求捕获为 SysML 需求，该需求具有唯一标识、名称和文本规范。整个利益相关者需求列表可以显示在 SysML 需求选项卡（见下图）或框图中。利益相关者的需求可以通过包含关系在层次上相互关联（分组）。
下一步是什么？
- 利益相关者的需求用于在 B3.initial 中定义系统上下文。
- 功能性利益相关者的需求通过在 B2 中的用例和用例场景进一步分析和改善。
- 非功能性利益相关者的需求通过 B4 中效能（价值属性）指标来改善。
Tutorial
Step 1. 梳理B1-W1的模型
梳理良好的模型更易于阅读、理解和维护。这就是为什么我们建议将您的模型梳理到包中。SysML模型中的包与文件系统图形用户界面(GUI)中的文件夹非常相似：文件夹用于梳理文件，而包用于梳理图和元素(包括其他包)。
根据 MagicGrid 框架的设计，捕获利益相关者需求的模型工件应该存储在下图所示的包结构下。可以看到，顶层包代表域，中层包代表视角，底层包代表单元格。
注：如果您使用 MagicGrid QuickStart 或 MagicGrid Blank 模板，则可以跳过此步骤（以及建立模型结构的其他步骤）。 它们都带有 19.0 版本的建模工具，并包含基于 MagicGrid 框架的预定义结构。
注：在包名称中使用数字使您能够保留模型树中的包位置。
为 B1-W1 梳理模型:
- 右键单击Model包(这是根包的默认名称)并选择Create Element。
- 在搜索框中，键入pa，元素类型Package的前两个字母，然后按Enter。
- 输入1 Problem Domain指定新包的名称并按Enter。
- 右键单击 1 Problem Domain 包并选择 Create Element。
- 重复steps 2 和 3 以创建名为 1 Black Box 的包。
- 右键单击 1 Black Box 包并选择 Create Element。
- 重复steps 2 和 3 以创建名为 1 Stakeholder Needs 的包。
Step 2. 为利益相关者的需求创建表格
为了捕获和显示利益相关者的需求，我们建议使用 SysML 需求表。
创建用于捕获利益相关者需求的 SysML 需求表：
- 右键单击 1 Stakeholder Needs 包并选择Create Diagram。
- 在搜索框中，键入 rt，其中 r 代表requirement，t 代表table，然后双击 Enter。则表已创建。注： 请注意，该表是以存储它的包命名的。这个名字也适用于表格。您只需要从其名称中删除序列号。
- 选择 1 Stakeholder Needs 包并将其拖到表的 Criteria 区域中的 Scope 框中。 从现在开始，每次添加 1 Stakeholder Needs 包的内容时都会更新该表。
Step 3. 捕捉利益相关者的需求
假设您需要将以下利益相关者的需求捕获到您的模型中：
单个利益相关者需求可以存储为 SysML 需求，该需求具有唯一标识、名称和文本规范。
您可以通过以下方式之一将利益相关者的需求纳入您的模型：
- 直接在模型中捕获信息
- 从 Microsoft Excel 电子表格复制信息
- 从 ReqIF 文件导入信息
- 同步来自 IBM Rational DOORS 的信息
直接在模型中捕获信息
直接在模型中捕捉利益相关者的需求：
1. 如果未显示，请打开在step 2 of the B1-W1 initial phase tutorial 中创建的表。
2. 在该表的工具栏上，单击Add New并选择Requirement。
3.在新创建的行中，键入step 3 of the B1-W1 initial phase tutorial的表中显示的第一个利益相关者的名称和文本。
4.重复steps 2和3，直到您拥有表中的所有项目，如下图所示。
注： 在SysML需求表中创建的项目也会出现在Model Browser中。
从Microsoft Excel电子表格复制信息
如果在Microsoft (MS) Excel电子表格中向您提供利益相关者需求列表，您可以通过利用建模工具的复制-粘贴功能，轻松地将此信息传输到SysML模型。
从 MS Excel 电子表格复制利益相关者的需求
1. 打开电子表格并选择要复制到模型的内容。
2. 复制内容：
- 在 Windows 或 Linux 上按 Ctrl+C。
- 在 macOS 上按 Command+C。
3. 切换到建模工具并打开在step 2 of the B1-W1 initial phase tutorial中创建的 SysML 需求表（如果尚未打开）。
4. 将内容粘贴到表格中：
- 在 Windows 或 Linux 上按 Ctrl+V。
- 在 macOS 上按 Command+V。
5. 选择 Requirement 作为粘贴数据的类型。
6. 等待利益相关者的需求粘贴到表格中。
注： 复制到 SysML 需求表的项目也会出现在Model Browser中。
从 ReqIF 文件导入信息
可能会使用这些工具之一来收集利益相关者的需求：
- IBM® Rational® DOORS®
- PTC Integrity Modeler
- Polarion® REQUIREMENTSTM
- Siemens Teamcenter
- Dassault Systèmes Reqtify
在这种情况下，需求管理工具和建模工具之间的信息可以通过需求交换格式 (ReqIF) 文件进行传输。因此，将利益相关者的需求纳入您的模型包括：
1. 将需求从需求管理工具导出到 ReqIF 文件。
2. 将 ReqIF 文件导入建模工具中的 SysML 模型。
我们跳过第一步，假设您已经获得了 ReqIF 文件。
从 ReqIF 文件导入利益相关者的需求：
1. 从主菜单中，选择File > Import From > Requirements Interchange Format (ReqIF) File。
2. 从您的文件系统中选择 ReqIF 文件，然后单击Open。
3. 在 Select Package for New Data对话框中，选择要存储导入的利益相关者需求的包； 即，1 Stakeholder Needs包。
4. 单击OK。
5. 等待利益相关者需求导入1 Stakeholder Needs包。由于该包是 SysML 需求表的域（参见step 2 of the B1-W1 initial phase tutorial），所有导入的项目也会出现在表中。
同步来自 IBM Rational DOORS 的信息
如果在 IBM® Rational® DOORS® 项目中收集了利益相关者的需求（参见下图），您可以通过在 DOORS 和建模工具之间同步数据将它们放入 SysML 模型中。
注：只有安装了Cameo DataHub插件，建模工具才能与 DOORS 同步。
在本教程中，我们假设需求团队仅使用 DOORS 来捕获利益相关者的需求，并在 SysML 模型中执行进一步的分析。为此，我们需要在 DOORS 和建模工具之间建立单向同步。在单向同步中，条目从 DOORS 复制到建模工具，但没有条目从建模工具复制回 DOORS。
将利益相关者的需求从 DOORS NG 6.x 同步到建模工具：
1. 确保在建模工具上安装了 Cameo DataHub Plugin 18.1 或更高版本。
2. 连接到 DOORS NG 6.x 存储库：
a. 从建模工具的主菜单中，选择Tool > DataHub > DataHub Explorer。Cameo DataHub Explorer 面板在建模工具窗口的右侧打开。
b. 在打开面板的工具栏上，单击Add Data Source按钮。
c. 提供所需信息，单击Create，如下图所示。
d. 等待建模工具连接到 DOORS NG 6.x 存储库。操作完成后，Cameo DataHub Explorer 面板的结构树显示来自 DOORS 存储库的项目（作为包）。 其中一个项目是 CCU Stakeholder Needs。
3. 同步数据：
a. 在 Cameo DataHub Explorer 面板的工具栏上，单击Operation下拉列表框并选择 Copy Data with Sync。
b. 在 Cameo DataHub Explorer 结构树中，选择 CCU Stakeholder Needs 包并将其拖到Model Browser中的 1 Black Box 包上（在建模工具窗口的左侧）。
c. 等待同步完成的消息。两个结构树中的同步项目都标记有S（见下图）。
4. 使同步单向：
a. 在建模工具的Model Browser中，右键单击 CCU Stakeholder Needs 包，然后选择 DataHub Actions > DHLink Panel。DHLinks 面板在建模工具窗口的底部打开。
b. 右键单击Direction单元格并选择更改Direction > Sync to MagicDraw。 同步更改为单向，源项目增加标记 1。
Step 4. 对利益相关者的需求进行分组
在您的模型中有利益相关者的需求后，您可以根据它们的性质将它们分组。这些组可以是与系统相关的政府法规、用户需求或业务需求，等等。不同性质的利益相关者需求从不同的来源导入到模型中是很常见的。例如，用户需求可以从需求管理工具同步，法规可以从 MS Excel 电子表格中复制。
现在让我们分析一下您模型中车辆气候控制单元的利益相关者需求。实际上，它们是用户需求，因此可以在 SysML 需求类型的User Needs元素下进行分组。我们建议使用常规 SysML requirement元素作为一个组元素。组元素本身可能没有任何文本。
对利益相关者的需求进行分组：
1. 创建分组需求：
a. 在Model Browser中，右键单击 1 Stakeholder Needs 包并选择Create Element。
b. 在搜索框中，键入 re ——需求类型的第一个字母，然后按 Enter。则创建了一个需求类型的新元素。
c. 键入 User Needs 以指定需求的名称，然后按 Enter。
2. 在Model Browser中，选择所有先前捕获的利益相关者需求并将它们拖到User Needs需求上，则这些利益相关者需求就嵌套到分组User Needs需求下。
注：要选择结构树中的一组相邻项目，请单击第一个项目，按 Shift，并在按住的同时选择最后一个项目。
3. 查看 SysML 需求表中的相应更改。
注：确保表格以Compact tree模式显示。为此，单击表格工具栏上的选项按钮 ，然后选择 Display Mode > Compact Tree。
Step 5. 利益相关者需求编号
我们用于捕获和存储利益相关者需求的SysML需求，在默认情况下使用整数进行编号。我们建议为这些简单的数字添加前缀，以便将利益相关者需求与其他需求区分开来，例如系统、组件和物理需求，这些需求将在以后创建。假设我们想给这些数字加上一个前缀SN- (S代表利益相关者stakeholder，N代表需求needs)。
我们还需要将编号从 1 重置，因为分组后初始编号已自动更改为 5。
用前缀 SN- 编号利益相关者的需求：
1. 在Model Browser中，右键单击分组需求 User Needs 并选择 Element Numbering。 Element Numbering对话框打开。
2. 在对话框中，单击 Prefix 列的空值单元格以启动编辑，键入 SN- 并按 Enter。 对话框模型树中利益相关者需求的每一项都以前缀 SN- 编号。
3. 单击Details以查看更多选项。
4. 单击以选中Renumber from Initial Value复选框。
5. 单击Renumber Recursively按钮。
6. 单击OK关闭对话框。
Step 6. 对利益相关者需求进行分类
利益相关者需求可以是功能性的，也可以是非功能性的。功能性利益相关者需求指定 SoI 的预期用途。它们通过 MagicGrid 框架的 B2 单元中的用例和用例场景进一步改善。 非功能性利益相关者需求指定 SoI 的非功能性特征。它们通过框架的 B4 单元中的效能（价值属性）指标来改善。
分类促进了对利益相关者需求的进一步分析，特别是当您必须处理大量的信息时。如果情况不需要，可以跳过此步骤。
捕获的功能性利益相关者需求应该转换为功能性需求。非功能性利益相关者的需求可以保持简单的需求形式。很明显，Setting Temperature和Heat and Cool Modes都是功能性利益相关者需求。
将Setting Temperature和Heat and Cool Modes需求转换为功能性的：
1. 在Model Browser中右键单击这两个需求。
2. 选择Refactor > Convert To > More Specific > Functional Requirement。 两个需求都转换为功能性的，并且在每个元素图标上显示 F 而不是 R。
1.2.3 B3.系统上下文: initial
它是什么？
系统上下文或操作环境决定了系统的外部视图。它必须引入不属于系统但与该系统交互的元素。可以为单个 SoI 定义多个系统上下文。除了系统本身（目前被认为是一个黑盒），特定系统上下文中的元素集合可以包括在该上下文中与 SoI 交互的外部系统和用户（人类、组织）。
该单元中的建模包括两个阶段：initial和final。在 B3 的initial阶段，定义了一个或多个系统上下文，并确定了参与每个上下文的元素。在 B3 的final阶段，指定与每个系统上下文的交互。由于这需要分析系统行为，因此您应该首先确定该系统上下文的用例并为用例场景建模。这就是 B3 单元前插入了 B2 单元的原因。
B3单元格的initial阶段产出：
- 系统上下文的定义
- 每个系统上下文的参与者：SoI、系统的假定用户、其他系统等。
谁是负责人？
在典型的多学科系统工程团队中，系统上下文由需求团队指定。
如何建模？
在建模工具中，系统上下文可以被捕获为 SysML 模块类型的元素。系统上下文的参与者可以指定为该系统上下文的部分属性，并在为该系统上下文创建的 SysML 内部框图 (ibd) 中表示。每个部分都由模块输入，模块定义了 SoI、用户或模型中的另一个系统。
注：我们建议使用block而不是actor来定义人(例如SoI的用户)，原因如下:
- block被视为系统上下文的一部分，actor不是。
- block可以标记为外部，actor不能。
- block可以定义它的行为，actor不能。
接下来是什么?
- 系统上下文用于分析系统在B2中的行为。系统的各种用例被分组到系统上下文中,每个用例都是在其中执行的。
- 作为该系统上下文的一部分属性，捕获的每个系统上下文的参与者也在B2中使用。它们可以在描述用例场景的SysML活动图中表示为泳道分区。
Tutorial
Step 1. 梳理B3的模型
遵循 MagicGrid 框架的结构，系统上下文和它们所拥有的 SysML 内部框图，连同它们所代表的元素，应该存储在 1 Black Box 包内的一个单独包中。我们建议以单元命名包，即 3 System Context。
为 B3 梳理模型：
1. 右键单击 1 Black Box 包并选择 Create Element。
2. 在搜索框中，输入 pa（元素类型 Package 的前两个字母），然后按 Enter。
3. 键入 3 System Context 以指定新包的名称，然后按 Enter。
Step 2. 捕获系统上下文
可以通过分析 B1-W1.initial 中捕获的利益相关者需求来识别系统上下文。 车辆气候控制单元的利益相关者需求使您能够识别单一环境，即Vehicle In Use。 它可以作为 SysML 块类型的元素在您的模型中捕获。
创建一个捕获 Vehicle In Use 系统上下文的块：
1. 右键单击 step 1 of the B3 initial phase tutorial中创建的 3 System Context 包，然后选择 Create Element。
2. 在搜索框中，键入 bl，所需元素类型block的首字母，然后按 Enter。
3. 键入 Vehicle In Use 以指定新块的名称，然后按 Enter。 模块在模型浏览器中创建和表示。
Step 3. 为系统上下文创建一个ibd（内部模块图）
要开始指定Vehicle In Use系统上下文的参与者，首先需要为捕获该系统上下文的模块创建一个SysML内部模块图。
为Vehicle In Use模块创建一个ibd：
1. 右键单击Vehicle In Use模块并选择Create Diagram。
2. 在搜索框中，键入ibd（SysML内部模块图的首字母缩写），然后双击Enter。该模块图在Model Browser中创建并表示在Vehicle in Use模块下。
注：模块图以它所属模块命名。由于这个名称也非常适合模块图，所以不需要更改。
Step 4. 捕获系统上下文的参与者
系统上下文的参与者可以被捕获为part属性，每个part属性应该由 定义SoI概念的模块、系统的假定用户(人、组织) 或 模型中的某些外部系统 输入。
注：这里您应该记得SysML规范，它告诉您应该使用block来定义概念，而使用part来指定这些概念的用法。任何概念，一旦在模型中定义，都可以在许多系统环境中使用。例如，汽车气候控制单元SoI定义为一个block，它可以被当作part输入到各种系统上下文中，这意味着它参与到所有这些系统上下文中。
利益相关者需求表明，Vehicle In Use系统上下文包括两个参与者:车辆气候控制单元和车辆乘员(司机或乘客)。此外，系统上下文必须包括一个为SoI提供能量的外部系统(即使在利益相关者需求中没有提到)。
捕获Vehicle In Use系统上下文的参与者：
1. 打开step 3 of the B3 initial phase tutorial中创建的ibd，如果还没有打开的话。
2. 确保 类型选择模式(Type Selection Mode) 在模块图中是打开的。否则，在此图中创建的part将不会按block输入。
注：在此模式下，当您创建part property时，该工具会为您提供一个block列表，您可以从中选择part property类型。如果所需的block尚不存在，您可以通过直接在part property图块上键入其名称来简单地创建它。
3. 单击模块图面板上的 部件属性(Part Property) 按钮，然后单击模块图窗口上的空白位置。这将创建一个未命名的part property，并提供要输入它的现有block的列表。
4. 直接在代表part property的图块上的冒号(":")后键入Climate Control Unit，然后按 Enter。则对应的Climate Control Unit模块将直接在Model Browser中被创建。
注：启用Type Selection Mode后，在part property图块上键入的 是被用于定义 新block 名称name的，其代表该part property的类型type，而不是part property自己的名称name。如果您还想指定名称name，请在图块上的冒号(":")前键入。但是，名称不是必需的，因为在此图中创建的part property可以通过它们的类型type轻松识别。
注：即“name : type”。
5. 重复steps 3和4以创建另外两个part property：一个由Vehicle Occupant模块输入，另一个由Energy Supply模块输入。
注：因为您需要连续创建多个part property，所以推荐使用Sticky按钮的功能(参见下图)，这样您就不需要每次创建新的part property时都单击面板上的Part Property按钮。当启用Sticky模式时，您可以根据需要创建所选类型的任意数量的元素。完成后按Esc退出。
完成后，您将拥有三个part property以及在模型中对应键入的相同数量的block。
1.2.4 B2.用例
它是什么？
在这个单元中，功能性利益相关者需求通过用例和用例场景进行细化。与利益相关者需求相比，用例更准确地说明人们对系统的期望以及他们希望通过使用系统实现什么。所有用例都分组到B3. System Context.initial定义的系统上下文中。
总的来说，这个单元产出：
- 为用户提供可衡量价值的功能性用例。
- 关于系统如何与用户和/或其他系统交互的用例场景。
谁是负责的人？
在典型的多学科系统工程团队中，用例由需求团队指定。
如何建模？
在建模工具中，可以通过利用 SysML 用例图的基础结构来捕获系统的用例。每个用例图的创建都应该考虑到 B3. System Context.initial中定义的系统上下文之一。用例可以被捕获为用例类型的元素。单个用例可以在不同的系统上下文中执行。
在系统上下文中执行一个或多个用例的实体应该在用例图中表示为block。在initial phase of B3创建的这些block类型是系统上下文的part属性。如下图所示，即使是人类，例如车辆乘员(vehicle occupant)，也应该表示为block。
注：我们建议使用block而不是actor来定义人类，原因如下：
- block被视为系统上下文的一部分，而actor不是。
- block可以标记为外部，而actor不能。
- block可以定义其行为，而actor不能。
每个用例都必须有一个名称name和主要场景primary scenario。 替代场景是可选的。 可以以 SysML 活动图或序列图的形式捕获用例场景。在活动图中，SoI、系统的假定用户和/或其他系统可以表示为泳道分区。在序列图中，它们表示为生命线。SoI 同时被认为是一个黑盒。
下一步是什么？
- 现在您有了用例场景，您可以切换到 B3.final。用例场景作为输入，用于在各种系统上下文中指定 SoI 与其环境之间的交互。
- 主要用例场景，描述系统与其环境中的一些外部实体之间的交互，被分解以指定 W2.initial 中子系统之间的内部动作/序列流。
Tutorial
Step 1. 为 B2 梳理模型
遵循 MagicGrid 框架的结构，SysML 活动或序列图形式的用例及其场景，连同它们代表的元素，应存储在 1 Black Box 包内的单独包中。我们建议以单元格命名包，即 2 Use Cases。
为 B2 梳理模型：
1. 右键单击 1 Black Box 包并选择 Create Element。
2. 在搜索框中，输入 pa（元素类型 Package 的前两个字母），然后按 Enter。
3. 键入 2 Use Cases 以指定新包的名称，然后按 Enter。
Step 2. 创建用例图
要开始捕获 Vehicle In Use 系统上下文的用例（在step 2 of the B3 initial phase tutorial 中定义），您需要先创建一个 SysML 用例图。您还需要在用例图窗口上显示捕获系统上下文的block的图块。代表 SoI 用户的 Vehicle Occupant block也应该显示在用例图窗口中。
创建用例图来捕获在 Vehicle In Use 系统上下文中执行的用例：
1. 右键单击 2 Use Cases 包并选择 Create Diagram。
2. 在搜索框中，键入 uc（代表use case），然后按 Enter，则用例图已创建。
注：如果您有多个系统上下文，我们建议将每个系统上下文的用例存储在单独的包中。在这个例子下，没有这样的需要。
3. 键入 Use Cases of Vehicle In Use SC 以指定新用例图的名称，然后再次按 Enter。
4. 在 Model Browser 中，选择 Vehicle In Use 模块并将其拖到新创建的用例图窗口中。 则Vehicle In Use 模块的图块出现在用例图上。
5. 在 Model Browser 中，选择 Vehicle Occupant 模块并将其也拖到该用例图窗口中。则Vehicle Occupant 模块的图块也出现在用例图上。
Step 3. 捕获用例
通过分析利益相关者需求，我们可以识别在Vehicle In Use系统上下文中执行的Feel Comfortable Temperature用例。现在让我们在Use Cases of Vehicle In Use SC用例图中捕获它。
捕获Feel Comfortable Temperature用例：
1. 打开在step 2 of the B2 tutorial中创建的用例图（如果尚未打开）。
2. 单击用例图窗口上的Use Case按钮，并将鼠标移动到Vehicle In Use模块的图块上。
3. 当您看到Vehicle In Use图块周围的蓝色边框时，单击它。一个未命名的用例在模块的图块中创建。
4. 输入Feel Comfortable Temperature来指定这个用例的名称，然后按Enter。
5. 双击用例打开它的详述(Specification)，并确保将Vehicle In use模块设置为它的对象(Subject)。
6. 选择 Feel Comfortable Temperature 用例，单击其智能操纵器工具栏上的关联(Association)按钮，然后选择代表系统用户的 Vehicle Occupant 模块，将这两个元素关联起来。
Step 4. 创建用于指定用例场景的图
可以在 SysML 活动图或序列图中捕获用例场景。我们选择前者。
创建 SysML 活动图以指定Feel Comfortable Temperature用例场景：
1. 在Use Cases of Vehicle In Use SC图中，右键单击Feel Comfortable Temperature用例的图块，然后选择Create Diagram。
2. 在搜索框中，键入 SysML 活动图的首字母缩写词 act，然后按 Enter。活动图已创建并打开。它由同名的 SysML 活动所有。
注：现在，如果返回显示Feel Comfortable Temperature用例的用例图，您可以看到该用例的图块装饰有耙子图标。该装饰意味着用例包含一个内部图，即Feel Comfortable Temperature活动图。双击用例的图块打开该内部图。
Step 5. 指定用例场景
假设Feel Comfortable Temperature用例场景包括以下步骤：
1. 打开气候控制Turn on Climate Control
2. 检查系统Check System
3. 显示温度Display Temperature
4. 启动气候控制Start Climate Control
5. 设定温度Set Temperature
6. 达到所需温度Reach Required Temperature
7. 保持温度Maintain Temperature
8. 关闭气候控制Turn off Climate Control
9. 停止气候控制Stop Climate Control
指定基本用例场景：
1. 如果尚未打开，打开Feel Comfortable Temperature活动图（在step 4 of the B2 tutorial中创建的）。
2. 确保在图中启用了Automatic Behavior Creation模式（参见下图）。否则，图中创建的action将不会以活动(activity)键入。
注：活动对于在 W2 中执行的功能分解是必要的。
3. 单击图面板上的Initial Node按钮，然后单击图窗口上的空白位置。初始节点被创建并显示在图上。
4. 单击初始节点的智能操纵器工具栏上的控制流按钮，然后单击图窗口上的空白处。创建了一个未命名的action，类型为activity。
5. 单击action的图块并在冒号 (“:”) 后键入Turn on Climate Control以命名活动。完成后按 Enter。
6. 重复步骤 4 和 5 以从上面的列表中捕获其他步骤。
7. 选择最后一个action的图块，然后单击其智能操纵器工具栏上的控制流按钮。
8. 右键单击图窗口上的空白位置，选择Activity Final。终止节点创建并显示在图上。
完成后，您的Feel Comfortable Temperature图应该与下图中的非常相似。
现在假设您希望通过添加替代操作流来指定如果气候控制单元不工作会发生什么情况，从而使场景更加复杂。为此，您需要在 Check System 和 Display Temperature action之间插入一个决策节点，并绘制两个带适当判定条件(guard)的控制流。
使用替代流程更新用例场景：
- 单击图面板上的Decision按钮，然后单击Check System和Display Temperature action之间的控制流。
- 单击After Control Flow或Before Control Flow。则决策节点被插入。
- 选择 决策节点 和Display Temperature action之间的控制流，键入 [OK，然后按 Enter。则为此控制流指定了[OK]判定条件(guard)。
- 选择决策节点，单击其智能操纵器工具栏上的控制流按钮，然后单击Stop Climate Control action。控制流已创建。
- 选择该控制流，键入 [Not OK，然后按 Enter。则为该控制流指定了 [Not OK] 判定条件(guard)。
完成后，您的Feel Comfortable Temperature图应该与下图中的非常相似。
应该向此图中添加更多细节以使用例场景完整（如下图）。 此处不讨论如何执行此操作，但您可以查看有关如何插入分支节点和端口的建模工具的最新文档。
Step 6. 将action分配给系统上下文的参与者
在您的模型中拥有Feel Comfortable Temperature用例的整个场景后，您可以指定相关系统上下文的哪个参与者负责执行哪个action。对此有一个通用术语：将行为分配给结构。
您可以使用泳道分区来表示系统上下文的参与者。在这个例子下，你需要其中的两个，它们是模型中捕获的作为Vehicle In Use系统上下文的part属性：part属性的一种是Vehicle Occupant模块，另一种是Climate Control Unit模块(见step 4 of the B3 initial phase tutorial)。
在建立分配之前，您需要确保在活动图中启用了使用分配(allocation to usage)模式。此模式允许您传递考虑到系统上下文而建立的分配。否则，分配是通用的，与任何系统上下文无关。
在Vehicle In Use系统上下文中分配行为到结构：
1. 单击活动图面板上的Vertical Swimlanes按钮，然后单击该图窗口上的空白区域。打开Represent Properties对话框。
2. 由于默认情况下在对话框中选择了所有项目，单击以清除 Energy Supply 模块键入的part属性（如下图）。您不需要将此图中的任何action分配给此part属性。
注：该对话框始终显示属于用例主题的part属性列表，其中包含活动图。在这种情况下，会显示 Vehicle In Use 模块的part属性（请参阅step 4 of the B3 initial phase tutorial)）。
3. 单击对话框上的OK按钮。泳道显示在图上。
注：泳道分区始终按字母顺序从 A 到 Z 排列。因此，默认情况下，Climate Control Unit分区显示在左侧，而Vehicle Occupant显示在右侧。如果您希望 Vehicle Occupant 分区位于左侧（见下图），请选择 Climate Control Unit 分区的标题，然后单击 Move Swimlane Right 按钮。这样，泳道分区被交换。
4. 右键单击任何泳道分区，然后选择Allocation Mode > Usage（如果尚未选择）。图中启用了使用分配模式。
注：此模式允许您传递考虑到系统上下文而建立的分配。否则，分配是通用的，与任何系统上下文无关。
5. 将vehicle occupant的actions拖到Vehicle Occupant泳道内。
6. 将climate control unit的actions拖到Climate Control Unit泳道。
完成后，您的活动图Feel Comfortable Temperature应该与下面的非常相似。
1.2.5 B3.系统上下文:final
它是什么？
系统上下文或操作环境决定了系统的外部视图。它必须引入不属于系统但与该系统交互的元素。可以为单个 SoI 定义多个系统上下文。 除了系统本身（目前被认为是一个黑盒），特定系统上下文中的元素集合可以包括在该上下文中与 SoI 交互的外部系统和用户（人类、组织）。
该单元中的建模包括两个阶段：initial和final。在 B3 的initial阶段，定义了一个或多个系统上下文，并确定了参与每个上下文的元素。在 B3 的final阶段，指定每个系统上下文中的交互。由于这需要分析系统行为，因此您应该首先确定该系统上下文的用例并为用例场景建模。这就是 B3 单元格被 B2 单元格中断的原因。
B3 单元格的final阶段产出：
- initial phase of B3定义的每个系统上下文的参与者之间的关系
- 通过这些关系流动的项目
谁是负责的人？
在典型的多学科系统工程团队中，每个系统上下文中的交互由需求团队指定。
如何建模？
在建模工具中，系统上下文的参与者之间的关系可以被捕获为代表这些参与者的part属性之间的连接器。一旦创建了连接器，就必须指定从连接器一端流向另一端的一个或多个项目，因为连接器本身并没有说明交互的性质。它可以是物理、信息或控制流。项目可以作为Signal信号、block模块或value值 类型存储在模型中，具体取决于它们的性质。
如下图所示，系统上下文图可以补充与 SoI 相关的各种图像，以便将结果呈现给利益相关者，甚至包括那些无法阅读模型的人。
下一步是什么？
- 创建捕获感兴趣系统SOI的模块后，可以捕获描述非功能性利益相关者需求的系统的定量特征。因此，您可以切换到 B4. Measurements of Effectiveness。
Tutorial
Step 1. 指定系统上下文参与者之间的交互
现在是时候更新 Vehicle In Use 系统上下文的 ibd（参见 step 4 of the B3 initial phase tutorial）。为此，您应该分析相关用例的场景，即Feel Comfortable Temperature。更准确地说，您应该考虑跨越泳道分区边界的控制流和对象流，泳道分区表示该系统上下文的part属性。 用例场景揭示了这些part属性如何相互关联：vehicle occupant控制Climate Control Unit，该单元为他/她提供例如状态和车厢温度等信息。
让我们首先绘制一个连接器来表示交互。
绘制由Vehicle Occupant模块输入的part属性和由Climate Control Unit模块输入的part属性之间的连接器：
1. 打开Vehicle In Use的 ibd：
a. 按 Ctrl + Alt + F 打开Quick Find对话框。
b. 单击Diagram以设定仅搜索diagram并键入 Veh。
c. 当您在搜索结果列表中看到选中的 Vehicle In Use 的ibd（见下图）时，按 Enter。 所选图打开。
2. 选择由 Vehicle Occupant 模块键入的part属性，然后单击其智能操纵器工具栏上的连接器按钮。
3. 选择由Climate Control Unit模块键入的part属性。连接器已创建。
您还可以在由Energy Supply模块输入的part属性和由Climate Control Unit模块输入的part属性之间创建一个连接器。完成后，您的 ibd 图应该与下面的非常相似。
Step 2. 分配系统上下文参与者之间流动的项目
现在，让我们创建从连接器的一端流向另一端并向后流动的项目。我们建议将捕获这些项目的元素存储在 3 System Context 包中的单独包内。
如果我们假设您已经自己创建了 1 Exchange Items 包，我们可以直接转到创建流动的项目并将它们分配给连接器。可以在单个连接器上分配一个或多个项目流。
捕获项目流并将它们分配给part属性之间的连接器：
1. 右键单击 1 Exchange Items 包并选择Create Element。
2. 在搜索框中，输入元素类型 Signal 的前两个字母 si，然后按 Enter。
3. 输入 Control 以指定新信号的名称，然后按 Enter。
4. 将信号拖动到Vehicle In Use的 ibd 图中由 Climate Control Unit 模块输入的part属性与由Vehicle Occupant 模块输入的part属性之间的连接器上。
5. 在打开的对话框中，选择 From :Vehicle Occupant To :Climate Control Unit 作为流动方向，然后单击 OK。 Control信号分配给连接器。
6. 重复步骤 1 到 3 以创建名为 Status 的信号。
7. 将信号拖动到 Vehicle In Use的 ibd图中的同一连接器上。
8. 在打开的对话框中，选择 From :Climate Control Unit To :Vehicle Occupant 作为流动方向，然后单击 OK。 Status信号分配给连接器。
您还可以在由Energy Supply模块输入的part属性和由Climate Control Unit模块输入的part属性之间分配一个项目流。流动的项目可以是模型中作为模块捕获的电能和机械能。完成后，您的 ibd 图应该与下面的非常相似。
注：正如您在上图中所见，系统上下文图可以补充与 SoI 相关的各种图像，以便将结果呈现给利益相关者，甚至包括那些无法阅读模型的人。有关更多信息，请参阅建模工具的最新文档。
1.2.6 B4.效能指标
它是什么？
在此单元格中，非功能性利益相关者的需求通过效能指标 (MoE) 进行细化，其以数字格式捕获 SoI 的特征。MoE 是系统工程中广泛使用的传统术语，描述系统在特定上下文中执行任务的程度。在问题域模型中，它们充当高级关键性能指标，将在方案域模型中自动检查。
同一组 MoE 可用于不同模型，以指定其他感兴趣系统SOI的数值特征。
谁是负责的人？
在典型的多学科系统工程团队中，MoE 由需求团队指定。
如何建模？
要在建模工具中捕获 MoE，可以使用 SysML 模块定义图 (bdd)。要定义一组可重用的 MoE，应创建一个单独的模块并将其设置为代表 SoI 的模块的超类型。 在实际项目中，具有可重用 MoE 集的模块存储在外部模型中，也称为库。MoE 被捕获为应用了 «moe» 模板的值属性。SoI 的模块从超类型模块继承它们。建模工具中的重新定义机制允许您定义不同的默认值并按每个 MoE 细化不同的要求。
下一步是什么？
- 现在您有了效能指标，您可以指定设计约束，这可用于验证系统设计是否正确（参见 S4）。
Tutorial
Step 1. 为 B4 梳理模型
遵循 MagicGrid 框架的结构，捕获效能指标的模型元素应存储在 1 Black Box 包内的单独包中。我们建议以单元格命名包，即 4 Measurements of Effectiveness。
为 B4 梳理模型：
1. 右键单击 1 Black Box 包并选择 Create Element。
2. 在搜索框中，输入 pa（元素类型 Package 的前两个字母），然后按 Enter。
3. 键入 4 Measurements of Effectiveness 以指定新包的名称，然后按 Enter。
Step 2. 创建用于捕获 MoE 的模块
要开始捕获Vehicle Climate Control Unit的MoE，您首先需要创建一个 bdd 和一个模块block以设置为Climate Control Unit模块的超类型。 请记住，如果它是一个真实世界的项目，则 MoEs 持有者将在某个外部模型中创建，也称为library库。
创建用于捕获 MoE 的图和模块：
1. 右键单击 4 Measurements of Effectiveness 包并选择 Create Diagram。
2. 在搜索框中，键入SysML模块定义图的首字母缩写词 bdd，然后双击 Enter。则bdd图已创建。
注：请注意，该图以存储它的包命名。这个名称也非常适合该图。您只需要从其名称中删除序列号。
3. 单击图面板上的Block按钮，然后单击该图窗口中的空白区域。创建了一个未命名的模块。
4. 键入 MoEs Holder 以指定此模块的名称，然后按 Enter。
5. 在Model Browser中，选择 Climate Control Unit 模块并将其拖到图窗口中。Climate Control Unit模块的图块出现在图中。
6. 单击 MoEs Holder模块的智能操纵器工具栏上的Generalization 按钮，然后单击 Climate Control Unit 模块的图块。MoEs Holder 模块成为Climate Control Unit模块的超类型。
Step 3. 捕获 MoE
现在让我们分析非功能性利益相关者需求SN-1.3 Noise Level和 SN-1.4 Climate Control Mass。SN-1.3 提示您创建Sound Level MoE，SN-1.4 确定Total Mass MoE。让我们在您的模型中捕获这些 MoEs。
捕获Vehicle Climate Control Unit的 MoEs：
1. 选择 MoEs Holder 模块的图块，然后单击Create Element按钮 >Value Property。
2. 键入 Sound Level 以指定新值属性的名称，然后按 Enter。
3. 右键单击 value 属性并选择 Stereotype。
4. 在搜索框中，输入 moe 并按 Ctrl+空格键 选择 «moe» 模板。
5. 按 Enter。«moe» 模板应用于Sound Level值属性。
6. 右键单击 value 属性并选择 Is Derived。它变成了派生的，这意味着它是可计算的（不可定义的）。
7. 重复整个过程以捕获Total Mass MoE。
除此之外，您应该为这些 MoE 指定值类型。大多数常用的值类型都存储在 ISO 80000 单位library中。
将标准单元（来自库）设置为 MoE 类型：
1. 选择任何值属性，然后单击智能操纵器工具栏上的 ISO。等到单元库加载完毕。
2. 选择Total Mass值属性，然后单击智能操纵器工具栏上的指定类型(Specify Type)按钮。
3. 键入kilog以查找mass[kilogram]值类型并选择它。类型已指定。
自定义单位应手动创建。
将自定义单位设置为 MoE 类型：
1. 选择Sound Level属性，然后单击智能操纵器工具栏上的指定类型按钮。
2. 键入 dBA 并按 Enter。自定义值类型将直接在模型中4 Measurements of Effectiveness 包下创建，并指定为 Sound Level 值属性的值类型。
注：作为 MoEs Holder 模块捕获的一组 MoE 稍后可以用于不同的模型，以将相同的数值特征分配给其他感兴趣的系统。
1.3 白盒视角
1.3.1 简介
一旦完成了从黑盒视角定义问题，或者说完成了 SoI 的操作分析，您可以切换到从白盒视角分析 SoI。这有助于详细了解系统应如何运行，而不是已经生成系统设计。
在问题域定义的第二阶段，您应该对系统功能进行更深入的分析，以识别功能模块，也称为 SoI 的逻辑子系统。功能模块是系统方案架构的第一步。
对系统功能进行更深入的分析称为功能分解。如下图所示，SoI 执行的每个功能（如 B2 单元格（第2层）中所标识的）都在 W2.initial 单元格（第3层）中分解。详细行为的功能之后将按功能模块分组，以传达每个功能模块执行一个或多个功能。
功能分解过程可以根据需要进行多次迭代，以实现问题域定义的相关颗粒度。如下图所示，每个细节层的功能都可以分解为更详细的行为。功能模块相应地分解为更基本的结构。 值得一提的是，系统行为和结构的颗粒度必须在每个细节级别保持一致。
在识别逻辑子系统之后，可以指定它们之间的交互。每个子系统都可以有自己的数值特征，即效能指标MoE。SoI 的功能、其逻辑架构和 MoEs 共同建立了指定系统要求的基础（参见 S1 单元）。
在相关页面中逐步解释了从白盒视角对问题域建模。
1.3.2 W2.功能分析:initial
它是什么？
在此单元格中，您应该通过分解 B2 中 SoI 执行的每个功能来更深入地分析系统行为。
该单元中的建模包括两个阶段：initial和final。在 W2 的initial阶段，由 SoI 执行的顶级功能被分解以指定更详细的系统行为。这有助于识别执行这些功能的功能模块，也称为逻辑子系统。要捕获这些子系统，您应该切换到 W3。之后，您应该返回 W2 并指定哪些子系统负责执行哪些功能。
重要的是要注意，进行更深入的分析，功能分解后的子功能也可以分解。可以根据需要进行多次分解，以达到您需要解决的问题的相关颗粒度。从其子功能的角度来看，每个分解的子功能都被视为一个功能。
W2 单元的初始阶段产生的被分解的用例场景，也称为白盒场景。
谁是负责的人？
在典型的多学科系统工程团队中，功能分析由需求团队执行。
如何建模？
功能分析是使用 SysML 活动图对用例场景进行连续的细化。
应该为 B2 中分配给 SoI 的每个功能创建一个新的 SysML 活动图。 尽管有两个甚至更多泳道分区，但您应该只选择嵌套在表示捕获 SoI 的模块的分区下的那些功能。下图显示了由Climate Control Unit 的SoI 执行的Reach Required Temperature功能（它是Feel Comfortable Temperature用例场景的一部分）的白盒场景。
对白盒场景的action流进行建模会促进 SoI 逻辑子系统的识别。
下一步是什么？
- 白盒场景促进了 SoI 逻辑子系统的识别。因此，下一个单元格是 W3。
Tutorial
Step 1. 为 W2 梳理模型
根据 MagicGrid 框架的设计，捕获分解系统功能的模型工件应该存储在下图所示的包结构下。可以看到，顶层包代表域，中层包代表视角，底层包代表单元格。
为 W2 梳理模型
1. 右键单击 1 Problem Domain 包并选择 Create Element。
2. 在搜索框中，输入 pa（元素类型 Package 的前两个字母），然后按 Enter。
3. 键入 2 White Box 以指定新包的名称并按 Enter。
4. 右键单击 2 White Box 包并选择 Create Element。
5. 重复步骤 2 和 3 以创建名为 2 Functional Analysis 的包。
Step 2. 创建活动图以分解功能
假设您想将模型中捕获的功能分解为Reach Required Temperature活动。如果是这样，您需要在该活动中创建一个 SysML 活动图。
在Reach Required Temperature活动中创建 SysML 活动图
1. 打开Reach Required Temperature活动图：
a. 按 Ctrl + Alt + F 打开Quick Find对话框。
b. 单击Diagram以设定仅搜索图并键入 Fe。
c. 当您看到在搜索结果列表中选择的 Feel Comfortable Temperature 活动图（见下图）时，按 Enter。活动图已打开。
2. 选择 Reach Required Temperature action的图块，然后单击其智能操纵器工具栏上的 SysML Activity Diagram 按钮（参见下图）。 一个新创建的活动图打开。
3. 在Model Browser中，选择Reach Required Temperature action：
a. 右键单击图窗口上的Reach Required Temperature action的图块。
b. 选择Go To > Behavior Reach Required Temperature。在模型浏览器中该活动已被选中。
4. 将Reach Required Temperature action拖到2 Functional Analysis包中。相关活动图一起移入。
注：现在，如果您返回活动图Feel Comfortable Temperature（只需单击打开图工具栏上的返回箭头），您可以看到Reach Required Temperature action的图块装饰有耙子图标()。该图标意味着此action包含一个内部图，只需双击该action的图块即可打开该图。
Step 3. 指定白盒场景
现在让我们指定捕获为Reach Required Temperature活动的功能的白盒场景。
假设该场景包括以下步骤：
1. 系统准备
2. 加热（如果所需温度高于（>）舱内温度）
3. 降温（如果所需温度低于（<）舱内温度）
4. 传输数据
5. 显示数据
指定Reach Required Temperature活动的白盒场景：
1. 如果尚未打开，请打开Reach Required Temperature活动图。
2. 确保在图中启用了自动行为创建(Automatic Behavior Creation)模式。否则，图表中创建的action将不会以活动输入。为此，单击Automatic Behavior Creation按钮一次或两次。
3. 单击图面板上的Initial Node按钮，然后单击图窗口上的空白位置。创建初始节点。
4. 单击初始节点图块的智能操纵器上的Control Flow按钮，然后单击图窗口上的空白处。 创建由新活动输入的新action。
5. 键入 Prepare System，然后按 Enter。
注：确保在冒号 (“:”) 后键入名称。否则，名称将赋予给action，但不会分配给类型是该action的活动。
6. 捕获其他项目以构建完整的场景，如下图所示。以下是帮助您的指南：
- 要捕获action，请使用智能操纵器工具栏，如步骤 4 中所示。
- 要在现有元素之间绘制控制流，请单击要位于尾端的元素的智能操纵器上的Control Flow按钮，然后单击要位于箭头端的元素。
- 要更改在新控制流箭头端创建的元素的类型（例如，从action到decision或从decision到merge），请右键单击（而不是简单地单击！）图窗口并选择该类型。
- 要指定判定条件(guard)，请选择控制流并键入方括号，然后指定条件，例如，[Required Temp > Cabin Temp。
刚刚创建的场景使我们能够假设Vehicle Climate Control Unit可能由四个子系统组成：一个用于控制其他子系统，一个用于加热空气，一个用于冷却空气，一个用于向用户显示数据。因此，现在是移动到 W3 单元格并学习如何捕获它们的时候了。
1.3.3 W3.逻辑子系统通信
它是什么？
虽然initial phase of the W2 cell的功能分析有助于识别逻辑子系统，但该单元将在模型中定义它们。逻辑子系统应被视为一组互连和交互的部件，它们执行感兴趣的系统的一个或多个功能。
需要注意的是，每个子系统都可以分解为更基本的结构。这种分解的迭代次数取决于您要解决的系统架构的颗粒度级别。从其内部部件的角度来看，每个子系统都被视为一个系统。
总的来说，这个单元格产出：
- SoI 的输入和输出
- SoI 交互的逻辑子系统的定义：
- 逻辑子系统之间
- 逻辑子系统与系统外部之间
谁是负责的人？
在典型的多学科系统工程团队中，系统的结构分解由需求团队执行。
如何建模？
要定义 SoI 的输入和输出，您可以使用为模块创建的 bdd 基础结构，它代表您模型中的系统。这些输入和输出可以指定为系统模块的代理端口(proxy port)。其中一些通常是通过分析 B3 中指定的系统上下文来确定的，而其他一些则是根据initial phase of the W2 cell执行的功能分析的结果来确定的。代理端口应按接口模块输入，我们建议将其存储在单独的文件夹中，以保持模型梳理良好。下图显示了Climate Control Unit的输入和输出。
要定义 SoI 的逻辑子系统以及它们之间的交互，您可以利用为代表模型中 SoI 的模块创建的 ibd 基础结构。在initial phase of the W2 cell执行功能分析时识别的逻辑子系统可以指定为表示 SoI 的模块的part属性。输入这些part属性的模块应存储在单独的文件夹中，以保持模型梳理良好。这些part属性之间的连接器表示适当的逻辑子系统之间的交互。part属性与图框之间的连接器表示part属性与系统外部（输入和输出）之间的交互。应通过代理端口(proxy port)建立连接。下图显示了Climate Control Unit的逻辑子系统。
如果功能分析需要分解 SoI 的一个或多个子系统，我们强烈建议对每个子系统使用与 SoI 相同的模型结构模式。为每个较低级别重复在最高抽象级别创建的结构有助于建立良好且易于阅读的模型递归结构。
下一步是什么？
- 在定义了逻辑子系统并指定了它们之间的交互后，您可以通过将子功能按逻辑子系统分组来完成功能分析，这意味着您应该移动到 W2.final。
Tutorial
Step 1. 为 W3 梳理模型
遵循MagicGrid框架的结构，捕获系统架构的模型构件应该存储在2 White Box包中的一个单独的包中。我们建议将包命名为Logical Architecture(逻辑架构)。
为W3梳理模型：
1. 右键单击2 White Box包并选择Create Element。
2. 在搜索框中,键入pa（元素类型Package的前两个字母）,并按Enter。
3. 键入3 Logical Architecture指定新包的名称，并按Enter。
为了更好地梳理3 Logical Architecture包的内部结构，您需要创建更多的包。它们是:
- 1 Interfaces(接口)
- 2 Logical Subsystems
当您自己创建它们时(通过遵循前面的过程)，您Model Browser内的方案域模型应该与下图中显示的相同。
Step 2. 创建用于捕获SoI接口的bdd
要开始捕获接口(指定SoI的输入和输出)，首先需要创建一个bdd，并在图窗口上显示捕获系统的模块。但是在此之前，您应该通过将该模块移动到包3 Logical Architecture来更改模型中该模块的位置。
创建和准备用于捕获SoI接口的bdd：
1. 创建bdd:
a. 右键单击3 Logical Architecture包并选择Create Diagram。
b. 在搜索框中，键入SysML模块定义图的首字母缩写bdd，然后按Enter键。创建bdd图。
c. 键入Climate Control Unit指定新图的名称，并再次按Enter键。
2. 在Model Browser中，选择Climate Control Unit模块。为此，使用快速查找功能:
a. 按Ctrl + Alt + F，快速查找(Quick Find)对话框打开。
b. 键入Cli。
c. 当您在搜索结果列表中看到Climate Control Unit模块被选中时(见下图)，按Enter键。Climate Control Unit模块在Model Browser中被选中。
3. 拖动Climate Control Unit模块到新创建的3 Logical Architecture包 (参见step 1 of the W3 tutorial)。
4. 将Climate Control Unit模块拖到图窗口中。模块的图块出现在图上。
Step 3. 捕捉SoI接口
通过分析final phase of the B3 cell指定的系统上下文，我们可以得出结论，Climate Control Unit从车辆的客舱中吸走空气且必须由车辆乘员控制。这些是SoI的输入。它还需要电力和机械动力，这可以从initial phase of the W2 cell进行的功能分析结果中得到。
功能分析结果还显示，Climate Control Unit为客舱提供冷却或加热空气。系统状态，如Climate Control On或Climate Control Off，以及机舱内的空气温度也会输出。这可以从final phase of the B3 cell指定的系统上下文中识别出来。
输入和输出可以指定为Climate Control Unit模块的代理端口(proxy port)。代理端口不需要名称，但是它们应该由接口(interface)模块来定义，接口模块定义了上面描述的输入和输出。in方向的接口模块的流属性表示输入，out方向的接口模块的流属性表示输出。
捕获系统接口：
1. 打开Climate Control Unit Interfaces图(如果还没有打开的话)。
2. 确保图中的Type Selection Mode是打开的。该模式允许您在创建代理端口后立即输入(带有接口块)。
3. 选择Climate Control Unit模块的图块，并在其智能操纵器上单击代理端口(Proxy Port)按钮(见下图)。一个新的代理端口出现在图块的边界上。
注：代理端口默认为p1, p2，…pn。没有必要重命名它们，因为它们不传递任何语义。
4. 在代理端口图块上直接在冒号(“:”)旁边键入Air并按Enter。一个用于输入代理端口的新接口模块被创建并显示在Model Browser的3 Logical Architecture包中。
5. 选择该接口模块并将其拖到图窗口中。接口模块的图块出现在图上。
6. 单击该图块上的Create Element按钮，然后选择Flow Property。
7. 直接在接口模块的图块上键入Air Flow来指定新的流属性的名称并按Enter键。
注：在本例中，您不需要修改flow属性的方向，因为默认的方向应该是inout。在相反的情况下，您可以简单地通过删除方向指示器的不相关部分(In或out)来改变方向。
结果，一个双向箭头出现在代理端口的图块上(见下图)。这表明代理端口既是SoI的输入接口，也是SoI的输出接口。
8. 重复step3 ~step7指定其他接口。完成之后，Climate Control Unit接口图的内容应该类似于下图。
注：我们建议在Climate Control Unit模块的左侧边界放置in代理端口的图块，并在右侧边界放置out和inout代理端口的图块。
注：下图显示了Blackbox ICD Table，这是Climate Control Unit interfaces的另一种视图。本教程没有解释如何构建表，但是您可以在建模工具的最新文档中找到此信息。
9. 在Model Browser中，选择所有的接口模块，并将它们拖到您在step 1 of the W3 tutorial中创建的1 Interfaces包中。
注：要在结构树中选择一组不相邻的项，请单击第一个项，按Ctrl，并在按住它的同时，依次选择其他项。
模块被移动到1 Interfaces包中。
Step 4. 创建用于捕获逻辑子系统的ibd
Climate Control Unit的逻辑子系统可以在ibd中指定，它属于Climate Control Unit模块。根据SysML，此图的框架表示SoI的边界，因此允许您通过代理端口指定SoI内部部分与系统外部之间的交互(参见step 3 of the W3 tutorial)，显示在该框架上。
创建一个ibd来捕获SoI的逻辑子系统：
1. 在Model Browser中，右键单击Climate Control Unit模块，选择Create Diagram。
2. 在搜索框中，键入SysML内部框图的首字母缩写ibd，然后按Enter。打开Display Parts/Ports对话框。
3. 单击Clear All，然后单击对话框右侧的Proxy Port。在左侧的结构树中，只有Climate Control Unit模块的代理端口被选中。
4. 单击OK。内部模块图被创建，并且代理端口显示在它的边框上。
5. 键入Climate Control Unit subsystems指定新图的名称，并再次按Enter键。
6. 将in代理端口的图块移动到图框的左边框上，将inout代理端口的图块移动到右边框上。
您的内部模块图的最终视图应该类似于下图。
注：当Climate Control Unit接口bdd(参见step 3 of the W3 tutorial)将SoI表示为一个黑盒时，ibd被创建，为将相同的系统表示为一个白盒: Climate Control Unit模块被打开以查看其内部结构。这就是为什么bdd中Climate Control Unit模块的边界上显示的代理端口会显示在ibd的框图中。
Step 5. 捕捉逻辑子系统
正如initial phase of the W2 cell的功能分析显示的那样，Climate Control Unit由以下几个逻辑子系统组成:
- Control System
- User Interface (UI) System
- Heating System
- Cooling System
这些子系统可以指定为Climate Control Unit模块的part属性。part属性不需要名称，但它们应该由定义上述逻辑子系统的模块输入。
定义逻辑子系统：
1. 打开在step 5 of the W3 tutorial中创建的Climate Control Unit Subsystems ibd图（如果尚未打开）。
2. 确保图中的Type Selection Mode处于打开状态。否则，在此图中创建的部件将不会按block输入。
3. 单击图面板上的 Part Property 按钮，然后单击图窗口上的空白处。创建了一个未命名的part属性，并提供了要输入它的现有block的列表。
4. 直接在part属性图块上的冒号 (“:”) 旁边键入Control System，然后按 Enter。用于输入刚刚创建的part属性的 Control System 模块在Model Browser中创建。
5. 重复step 3和4，从上面的列表中创建另一个逻辑子系统。
当你完成后，你的Climate Control Unit Subsystems的ibd图应该看起来非常与下图相似。
Step 6. 在SoI的上下文中指定交互
逻辑子系统可以相互交互，也可以与系统外部交互。两个子系统之间的交互可以指定为连接两个适当part属性的连接器。子系统和SoI外部之间的连接可以指定为连接适当的part属性和图框架的连接器(在这里，您应该记住ibd中的图框架表示SoI的边界)。在这两种情况下，连接器都是通过代理端口建立的。
从指定来自SoI外部的交互连接开始会更容易一些。让我们指定Climate Control Unit的所有逻辑子系统都需要电力或机械动力，也就是一般的能量。
通过Energy代理端口在图框架和Control System part属性之间绘制一个连接器：
1. 选择Energy代理端口，并单击其智能操纵器工具栏上的连接器按钮。
2. 单击Control System part属性。
3. 选择New Proxy Port。在Control System part属性上创建代理端口，并在图框架和所选part属性之间建立连接器。
重复上述步骤，绘制其余适当的连接器。当你完成后，你的Climate Control Unit Subsystems ibd图应该与下图非常类似。
此外，有必要指出，Heating System从舱室中吸取一些空气，并将加热后的空气送回。
通过Air代理端口在图框架和Heating System part属性之间画一个连接器：
1. 选择Air代理端口并单击其智能操纵器工具栏上的连接器按钮。
2. 点击Heating System part属性。
3. 选择New Proxy Port。在Heating System part属性上创建代理端口，并在图框架和所选part属性之间建立连接器。
重复这个步骤来绘制另一个连接器，这次是在图框架和Cooling System part属性之间，以指定Cooling System也从舱室中吸取一些空气，并将冷却的空气送回。因此，您的ibd图应该如下图所示。
注：可以通过修改连接器的符号属性来更改连接器的颜色(以及其他特性)。为此，右键单击连接器并选择Symbol Properties。在打开的对话框中，选择Pen Color属性的值单元格，然后点击…按钮来打开Color对话框。然后选择蓝色，或任何其他你想要的颜色，并关闭两个对话框。
与SoI外部的另一个交互是接受用户(即车辆乘员)的命令，并提供信息，如Climate Control Unit的状态或车厢温度。
通过I/O代理端口绘制图框架和UI System part属性之间的连接器：
1. 选择I/O代理端口，并单击其智能操纵器工具栏上的Connector按钮。
2. 单击UI System part属性。
3. 选择New Proxy Port。在UI System part属性上创建一个代理端口，并在图框架和所选part属性之间建立连接器。
现在是时候指定子系统之间的交互了，所以让我们定义Control System 管理Climate Control Unit中其余的逻辑子系统，并接收它们各自的状态。
在Control System和UI System part属性之间绘制连接器：
1. 选择Control System part属性，并单击其智能操纵器工具栏上的代理端口按钮。
2. 选择I / O。新的代理端口由I/O接口模块输入。
3. 选择其智能操作器工具栏上的Connector按钮。
4. 单击UI System part属性。
5. 选择New Proxy Port。在UI System part属性上创建一个代理端口，并在这些part属性之间创建新的连接器。
重复上述步骤，从Control System part属性绘制到Heating System和Cooling System part属性的连接器。完成后，您的Climate Control Unit Subsystems ibd图应该与下图非常类似。
注：下图显示了Climate Control Unit Subsystems ibd的另一个视图。本教程没有解释如何构建表，但是您可以在建模工具的最新文档中找到这些信息。
定义逻辑子系统的模块默认情况下与Climate Control Unit 模块存储在同一个包中。为了保持模型的良好结构，我们建议将它们移到2 Logical Subsystems包中，它是3 Logical Architecture包的子包。
将捕获逻辑子系统的模块移动到2 Logical Subsystems包中：
1. 在Model Browser中，选择所有捕获逻辑子系统的模块。
2. 将选中项拖到2 Logical subsystems包中。
注：当您决定分解这些子系统时，请记住，指定每个子系统的模型结构应该通过使用与SoI相同的结构模式来创建。下图展示了在Cooling System分解的情况下系统模型的结构。
1.3.4 W2.功能分析:final
它是什么?
W2单元的final阶段是完成SoI功能分析的必要阶段。完成需要将系统行为分配给该系统的结构。换句话说，您应该指定W3中定义的逻辑子系统负责执行每个功能。为此，功能按逻辑子系统分组。
在这里，重要的是要理解系统行为和结构的颗粒度必须在每个细节级别上保持一致。这意味着您不能将子系统组件的功能分配给该子系统。这就是为什么我们建议在SoI的功能-结构分解的每次迭代中，按照精确的顺序执行W2.initial, W3和W2.final。只有在您完全完成当前颗粒度级别之后，才有可能进行更深入的分析。行为分解和结构分解颗粒度级别之间的推荐对应关系如下图所示。
负责人是谁?
在一个典型的多学科系统工程团队中，功能分析是由需求团队执行的。
如何建模?
在显示initial phase of the W2 cell捕获的白盒场景的SysML活动关系图中，子系统可以表示为泳道分区。泳道分区实际上代表了SoI块的part属性。捕获系统功能的action可以很容易地分配给相关的泳道分区，方法是将该action拖放到它上面。
如下图所示为Reach Required Temperature功能的各个子功能，按照SoI的逻辑子系统进行分组：Control System、UI System、Heating System和Cooling System。
接下来是什么?
- 系统功能和逻辑架构，无论是否具有SoI的数值特性，都为系统需求规范建立了基础。因此，您可以切换到W1。
- 您可能还需要为一个或多个逻辑子系统指定数值特征，这将比在B4中为整个SoI定义的那些更具体。在这种情况下，您应该移动到W4。
Tutorial
Step 1. 通过逻辑子系统对功能进行分组
现在是时候用泳道分区更新SysML活动图Reach Required Temperature(参见step 2 of the W2 initial phase tutorial)了，泳道分区代表Vehicle Climate Control Unit的逻辑子系统。在后续中，应该将action分配给这些泳道分区，以便指定哪些逻辑子系统负责执行每个功能。
按照逻辑子系统对功能进行分组
1. 打开SysML活动图Reach Required Temperature:
a. 按Ctrl + Alt + F打开Quick Find对话框。
b. 单击Diagram以便只搜索图，并键入Rea。
c. 当您看到在搜索结果列表中选择了SysML活动图Reach Required Temperature(参见下图)时，请按Enter。图被打开。
2. 在Model Browser中选择Climate Control Unit模块:
a. 按Ctrl + Alt + F打开Quick Find对话框。
b. 单击Any Element只搜索特定的元素，然后键入Cli。
c. 当您在搜索结果列表中看到Climate Control Unit模块被选中时(见下图)，按Enter键。
3. 展开选定的模块(如果还没有展开的话)，并选择它所包含的所有part属性。
注：要选择结构树中相邻项的集合，请单击第一个项，按Shift键，同时按住它，选择最后一个项。
4. 将选中项拖到打开的图窗口的空白区域。空白的泳道分区与标题命名为相应的part属性被创建并显示在图中(见下图)。
注：如果您希望分区的顺序与下图相同，请选择Control System分区的顶部，并单击Move Swimlane Left按钮两次。因此，它成为连续的第二个分区。
5. 右键单击任一泳道分区并选择Allocation Mode > Usage。在图中启用了对使用模式的分配。
6. 将Prepare System和Transfer Data action、初始节点和最终节点(两者都是合并节点)以及决策节点拖动到Control System分区。
7. 将Heat action拖动到Heating System分区。
8. 将Cool action拖动到Cooling System分区。
9. 拖动Display Temperature到UI System分区。
完成之后，SysML活动图Reach Required Temperature应该与下面的图非常相似。
尽管比step 5 of the B2 tutorial中定义的黑盒场景更详细，但这仍然是一个高级场景，也应该进行分解。为此，您应该分解每个功能，根据需要对W2.initial、W3和W2.final步骤执行尽可能多的迭代。
1.3.5 W4.分系统效能分析
它是什么？
在此单元格中，您应该为 SoI 的一个或多个子系统指定效能分析，以进一步细化非功能性利益相关者的需求。 此单元格是可选的，因为您可能不需要指定除了 B4 单元格中定义的效能分析之外的其他效能分析。
谁是负责的人？
在典型的多学科系统工程团队中，MoE 由需求团队指定。
如何建模？
要在建模工具中捕获子系统的效能分析，您可以利用 SysML bdd 的基础结构——就像您使用它在 B4 单元中捕获 SoI 的效能分析一样。 有可能在这个单元中你甚至不需要创建一个新的 bdd； 您可以利用为指定子系统接口而创建的一个。 为了更好地理解，请记住 step 6 of the W3 tutorial末尾给出的示例。 想象一下，Cooling System 已经在直接在 Cooling System 包下创建的 bdd 中指定了接口（参见step 3 of the W3 tutorial）。这个 bdd 以后可以用于另一个目的，即，用于捕获Cooling System的效能分析。
下一步是什么？
l 通过效能指标，您可以指定设计约束，可用于验证系统设计（参见 S4）。
Tutorial
1.3.6 B1-W1.利益相关者需求:final
它是什么？
为了拥有完整的问题域模型，您需要在捕获利益相关者需求的元素与捕获 SoI 的功能、逻辑架构和非功能特征的元素之间建立可追溯关系。 由于后者比利益相关者的需求更具体，我们建议建立细化关系。 这些关系应该指向最低细节层次的元素，例如，捕获功能分解模型的叶函数的活动。 在理想情况下，利益相关者的每一项需求都必须通过其他 SysML 类型的一个或多个元素进行细化。
谁是负责的人？
在典型的多学科系统工程团队中，可追溯性关系由需求团队建立。
如何建模？
这两个 SysML 图都不适合创建大量整合关系，例如 «refine»(改善)。 为此，矩阵或映射更合适。 该建模工具提供了多种用于指定整合关系的预定义矩阵。为了捕获«refine»关系，可以使用Refine Requirement Matrix(改善需求矩阵)。
下一步是什么？
- 您可以转到指定系统需求，这在 S1.initial 中进行了描述。
Tutorial
Step 1. 创建用于捕获改善关系的矩阵
为了准备好捕捉«refine»关系，您应该首先创建一个 Refine Requirement Matrix。由于该矩阵用于指定存储在模型中的 1 Stakeholder Needs 包（作为需求）下的利益相关者需求的改善，因此也可以在此处创建。
预定义矩阵在其列中表示需求，并在其单元格中改善关系。您只需要指定矩阵在其行中显示活动和值属性（带有«moe»元类型），并且
- 列元素取自 1 Stakeholder Needs 包
- 行元素取自2 Functional Analysis包和4 Measurements of Effectiveness包
创建改善需求矩阵：
1. 连续展开1 Problem Domain和1 Black Box packages包（如果尚未展开）。
2. 右键单击 1 Stakeholder Needs 包并选择 Create Diagram。
3. 在打开的对话框中，单击Expert按钮以打开相应的模式。
4. 在搜索框中，键入 rrm，它是 Refine Requirement Matrix 的首字母缩写词，然后按 Enter。 矩阵已创建。
5. 键入 Functions and MoEs to SNs 以指定新矩阵的名称，然后再次按 Enter。
6. 指定列元素类型：
a. 在Model Browser中，选择 1 Stakeholder Needs 包。
b. 将其拖到矩阵内容上方 Criteria 区域中的 Column Scope 框中。选中的包成为矩阵列的范围（见下图）。
7. 指定行元素类型：
a. 在Model Browser中，选择任何活动；例如，Cool活动。
b. 按住 Ctrl 键，选择任意值属性；例如，Total Mass值属性。
c. 将所选内容拖到矩阵内容上方Criteria区域中的Row Element Type框上。矩阵的行设置为显示所选类型的元素（见下图）。
8. 指定行元素范围：
a. 在Model Browser中，选择 2 Functional Analysis 包。
b. 按住 Ctrl 键，选择 4 Measurements of Effectiveness 包。
c. 将所选内容拖到矩阵内容上方 Criteria 区域中的 Row Scope 框中。选中的包成为矩阵行的范围（见下图）。
下图显示了矩阵的Criteria区域，突出显示了第 6、7 和 8 步相关条件。
Step 2. 捕获改善关系
现在您已准备好捕捉改善关系。让我们在 Cool 活动和 SN-1.2 Heat 和 Cool Modes 利益相关者需求（作为需求捕获）之间创建一个，以传达前者对后者的改善。
指定矩阵中的改善关系：
1. 双击显示SN-1.2 Heat and Cool Modes需求的行与显示Cool活动的列交叉处的单元格。 派生关系在适当的项目之间创建并显示在单元格中。
捕获所有改善关系后，您的 Functions 和MoEs to SNs矩阵应该类似于以下由其他 SysML 类型的一个或多个元素定义的矩阵。
