UML用例图-抽奖系统

UML用例图-抽奖系统,uml,use-case,use-case-diagram,Uml,Use Case,Use Case Diagram,在这个用例图中,我试图展示抽奖管理员如何在客户进入抽奖后查看更新的抽奖列表。一旦客户进入抽奖,系统将验证并检查是否存在重复项,如果没有重复项,将更新抽奖列表 下图是我对该场景的尝试,但我不确定它是否正确。你能给我一些建议吗? 编辑:我有几个问题: 1) 如果我使用抽奖系统本身来验证抽奖条目,我将不需要使用用例进行验证,因为抽奖系统不是正确的参与者 2) 但是,如果参与者是抽奖系统的另一名工作人员(他或她在其中手动分拣抽奖),验证用例是否适用 3) 如果是,这是正确的图表来说明(2) 更新条目-

在这个用例图中,我试图展示抽奖管理员如何在客户进入抽奖后查看更新的抽奖列表。一旦客户进入抽奖,系统将验证并检查是否存在重复项,如果没有重复项,将更新抽奖列表

下图是我对该场景的尝试,但我不确定它是否正确。你能给我一些建议吗?

编辑:我有几个问题:

1) 如果我使用抽奖系统本身来验证抽奖条目,我将不需要使用用例进行验证,因为抽奖系统不是正确的参与者

2) 但是,如果参与者是抽奖系统的另一名工作人员(他或她在其中手动分拣抽奖),验证用例是否适用

3) 如果是,这是正确的图表来说明(2)

更新条目-->验证

您的图表有几个错误:

  • 系统从来都不是外部参与者。它在以边界为代表的系统内起作用
  • 因此,
    验证
    不是有效的用例。这是一些内部功能
  • 的工作方式相反(移动指向另一侧的箭头)
  • 这与
    相同
  • 验证
    不是用例的名称。它需要谓词/主语,还可以选择一个宾语
  • 泛化(到
    更新条目
    )对于UCs来说是个坏主意,可能不是您想要在这里显示的内容(那么这里的意图是什么?)
  • 基本上,UCs是为其主要参与者带来的附加值。它们与所涉及的功能无关。试着集中注意力,避免任何倾向于功能分解的事情
编辑

  • 没错
  • 如果有人在那里这样做,你有一个演员和这样一个UC(尽管它应该被正确命名)
  • 这可能是正确的它是否正确取决于所考虑系统的要求(您最终想要实现的目标)

  • 嗨,非常感谢你的解释!你能看一下更新后的帖子吗?关于你的解释,我有几个问题。
    Update entry -- <<includes>> --> Verification