模块 4：建模方法
"仅仅拥有一门语言"为什么不够 — 视角、视图、模型组织，以及主要 MBSE 框架的预览。
仅有语言远远不够
在模块 3 中，我们探讨了 MBSE 的第一根支柱 — 建模语言。你现在了解了 SysML、UML 和领域专用语言所提供的：描述系统的词汇和语法。但拥有一门语言就像拥有一本词典 — 你仍然需要语法规则、文章结构和写作流程才能写出一篇连贯的文章。
拥有一架钢琴并不能让你成为钢琴家。你还需要一套方法 — 练习计划、乐理知识、音阶练习，以及学习曲目的结构化方式。没有方法，两个拥有同一架钢琴的人会弹出截然不同（甚至互不兼容）的音乐。MBSE 也是如此：语言是钢琴；方法是让音乐和谐统一的纪律。
如果没有统一的建模方法，使用同一种语言的不同工程师将产生不一致、不兼容的模型。一位工程师可能从需求开始建模，另一位从结构开始，第三位从行为开始 — 最终的模型将无法拼合在一起。方法提供的纪律能够将各个工程师的独立建模工作整合为一个连贯的系统描述。
没有方法会出什么问题？
- 结构不一致：各团队以不同方式组织模型，导致集成困难重重。
- 视角缺失：由于没有人规定应该创建哪些视角，重要的利益相关方视角被忽略。
- 重复劳动：工程师不知道已有哪些模型、如何复用，导致大量重复工作。
- 可追溯性断裂：如果模型元素之间没有规定的关系，从需求到设计再到验证的追溯就无从谈起。
什么是建模方法？
建模方法是一套规定好的建模活动序列、需要创建的视角和视图，以及组织和关联模型元素的规则。它回答三个根本性问题：
- 我需要创建哪些模型？ — 需要哪些图表、视图和工件？
- 按什么顺序？ — 哪些建模活动先做，哪些依赖于前置输出？
- 它们如何关联？ — 模型元素如何在不同视图之间进行追溯和链接？
一个定义良好的方法提供了一个可重复的过程，任何具备资质的工程师都可以遵循它来创建一致且完整的系统模型。它弥合了"拥有一门语言"（符号体系）和"拥有一个可用的、连贯的模型"（最终成果）之间的鸿沟。
ISO 42010（正式名称 ISO/IEC/IEEE 42010:2022）是架构描述的国际标准。它定义了架构框架、视角（viewpoint）、视图（view）和模型种类（model kind）等概念 — 为如何记录系统架构提供了严格的术语体系。大多数 MBSE 方法都与 ISO 42010 的概念保持一致，即使它们没有明确引用该标准。
建模方法的组成要素
- 视角定义：需要哪些系统视角（功能、结构、行为等）。
- 视图规范：每个视图包含什么内容、使用什么符号、服务什么目的。
- 过程步骤：活动的先后顺序 — 例如，"首先捕获利益相关方需求，然后定义用例，再将功能分配到结构"。
- 模型组织规则：包（package）、命名空间和目录应该如何组织。
- 一致性规则：如何确保在一个视图中定义的元素在另一个视图中被正确引用。
视角与视图
一个复杂系统无法从单一视角被完整理解。不同的利益相关方关心不同的方面：客户关心功能，安全工程师关心隐患，制造团队关心物理结构。视角（viewpoint）和视图（view）提供了一种有纪律的方式来呈现同一系统的多个视角。
想象一栋建筑。它有平面图（结构视图）、电气图（电气视图）和疏散路线图（安全视图）。这三者描述的是同一栋建筑，但来自不同的利益相关方视角。建筑师看平面图，电气工程师看电气布线图，消防部门看疏散路线。没有任何一张图能讲述全部故事 — 但它们合在一起就提供了完整的画面。
ISO 42010 核心概念
ISO 42010 为架构描述定义了精确的术语：
- 架构框架（Architecture Framework）：在特定领域或社区中，用于架构描述的一组协调的视角、约定和实践。
- 视角（Viewpoint）：用于构建和解释特定类型视图的约定规范。它规定了建什么模型以及如何建。
- 视图（View）：从特定视角对系统的具体表述。它是视角规范的一个实例。
- 模型种类（Model Kind）：视图中特定类型模型的约定（例如，"一张 SysML 模块定义图"就是一种模型种类）。
利益相关方驱动的视角
视角的选择应由利益相关方的关注点驱动。下表说明了不同的利益相关方如何产生不同的视角：
| 利益相关方 | 关注点 | 视角 | 示例视图 |
|---|---|---|---|
| 客户 | 系统做什么？ | 功能视角 | 用例图、运行场景 |
| 系统架构师 | 系统如何组织？ | 结构视角 | 模块定义图、内部模块图 |
| 安全工程师 | 可能出什么问题？ | 安全视角 | 故障树、危害分析视图 |
| 软件开发者 | 需要实现什么行为？ | 行为视角 | 状态机、活动图 |
| 测试工程师 | 如何验证系统？ | 验证视角 | 测试用例矩阵、需求追溯 |
| 项目经理 | 进度和成本如何？ | 项目视角 | 工作分解结构、里程碑视图 |
一个好的建模方法会规定哪些视角是必须的、哪些是可选的，以及不同视角的视图之间如何通过可追溯性进行关联。
主要 MBSE 框架 — 预览
在过去二十年中，涌现了多个 MBSE 框架（方法），每个框架都有不同的理念、来源和侧重点。本节提供简要概述 — 模块 6、7 和 8 将分别深入探讨 OOSEM、MagicGrid 和 IBM Harmony。
OOSEM（面向对象系统工程方法）
由 INCOSE 开发，OOSEM 遵循自顶向下的方法：利益相关方需求 → 用例 → 逻辑架构 → 物理架构。原则上它不依赖特定语言，但与 SysML 紧密关联。OOSEM 强调需求可追溯性和迭代精化。
MagicGrid
由 No Magic（现为 Dassault Systèmes）创建，MagicGrid 将建模组织为一个矩阵：行（问题域、解决方案域、实现域）和列（需求、结构、行为、参数）。它的优势在于提供清晰的可视化路线图，告诉工程师下一步该填写矩阵的哪个单元格。
IBM Harmony
IBM Rational 开发的一种用例驱动、以架构为中心的方法。Harmony 非常重视行为建模 — 状态机和活动图是其核心。它在每次迭代中遵循"规约 → 设计 → 验证"的循环。
UAF（统一架构框架）
专为国防和企业架构设计，UAF 提供了一套全面的视角，涵盖战略、运营、服务和资源等层面。它比上述方法更加复杂，通常用于大型政府和军事项目。
CESAM（CESAMES 系统架构方法）
由法国 CESAMES 研究所开发，CESAM 聚焦于系统架构，强调运营、功能和构造视角。在法国航空航天和交通运输行业尤为流行。
| 框架 | 来源 | 主要侧重 | 语言依赖性 | 复杂度 |
|---|---|---|---|---|
| OOSEM | INCOSE | 需求驱动、自顶向下分解 | 语言无关（常用 SysML） | 中等 |
| MagicGrid | No Magic / Dassault | 基于矩阵的模型组织 | SysML（紧耦合） | 中等 |
| IBM Harmony | IBM Rational | 用例驱动、以行为为中心 | SysML / UML | 中高 |
| UAF | OMG / NATO | 企业与国防架构 | UAF Profile（SysML/UML） | 高 |
| CESAM | CESAMES（法国） | 系统架构、运营视角 | 语言无关 | 中等 |
没有哪个框架是"最好的"。正确的选择取决于你的领域（航空航天、汽车、国防）、你的组织成熟度以及你所采用的建模语言。许多组织会对框架进行裁剪和定制，而非照搬。从最适合你当前场景的框架开始，然后逐步演进。
方法-语言-工具对齐
MBSE 的三根支柱 — 语言、方法和工具 — 必须协调一致。每根支柱各有其独特的作用：
- 方法规定建什么模型以及建模的顺序。
- 语言提供表达模型的构造元素（关键字、图表、语义）。
- 工具提供创建、存储、浏览和分析模型的环境。
当三者对齐时，工程师可以按照方法规定的步骤，使用语言的构造元素来表达每一步，并利用工具高效地创建和管理产出的工件。当三者不对齐时，结果就是浪费精力、变通方案和挫败感。
良好对齐的例子
- MagicGrid + SysML + Cameo Systems Modeler：方法专为 SysML 设计，工具原生支持 MagicGrid 模板。
- OOSEM + SysML v2 + Eclipse SysML v2 Pilot：OOSEM 的流程自然映射到 SysML v2 构造，试验工具支持文本记法。
不对齐的例子
- 方法要求进行参数分析，但工具不支持约束块。
- 方法要求追溯矩阵，但语言没有正式的追溯关系。
- 工具支持丰富的行为建模，但方法从未规定行为视图。
常见的不对齐场景：
1. 工具过于强大，但没有方法：团队购买了昂贵的 MBSE 工具，却没有统一的方法。工程师们随意创建模型，毫无一致性 — 工具沦为高级画图软件。
2. 方法-语言不匹配：方法要求创建的视图是所选语言无法表达的（例如，要求用没有参数建模能力的语言进行成本建模）。
3. 工具锁定：方法与某一工具的专有特性深度绑定，以至于更换工具就意味着放弃整套方法。
在启动 MBSE 采纳计划之前，请务必验证你的方法、语言和工具是否构成一个协调的三位一体。