我必须为我的一个作业创建一个用例和序列图 . 这是描述：
请考虑以下对自动气泵系统的描述 .
自动加油泵允许客户使用信用卡，借记卡和现金购买天然气 . 不使用时，泵显示有关每日特价和销售的信息 . 要使用泵，客户应指明付款方式 . 如果选择现金，则客户等待直到售货员激活泵 . 如果使用信用卡或借记卡，客户通过连接到泵的读卡器刷卡 . 在借记卡的情况下，输入密码 . 信用卡/借记卡通过与信用公司计算机的通信进行验证，并且泵被激活 . 然后，客户选择气体类型，从泵中移除“泵喷嘴”并通过泵送气体来购买气体 . 客户通过将“泵喷嘴”更换回泵来结束交易 . 如果使用信用卡/借记卡，则客户的帐户将收取所用燃料的费用，客户可以选择打印收据并且交易结束 . 如果需要现金支付，则泵保持空闲状态，直到售货员收到客户的付款并将泵重置为空闲状态 . 每日电台经理更新每个等级天然气的定价信息 . 此外，在每天结束时，信用卡交易被发送到信用卡公司进行支付 .
对于用例图，我觉得它是对的，只是真的在寻找反馈 .
UML图片：
对于序列图，场景是：“使用信用卡购买天然气”
我觉得我错过了一个GasPump控制器实体，或者它现在的状态如何？车辆真的有必要吗？
1 回答
用例图
"Payment"，"Gas type"，"End of day summary"不是用例的专有名称 . "Update price information"是 .
所有"include"实际上是"extend"（如果我理解用例的实际含义） . 因为它们是可选的 .
像"Payment"，"End transaction"这样的场景看起来像是独立的 . 这不是真的，它们包含在"Purchase gas"中 . （我相信'end transaction'只是在那里迈出的一步，最好更名为反映真实行动的东西，如"Replace nozzle" . ）
"Credit card companies computer"对于演员来说不是一个好名字 . 用例是技术中立的，actor是一个角色，而不是枚举 . 只是"Credit card company" .
缺少
"Validate card"方案 . 我会在"Prove solvency"这样的场景中包含它和"Activate pump" .
没有必要为借记卡和信用卡设置单独的方案，因为它不会影响用例中的任何内容 .
像"Calculate total amount"这样的场景通常会隐藏很多惊喜和业务规则，更好地拥有它 .
这取决于您想要描绘的级别 . 在您的情况下，它似乎是用户目标级别，您不需要控制器 .
只有它确实有所作为，即它是演员 .