4. 用例图与系统边界

在复杂机电系统的SysML建模中，用例图承担着一个非常明确的职责：把“系统”当作一个黑盒，从外部视角说明它应当为谁提供什么服务。它不回答系统内部由哪些机械、电气、控制子系统组成，也不回答信号如何流转，而是先划定系统边界，再识别边界之外的参与者，最后用一组系统级用例描述系统对外承诺的能力。对于机电一体化设备而言，这一步做得好不好，直接决定后续需求分解、接口定义和验证场景是否有一致的出发点。

系统边界是用例图的第一要素。边界不是物理外壳，而是建模者所关注的那一层“待建系统”。例如一台六轴工业机器人，如果本次建模对象是“机器人本体+控制器”，那么示教器、上位MES、安全光栅、末端执行器气源都属于外部；如果建模对象只是“机器人控制器软件”，那么伺服驱动器和本体反而成为外部参与者。因此，在画用例图之前，必须先写清一句边界声明，例如：“本模型的研究对象为机器人控制器，负责轨迹规划、伺服指令输出与安全状态管理；伺服驱动器、示教器、安全回路、上位机均视为外部。”这句话是后续所有参与者识别和用例划分的基准。

参与者（Actor）是边界之外与系统交互的角色，既可以是人，也可以是外部系统、设备或环境。识别参与者时，建议沿三条线索扫描：谁向系统发出指令、谁接收系统输出、谁与系统共享物理量或能量。以数控机床为例，操作员发出加工指令并接收状态显示；CAM系统下发G代码；伺服驱动器接收运动指令并反馈位置；冷却与液压单元接收开关量并反馈压力；电网提供电能。它们都是参与者，但关注点不同。参与者还可以用泛化关系组织，例如“维护工程师”和“操作员”都可泛化为“机床用户”，从而共享一部分用例。

用例是系统级服务，命名应使用“动词+宾语”的形式，并站在系统职责角度描述，而不是描述参与者的动作。例如“加工零件”比“操作员装夹零件”更合适，因为装夹可能属于外部操作。一个复杂机电系统的用例通常可分为几类：运行控制类（启动、停止、模式切换）、任务执行类（执行加工、执行搬运、执行装配）、状态监视类（显示运行状态、上报故障）、参数管理类（标定、配置工艺参数）、安全与维护类（急停、复位、诊断）。这些用例共同构成系统对外承诺的服务集合。

用例之间的关系是细化系统服务的关键。常见关系有三种：关联表示参与者与用例之间的交互；包含（«include»）表示一个用例必然执行另一个用例，例如“执行轨迹运动”必然包含“监视运行状态”；扩展（«extend»）表示在特定条件下才插入的行为，例如“安全急停与复位”可以在“执行轨迹运动”过程中被触发。包含关系用于抽取公共行为，扩展关系用于描述异常或可选路径，二者不能混用。泛化关系则用于用例或参与者的分类，例如“执行搬运”和“执行装配”都可泛化为“执行任务”。

用例本身只是服务目录，真正让服务可验证的是场景（Scenario）。一个用例可以对应多个场景，包括主成功场景和若干备选场景。SysML中通常用活动图、序列图或状态机来细化场景，但用例图阶段至少要建立“用例—场景”的关联清单。以“执行轨迹运动”为例，主成功场景是：操作员通过示教器下发启动指令→控制器校验安全条件→控制器向伺服驱动器输出轨迹指令→伺服驱动器反馈到位→控制器上报完成。备选场景包括：安全门被打开导致暂停、伺服过载触发报警、轨迹点超出软限位。每个场景都应能追溯到具体参与者和系统级输入输出。

下面给出一份可直接用于建模评审的用例—参与者—场景关联表示例，字段按机电系统实际需要设置，不引入无关管理字段。

在建模工具中落地时，建议把每个用例进一步关联到需求条目和验证用例。例如“安全急停与复位”可关联需求“急停触发后100ms内切断伺服使能”，验证场景则记录触发时刻、使能信号下降沿时刻和复位条件。这样，用例图就不再是孤立的功能目录，而是从外部参与者到系统级服务、再到可验证场景的完整链条。对于复杂机电系统，边界一旦变化，参与者、用例和场景都要同步评审，避免出现“边界在控制器、用例却描述整机”的错位。

最后需要强调，用例图的价值在于控制复杂度。复杂机电系统往往有几十个外部接口，如果一开始就陷入内部结构，很容易迷失。用例图用边界把系统包起来，用参与者把外部角色列清楚，用系统级用例把对外服务定义完整，再用场景把每条服务展开成可验证的路径。后续的块定义图、内部块图、活动图和状态机，都可以在此基础上逐步细化，而不会偏离系统对外承诺的职责范围。