通过VISA付款：
- 摘要用例 - “用户可以通过 VISA 付款”
- 具体用例 - “用户可以从超市终端付款”
- “扩展”关系 - “银行终端具有扩展功能（如结果余额打印）”
- “包含”关系 - “付款包含授权用例”
- 连接抽象和具体用例的“继承”关系 - 它更复杂。但想象一下 2 方支付（当 2 个用户应该在交易完成之前存钱时）。
- 至少有两个具体参与者 - 让我们回顾一下用例“查看余额历史记录”。抽象
permitted user可以看到历史，具体permitted user是一个system-admin和card-holder
更新
“扩展” - 实际上有两个 UC：（1）“用户可以通过签证付款”（2）“通过签证付款并打印余额”。
“继承” - 让我澄清一下这个UC：继承与扩展非常相似，几乎没有什么区别，当“继承”改变系统处理方式时，“扩展”引入了一些新的活动。在我的示例中，我们仍然需要通过 VISA 付款，但为了确认交易，此付款应由 2 个参与者完成。第一个付款，她/他的钱被暂时冻结，第二个付款，她/他的钱确认全部付款。但从卖家的角度来看，这个用例可以看作是简单的支付操作。所以我们不改变服务的价值（与从用户角度的“扩展”相比），而是改变交易完成的标准。
例如 - 抽象或具体用例是否应包括“授权”用例
非常好的问题。摘要可以通过两种方式包含“授权”：
如果您确定只有一种可能的授权方式 - 那么摘要应该包括。
如果有不止一种授权方式 - 那么您需要提供具有所有可能继承的抽象用例“授权”。所以摘要UC将“包含”摘要“授权”。
我没有看到任何
