我正在寻找一个用例图的理想示例，它可以解释大多数棘手的地方，并成为新用例图的一个很好的模型。
它必须具有以下内容：
- 抽象用例
- 具体用例
- “扩展”关系
- “包括”关系
- 连接抽象用例和具体用例的“继承”关系
- 至少有两个具体的参与者
- 抽象的演员
当然应该是
- 语法正确（符合 UML 2.x）
- 语义正确
- 综合的
- 不太复杂
我搜索了自己，没有找到任何包含所有内容的好例子。
可能有人有这样的例子并且可以分享它。先感谢您！
问问题
6573 次
2 回答
5
VISA付款：
- 抽象用例 - “用户可以支付海湾签证”
- 具体用例 - “用户可以从超市终端付款”
- “扩展”关系 - “银行终端具有扩展功能（如结果余额打印）”
- “包括”关系 - “支付包括授权用例”
- “继承”连接抽象和具体用例的关系——它更复杂。但是想象一下 2 方支付（当 2 个用户应该在交易完成之前存入钱）。
- 至少有两个具体的参与者——让我们回顾一下用例“查看余额历史”。抽象
permitted user可以看到历史，具体permitted user是一个system-admin和card-holder
更新
“扩展” - 实际上有两个 UC：（1）“用户可以通过签证支付”（2）“通过签证支付并打印余额”。
“继承”-让我澄清一下这个UC：继承与扩展非常相似，当“继承”改变系统处理方式时，“扩展”引入一些新活动几乎没有区别。在我的示例中，我们仍然需要通过 VISA 付款，但要确认交易，这笔付款应由 2 个参与者完成。一次付款，她/他的钱被暂时冻结，第二次付款，她/他的钱确认全部付款。但从卖家的角度来看，这个用例可以看作是简单的支付操作。所以我们不会改变服务的价值（与用户角度的“扩展”相比），而是改变交易完成的标准。
例如 - 抽象或具体用例是否应该包括“授权”用例
非常好的问题。摘要可能以两种方式包含“授权”：
如果您确定只有一种可能的授权方式 - 那么抽象应该包括。
如果有不止一种授权方式 - 那么您需要提供具有所有可能继承的抽象用例“授权”。所以抽象的UC会“包含”抽象的“授权”。
我没有看到任何
于 2012-04-23T15:56:43.770 回答
2
于 2012-04-24T03:18:15.257 回答