UML用例/序列图的创建

Question

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

请考虑以下对自动气体泵系统的描述。

自动燃气泵允许客户使用信用卡、借记卡和现金购买汽油。当不使用时，泵会显示每日特价和销售的信息。使用泵时，客户指示付款方式。如果选择现金，客户将一直等到售货员启动泵。如果使用信用卡或借记卡，客户可以通过与泵连接的读卡器刷卡。在借记卡的情况下，输入一个引号。信用卡/借记卡通过与信用公司计算机的通信进行验证，泵被激活。然后，客户选择气体类型，从泵中取出“泵喷嘴”，并通过抽气来购买气体。客户将“泵喷嘴”替换回泵，从而结束交易。如果使用了信用卡/借记卡，客户的账户就会被收取燃油费用，客户可以选择打印收据，交易结束。如果需要现金付款，泵将保持闲置状态，直到售货员收到客户的付款并将泵重置为空闲状态。每日加油站经理更新每一等级汽油的价格信息。此外，在每天结束时，信用卡交易被发送到信用卡公司付款。

对于用例图，我觉得它是正确的，只是寻求反馈真的。

UML图像：

用例图

序列图

对于顺序图，场景是：“用信用卡购买煤气”

我觉得我缺少了一个GasPump控制器实体，或者说，现在的情况还好吗？这辆车真的需要吗？

Answer 1

用于用例图

1. “支付”、“气体类型”、“结束日总结”不是用例的正确名称。“更新价格信息”是。
2. 所有的“包括”实际上都是“扩展”(如果我正确理解用例的实际含义)。因为它们是可选的。
3. 像“支付”、“结束交易”这样的场景看起来是独立的。这不是事实，它们包括在“购买气体”中。(我认为‘结束交易’只是一个步骤，最好改名为反映实际行动的东西，比如“更换喷嘴”。)
4. “信用卡公司电脑”不是演员的好名字。用例是技术中立的，参与者是角色，而不是集合枚举。只是“信用卡公司”。
5. 缺少“验证卡”方案。我会把它和“激活泵”包括在“证明偿付能力”这样的场景中。
6. 没有必要对借记卡和信用卡有单独的场景，因为它不会影响用例中的任何东西。
7. 像“计算总金额”这样的场景通常隐藏了很多惊喜和业务规则，最好是拥有它。

我觉得我缺少了一个GasPump控制器实体，或者说，现在的情况还好吗？

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

这辆车真的需要吗？

只有当它真的做了什么，也就是说，如果它是一个演员。