UML用例/序列图创建

我必须为我的一项任务创建一个用例和序列图。以下是描述：

考虑以下自动气体泵系统的说明

自动加油泵允许客户使用信用卡、借记卡和现金进行加油 买汽油。不使用时，泵会显示有关每日特价商品和服务的信息 出售。使用泵时，客户应指明付款方式。如果选择“现金” 客户等待售货员启动泵。如果使用信用卡或借记卡 使用时，客户通过连接到泵的读卡器刷卡。在这种情况下 对于借记卡，输入pin码。信用卡/借记卡由 与信贷公司计算机通信，泵启动。这个 然后，客户选择气体类型，从泵上取下“泵喷嘴”，然后 通过泵送天然气来购买天然气。客户通过更换 “泵喷嘴”回到泵中。如果使用了信用卡/借记卡，客户的 账户收取燃油费，客户可以选择打印收据 交易结束。如果需要现金支付，泵将保持闲置状态，直到 售货员收到客户的付款并将泵重置为空闲状态。 每天，加油站经理更新每种等级天然气的定价信息。另外，在 每天结束时，信用卡交易被发送到信用卡公司进行处理 付款

对于用例图，我觉得它是正确的，只是在寻找反馈

UML图像：

对于序列图，场景是：“使用信用卡购买天然气”

我觉得我缺少了一个GasPump控制器实体，或者只是拥有它现在的样子还可以吗？此外，车辆真的有必要吗？

用于用例图

“付款”、“气体类型”、“日终总结”不是用例的专有名称。“更新价格信息”为

所有的“include”实际上都是“extend”（如果我正确理解用例的实际含义）。因为它们是可选的

像“支付”、“结束交易”这样的场景看起来是独立的。事实并非如此，它们包含在“购买天然气”中。（我认为“结束交易”只是其中的一步，最好改名为反映实际行动的内容，如“更换喷嘴”。）

“信用卡公司电脑”对这个演员来说不是个好名字。用例是技术中立的，参与者是角色，而不是集合枚举。只是“信用卡公司”

缺少“验证卡”方案。我会在“证明偿付能力”这样的场景中包括它和“启动泵”

借记卡和信用卡不需要有单独的场景，因为它不会影响用例中的任何内容

像“计算总金额”这样的场景通常隐藏了很多惊喜和业务规则，最好有它

我觉得我缺少了一个GasPump控制器实体，或者只是拥有它现在的样子还可以吗

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

还有车辆真的有必要吗

---

只有当它真的做了什么，例如，如果它是一个演员

谢谢大家!！所以这辆车不算是演员，是吗？或者是因为它和气体泵相互作用@Vladt车辆不相互作用，这是关键。此外，它可以是一辆油罐车，而不是一辆汽车。