UML用例/顺序图创建

Question

我必须为我的一项任务创建一个用例和序列图。 说明如下：

考虑以下关于自动气泵系统的描述。

自动化的加油泵允许客户使用信用卡，借记卡和现金购买汽油。 不使用时，泵会显示有关每日特价和销售的信息。 要使用泵，客户需要说明付款方式。 如果选择现金，则客户将等到售货员激活泵。 如果使用信用卡或借记卡，则客户可通过连接到泵的读卡器刷卡。 如果是借记卡，则输入密码。 信用卡/借记卡通过与信贷公司计算机的通信进行验证，然后泵被激活。 然后，客户选择气体类型，从泵上卸下“泵喷嘴”，然后通过泵送气体来购买气体。 客户通过将“泵喷嘴”放回泵中来结束交易。 如果使用了信用卡/借记卡，则向客户的帐户收取所收取的燃料费用，客户可以选择打印收据，交易结束。 如果需要现金付款，则泵将保持闲置状态，直到售货员收到客户的付款并将泵重置为闲置状态为止。 每日站长会更新每种等级的天然气的价格信息。 而且，每天结束时，信用卡交易都会发送到信用卡公司进行付款。

对于用例图，我觉得是对的，只是真正地寻找反馈。

UML图片：

用例图

顺序图

对于“序列图”，场景为：“使用信用卡购买汽油”

我觉得我想念一个GasPump控制器实体，还是现在就好了吗？ 车辆真的有必要吗？

Answer 1

对于用例图

1. “付款”，“气体类型”，“日末摘要”不是用例的专有名称。 是“更新价格信息”。
2. 所有的“ include”实际上都是“ extend”（如果我正确理解了用例的实际含义）。 由于它们是可选的。
3. “付款”，“结束交易”等场景看起来像是独立的。 这是不正确的，它们包含在“购买气体”中。 （我认为“最终交易”只是其中的一步，最好将其重命名为反映实际操作的内容，例如“更换喷嘴”。）
4. “信用卡公司的计算机”不是演员的好名字。 用例是技术中立的，参与者是角色，而不是枚举。 只是“信用卡公司”。
5. 缺少“验证卡”方案。 我会在“证明偿付能力”之类的场景中包括它和“激活泵”。
6. 借记卡和信用卡不需要有单独的方案，因为它在用例中不受影响。
7. 诸如“计算总金额”之类的场景通常会隐藏很多惊喜和业务规则，最好拥有它。

我觉得我想念一个GasPump控制器实体，还是现在就好了吗？

这取决于您要描绘的级别。 在您的情况下，这似乎是用户目标级别，并且您不需要控制器。

车辆真的有必要吗？

仅当它确实做某事，即它是演员时。