3. 用例建模与系统边界

用例建模是需求工程中最贴近“用户视角”的一环。它不关心系统内部如何实现，只回答三个问题：谁在使用系统、系统为谁提供什么有价值的结果、系统的职责边界在哪里。在 Cameo Systems Modeler 中，用例模型通常放在需求包或独立的 Use Case 包中，通过 Use Case Diagram 表达参与者与用例的关系，通过用例描述（Use Case Description）补充主成功场景与异常流，再通过 «trace»、«derive» 等依赖把用例与需求关联起来，形成从“用户目标”到“系统需求”的可追溯链路。

一、参与者：从角色而非人名出发

参与者（Actor）是系统外部与系统交互的角色，可以是人、外部系统、定时器或设备。识别参与者时，应避免直接写具体人名或岗位名，而应抽象为“扮演该角色的一类用户”。例如“值班调度员”“支付网关”“温度传感器”都是参与者。判断一个对象是否为参与者，关键看它是否位于系统边界之外，并且是否与系统存在交互（发起或接收）。

参与者之间可以存在泛化关系。例如“高级操作员”继承“普通操作员”，前者拥有后者的全部用例访问权限，并额外拥有“配置报警阈值”等用例。在 Cameo 中，用 Generalization 箭头从子参与者指向父参与者即可表达。

二、用例：以可观测结果为单位

用例（Use Case）描述系统为参与者提供的一段完整、有价值的行为。命名建议采用“动词+宾语”的形式，如“提交订单”“查询库存”“生成月度报表”。一个用例应当以“参与者获得可观测结果”为完成标志，而不是以某个内部函数调用结束为标志。

用例之间常见三种关系：

• 包含（«include»）：基础用例必然执行被包含用例。例如“提交订单”必然执行“验证用户身份”。
• 扩展（«extend»）：扩展用例在特定条件下才插入基础用例。例如“提交订单”在库存不足时触发“通知补货”。
• 泛化（Generalization）：子用例继承父用例的行为并可覆盖或扩展。例如“支付”可泛化为“信用卡支付”“余额支付”。

三、系统边界：用矩形框划定职责

系统边界在用例图中表现为一个矩形框，框内是用例，框外是参与者。边界不是装饰，而是职责声明：框内的一切由本系统负责实现，框外的一切由外部承担。边界一旦确定，后续的需求分配、接口定义、测试范围都以此为准。若某用例被放入框内，就意味着系统必须实现它；若某交互被放在框外，则系统只需定义接口而不实现其内部逻辑。

在 Cameo 中，系统边界通常用一个 Package 或 Class 表示，并在用例图中以矩形呈现，用例作为其内部元素排列。参与者放在矩形外部，用关联线（Association）连接到用例。

四、用例描述：把椭圆展开成可执行场景

用例图只给出骨架，真正可验证的内容在用例描述中。一份完整的用例描述至少包含：用例名称、参与者、前置条件、后置条件、主成功场景、扩展/异常流。主成功场景按“参与者动作—系统响应”交替编号，便于评审和测试用例设计。

以“提交订单”为例，可编写如下描述（示例参数为教学假设）：

用例名称：提交订单
参与者：客户（主）、支付网关（辅）
前置条件：客户已登录，购物车非空
后置条件：订单状态为“已受理”，库存预占成功

主成功场景：
1. 客户点击“提交订单”。
2. 系统执行「验证用户身份」。
3. 系统校验购物车商品库存，预占库存。
4. 系统执行「处理支付」，向支付网关发起扣款请求。
5. 支付网关返回扣款成功。
6. 系统生成订单号，状态置为“已受理”，返回受理结果。

扩展流：
3a. 库存不足：系统提示缺货商品，触发「通知补货」，用例结束。
5a. 扣款失败：系统释放预占库存，提示支付失败，用例结束。

注意：扩展流编号“3a”表示在主场景第 3 步之后发生的分支，这种编号方式让评审者能精确定位异常发生的位置。

五、建立用例与需求的追溯关系

用例描述的是“用户要什么”，需求描述的是“系统必须满足什么”。两者之间需要建立可追溯关系，才能在需求变更时快速评估影响范围。在 Cameo 中，常用 «trace» 依赖从用例指向需求，或用 «derive» 表示需求由用例推导而来。

追溯关系应满足三条实践原则：

1. 每个用例至少追溯一条需求，否则该用例可能没有实现价值。
2. 每条功能需求至少被一个用例覆盖，否则该需求可能无法验证。
3. 追溯方向统一：建议从用例指向需求，便于用 Traceability Matrix 反向查询“某需求由哪些用例支撑”。

六、常见误区与检查要点

• 把内部步骤当用例：如“打开数据库连接”不是用例，因为它不产生对参与者有价值的结果。
• 参与者写成具体人名：应抽象为角色，否则人员变动会导致模型失效。
• 边界模糊：若一个用例既包含系统内逻辑又包含外部系统逻辑，应拆分并明确接口。
• 追溯缺失：用例与需求脱节会导致需求变更时无法评估影响。

完成本节建模后，应能回答：系统为哪些角色服务、每个角色能获得什么结果、系统负责什么、不负责什么、每个用例对应哪条需求。这四组答案就是用例建模的交付物，也是后续状态机建模和接口设计的输入。