UML用例/序列图创建

Question

我必须为我的一个作业创建一个用例和序列图。这是描述：

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

自动加油泵允许客户使用信用卡，借记卡和现金 购买天然气。不使用时，泵显示有关每日特价的信息 销售。要使用泵，客户应指明付款方式。如果选择现金 客户等到售货员启动泵。如果是信用卡或借记卡 使用时，客户通过连接到泵的读卡器刷卡。在这种情况下 借记卡输入一个密码。信用卡/借记卡已通过验证 与信用公司计算机通信并激活泵。该 然后客户选择气体类型，从泵中取出“泵喷嘴” 通过抽气来购买天然气。客户通过替换来结束交易 “泵喷嘴”回到泵中。如果客户使用信用卡/借记卡 帐户收取的燃料费用，客户可以选择打印收据 交易结束。如果需要现金支付，则泵保持闲置状态直到 售货员收到客户的付款并将泵重置为空闲状态。 每日电台经理更新每个等级天然气的定价信息。此外，在 每天结束的信用卡交易都会发送到信用卡公司 付款。

对于Use Case Diagram我觉得它是对的，只是真的在寻找反馈。

UML图片：

Use Case Diagram

Sequence Diagram

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

我觉得我错过了一个GasPump控制器实体，或者它只是现在的状态还好吗？车辆真的有必要吗？

Answer 1

用例图

1. ＆＃34;付款＆＃34;，＆＃34;气体类型＆＃34;，＆＃34;结束日期摘要＆＃34;用例不是专有名称。 ＆＃34;更新价格信息＆＃34;是
2. 所有＆＃34;包括＆＃34;实际上是＆＃34;延伸＆＃34; （如果我理解用例的实际含义）。因为它们是可选的。
3. 场景如＆＃34;付款＆＃34;，＆＃34;结束交易＆＃34;看起来他们是独立的。事实并非如此，它们包含在＆＃34;购买燃气＆＃34;中。 （我相信＆＃39;结束交易＆＃39;只是在那里迈出的一步，最好重新命名为反映实际行动的东西，比如＆＃34;替换喷嘴＆＃34;。）
4. ＆＃34;信用卡公司电脑＆＃34;对演员来说不是一个好名字。用例是技术中立的，actor是一个角色，而不是枚举。只是＆＃34;信用卡公司＆＃34;。
5. ＆＃34;验证卡＆＃34;场景丢失了。我将它包括在内并且＆＃34;激活泵＆＃34;在＆＃34;证明偿付能力＆＃34;。
的情况下
6. 没有必要为借记卡和信用卡设置单独的方案，因为它不会影响用例中的任何内容。
7. ＆＃34;计算总金额等情景＆＃34;通常会隐藏很多惊喜和业务规则，最好有它。

  

我觉得自己错过了一个GasPump控制器实体，或者它现在的状态如何，还不错？

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

  

车辆真的有必要吗？

只有它实际上有所作为，即它是演员。