Day07-06｜2.8.4 基于模型的系统工程：用统一模型连接需求、架构与验证

教材定位：系统架构设计师教程（第 2 版）第 2 章“计算机系统基础知识”第 2.8.4 节。

学习目标：理解基于模型的系统工程（MBSE）的基本思想、模型对象、视图和生命周期；掌握模型在需求分析、功能分解、结构设计、行为描述、接口管理、验证确认和变更影响分析中的作用；能够区分模型、文档和代码，并在案例题、论文中说明 MBSE 的收益与实施条件。

一、什么是基于模型的系统工程

传统系统工程大量依赖自然语言文档、表格和分散图纸。文档便于阅读和归档，但不同文档之间容易出现术语不一致、关系遗漏、版本不同步和变更影响难以分析等问题。基于模型的系统工程把模型作为描述系统及其关系的重要主线，用结构化、可追踪、可分析的模型支撑系统全生命周期活动。

MBSE 不是简单地“画更多图”，也不是把 Word 文档换成某种建模工具。它强调以模型承载系统的需求、要素、关系、行为、约束、验证和变更，并通过统一语义和规则减少歧义。文档仍然有价值，但更多作为模型的视图、报告或交付物，而不是唯一事实来源。

二、模型的基本组成

1. 模型元素与关系

模型元素可以是利益相关者、需求、功能、组件、接口、数据、状态、活动、节点、约束、测试用例和风险。关系说明元素之间如何关联，例如需求被功能满足，功能被组件实现，组件通过接口连接，测试用例验证需求，风险影响某项设计决策。

模型的价值主要来自关系，而不仅是元素本身。一个“支付服务”名称的信息有限；如果模型还说明它实现支付授权功能、调用外部支付接口、产生支付事件、受合规约束，并由哪些测试验证，架构师才能进行系统分析。

2. 多视图表达

复杂系统不可能用一张图完整表达。MBSE 通常采用多个视图：需求视图说明目标和约束，场景视图说明用户与系统交互，功能视图说明系统能力，逻辑结构视图说明职责划分，物理或部署视图说明运行位置，接口视图说明连接关系，状态和时序视图说明动态行为，验证视图说明如何证明目标达成。

视图必须保持一致。例如逻辑视图中的组件若没有部署节点，物理视图就无法说明运行位置；需求视图要求低延迟，而行为模型存在长时间同步调用，设计就需要重新权衡。模型一致性检查可以帮助发现这些冲突。

三、MBSE 的核心活动

1. 需求建模

需求模型记录需求的来源、对象、条件、行为、质量指标、优先级和验证方法。自然语言需求可以保留，但关键需求应结构化并可追踪。性能需求要关联负载、场景和测量方法，安全需求要关联资产、威胁和控制措施，接口需求要关联交互双方和版本规则。

需求建模不能把“用户希望快一点”直接变成架构结论，而应继续澄清场景、负载和可接受范围。例如核心查询在 95% 情况下不超过 2 秒，峰值并发 1000，错误率不超过某阈值。这样才能把需求分配给缓存、索引、计算资源和测试环境。

2. 功能与结构建模

功能建模从系统任务出发，逐层分解能力，明确输入输出和约束；结构建模把功能分配到子系统、组件、设备或人工角色。分配关系必须可解释：某个组件为什么承担某功能，是否有重复职责，是否存在未分配功能，某个质量属性由哪些结构共同支撑。

功能和结构不一定一一对应。一个功能可能由多个组件协作完成，一个组件也可能支持多个功能。架构师应识别共享能力和关键依赖，避免因为简单映射造成过度集中或循环依赖。

3. 行为和状态建模

行为模型描述事件、活动、状态、时序和反馈。它特别适合表达订单、支付、设备、审批、任务和故障处理等具有生命周期的对象。状态模型能够明确哪些状态可以转换、谁触发转换、转换失败如何处理、状态是否可逆。

例如订单可以经历待支付、已支付、配货中、已发货、已完成和已取消。支付超时、重复通知、库存不足和人工关闭都可能触发不同路径。若只在接口文档中写“更新订单状态”，容易造成并发覆盖和非法跳转；状态模型可以成为实现、测试和审计的共同依据。

4. 接口与约束建模

接口模型不仅描述字段，还应描述提供方、使用方、方向、协议、时序、频率、错误、超时、安全和版本。对硬件系统，还要描述电气、机械、环境和时钟约束；对分布式系统，还要描述网络分区、重试、幂等和一致性。

约束模型把资源、法规、时间、成本和安全边界显式化。设计方案满足一项需求但违反约束，仍不能认为可行。模型可以帮助分析“如果增加某个节点，成本和能耗是否超标”“如果跨区域同步，延迟和合规是否允许”。

四、模型与验证确认

MBSE 强调从需求开始建立验证关系。每个关键需求都应关联验证方法、测试条件、输入数据、预期结果、责任人和证据位置。这样在设计阶段就可以发现“需求无法验证”或“没有实现责任”的问题。

模型可以支持静态检查、仿真、性能分析、接口一致性检查和测试用例生成，但模型分析不能替代真实系统测试。仿真模型可能简化了网络、用户行为和故障；代码生成可能与手工代码产生差异；真实环境还会出现配置、权限和运维问题。因此应采用模型验证、组件验证、集成验证和真实场景确认相结合的策略。

五、配置、版本与变更影响分析

模型本身也是配置项，需要版本、权限、评审、基线和变更记录。模型版本要能够关联需求版本、架构版本、代码版本、测试版本和部署版本。否则模型很快会变成过时图纸，无法支撑生产问题定位。

变更影响分析是 MBSE 的重要价值。假设某项法规要求把数据保存期从一年改为五年，模型可以沿数据需求找到存储设计、容量模型、备份策略、归档流程、权限、成本和验证用例。假设外部设备协议升级，模型可以找到适配器、消息格式、时序、模拟器、测试和发布窗口。

影响分析不是完全自动的。模型关系必须及时维护，团队要明确谁负责更新，工具要能检查悬空关系和冲突，变更还需要专业判断。自动化工具提高了分析效率，但不能代替架构师对业务影响和风险的判断。

六、实施 MBSE 的常见误区

第一，把 MBSE 等同于购买建模工具。工具只能提供存储、绘图、检查和协作能力，无法自动产生正确模型。组织还需要建模规范、术语字典、角色责任、评审机制和培训。

第二，模型过度追求完整。若把所有实现细节都建模，维护成本会超过收益。应优先建模高风险、高耦合、高变化和需跨团队协作的内容。

第三，只建立静态结构模型。没有行为、状态、接口和验证关系，模型无法解释故障和动态质量属性。系统工程至少要覆盖对当前决策有价值的多种视图。

第四，模型与代码、配置和测试脱节。模型必须进入需求、架构、开发、测试和运维流程，重要变更要触发模型更新或一致性检查。

第五，忽视组织和文化。MBSE 会改变团队协作方式，要求业务、系统、软件、硬件、测试和运维使用共同语义。若只是某个架构师单独维护，项目结束后模型就会失效。

七、案例：无人机巡检系统的 MBSE

某电力企业建设无人机巡检系统，包含飞行器、地面站、通信链路、任务规划、图像处理、缺陷识别和人工复核。系统需要在通信中断、低电量和恶劣天气下保持安全。

需求模型记录巡检目标、飞行区域、通信延迟、续航、安全等级和人工接管条件。功能模型分解任务规划、飞行控制、数据采集、图像处理、告警和归档；结构模型把功能分配给机载设备、地面站、云平台和操作人员；行为模型描述起飞、巡检、返航、降落、失联和低电量状态；接口模型描述飞控、传感器、通信和平台服务之间的协议、时序和故障。

验证模型把失联返航、低电量降落、图片完整性、告警时限和权限控制关联到仿真、现场测试和演练。若通信协议变化，可以分析机载软件、地面站、模拟器和测试用例的影响。模型不代替飞行试验，但可以在试验前暴露状态遗漏和接口冲突，减少现场风险。

八、练习与详细答案

1. MBSE 与单纯画架构图有什么区别？
2. 为什么模型中的关系比单个元素更重要？
3. MBSE 如何帮助变更影响分析？
4. 模型验证能否完全替代真实测试？
5. 实施 MBSE 需要哪些组织条件？

答案：1. MBSE 以模型作为跨生命周期的结构化信息载体，强调语义、关系、追踪、分析和验证，架构图只是某个模型视图；2. 关系表达需求、功能、组件、接口和验证之间的逻辑，决定模型能否支持分析和追踪；3. 通过沿模型关系找到受影响的需求、组件、数据、接口、测试和部署，减少遗漏；4. 不能，模型可能简化真实环境，必须结合组件、集成、现场和运行验证；5. 需要统一术语和建模规范、角色责任、工具与权限、评审基线、培训、模型维护流程以及与开发测试运维的集成。

案例题：某项目维护了大量架构图，但接口升级后多个团队仍按旧字段开发。如何使用 MBSE 改进？

参考答案：现有图纸是静态文档，缺少接口元素、版本、提供方和使用方关系，也没有与需求、代码和测试追踪。应建立统一接口模型和数据字典，明确字段语义、方向、时序、错误、版本兼容和安全约束；将接口与实现组件、契约测试、模拟器和部署版本关联；以接口基线控制变更，升级时进行影响分析、兼容窗口和灰度验证；通过模型一致性检查和自动生成接口文档减少人工同步错误。

九、论文素材与复盘

论文中写 MBSE 时，应避免只写“使用建模工具”。可以说明项目跨硬件、软件和外部设备，传统文档存在术语不一致和变更遗漏，因此建立需求、功能、结构、行为、接口和验证模型；通过需求追踪、状态建模、接口基线和变更影响分析控制复杂度；再用仿真、契约测试、集成测试和现场演练验证模型与实际系统的一致性。

今日核心记忆句：MBSE 不是多画图，而是用统一模型表达元素和关系；模型要连接需求、功能、结构、行为、接口、部署和验证；关系和追踪使变更可分析；模型能提前发现问题，但不能替代真实测试；工具之外还需要规范、基线、责任和组织协同。