在基于模型的系统工程（MBSE）领域中，清晰性至关重要。工程师和架构师不断在系统设计的复杂领域中探索，力求精确地表达系统的结构与意图。系统建模语言（SysML）工具箱中两个最关键的工具是需求图和块定义图。尽管两者都是标准的基础，但它们各自承担着不同的用途，并在不同抽象层次上运作。
在恰当的时机选择合适的图表，可以防止模型膨胀，并确保利益相关者能够清晰地理解系统定义，避免混淆。本指南深入探讨了这两种图表在机制、应用和战略上的差异。我们将分析它们的结构元素、关系类型，以及在哪些特定场景下一种图表优于另一种。无论你是定义高层架构，还是追踪特定的安全需求，理解这一区别对于构建稳健的系统定义都至关重要。
理解SysML基础 🏗️
SysML是一种通用建模语言，旨在用于指定、分析、设计和验证复杂系统。它扩展了统一建模语言（UML），以满足系统工程的特定需求。SysML的核心原则是关注点分离。不同的图表聚焦于系统的不同方面，以保持模型的可管理性。
在构建模型时，你必须决定如何表示系统。你是在定义什么系统必须做什么，还是在定义如何系统是如何构建的？这一根本性问题通常决定了是选择需求图还是块定义图。
- 需求图：关注系统必须满足的需求、约束和条件。它是可追溯性和验证的主要载体。
- 块定义图：关注系统的组成、结构和内部组织。它定义了构成整体的物理或逻辑部分。
混淆常常产生于两个图表都涉及“项目”这一概念。然而，在SysML中，需求上下文中的项目是一个逻辑需求，而块上下文中的项目则是一个结构组件。明确区分这一点，是实现有效建模的第一步。
块定义图（BDD） 🧱
块定义图是SysML中系统架构的基石。它提供了系统结构的高层视图。可以将其视为系统骨架的蓝图。它定义了块、它们的属性以及块之间的关系。
BDD的核心元素
多个特定元素构成了BDD。理解这些元素对于准确建模至关重要。
- 块：结构的基本单元。块代表一个物理或逻辑组件。它可以是一块硬件、一个软件模块、一个子系统，甚至是一个抽象概念。
- 属性：这些定义了块的特征。属性是块的一部分。例如，发动机是一个块，其燃油箱是该发动机的一个属性。
- 端口：端口定义了块与其环境或其他块交互的接口。它们指定了流入或流出的信息或能量类型。
- 操作：块可以定义其执行的行为。操作是与块相关联的功能或方法。
- 约束：尽管BDD主要处理结构，但可以对块施加约束，以定义属性上的数学限制或逻辑条件。
BDD中的关系
BDD 的强大之处在于各个模块之间的相互关系。这些关系定义了系统的组成。
- 关联： 模块之间的通用连接。它表示一个模块的实例与另一个模块的实例相连。这并不表示拥有关系。
- 聚合： 一种较弱的组合形式。它表示一种“整体-部分”关系，其中部分可以独立于整体存在。例如，图书馆包含书籍，但书籍可以在没有图书馆的情况下独立存在。
- 组合： 一种强聚合形式。它表示部分无法脱离整体而存在。如果整体被销毁，部分也将被销毁。这对于定义系统层次结构至关重要。
- 泛化： 定义继承关系。一个特定模块是更一般模块的特化版本。这有助于复用结构定义。
何时使用BDD
当您需要定义系统架构时，应使用模块定义图。它是以下用途的首选图表：
- 建立系统层次结构和分解。
- 定义子系统之间的接口。
- 指定系统的物理或逻辑构成。
- 可视化数据或能量通过结构连接的流动。
- 记录特定子系统的内部结构。
例如，如果您正在设计一艘航天器，BDD 将定义主干、电源分配单元、热控系统以及它们之间的物理连接方式。它回答了这样一个问题：“系统由什么构成？”
需求图（ReqD）📋
需求图是管理系统需求生命周期的主要工具。它允许您组织需求、定义其层级关系，并将其与其他模型元素关联。与关注物理结构的BDD不同，需求图关注的是意图和义务。
需求图的核心元素
需求图包含一组特定元素，用于管理逻辑关系和可追溯性。
- 需求： 对需满足的需求或条件的陈述。需求按类型分类（例如：功能、性能、接口）。
- 需求图： 用于容纳需求及其关系的容器。一个单一的系统模型可以包含多个用于不同领域的需要图。
- 需求属性： 可以附加到需求上的属性，如ID、优先级、状态和验证方法。
- 约束： 限制系统行为或状态的数学或逻辑表达式。
需求图中的关系
可追溯性是需求图的超能力。SysML为需求定义了四种特定的关系类型：
- 细化：将高层次需求与更详细的子需求相连。它展示了需求是如何被分解为可管理的部分的。
- 追溯：连接两个在逻辑上相关但不一定具有层级关系的需求。例如，客户的需求可能追溯到子系统派生出的需求。
- 满足：将需求与满足它的设计元素（如块或活动）相连。这对于验证至关重要。
- 推导：将一个需求与从其逻辑推导出的另一个需求相连。这通常发生在分解过程中。
何时使用需求图（ReqD）
当你需要管理系统的“为什么”和“是什么”时，需求图至关重要。使用它来：
- 捕获利益相关者的需求和约束。
- 在需求与设计之间建立可追溯性矩阵。
- 确保每个需求都由一个设计元素来满足。
- 管理需求变更在整个模型中的影响。
- 验证系统中不存在孤立的需求。
使用需求图可确保系统是为实现使命而构建的。它回答了这样一个问题：“系统必须实现什么？”
关键结构差异 🆚
为了巩固这一区别，让我们并排比较这些图表在处理数据、关系和范围方面的异同。
| 特性 | 块定义图（BDD） | 需求图（ReqD） |
|---|---|---|
| 主要关注点 | 系统结构与组成 | 系统需求与可追溯性 |
| 核心元素 | 块、端口、属性、操作 | 需求、约束、关系 |
| 关键关系 | 组合、聚合、关联 | 细化、满足、追溯、推导 |
| 范围 | 物理/逻辑架构 | 功能/性能意图 |
| 验证链接 | 由……满足（通过满足关系） | 满足（通过满足关系） |
| 变更影响 | 结构变更影响接口 | 需求变更影响验证 |
此表强调，尽管它们相互关联，但在功能上并不重叠。BDD 描述的是容器，而 ReqD 描述的是任务的内容。
何时选择 BDD 而非 ReqD 🏗️
在系统工程生命周期的某些特定阶段，块定义图是更优的选择。若依赖需求图进行结构定义，会导致混淆。
1. 定义系统层级
当您处于项目的顶层时，需要将系统分解为可管理的子系统。BDD 允许您定义一个顶层块，并将其与更低层级的块组合。这将形成一个清晰的分解树。
- 使用组合来表示所有权。
- 使用泛化来表示可重用的子系统。
- 使用属性来定义系统的库存。
2. 规定接口
接口是系统交汇的边界。在 SysML 中，接口通常使用 BDD 上的端口和流来建模。如果需要定义电压、数据协议或机械安装点，BDD 是正确的建模工具。
- 定义标准接口以确保兼容性。
- 可视化块之间的信号流动。
- 确保物理连接与逻辑连接一致。
3. 建模物理约束
如果系统存在物理限制，如重量、体积或功耗，这些通常作为 BDD 中块的属性进行建模。虽然可以在 ReqD 中使用约束，但结构约束最好直接放在块本身上。
4. 架构评审
在架构评审过程中，利益相关者需要看到系统的结构。他们会询问组件及其组合方式。BDD 提供了架构决策的可视化证据，它是系统物理现实的地图。
何时选择 ReqD 而非 BDD 🎯
相反，有些情况下 BDD 不够充分。如果重点在于合规性、验证或任务成功，需求图则具有优先权。
1. 捕获利益相关者需求
任何项目的第一步都是理解客户的需求。这是一个逻辑上的任务，而不是结构上的任务。你不能为“客户满意度”画一个模块。你必须使用需求来捕捉这一意图。
- 记录所有功能性和非功能性需求。
- 立即分配优先级和验证方法。
- 确保在设计过程中没有需求被遗漏。
2. 管理可追溯性
可追溯性是指能够从需求的来源追踪到其实施过程的能力。ReqD 是唯一专门设计用来清晰展示这一传承关系的图表。它将利益相关者的需求链接到派生需求，再链接到设计模块。
- 将高层次需求与低层次规格相链接。
- 将需求与满足它们的模块相链接。
- 将需求与验证它们的测试相链接。
3. 确保完整性
系统工程中最大的风险之一是存在没有需求的设计，或者有需求却没有设计。ReqD 帮助你进行审计。你可以检查每个需求是否都具有指向某个模块或活动的“满足”关系。
4. 处理变更管理
当需求发生变化时，你需要了解其影响。ReqD 允许你将需求追溯到所有依赖元素。如果性能需求发生变化，你可以看到哪些模块依赖于该性能指标。
集成结构与需求 🔗
当这两个图表协同使用时，SysML 的真正威力才得以显现。它们并非互斥，而是相辅相成。一个健壮的模型通过特定关系将 BDD 和 ReqD 联系起来。
1. 分配
分配是指将需求分配给结构元素的过程。在模型中，这通常通过在需求（在 ReqD 中）与模块（在 BDD 中）之间创建“满足”关系来实现。这验证了结构的存在是为了满足需求。
- 确保每个需求都已分配。
- 确保每个模块都有其目的。
- 使用分配来验证覆盖范围。
2. 结构的细化
当你在 BDD 中分解一个模块时，你也应该在 ReqD 中分解相应的需求。这能确保结构与意图保持一致。如果你将一个模块拆分为两个，就必须确保需求也被正确拆分或分配到新部分。
3. 参数传播
模块上的属性可以与需求中的参数相链接。这使得你可以从需求约束中驱动设计值。例如，ReqD 中的重量限制可以传播到 BDD 中模块的质量属性上。
常见的建模陷阱 ⚠️
即使经验丰富的建模者在区分这些图表时也可能出错。识别常见错误有助于保持模型的完整性。
1. 混淆逻辑与结构
一个常见错误是将需求放在模块定义图中。需求是逻辑实体，而不是结构部分。将它们放在 BDD 中会混淆“是什么”与“怎么做”。应将它们保留在 ReqD 中。
- 不要将需求视为一个模块。
- 不要将需求放入组合关系中。
- 保持结构层次与需求层次的分离。
2. 需求图过于复杂
由于需求图关注的是逻辑，很容易变成错综复杂的线条网络。避免为整个系统创建单一的、庞大的需求图。相反，应为不同的领域或子系统使用多个图表。
- 将相关的需求归为一组。
- 使用细化来创建子图。
- 关注可追溯性，而不仅仅是罗列文本。
3. 忽视满足关系
许多模型列出了需求和模块，但未能将它们关联起来。如果没有“满足”关系，就无法证明系统满足了需求。这会在设计与验证之间造成脱节。
- 始终将需求与模块关联。
- 尽可能确保链接是双向的。
- 在评审过程中审核这些链接。
4. 用BDD表示功能流程
虽然BDD展示的是连接关系，但并不用于表示顺序或控制流。为此，应使用活动图或顺序图。使用BDD来展示系统随时间的运行方式，会造成静态行为与动态行为之间的混淆。
有效建模的最佳实践 ✅
为确保您的SysML模型具有鲁棒性和实用性，请遵循以下管理需求和模块的指导原则。
- 保持一致性： 如果您在BDD中更改了模块名称，请确保引用它的需求也相应更新。一致性是实现自动化分析的关键。
- 命名规范： 采用严格的命名规范。对于模块，使用物理名称（例如：“液压泵”）；对于需求，使用逻辑名称（例如：“保持压力 > 100 psi”）。
- 分层： 不要在同一张图上混合使用高层次和低层次的细节。为架构创建顶层BDD，为子系统创建详细BDD。需求也应如此处理。
- 使用配置文件： 如果您的组织有特定标准，请将其定义为配置文件。这可以确保模块和需求遵循公司级标准，而不会使核心模型变得杂乱。
- 定期审计： 定期执行可追溯性检查。确保满足的需求比例较高，并且没有孤立的模块。
战略选择总结 📝
在需求图与模块定义图之间进行选择，取决于您要回答的具体工程问题。BDD回答的是关于组成、接口和物理结构的问题。它是系统身体的地图。
需求图回答的是意图、合规性和验证方面的问题。它是系统使命的地图。通过理解两者的独特优势，您可以构建既结构稳固又关键任务导向的模型。
有效的系统工程需要平衡。您需要结构来维持系统的整体性，也需要需求来确保系统正常运行。两者单独都不足以胜任。当正确使用时，BDD和ReqD相辅相成，确保复杂系统按时且符合规范地交付。
在继续您的建模旅程时，请记住要保持关注点的分离。使用BDD来表示硬件和软件架构，使用ReqD来表示逻辑和需求。这种关注点的分离将降低复杂性，并提高模型的可靠性。
通过遵循这些实践，您可以确保您的SysML模型始终保持清晰、可维护，并成为工程团队的宝贵资产。选择非常明确：为构建而设计结构，为目的而定义需求。