UML 使用 Case/Sequence 图创建
UML Use Case/Sequence Diagram Creation
我必须为我的一项作业创建用例和序列图。这是描述:
考虑以下自动气泵系统的描述。
自动加油泵允许客户使用信用卡、借记卡和现金来
购买天然气。不使用时,泵会显示有关每日特价和
销售量。要使用泵,客户需指定付款方式。如果现金是 selected
顾客一直等到售货员启动水泵。如果信用卡或借记卡是
使用后,客户通过连接到泵的 reader 刷卡。在这种情况下
输入借记卡的密码。 credit/debit 卡片由以下人员验证
与信贷公司的计算机通信,泵被激活。这
客户然后 selects 气体类型,从泵中取出 "pump nozzle" 并
通过抽气购买天然气。客户通过更换
"pump nozzle" 回泵。如果使用了客户的 credit/debit 卡
帐户被收取燃料费用,客户可以select打印收据
交易结束。如果需要现金支付,泵将保持闲置状态直到
售货员收到客户的付款并将泵重置为空闲状态。
加油站经理每天更新每个等级天然气的定价信息。此外,在
每天结束时将信用卡交易发送给信用卡公司
付款。
Use Case Diagram我觉得是对的,真的只是在寻求反馈。
UML 图片:
Use Case Diagram
Sequence Diagram
对于序列图,场景是:"Purchase gas with a Credit Card"
我觉得我缺少一个 GasPump 控制器实体,或者现在就这样就好了吗?还有车辆真的有必要吗?
用例图
- "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" 不是演员的好名字。用例是 technology-neutral 并且 actor 是一个角色,而不是集合枚举。就 "Credit card company".
- "Validate card" 场景缺失。我会将它和 "Activate pump" 包括在 "Prove solvency".
这样的场景中
- 不需要为借记卡和信用卡设置单独的场景,因为它不会影响用例中的任何内容。
- 像"Calculate total amount"这样的场景通常隐藏着很多惊喜和商业规则,最好有它。
I feel like i'm missing a GasPump controller entity or is it fine with just having how it is now?
这取决于你想要描绘的层次。在你的情况下,它似乎是 user-goal 级别,你不需要控制器。
Also is the vehicle really necessary?
只有当它真的做了某事时,即如果它是一个演员。
我必须为我的一项作业创建用例和序列图。这是描述:
考虑以下自动气泵系统的描述。
自动加油泵允许客户使用信用卡、借记卡和现金来 购买天然气。不使用时,泵会显示有关每日特价和 销售量。要使用泵,客户需指定付款方式。如果现金是 selected 顾客一直等到售货员启动水泵。如果信用卡或借记卡是 使用后,客户通过连接到泵的 reader 刷卡。在这种情况下 输入借记卡的密码。 credit/debit 卡片由以下人员验证 与信贷公司的计算机通信,泵被激活。这 客户然后 selects 气体类型,从泵中取出 "pump nozzle" 并 通过抽气购买天然气。客户通过更换 "pump nozzle" 回泵。如果使用了客户的 credit/debit 卡 帐户被收取燃料费用,客户可以select打印收据 交易结束。如果需要现金支付,泵将保持闲置状态直到 售货员收到客户的付款并将泵重置为空闲状态。 加油站经理每天更新每个等级天然气的定价信息。此外,在 每天结束时将信用卡交易发送给信用卡公司 付款。
Use Case Diagram我觉得是对的,真的只是在寻求反馈。
UML 图片:
Use Case Diagram
Sequence Diagram
对于序列图,场景是:"Purchase gas with a Credit Card"
我觉得我缺少一个 GasPump 控制器实体,或者现在就这样就好了吗?还有车辆真的有必要吗?
用例图
- "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" 不是演员的好名字。用例是 technology-neutral 并且 actor 是一个角色,而不是集合枚举。就 "Credit card company".
- "Validate card" 场景缺失。我会将它和 "Activate pump" 包括在 "Prove solvency". 这样的场景中
- 不需要为借记卡和信用卡设置单独的场景,因为它不会影响用例中的任何内容。
- 像"Calculate total amount"这样的场景通常隐藏着很多惊喜和商业规则,最好有它。
I feel like i'm missing a GasPump controller entity or is it fine with just having how it is now?
这取决于你想要描绘的层次。在你的情况下,它似乎是 user-goal 级别,你不需要控制器。
Also is the vehicle really necessary?
只有当它真的做了某事时,即如果它是一个演员。