1. SysML建模全景导入

在复杂系统研发中，真正昂贵的错误往往不是代码写错，而是需求理解偏差、接口定义不清、架构决策缺乏依据。SysML（Systems Modeling Language）正是为应对这类问题而生的系统建模语言。它把系统需求、结构、行为、参数约束统一到一套模型里，让工程团队在"画图"之外，获得可追溯、可分析、可验证的系统描述。

SysML的定位与MBSE价值

SysML是一种基于模型的系统工程（MBSE）描述语言。MBSE的核心主张是：用模型取代以文档为中心的传统工程方式，把系统需求、设计、分析、验证信息集中在一个权威模型源中。传统文档方式下，需求写在需求文档里，架构画在另一份图纸里，接口定义散落在接口控制文件中，一旦变更，追踪关系靠人工维护，极易断裂。MBSE则让需求、架构、行为、参数之间建立显式关系，变更影响可以沿模型链路自动传播。

SysML的价值可以概括为三点：表达力——覆盖需求、结构、行为、参数四类系统关注点；可追溯性——需求与设计元素之间可建立满足、验证、派生等关系；可分析性——参数图支持工程计算，行为模型支持仿真验证。对于安全关键、多学科耦合、长生命周期系统，这些能力直接决定研发质量与迭代效率。

SysML与UML的关系

SysML由UML演化而来，但并非UML的简单子集。UML面向软件系统，强调类、对象、用例、交互；SysML面向更广泛的工程系统，包括机械、电子、液压、软件、人员、设施等。SysML复用了UML的部分图，如用例图、活动图、状态机图、序列图，同时新增了需求图、块定义图、内部块图、参数图，并对UML原有图进行了系统化裁剪与扩展。

理解二者关系的关键在于：UML的类（Class）在SysML中对应块（Block），块可以拥有值属性、流属性、操作、约束和端口；UML的关联在SysML中可细化为组合、引用、泛化等关系，并支持项目特有的依赖语义。因此，SysML不是替代UML，而是在系统层级上扩展了UML的表达边界。

需求与架构建模在生命周期中的位置

系统生命周期通常经历概念、需求、架构、详细设计、实现、验证、运维等阶段。SysML建模并非只在某一阶段使用，而是贯穿始终，但不同阶段的建模重心不同。

在需求阶段，建模重点是需求图与用例图。需求图把文本需求组织成层次结构，标注需求之间的包含、派生、细化关系；用例图从外部视角描述系统与参与者之间的交互目标。此阶段的核心问题是"系统要做什么、为谁做、做到什么程度"。

在架构阶段，建模重心转向块定义图与内部块图。块定义图定义系统及其组成部分的类型、属性、操作和关系；内部块图描述块内部各部分之间的连接、端口和流。此阶段回答"系统由哪些部分组成、它们如何连接、接口是什么"。

在详细设计与验证阶段，活动图、状态机图、序列图、参数图发挥作用。活动图描述功能流程与数据流，状态机图描述系统状态迁移，序列图描述组件间消息交互，参数图把工程约束写成可计算方程，支持质量、功耗、成本等参数分析。

需要强调的是，这些模型不是彼此孤立的。需求图中的需求可以通过"满足"关系链接到架构中的块，架构中的块可以通过"分配"关系链接到行为模型中的活动或状态，参数图中的约束可以绑定到块的属性上。这种跨图追溯能力，正是SysML区别于普通绘图工具的关键。

课程项目背景介绍

本课程以一个无人机巡检系统作为贯穿项目。该系统面向电力线路巡检场景，包含飞行平台、云台相机、图传链路、地面站、任务规划软件和运维人员等要素。选择这一项目，是因为它同时具备需求层次丰富、架构多学科耦合、行为状态复杂、参数约束明确等特点，适合完整演练SysML四类建模。

项目的主要需求示例包括：续航时间不低于45分钟（示例指标）、巡检图像分辨率不低于4000×3000像素、图传延迟不高于200毫秒、支持自动返航与失联保护。架构上，飞行平台可分解为机体、动力、飞控、导航、电源等块；地面站可分解为任务规划、图像显示、数据存储等块。行为上，一次巡检任务可建模为"起飞—巡航—拍摄—返航—降落"的活动流程，以及"待机—自检—飞行—故障—返航"的状态迁移。参数上，续航时间与电池容量、整机重量、巡航速度之间存在可计算的约束关系。

学习SysML，工具操作只是表层，真正需要建立的是"用模型思考系统"的习惯：面对一个复杂系统，先问需求边界在哪里，再问架构如何分解与连接，然后问行为如何流转与状态如何迁移，最后问关键参数是否满足约束。这条思维链路，就是本课程希望帮助大家建立的核心能力。