4. 用例与系统上下文建模

在系统工程中，用例建模解决的核心问题是：谁在使用系统、系统为谁提供什么可观察的价值、系统的边界在哪里。它不描述系统内部如何实现，而是从外部视角锁定系统职责。对于 IBM Rhapsody 而言，用例图是需求工程的起点，也是后续状态图、活动图和序列图的输入来源。本节围绕用例图、参与者与系统边界、用例描述与场景、上下文图以及用例与需求追溯五个方面展开，重点说明在 Rhapsody 中如何落地这些概念。

一、用例图：外部视角的职责契约

用例图由参与者（Actor）、用例（Use Case）、系统边界（System Boundary）以及它们之间的关系构成。参与者是位于系统外部、与系统交互的角色，可以是人、外部系统、定时器或环境；用例是系统对外提供的一组可观察行为，通常以“动词+名词”命名，例如“启动巡航”“采集温度”“下发控制指令”。

用例之间的关系主要有三种：关联表示参与者与用例之间的通信；包含（include）表示一个用例必然复用另一个用例的行为，例如“执行自检”包含“读取传感器状态”；扩展（extend）表示在特定条件下才插入的附加行为，例如“处理告警”在“温度超限”时扩展“触发降温”。在 Rhapsody 中，这些关系通过用例图中的连线类型直接表达，并在浏览器中形成可追溯的模型元素。

二、参与者与系统边界：先划清“内外”

系统边界是本节最容易被忽视却最关键的概念。边界之内是系统要负责实现的部分，边界之外是系统需要交互但不负责实现的部分。划错边界会导致需求蔓延或职责缺失。判断方法很直接：如果一个对象的行为需要由本项目实现，它就在边界内；如果它由外部提供、系统只能与其交互，它就在边界外。

参与者识别可以从三个方向入手：直接操作者（如操作员）、被动受益者（如维护人员）、外部系统（如飞控计算机、地面站）。在 Rhapsody 中，参与者通常建模为 Actor 元素，外部系统可以建模为带有构造型的外部类，以便后续在序列图中作为消息端点。系统边界在用例图中用矩形框表示，框内放用例，框外放参与者。

三、用例描述与场景：把“一句话”展开成可验证行为

用例图只给出骨架，真正承载需求细节的是用例描述。一个完整的用例描述通常包含：用例名称、参与者、前置条件、后置条件、基本流、备选流、异常流以及非功能约束。基本流描述最典型的成功路径，备选流描述条件分支，异常流描述失败或降级处理。

以“采集环境数据”为例，基本流可以写成：操作员下发采集指令 → 系统校验航线状态 → 系统启动传感器 → 系统按采样周期读取温度、湿度、气压 → 系统打包数据 → 系统回传地面站。备选流可以包括“航线未就绪时拒绝启动”“传感器无响应时切换备用通道”。这些描述在 Rhapsody 中可以直接作为用例的说明属性，也可以关联到需求元素。

场景是用例的一次具体执行实例。同一个用例可以有多个场景，例如正常采集、传感器故障采集、通信中断采集。场景是后续绘制序列图和状态图的重要输入，也是测试用例设计的直接依据。

四、上下文图：把系统放进真实环境

上下文图与用例图互补。用例图强调“谁与系统交互、系统提供什么用例”，上下文图强调“系统与外部实体之间的接口、数据流和约束”。在上下文图中，系统通常画成中心方块，外部实体围绕四周，连线标注接口类型、数据方向、协议或物理介质。

例如无人机巡检系统的上下文图可以标注：与地面站之间是遥测数据下行和指令上行，采用无线链路；与电池管理系统之间是电量状态和告警信号，采用 CAN 总线；与环境之间是风速、温度等物理量输入。这些接口信息会直接影响后续的端口定义和接口建模。

五、用例与需求追溯：让每个需求都有归属

用例与需求追溯的目标是建立双向可追踪关系：每个需求至少被一个用例覆盖，每个用例至少对应一个需求来源。在 Rhapsody 中，可以通过需求元素、追溯关系（Trace）或需求图来实现。常见做法是：在需求库中为每条需求分配唯一标识，例如 REQ-ENV-001“系统应支持每 100 ms 采集一次温度”；然后在用例描述中引用该标识，并在模型浏览器中建立 Trace 链接。

追溯关系建立后，可以做两类检查：覆盖检查——是否存在没有任何用例覆盖的需求；冗余检查——是否存在没有需求来源的用例。这两类检查能有效防止需求遗漏和范围蔓延。下表给出一个简化的追溯示例。

综合来看，用例与上下文建模的产出不是一张图，而是一组相互关联的模型元素：参与者、用例、边界、用例描述、场景、上下文接口和需求追溯关系。它们共同回答了一个问题——系统对外承诺什么、与谁交互、在什么条件下完成、由哪条需求驱动。只有这些关系在 Rhapsody 模型中真正建立起来，后续的行为建模和验证才有可靠的需求基础。